홈 서버를 위한 최고의 RAID 모니터링 도구 10가지

RAID 어레이가 정상으로 보이는 동안 드라이브 중 하나의 상태가 조용히 악화될 수 있습니다. 반대로 나머지 디스크가 여전히 SMART PASSED를 보고하는데도 성능이 저하될 수 있습니다.

따라서 우수한 모니터링에는 녹색 상태 표시등 하나만으로는 부족합니다. 최고의 홈 서버 환경은 어레이, 물리 드라이브, 재구축 또는 스크럽 작업, 그리고 변경 사항을 알려 주는 알림을 모니터링합니다.

RAID 모니터링은 SMART만으로 끝나지 않습니다

RAID 상태와 디스크 상태는 서로 다른 질문에 답합니다.

어레이 모니터링 도구는 스토리지 시스템에 예상된 구성원이 여전히 존재하는지, 중복성이 손실되었는지, 재구축·재동기화·스크럽 또는 일관성 작업이 실행 중인지 알려 줍니다.

SMART 모니터링은 어레이 아래의 개별 HDD, SSD 및 NVMe 드라이브를 확인합니다. 이를 통해 온도, 미디어 오류, 보류 중인 섹터, 재할당된 섹터, 내구성, 자체 테스트 결과 및 기타 장치 수준의 신호를 확인할 수 있습니다.

RAID 모니터링
     |
     +-- 어레이 상태
     |     정상 / 성능 저하 / 오프라인
     |
     +-- 드라이브 상태
     |     SMART / NVMe / 온도
     |
     +-- 복구
     |     재구축 / 재동기화 / 스크럽
     |
     +-- 기록
     |     추이 / 오류 / 용량
     |
     +-- 알림
           이메일 / 푸시 / 웹훅 / 채팅

이 구분이 중요한 이유는 정상적인 어레이에도 성능이 저하되는 드라이브가 포함될 수 있고, 성능이 저하된 어레이에도 SMART 상태가 여전히 정상인 개별 디스크가 여러 개 포함될 수 있기 때문입니다.

기본 RAID 모델은 RAID 작동 방식에서 자세히 다루지만, 모니터링은 더 간단한 원칙에서 시작합니다. 어레이와 그 아래의 드라이브를 모두 감시하세요.

RAID 모니터링 도구는 실제로 무엇을 감시해야 하나요?

유용한 홈 서버 모니터링 도구는 그 역할에 필요한 만큼 이러한 계층을 최대한 많이 다뤄야 합니다.

최고의 RAID 모니터링 도구를 선정한 기준

가장 보기 좋은 대시보드의 순위가 아닙니다. 아래 도구들은 모니터링 스택의 서로 다른 부분을 해결합니다.

다음과 같은 실용적인 질문 5가지를 기준으로 평가했습니다.

• 실제로 무엇을 관찰할 수 있나요? 어레이 상태, 개별 디스크, ZFS 풀, 하드웨어 RAID, 아니면 서버 전체인가요?
• 기록을 보존하나요? 오류 수가 천천히 증가하는 추세는 현재 값 하나보다 더 유용한 경우가 많습니다.
• 수동 확인 없이 알림을 보낼 수 있나요? 모니터링은 문제를 사전에 알려야 합니다.
• 배포가 얼마나 어렵나요? 사용자가 원하지 않는 한 단일 홈 NAS에 엔터프라이즈급 옵저버빌리티 인프라가 필요해서는 안 됩니다.
• 기본 RAID 도구를 보완하나요? 가장 강력한 구성은 일반적으로 어레이별 모니터와 디스크 상태 모니터링 계층을 결합합니다.

숫자 순서는 합성 벤치마크 점수가 아니라 편집상의 배열입니다.

한눈에 보는 홈 서버용 RAID 모니터링 도구 10선

1. Netdata — 종합 RAID 모니터링 대시보드

Netdata는 스토리지 시스템과 홈 서버의 나머지 부분을 하나의 모니터링 계층으로 관리하려는 경우 전반적으로 가장 강력한 선택입니다.

현재 Netdata의 스토리지 수집기는 RAID 사용자와 관련된 여러 아키텍처를 지원합니다.

Linux 소프트웨어 RAID의 경우 MD RAID 수집기는 /proc/mdstat를 읽고 MD 장치를 추적합니다. 물리 드라이브의 경우 Netdata에는 smartctl을 기반으로 하는 SMART 수집기가 있습니다. Netdata의 ZFS 풀 수집기는 zpool을 통해 풀 상태와 공간을 모니터링하며, StoreCLI RAID 수집기는 지원되는 하드웨어 RAID 어댑터, 물리 드라이브 및 백업 배터리를 모니터링할 수 있습니다.

이러한 폭넓은 지원 덕분에 Netdata는 특정 SMART 대시보드에 비해 유리합니다.

