드롭된 RAID 디스크인지 불량 드라이브 베이인지 실제 원인을 구분하는 방법

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

RAID 멤버가 떨어졌다고 해서 디스크가 자동으로 고장난 것은 아닙니다. 실제 원인은 제어된 점검과 전원 차단 교체 후 오류가 따라가는 부품입니다.

어레이 상태를 보존하고, 드라이브 일련번호와 베이를 기록하며, SMART 미디어 속성과 연결 오류를 비교하고, 컨트롤러 로그를 읽는 것부터 시작하세요. 그런 다음 한 번에 하나의 하드웨어 변수만 변경하세요. 이 방법은 정상 디스크를 교체하거나 결함 있는 베이를 통해 재구성하는 일을 피하는 데 도움이 됩니다.

재구성하거나 다른 디스크를 빼기 전에 중지하세요

저하된 어레이는 또 다른 실수나 장애를 견딜 공간이 적습니다. 읽을 수 있는 별도의 백업에 대체 불가능한 데이터가 있는지 확인하고, 현재 저장 상태를 저장하며, 하드웨어를 변경하기 전에 불필요한 쓰기를 줄이세요.

RAID 상태, 물리적 디스크 목록, SMART 보고서, 컨트롤러 이벤트의 스크린샷이나 내보내기를 캡처하세요. 경고 시간, 영향을 받은 논리 멤버, 보고된 베이, 모델, 일련번호, 미디어, 타임아웃, 리셋 또는 재연결 카운터를 기록하세요. 그 증거가 어레이 외부에 저장될 때까지 카운터를 초기화하지 마세요.

디스크가 다시 떨어지는지 확인하기 위해 재구성을 시작하지 마세요. 재구성은 살아남은 멤버들의 지속적인 I/O를 증가시키며 첫 번째 문제가 디스크, 연결 경로 또는 공유 컨트롤러 부품에서 발생했는지 숨길 수 있습니다.

경고를 단순히 베이 번호가 아닌 물리적 드라이브와 일치시키세요

RAID 소프트웨어는 운영 체제 장치 이름, 컨트롤러 슬롯, 인클로저 주소 또는 가상 멤버 번호를 표시할 수 있습니다. 이러한 라벨은 항상 영구적이지 않으므로 가장 안전한 식별자는 물리적 트레이와 일치하는 디스크 일련번호 또는 WWN입니다.

실용적인 문제 해결 가이드는 드라이브 일련번호를 기록할 것을 권장합니다. 장치 식별자가 변경될 수 있기 때문입니다. RAID 멤버, OS 장치, 일련번호 또는 WWN, 베이, 컨트롤러 포트, 경고 타임스탬프를 포함하는 작은 지도를 만드세요.

로케이트 LED는 확인 보조 수단으로만 사용하세요. 어떤 것을 제거하기 전에 표시된 일련번호를 트레이나 드라이브의 라벨과 비교하세요. 잘못된 정상 멤버를 빼면 복구 가능한 저하된 어레이가 다중 디스크 장애로 변할 수 있습니다.

드라이브 미디어 오류와 링크 오류를 구분하세요

드라이브 미디어 증거는 플래터, 플래시, 헤드 또는 드라이브 전자장치 쪽을 가리킵니다. 재할당된 섹터, 보고된 수정 불가능 오류, 현재 대기 중인 섹터, 오프라인 수정 불가능 섹터는 Backblaze가 조사할 하드 드라이브를 결정할 때 사용하는 다섯 가지 SMART 지표 중 일부입니다.

모든 0이 아닌 원시 값을 판결로 간주하지 말고 시간 경과에 따른 변화를 관찰하세요. 증가하는 미디어 카운트, 유사한 위치에서 반복되는 읽기 오류 또는 실패한 확장 자가 진단은 디스크 자체에 대한 의심을 높입니다. 전체 SMART 상태가 “통과”라고 해서 간헐적이거나 진행 중인 결함을 배제하지는 않습니다.

연결 증거는 디스크와 컨트롤러 사이 경로를 가리킵니다. UDMA CRC 오류는 SATA 링크에서 실패한 전송을 계산합니다; 증가하는 카운트는 손상된 미디어보다는 케이블, 커넥터, 백플레인, 컨트롤러 인터페이스 또는 드라이브 PCB 경로를 나타낼 수 있습니다.

로그를 사용하여 실패한 계층을 찾으세요.

SMART 데이터는 드라이브가 기록한 내용을 보여주고, 시스템 및 컨트롤러 로그는 스토리지 스택이 어떻게 연결을 잃었는지 보여줍니다. 명령 타임아웃, 링크 재설정, 장치 제거, 재연결, 전원 이벤트 및 컨트롤러 재설정과 미디어 또는 읽기 오류를 구분하세요.

