디스크 고장은 두 종류다. 정말 예고 없이 오는 것과, 신호를 보냈는데 아무도 보지 않은 것. 그리고 후자가 압도적으로 많다. 디스크는 대개 완전히 멈추기 전에 흔적을 남기는데, 그 흔적을 기록하는 것이 SMART(Self-Monitoring, Analysis and Reporting Technology)다. 문제는 SMART가 “물어보면 보여줄 뿐, 알아서 알려주지는 않는다”는 점이다. 그래서 대부분의 홈서버에서 SMART 데이터는 디스크가 죽고 난 뒤에 처음 열어보게 된다.
수십 개 속성 중, 정작 봐야 할 것은 소수다
smartctl -A를 실행하면 수십 개의 속성이 쏟아진다. 전부 볼 필요는 없다. 디스크 고장과 상관관계가 높다고 알려진 소수의 속성에 집중한다. 대용량 드라이브 통계를 공개해 온 Backblaze는 고장 예측력이 높은 속성으로 재할당·보류·오프라인 정정불가 계열을 꼽는다(Backblaze 드라이브 통계와 SMART).
| 속성(ID) | 의미 | 건강한 값 |
|---|---|---|
| Reallocated_Sector_Ct (5) | 손상돼 예비 영역으로 재할당된 섹터 수 | 0, 그리고 안 늘어남 |
| Current_Pending_Sector (197) | 불안정해서 재할당 대기 중인 섹터 | 0 |
| Offline_Uncorrectable (198) | 읽기/쓰기 모두 실패한 섹터 | 0 |
| UDMA_CRC_Error_Count (199) | 디스크↔호스트 전송 오류 (본체 아님) | 늘지 않으면 OK |
핵심은 절대값보다 추세다. 재할당 섹터가 5인 채로 1년째 그대로면 큰 문제가 아닐 수 있지만, 한 주에 0에서 20으로 늘었다면 그 디스크는 교체를 준비해야 한다. 그래서 한 번 보는 것이 아니라 정기적으로 봐야 의미가 있다.
NVMe는 속성 체계가 다르다
위 속성들은 SATA(HDD·SSD) 기준이다. NVMe SSD는 완전히 다른 지표 체계를 쓴다.
- Percentage Used: 제조사가 보증한 쓰기 수명 대비 소모율. 100%가 보증 한계(넘었다고 즉사하는 건 아니지만 경고선).
- Available Spare: 남은 예비 블록 비율. 이 값이 임계치(보통 10%) 아래로 내려가면 위험.
- Media and Data Integrity Errors: 복구 불가능한 데이터 오류 누적. 0이 아니면 주목.
참고로 이 글을 쓰며 확인한 내 서버 NVMe의 값은 Percentage Used 4%, Available Spare 100%, Media Errors 0, 누적 가동 29,830시간(약 3.4년)이었다. 3년 넘게 돌았는데 수명은 4%만 닳았다는 뜻 — 일반적인 홈서버 쓰기량으로는 NVMe 수명이 병목이 되는 일은 드물다는 게 숫자로 확인된다. 단, Unsafe Shutdowns가 146으로 적지 않았는데, 이는 정전·강제종료로 안전하게 못 꺼진 횟수다. 재부팅 후 자동 복구를 갖춰도 갑작스러운 전원 차단 자체는 줄여야 할 이유가 여기 있다.
USB 뒤의 디스크는 SMART가 반쪽이다
USB 외장 디스크의 함정에서 “장애의 주범은 디스크가 아니라 USB-SATA 브리지”라고 했는데, SMART 관점에서도 이 브리지가 말썽이다. 브리지 칩이 SMART 명령을 온전히 통과시키지 못하는 경우가 흔하다.
- 평범한
smartctl -A /dev/sdX가 안 먹고-d sat(SAT 패스스루) 옵션을 줘야 속성이 나오기도 한다. - 그렇게 해도 디스크 종류에 따라 일부 속성만 노출된다. 실제로 내 USB SSD 한 대는 재할당·오프라인 정정불가 두 항목만 보였고, 나머지는 브리지가 가려버렸다.
- 흥미로운 건 또 다른 USB 디스크(4TB)였다. 본체 건강 지표(재할당·보류·정정불가)는 전부 0인데 UDMA_CRC_Error_Count만 92로 쌓여 있었다. 이 값은 디스크 본체가 아니라 전송 경로(케이블·브리지·커넥터)의 오류 누적이다. “디스크는 멀쩡한데 다리가 문제”라던 그 USB 함정이, SMART 숫자로도 정확히 같은 이야기를 하고 있었던 셈이다.
교훈: USB 디스크는 SMART를 참고는 하되 맹신하지 말고, dmesg 에러·마운트 상태 같은 연결 계층 신호를 함께 봐야 한다.
수동 점검은 결국 안 하게 된다 — 자동 경보로
여기까지 읽고 “가끔 smartctl 돌려봐야지”라고 생각했다면, 솔직히 그 가끔은 오지 않는다. SMART의 가치는 정기 점검 + 임계 초과 시 자동 알림으로 자동화할 때 비로소 나온다.
두 가지를 건다. 첫째, 디스크 자체의 자가 진단을 주기적으로 돌린다.
# 짧은 자가 진단(보통 2분 내) — 주 1회 정도
smartctl -t short /dev/sda
# 결과는 나중에 조회
smartctl -l selftest /dev/sda둘째, 핵심 속성을 읽어 0이 아니면(혹은 지난번보다 늘었으면) 알림을 보내는 점검 스크립트를 cron에 건다. 판정 로직은 단순해도 된다 — 재할당·보류·정정불가가 0보다 크면 경고. 알림 경로는 이미 만들어 둔 텔레그램 알림을 그대로 재사용하면 된다. 점검 명령과 임계 판정은 smartmontools 공식 문서의 속성 설명을 기준으로 잡는다(smartmontools 매뉴얼).
솔직히 고백하면, 내 5분 주기 서버 모니터는 지금 dmesg의 I/O 에러·read-only 전환·마운트 해제·용량까지는 보지만 SMART 속성은 아직 보지 않는다. 연결 계층(브리지)에서 오는 장애를 한 번 크게 겪다 보니 그쪽 감시부터 짰고, 정작 디스크 본체의 느린 죽음을 감시하는 일은 뒤로 밀려 있었다. 위의 자가 진단·속성 임계 점검을 모니터에 추가하는 것이 이 글을 쓰며 정리된 내 다음 작업이다 — 마침 NVMe도 USB 디스크들도 지금은 건강하니, 값이 나빠지기 전에 감시를 붙여 두기 딱 좋은 시점이다.
결론: 받을 준비가 되어 있어야 신호다
디스크는 대개 신호를 보낸다. 재할당 섹터가 하나둘 늘고, 보류 섹터가 생기고, 자가 진단이 실패하기 시작한다. 그 신호를 **받을 장치(정기 점검 + 자동 경보)**가 없으면, 보낸 신호도 없는 것과 같다. 그리고 신호를 일찍 받는 것의 진짜 가치는, 디스크가 완전히 죽기 전에 백업에서 복구하는 리허설을 차분히 해볼 시간을 번다는 데 있다. 조기 경보와 3-2-1 백업은 한 쌍이다 — 하나는 위험을 미리 알리고, 하나는 그 위험이 현실이 됐을 때 데이터를 지킨다.