MD RAID
SMART
ZFS
하드웨어 RAID
파일 시스템
CPU
RAM
네트워크
컨테이너
     |
  Netdata
     |
대시보드 하나

단일 Netdata 에이전트는 독립적으로 실행되며 로컬 대시보드를 포트에서 제공할 수 있습니다 19999모니터링 에이전트 자체의 클라우드 연결은 선택 사항이지만, Netdata Cloud를 사용하면 중앙 집중식 보기와 추가적인 다중 노드 기능을 이용할 수 있습니다.

따라서 Netdata는 스토리지 모니터링을 시스템 부하, RAM 사용 압박, 파일 시스템 용량, Docker 활동 및 네트워크 성능과 함께 확인해야 하는 홈 서버에서 특히 유용합니다.

적합한 대상: RAID와 서버의 나머지 요소를 모두 아우르는 하나의 대시보드를 원하는 사용자.

절충점: Netdata는 디스크에만 집중하기보다는 광범위한 모니터링을 제공합니다. SMART 속성과 장기적인 물리 드라이브 성능 저하를 살펴보는 것이 목적이라면 Scrutiny가 더 깔끔한 화면을 제공합니다.

2. Scrutiny — 드라이브 상태 추세 파악에 가장 적합

Scrutiny는 원시 SMART 모니터링의 여러 약점을 해결하므로 홈 NAS에 추가하기 가장 유용한 도구 중 하나입니다.

SMART는 많은 속성을 제공하지만 모든 속성이 똑같이 유용한 것은 아닙니다. 제조업체의 임계값이 너무 보수적일 수도 있어 드라이브가 고장에 가까워질 때까지 “정상”으로 보일 수 있습니다.

Scrutiny는 SMART 데이터에 웹 UI, 과거 추세 저장, 온도 추적, 실제 드라이브 고장 데이터에 기반한 추가 임계값을 결합합니다.

이를 통해 다음과 같은 질문을 할 수 있습니다.

현재 보류 중인 섹터

1월       0
3월          0
6월          2
8월        8

현재 SMART 보고서 하나만 보면 해당 값이 8이라는 사실만 알 수 있습니다. Scrutiny는 이 지표가 잘못된 방향으로 변해 왔다는 것을 보여 줍니다.

또한 이메일, 웹훅, ntfy, Gotify, Slack, Discord, Telegram 및 기타 서비스를 통한 알림을 설정할 수 있습니다.

RAID 컨트롤러 지원 여부는 다음에 따라 달라집니다. smartctl 기저의 물리 드라이브에 액세스할 수 있어야 합니다. 이러한 이유로 Scrutiny는 컨트롤러 패스스루와 Docker 장치 매핑을 문서화하고 있습니다.

중요한 제한 사항은 다음과 같이 명확합니다.

Scrutiny는 드라이브를 모니터링할 뿐, RAID 어레이 자체를 모니터링하지는 않습니다.

Linux MD 어레이는 여전히 mdadm 또는 어레이를 인식하는 다른 계층으로 모니터링해야 합니다. ZFS 풀도 여전히 ZFS 전용 모니터링이 필요합니다.

적합한 대상: 과거 SMART 데이터와 온도 추세가 중요한 여러 HDD 또는 SSD를 사용하는 홈 서버.

절충점: Scrutiny에 정상 상태의 디스크가 여러 개 표시된다고 해서 RAID 어레이가 정상이라고 착각하지 마세요.

드라이브 상태 모니터링 계층은 드라이브 자체에도 좌우됩니다. 적합한 NAS 드라이브를 선택하면 재구축 및 연속 24시간 작동 중 피할 수 있는 문제를 줄일 수 있습니다.

3. smartmontools — HDD, SSD 및 NVMe 모니터링을 위한 최고의 기반

smartmontools는 Scrutiny만큼 시각적으로 화려하지는 않지만 더 근본적인 도구입니다.

이 프로젝트는 두 가지 핵심 도구를 제공합니다:

smartctl
   |
드라이브 검사 및 테스트

smartd
   |
드라이브를 지속적으로 모니터링

smartctl ATA/SATA, SCSI/SAS 및 NVMe 장치에서 SMART 및 상태 정보를 검사하고 드라이브 자체 테스트를 실행할 수 있습니다. smartd 데몬으로 실행되며 구성된 상태 조건을 지속적으로 확인합니다.

많은 상위 수준의 모니터링 제품은 결국 이 데이터에 의존합니다. Netdata의 SMART 수집기는 smartmontools를 필요로 하고, Scrutiny는 smartctl 데이터를 기반으로 디스크 상태 계층을 구축하며, Prometheus smartctl 익스포터는 동일한 인터페이스를 사용합니다.

이 프로젝트는 현재도 계속 발전하고 있습니다. 현재 업스트림 변경 로그에는 7.5 다음 세대의 미출시 버전으로 smartmontools 8.0이 기재되어 있습니다.