연결된 위치에 관계없이 미디어 오류를 보고하는 단일 시리얼 번호는 디스크 결함을 시사합니다. 하나의 케이블, 백플레인 커넥터, HBA 포트 그룹 또는 전원 분기를 공유하는 베이에서 여러 디스크가 떨어지는 경우 공유 경로 문제를 의심할 수 있습니다. 무거운 I/O 중에만 나타나는 결함은 유휴 상태 검사에서 놓치는 경계 연결 또는 전원 문제를 드러낼 수 있습니다.

고립된 메시지를 읽기보다는 타임라인을 구축하세요. 각 드롭을 동일한 시리얼, 베이, 작업 부하 및 컨트롤러 채널과 일치시키세요. 중요한 질문은 로그 라인이 심각하게 들리는지 여부가 아니라 반복된 사건에서 동일한 구성 요소가 공통으로 남아 있는지 여부입니다.

베이를 교체하기 전에 경로를 재장착하세요.

섀시와 RAID 플랫폼이 수행하려는 정확한 핫스왑 동작을 명시적으로 지원하지 않는 한, 어레이를 중지하고 전원을 끄세요. 핫스왑이 가능한 베이라고 해서 어레이가 활성 상태일 때 위치 이동이나 진단 교체가 자동으로 안전한 것은 아닙니다.

드라이브를 캐디에 다시 장착한 후 베이를 제공하는 데이터 및 전원 경로를 점검하세요. 시스템에 따라 이 경로에는 SATA 또는 SAS 커넥터, 분기 케이블, 백플레인 소켓, HBA, RAID 카드, 전원 하니스 및 인클로저 연결이 포함될 수 있습니다. 느슨한 장착, 손상된 래치, 이물질, 휜 접점, 케이블 장력 또는 여러 영향을 받는 베이를 제공하는 공유 커넥터를 찾아보세요.

재장착 후 CRC, 타임아웃 및 미디어 카운터에 대한 새로운 기준선을 기록하세요. 재구축을 시작하기 전에 제어된 읽기 또는 정상 서비스 부하로 원래 작업 부하를 재현하세요. 연결 카운터가 더 이상 증가하지 않고 디스크가 여전히 존재한다면, 원래 이벤트는 일시적인 접촉 문제였을 수 있습니다.

제어된 드라이브 및 베이 분리 테스트를 실행하세요

결정적인 테스트는 디스크 식별과 배열 안전을 유지하면서 변수 하나를 변경합니다. 모든 RAID 구현이 다른 슬롯의 멤버를 허용하는 것은 아니므로 가정하지 마세요. 플랫폼의 교체 또는 가져오기 동작을 먼저 확인하고, 시리얼 맵을 보이게 유지하며, 불확실할 때는 전원 차단 절차를 사용하세요.

  1. 백업과 저장된 진단 정보가 읽을 수 있는지 확인하세요.
  2. 의심 디스크, 원래 베이, 사용할 정상 경로에 라벨을 붙이세요.
  3. 의심 디스크를 정상 베이나 케이블 경로로 옮기거나 별도의 진단 컨트롤러에 연결하되 쓰기 작업은 하지 마세요.
  4. 의심 베이는 조인, 초기화, 포맷 또는 배열 재구성 없이 여분 또는 정상 디스크로만 테스트하세요.
  5. 동일한 제어된 읽기 작업 부하를 실행하고 새 로그 이벤트와 카운터 증가만 비교하세요.

독립적인 SATA 링크 리셋 분석도 같은 원리를 사용합니다: 같은 디스크를 다른 베이나 케이블 경로로 옮겨서 결함이 장치를 따라가는지 아니면 원래 연결에 남아 있는지 관찰하세요.

오류가 디스크를 따라가는지 아니면 베이에 머무르는지 해석하세요

가능하면 테스트의 양쪽 절반을 모두 사용하세요. 의심 디스크만 이동하면 다른 곳에서 실패하는지 알 수 있지만, 다른 디스크로 원래 베이를 테스트하는 것이 슬롯이나 공유 경로가 문제를 재현하는지 확인하는 방법입니다.