가벼운 홈 서버라면 smartd만으로 충분할 수 있습니다:

드라이브
  |
SMART
  |
smartd
  |
알림

드라이브가 중요한 임계값을 초과했다는 사실을 확인하기 위해 별도의 데이터베이스, 대시보드 및 메트릭 스택이 반드시 필요한 것은 아닙니다.

적합한 대상: 물리적 드라이브 상태와 자동화된 테스트를 위한 가볍고 검증된 기반을 원하는 사용자.

절충점: 명령줄 출력은 Scrutiny나 Cockpit보다 접근성이 낮으며, smartd만으로는 동일한 시각적 과거 분석 기능을 제공하지 않습니다.

4. mdadm Monitor — Linux 소프트웨어 RAID를 위한 최고의 기본 모니터

어레이가 Linux MD RAID라면 Netdata나 다른 대시보드를 설치했더라도 mdadm을 모니터링 계획에 포함해야 합니다.

mdadm --monitor 어레이 자체를 이해합니다.

다음과 같은 이벤트를 보고할 수 있습니다:

• 장치 장애;
• 성능이 저하된 어레이;
• 스페어 활성화;
• 장치 사라짐;
• 리빌드 시작;
• 리빌드 진행률;
• 리빌드 완료.

SMART가 해결하지 못하는 부분을 보완합니다:

smartd
  |
드라이브가 정상인가요?

mdadm --monitor
  |
RAID 어레이가 정상인가요?

최소한의 Linux 홈 서버에서는 mdadm 모니터링과 smartd를 함께 사용하면 대규모 웹 스택을 추가하지 않고도 놀라울 정도로 강력한 모니터링 시스템을 구축할 수 있습니다.

적합한 대상: MD RAID 1, 5, 6 또는 10을 기반으로 구축된 Debian, Ubuntu 및 기타 Linux 서버.

절충점: mdadm은 ZFS, 하드웨어 RAID 또는 그래픽 기반 장기 분석보다는 Linux 소프트웨어 RAID에 중점을 둡니다.

5. OpenZFS ZED — ZFS 풀을 위한 최고의 기본 이벤트 모니터링

ZFS 사용자는 모든 이벤트를 기존 RAID 용어에 억지로 대응시키기보다 ZFS를 ZFS로 모니터링해야 합니다.

ZED는 ZFS 이벤트 데몬으로, ZFS 커널 모듈이 생성하는 이벤트를 모니터링하고 일치하는 이벤트 클래스가 나타나면 구성된 ZEDLET 작업을 실행합니다.

모니터링 관계는 다음과 같습니다.

ZFS 커널
    |
  zevents
    |
   ZED
    |
ZEDLET 작업
    |
알림 / 자동화

따라서 ZED는 외부 디스크 대시보드가 아니라 ZFS 자체에 속하는 풀 및 장치 이벤트에 적합합니다.

따라서 완전한 ZFS 홈 서버 스택에는 다음이 포함될 수 있습니다.

ZED
 |
풀 이벤트

smartd / Scrutiny
 |
물리 드라이브 상태

Netdata / Grafana
 |
대시보드 및 기록

최적 대상: 풀 주변의 네이티브 이벤트 처리를 원하는 TrueNAS 스타일, OpenZFS 또는 Linux/BSD ZFS 사용자.

절충점: ZED는 이벤트 데몬이지, 완성도 높은 올인원 대시보드가 아닙니다. 장기적인 시각화가 중요하다면 다른 계층과 함께 사용하세요.

6. Cockpit Storage — Linux 초보자를 위한 RAID 모니터링 GUI

Cockpit은 일반 Linux 서버에 브라우저 기반 관리 인터페이스를 추가하는 가장 쉬운 방법 중 하나입니다.

Storage 애플리케이션은 로컬 디스크, 파티션, RAID, 암호화, NFS, iSCSI 및 기타 일반적인 스토리지 작업을 지원합니다.

Cockpit은 Storage 페이지에 SMART 장치 상태 정보도 추가했으며, 브라우저에서 디스크 자체 테스트를 실행할 수 있습니다.

따라서 다음과 같은 서버를 위한 강력한 초보자용 옵션이 됩니다.

Ubuntu / Debian / Fedora
          |
       Cockpit
          |
 브라우저 스토리지 UI
          |
 RAID + SMART + 마운트

전용 관측성 스택을 구축하기보다 스토리지를 관리하려는 사용자에게 특히 유용합니다.

최적 대상: 깔끔한 서버 관리 UI에서 RAID와 디스크 상태를 확인하려는 Linux 초보자.

절충점: Cockpit은 수개월간의 상세한 SMART 기록을 저장하는 것보다 현재 서버 상태를 표시하고 관리하는 데 더 적합합니다.

7. Prometheus + smartctl_exporter + Grafana — 장기 메트릭에 최적

모니터링 자체가 취미가 되면 Prometheus 스택은 특정 목적의 NAS 대시보드보다 훨씬 더 세밀한 제어 기능을 제공합니다.

공식 smartctl_exporter smartctl 통계를 Prometheus 메트릭으로 변환합니다. smartctl의 JSON 출력에 의존하므로 smartmontools 7.0 이상이 필요합니다.

아키텍처는 모듈식입니다:

SMART / RAID / ZFS 익스포터
           |
       Prometheus
           |
         Grafana
           |
 대시보드 + 알림

추가 익스포터 또는 노드 메트릭으로 다음 항목을 추가할 수 있습니다.

• 파일 시스템 용량
• 디스크 I/O
• ZFS 풀
• MD RAID 상태
• 온도
• 서버 부하
• UPS 메트릭
• 네트워크 활동.

현재 상태를 단순히 확인하는 것이 아니라 과거의 질문에 답하려는 경우 가장 강력한 선택입니다.

예를 들어 다음과 같습니다.

• 최근 RAID 재구축 중 드라이브 온도가 상승했나요?
• 복구 불가능한 오류가 처음 나타난 시점은 언제인가요?
• 드라이브를 하나 더 추가한 후 스토리지 지연 시간이 변했나요?
• 지난 1년 동안 풀 사용률은 얼마나 빠르게 증가했나요?

Grafana Alerting은 Prometheus 기반 규칙을 평가하고 조건이 충족되면 알림을 전송할 수도 있습니다.

적합한 경우: 장기 메트릭, 사용자 지정 대시보드, 상관관계 분석 및 유연한 알림을 원하는 애호가.

단점: Prometheus + 익스포터 + Grafana는 Scrutiny나 Netdata보다 훨씬 더 많은 구성이 필요합니다. 단순한 홈 NAS 하나만 사용하는 경우 이러한 복잡성은 실질적인 이점을 거의 제공하지 않을 수 있습니다.

8. Checkmk — 여러 홈 서버 모니터링에 가장 적합

Checkmk는 홈 랩에 한 대 이상의 머신이 있을 때 더욱 매력적입니다.

NAS만 생각하는 대신 다음과 같은 장치를 함께 사용할 수 있습니다.

NAS
백업 서버
Proxmox 호스트
미니 PC
라우터
UPS
스위치
     |
   Checkmk

Checkmk Linux 에이전트는 플러그인을 통해 하드웨어 모니터링을 지원하며, 최신 HDD와 SSD의 SMART 값도 포함합니다.

또한 지원되는 RAID 컨트롤러 뒤에 숨겨진 드라이브도 명시적으로 고려합니다. 컨트롤러에 따라 다음과 같은 도구가 smartmontools, tw_cli또는 MegaRAID 유틸리티가 필요할 수 있습니다.

더 큰 장점은 중앙 집중식 운영입니다. 여러 호스트, 서비스 상태, 알림 규칙, 그래프, 인벤토리, 용량 및 시스템 모니터링을 모두 하나의 인터페이스에서 관리할 수 있습니다.

적합한 경우: 여러 Linux 서버 및 인프라 장치와 함께 스토리지 상태를 모니터링해야 하는 홈 랩.

단점: Netdata나 기본 OS 모니터링으로 이미 중요한 장애 신호를 확인할 수 있다면, 단일 NAS에 Checkmk를 사용하는 것은 불필요한 오버헤드입니다.

9. StorCLI — LSI 및 Broadcom 하드웨어 RAID에 가장 적합

하드웨어 RAID는 운영 체제에서 하나의 가상 디스크로 보더라도 컨트롤러가 그 아래에서 여러 물리 드라이브를 관리할 수 있으므로, 모니터링 방식을 달리해야 합니다.

운영 체제
      |
 가상 드라이브
      |
 RAID 컨트롤러
      |
+-----+-----+-----+
디스크 1   디스크 2  디스크 3

StorCLI는 지원되는 LSI/Broadcom RAID 컨트롤러를 위한 Broadcom의 명령줄 관리 유틸리티입니다.

컨트롤러 상태, 가상 드라이브, 물리 드라이브, 재구축 작업, 인클로저 정보, 캐시 및 지원되는 배터리 또는 백업 구성 요소를 검사할 수 있습니다.

하드웨어 RAID 상태에는 다음과 같은 상태가 포함될 수 있습니다.

• 최적;
• 부분적 성능 저하;
• 성능 저하;
• 오프라인.

모든 RAID 컨트롤러에서 일반적인 SMART 도구가 멤버 드라이브를 자동으로 검색하지 못할 수 있으므로, 이러한 컨트롤러 수준의 가시성이 필수적입니다.

유용한 모니터링 조합은 다음과 같습니다.