관찰된 결과 가장 가능성 높은 계층 다음 조치
의심 디스크가 정상 베이에서 실패하고 다른 디스크는 원래 베이에서 안정적임 디스크 미디어, 드라이브 전자장치 또는 드라이브 펌웨어 비파괴 진단을 완료한 후 오류가 반복되거나 확장 테스트에 실패하면 디스크 교체
의심 디스크는 다른 곳에서 안정적이지만 원래 베이에서 다른 디스크가 실패함 베이 커넥터, 캐디 접점, 케이블, 백플레인, 컨트롤러 포트 또는 전원 경로 공유 하드웨어가 수리되거나 교체될 때까지 해당 경로 사용 중지
같은 커넥터 또는 HBA 그룹의 여러 베이에서 리셋 발생 공유 케이블, 백플레인 커넥터, 컨트롤러, 냉각 또는 전원 분배 공통 부품을 추적하고 공유 부품 하나를 교체한 후 재검사하세요
재장착 후 오류가 없고 모든 새 카운터가 안정적임 일시적이거나 경계적인 연결 원래 드롭을 유발한 작업 부하에서 계속 모니터링하세요
디스크에 미디어 오류가 나타나고 베이도 다른 드라이브와 링크 오류를 일으킴 하나 이상의 결함 단일 원인 진단을 강요하지 말고 디스크를 분리하여 경로를 별도로 수리하세요

한 번의 정상 부팅을 증거로 삼지 마세요. 유사한 작업 부하에서 관찰을 반복하고 총계뿐 아니라 카운터 변화량을 주시하세요. 미디어 오류가 일련 번호를 따른다면 디스크를 교체하세요. 링크 실패가 베이나 커넥터 그룹에 계속 연결되어 있다면 재구축 전에 해당 경로를 수리하세요.

적절한 수리 및 중지 조건 선택

증거가 디스크를 따른다면 다른 어레이 멤버를 확인하고, 플랫폼 지원 워크플로우를 통해 실패한 멤버를 교체하며, 재구축을 모니터링하세요. 브랜드만이 아니라 용량, 인터페이스, 작업 부하 및 어레이 요구 사항에 따라 적합한 NAS 교체 드라이브를 선택하세요.

증거가 베이에 남아 있다면 이미 리셋을 발생시키는 경로에 새 디스크를 넣지 마세요. 플랫폼이 허용하면 베이를 비활성화하고, 격리 테스트로 확인된 캐디, 케이블, 백플레인, 컨트롤러 채널, 인클로저 연결 또는 전원 분기를 수리하거나 교체하세요.

여러 멤버가 사라지거나, 어레이가 읽을 수 없게 되거나, 재구축 중 오류가 발생하거나, 디스크 식별이 불확실하거나, 검증된 백업이 없을 때는 중지하고 문제를 상위로 보고하세요. 경고를 없애기 위해 초기화, 포맷, 외부 메타데이터 삭제 또는 멤버 강제 재수입을 반복하지 마세요.

자주 묻는 질문

드라이브가 SMART를 통과했는데도 원인일 수 있나요?

네. SMART는 유용한 증거이지만 완전한 보장은 아닙니다. 간헐적인 전자 장치 문제, 펌웨어 동작, 명령 시간 초과 또는 공급업체 속성에 나타나지 않는 결함도 드라이브를 신뢰할 수 없게 만들 수 있습니다. SMART 추세를 로그, 확장 테스트 및 오류가 일련 번호를 따르는지와 결합하세요.

0이 아닌 CRC 카운트가 베이가 나쁘다는 증거인가요?

안 됩니다. 카운트는 이전 케이블이나 연결 이벤트를 기록할 수 있으며 원인이 해결된 후에도 0이 아닐 수 있습니다. 중요한 것은 재장착 후 값이 증가하는지, 그리고 그 증가가 디스크, 케이블 경로, 베이 그룹 또는 컨트롤러를 따르는지 여부입니다.

베이 진단을 위해 드라이브를 핫스왑해도 되나요?

인클로저, 컨트롤러, RAID 구현 및 정확한 작업이 핫스왑 안전으로 문서화된 경우에만 가능합니다. 더 안전한 일반 규칙은 어레이를 중지하고, 전원을 끄고, 일련 번호와 베이 맵을 보존하며, 초기화나 의도치 않은 재구축을 유발할 수 있는 이동을 피하는 것입니다.

진단을 마치기 전에 재구축해야 하나요?

공유 케이블, 백플레인, 컨트롤러 또는 전원 문제 가능성이 여전히 있을 때는 재구축하지 마세요. 재구축은 남은 경로에 부담을 주어 다른 멤버가 떨어질 수 있습니다. 백업을 확보하고, 실패한 계층을 식별하며, 살아남은 디스크를 확인한 후 안정적인 연결을 통해 재구축하세요.

실제 원인은 제어된 테스트에서 결함을 재현하는 구성 요소입니다. 첫 번째 빨간 아이콘이 아니라 일련 번호, 베이, 카운터 및 로그를 따라가며, 재구축을 신뢰하기 전에 실패한 계층을 수리하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.