Broadcom / LSI RAID
        |
      StorCLI
        |
     Netdata
        |
대시보드 + 알림

Netdata의 StoreCLI 수집기는 컨트롤러 정보를 가져와 나머지 서버 지표와 함께 표시할 수 있습니다.

적합한 대상: 지원되는 Broadcom, LSI 또는 MegaRAID 하드웨어 컨트롤러를 사용하는 홈 서버.

절충점: StorCLI는 범용 홈 서버 대시보드가 아니라 컨트롤러별 관리 도구입니다.

10. Zabbix — 고급 RAID 알림 및 자동화에 적합

Zabbix는 이 목록에서 가장 인프라 지향적인 옵션입니다.

현재 Agent 2 템플릿에는 공식 SMART 모니터링이 포함되어 있으며, 어레이와 컨트롤러 상태는 환경에 맞는 지원 통합 기능, 사용자 지정 항목, 스크립트 또는 템플릿을 통해 추가할 수 있습니다.

더 큰 규모의 Zabbix 배포는 다음을 결합할 수 있습니다.

SMART
RAID
ZFS
파일 시스템
UPS
온도
네트워크
서비스
     |
   Zabbix
     |
기록
트리거
알림
에스컬레이션

강점은 RAID 전용 화면에 있지 않습니다. 무엇을 장애로 간주할지와 그다음에 어떤 작업을 수행할지를 정확히 정의할 수 있다는 점에 있습니다.

예를 들어 하나의 경고는 일반 알림 채널로 전달하고, 어레이 성능 저하나 오프라인 가상 디스크는 더 긴급한 에스컬레이션을 트리거하도록 설정할 수 있습니다.

적합한 대상: 이미 Zabbix를 사용하고 있거나, 여러 시스템에 대한 상세한 알림 규칙과 자동화를 원하는 고급 사용자.

절충점: 설정 복잡도가 높습니다. 홈 NAS 한 대에서 디스크 두 개만 모니터링하기 위해 Zabbix를 설치하는 것은 대개 불필요합니다.

실제로 어떤 RAID 모니터링 도구를 사용해야 할까요?

RAID 상태와 SMART 상태: 서로 다릅니다

이러한 차이는 순위에 포함된 대부분의 도구 중 무엇을 선택할지보다 더 중요합니다.

유용한 예시는 다음과 같습니다.

mdadm:
어레이 정상

Scrutiny:
디스크 3
현재 보류 중인 섹터 = 0 → 2 → 8

어레이에는 아직 장애가 발생하지 않았지만 물리 드라이브의 기록을 보면 조사를 시작할 이유가 있습니다.

반대의 상황도 발생할 수 있습니다.

mdadm:
어레이 성능 저하

smartctl:
디스크 1 통과
디스크 2 통과
디스크 3 통과

SMART 장애 임계값으로 나타나지 않는 케이블, 전원, 컨트롤러, 장치 인식 문제 또는 기타 결함 때문에 누락된 구성원이 사라졌을 수 있습니다.

mdadm vs ZFS vs 하드웨어 RAID 모니터링

적합한 모니터링 도구는 부분적으로 RAID 로직이 어디에 있는지에 따라 달라집니다.

이것이 바로 스토리지 레이아웃이 모니터링 아키텍처에 영향을 미치는 이유입니다. 소프트웨어 RAID, ZFS, 하드웨어 RAID는 서로 다른 제어 계층을 통해 서로 다른 상태 정보를 노출합니다.

Scrutiny와 Netdata: 무엇을 설치해야 할까요?

서로 맞서기보다 함께 사용할 때 더 효과적입니다.

따라서 가정용 서버에 적합한 간단한 조합은 다음과 같습니다.

Netdata
  |
어레이 + 서버 상태

Scrutiny
  |
물리 드라이브 추이

애플리케이션 하나만 원한다면 Netdata가 더 많은 계층을 다룹니다.

NAS 운영 체제가 이미 어레이 상태를 효과적으로 모니터링한다면, Scrutiny는 물리 디스크를 더 긴 기간 동안 확인할 수 있게 해 주므로 새로운 정보를 더 많이 제공할 수 있습니다.

홈 NAS에 Prometheus와 Grafana가 필요한가요?

대개 그렇지 않습니다.

요구 사항이 다음 하나뿐이라면:

RAID 성능 저하 알림
디스크에 오류가 발생하고 있다는 알림

기본 어레이 알림에 smartd, Scrutiny 또는 Netdata를 더하면 훨씬 적은 인프라로 문제를 해결할 수 있습니다.

다음과 같은 사항이 중요하다면 Prometheus와 Grafana를 도입할 의미가 있습니다.

• 수개월 또는 수년에 걸친 기록;
• 여러 서버;
• 사용자 지정 대시보드;
• 온도와 I/O 상관관계 분석;
• 스토리지 증가 추적;
• RAID와 UPS, 네트워크, Docker, 호스트 메트릭 결합;
• 사용자 지정 PromQL 알림 규칙.

Grafana를 설치하는 잘못된 이유는 단지 대시보드가 인상적으로 보이기 때문입니다.

올바른 이유는 시간에 따른 기록이 필요한 질문이 있기 때문입니다.

어떤 RAID 알림을 설정해야 할까요?

대시보드를 먼저 열지 않아도 무언가가 사용자에게 도달할 수 있을 때만 모니터링이 유용해집니다.

어레이 알림

• 어레이 성능 저하;
• 어레이 오프라인;
• 예기치 않게 멤버가 누락됨;
• 핫 스페어 활성화;
• 리빌드 또는 재동기화 시작;
• 리빌드 실패;
• 리빌드 완료.

물리 드라이브 알림

• SMART 종합 상태 실패;
• 현재 보류 중인 섹터 수가 증가함;
• 오프라인 수정 불가능 섹터 수가 증가함;
• 재할당된 섹터 수가 크게 증가함;
• NVMe 중대 경고;
• SSD 내구도 또는 마모가 교체 수준에 근접함;
• 드라이브 온도가 예상 범위를 벗어난 상태로 유지됨.

ZFS 알림

• 풀 성능 저하;
• 장치 오류;
• 체크섬 오류 증가;
• 스크럽에서 오류 발견;
• 리실버링이 시작되었거나 실패함;
• 풀 용량이 설정한 임계값에 가까워짐.

하드웨어 RAID 알림

• 물리 드라이브 오류;
• 가상 드라이브 성능 저하;
• 가상 드라이브 오프라인;
• 리빌드가 중단되었거나 실패함;
• 컨트롤러 캐시 또는 백업 배터리 오류

정확한 온도 및 SMART 임계값을 다른 서버에서 무작정 복사해서는 안 됩니다. 드라이브 모델마다 제공하는 속성과 작동 범위가 다릅니다.

더 중요한 것은 원칙입니다.

열어 보지 않는 대시보드는 모니터링이 아닙니다.

SMART 테스트, 스크럽, 리빌드: 서로 다른 세 가지 작업

이러한 작업은 흔히 서로 혼동되지만, 검사하는 대상은 서로 다릅니다.

SMART 자체 테스트

SMART 자체 테스트는 개별 스토리지 장치에서 수행됩니다.

단일 드라이브
   |
SMART 테스트
   |
장치 수준 결과

긴 SMART 테스트는 짧은 테스트보다 드라이브 표면을 더 넓게 검사할 수 있지만, 전체 스토리지 시스템에서 RAID 패리티나 ZFS의 데이터 복사본까지 검증하지는 않습니다.

RAID 재구성 또는 재동기화

재구성은 장애가 발생했거나 교체된 구성원 이후 이중화를 복원합니다.

성능 저하된 RAID
     |
교체 드라이브
     |
재구성 / 재동기화
     |
이중화 복원됨

이는 디스크 상태 검사가 아니라 복구 작업입니다.

ZFS 스크럽 또는 RAID 일관성 검사

스크럽 또는 일관성 검사는 이미 존재하는 데이터와 이중화 관계를 검증합니다.

이는 다른 질문에 답합니다.

스토리지 아키텍처가 세 가지를 지원한다면 모니터링에서 세 가지를 모두 노출해야 하는 이유가 바로 여기에 있습니다.

다른 대시보드를 설치하기 전에 기본 NAS 알림 활성화

전용 NAS 운영 체제는 이미 필요한 첫 번째 모니터링 계층을 제공하고 있을 수 있습니다.

예를 들어 현재 ZimaOS 스토리지 관리에서는 설정 > 스토리지에서 어레이 상태, 드라이브 상태, 사용 가능한 용량 및 읽기/쓰기 속도를 확인할 수 있습니다. RAID 구성원이 장애를 일으키면 어레이가 성능 저하 상태로 전환되며, 드라이브를 교체한 후 복구 작업에서 재구성 과정을 안내합니다.

ZimaOS는 스토리지 인터페이스에서 장시간 실행되는 RAID 및 패리티 검사 진행률과 상세한 디스크 상태 정보도 제공합니다.

따라서 실용적인 순서는 다음과 같습니다.

1. 기본 NAS 알림 활성화
        |
2. 성능 저하된 어레이 감지 확인
        |
3. 물리 드라이브 이력 추가
        |
4. 유용한 경우에만 더 큰 옵저버빌리티 스택 추가

TrueNAS, Unraid, Synology, QNAP 및 기타 NAS 플랫폼도 기본 스토리지 상태 확인 기능을 제공하므로, 두 번째 모니터링 시스템을 추가하기 전에 이를 구성해야 합니다.

추가 계층은 기본 UI가 충분히 잘 답하지 못하는 질문에 답할 수 있어야 합니다.

RAID 모니터링은 백업을 대체하지 않습니다

완벽한 알림은 디스크 장애가 발생한 지 몇 초 만에 이를 알려줄 수 있습니다.

삭제된 폴더의 어제 버전을 복원할 수 없습니다.

랜섬웨어로 이미 암호화된 파일을 복구할 수 없습니다.

도난, 화재 또는 치명적인 컨트롤러 장애가 발생한 후 NAS를 복원할 수 없습니다.

따라서 RAID는 백업이 아닙니다.

RAID
  |
일부 드라이브 장애 후에도 가용성 유지

모니터링
  |
문제 신속 감지

백업
  |
손실되거나 손상된 데이터 복구

세 가지는 각각 안정성 문제의 서로 다른 부분을 해결합니다.

재구성 중에는 남은 드라이브가 지속적으로 작동하는 동안 이중화가 감소할 수 있으므로 모니터링이 특히 중요해집니다. 이 기간에 예기치 않은 전원 손실이 발생하면 또 다른 위험이 추가됩니다. 따라서 스토리지 작업 중 UPS 보호는 드라이브 상태 모니터링과 별도로 중요합니다.

권장 RAID 모니터링 스택

간단한 Linux RAID 서버

mdadm --monitor
       +
     smartd

가벼운 구성입니다.

mdadm은 Linux 어레이를 모니터링하고, smartd는 디스크를 모니터링합니다. 둘 다 무거운 웹 플랫폼이 필요하지 않습니다.

간편한 홈 NAS

네이티브 NAS 모니터링
         +
      Scrutiny

NAS 인터페이스가 어레이 상태와 재구축을 처리하고, Scrutiny가 드라이브 상태 기록과 알림을 추가합니다.

일반 Linux 홈 서버

Netdata
   +
Scrutiny

Netdata는 어레이와 전체 서버를 모니터링합니다. Scrutiny는 물리 드라이브의 더 상세한 기록을 제공합니다.

ZFS 홈 서버

ZED
 +
Scrutiny
 +
Netdata

ZED는 네이티브 ZFS 이벤트를 처리하고, Scrutiny는 드라이브 추세를 모니터링하며, Netdata는 시스템 전반을 보여 주는 더 넓은 대시보드를 제공합니다.

고급 홈랩

smartctl_exporter
MD / ZFS 익스포터
node_exporter
      |
  Prometheus
      |
   Grafana
      |
알림

메트릭 기록과 여러 서버의 관리가 전체 옵저버빌리티 스택을 유지할 만큼 중요할 때 적합합니다.

하드웨어 RAID 서버

StorCLI
   |
Netdata / Checkmk
   |
알림 + 대시보드

컨트롤러 유틸리티는 하드웨어 RAID 계층의 사실상 기준으로 남고, 모니터링 플랫폼은 그 상태를 확인하고 조치를 취할 수 있도록 보여 줍니다.

최종 결론

대부분의 홈 서버에서 Netdata가 가장 뛰어난 종합 RAID 모니터링 도구인 이유는 여러 스토리지 아키텍처를 아우르는 동시에 호스트 자체도 모니터링할 수 있기 때문입니다.

개별 드라이브의 기록이 중요하다면 Scrutiny가 가장 강력한 보조 도구입니다. 어레이 자체가 성능 저하 상태에 도달하기 전에 SMART 속성의 느린 변화를 파악하는 데 특히 유용합니다.

smartmontools는 여전히 디스크 상태 모니터링의 기반 계층이며, mdadm Monitor는 Linux 소프트웨어 RAID를 위한 가장 깔끔한 선택지 중 하나입니다.

OpenZFS ZED는 일반적인 SMART 데이터로 풀 이벤트를 대체하려 하기보다 ZFS 네이티브 모니터링 전략의 일부로 유지해야 합니다.

일반적인 Linux 서버에서는 Cockpit이 가장 쉬운 그래픽 옵션이며, 장기 메트릭이 실제 요구 사항이 되면 Prometheus와 Grafana가 더 적합합니다.

모니터링 대상 시스템의 수가 늘어날수록 Checkmk와 Zabbix의 가치가 높아지며, RAID 로직이 지원되는 LSI/Broadcom 하드웨어 내부에 있다면 StorCLI가 필수적입니다.

따라서 홈 서버에서 가장 신뢰할 수 있는 전략은 계층적으로 구성하는 것입니다.

어레이 상태
     +
드라이브 상태
     +
복구 상태
     +
알림
     +
기록

RAID는 보통 여러 계층에서 장애가 발생하므로 모니터링도 계층적으로 구성해야 합니다.

FAQ

홈 서버에 가장 적합한 RAID 모니터링 도구는 무엇인가요?

Netdata는 Linux MD RAID, SMART 장치, ZFS 풀, 지원되는 하드웨어 RAID, 그리고 서버의 나머지 부분까지 하나의 인터페이스에서 모니터링할 수 있어 전반적으로 가장 뛰어난 선택지 중 하나입니다. 상세한 물리 드라이브 SMART 기록이 우선이라면 Scrutiny가 더 강력한 전문 도구입니다.

Scrutiny는 RAID 모니터링 도구인가요?

Scrutiny는 SMART 데이터를 통해 RAID 어레이 아래의 물리적 드라이브를 모니터링합니다. Linux MD RAID의 mdadm, ZFS 이벤트의 ZED, 지원되는 하드웨어 RAID 컨트롤러의 StorCLI와 같은 어레이 수준 모니터링을 대체하지는 않습니다.

드라이브에 장애가 발생하고 있는데도 SMART에 PASSED가 표시될 수 있나요?

SMART PASSED는 해당 드라이브가 장치 전체 SMART 장애 조건을 아직 초과하지 않았다는 뜻입니다. 그 상태가 failed로 바뀌기 전에 개별 속성이 우려스러운 방식으로 변할 수 있습니다. 기록 모니터링은 이러한 추세를 보여 주므로 유용합니다.

mdadm RAID를 모니터링하는 가장 좋은 방법은 무엇인가요?

어레이 이벤트에는 mdadm의 모니터링 모드를 사용하고, 물리적 드라이브 상태 확인을 위해 smartmontools 또는 Scrutiny와 함께 사용하세요. Netdata를 추가하면 그래픽 MD RAID 및 서버 모니터링 계층을 제공할 수 있습니다.

ZFS 풀을 모니터링하는 가장 좋은 방법은 무엇인가요?

풀 이벤트와 상태에는 ZED 및 zpool과 같은 ZFS 네이티브 도구를 사용하세요. 개별 드라이브 상태를 확인하려면 smartmontools 또는 Scrutiny를 추가하고, 기록 시각화가 필요하다면 Netdata, Prometheus 또는 Grafana를 사용하세요.

RAID 모니터링으로 하드 드라이브가 고장 나기 전에 장애를 감지할 수 있나요?

어레이 모니터링만으로는 감지하지 못할 수 있습니다. SMART 기반 도구는 어레이에서 멤버 하나가 손실되기 전에 변화하는 드라이브 상태 속성을 표시할 수 있지만, 어떤 모니터링 시스템도 모든 드라이브 장애를 안정적으로 예측할 수는 없습니다.

Netdata와 Scrutiny 중 무엇을 사용해야 하나요?

RAID, 스토리지, CPU, RAM, 네트워크 및 서비스를 아우르는 전체 서버 대시보드 하나를 원한다면 Netdata를 사용하세요. 상세한 SMART 추세와 드라이브 상태 기록이 우선이라면 Scrutiny를 사용하세요. 두 도구를 함께 실행하면 서로 다른 계층을 담당하므로 유용할 수 있습니다.

RAID를 모니터링하려면 Grafana가 필요한가요?

아니요. Grafana는 장기 메트릭, 사용자 지정 대시보드, 여러 시스템 및 상관관계 분석에 유용합니다. 간단한 홈 NAS는 기본 알림과 smartmontools, Scrutiny 또는 Netdata만으로도 충분히 모니터링할 수 있는 경우가 많습니다.

RAID 서버는 어떤 알림을 보내야 하나요?

최소한 성능 저하 또는 오프라인 상태의 어레이, 누락된 멤버, 리빌드 실패, SMART 상태 실패, 중요한 SMART 속성 변경, 높은 드라이브 온도, ZFS 오류, 해당되는 경우 하드웨어 RAID 컨트롤러 또는 캐시 결함에 대한 알림을 구성하세요.

RAID 스크럽은 SMART 테스트와 같은 것인가요?

아니요. SMART 테스트는 개별 드라이브에서 실행됩니다. 스크럽 또는 일관성 검사는 스토리지 시스템 수준에서 데이터와 이중화를 검증합니다. 리빌드는 디스크 장애 또는 교체 후 이중화를 복원합니다.

RAID 모니터링이 백업을 대체하나요?

아니요. 모니터링은 장애를 신속하게 감지하는 데 도움이 되며, RAID는 특정 드라이브 장애 후에도 가용성을 유지할 수 있습니다. 그러나 삭제되었거나 암호화되었거나 손상된 파일 또는 과거에 변경된 파일을 복원해 주지는 않습니다. 별도의 백업이 여전히 필요합니다.

RAID에서 SSD와 NVMe 드라이브를 모니터링해야 하나요?

예. SSD와 NVMe 드라이브는 치명적 경고, 온도, 미디어 오류, 내구성 또는 마모와 같은 상태 정보를 제공합니다. 정확한 속성은 HDD SMART 데이터와 다르므로 모니터링 도구에 적절한 장치 지원이 필요합니다.