The most important correction in this source is that the array did not remain a confirmed “one disk failed” RAID. After the user booted with each drive separately, both were individually workable. Reconnecting both drives produced [UU] 이 원문에서 가장 중요한 정정 사항은 어레이가 확정적으로 “디스크 하나가 고장 난” RAID 상태로 계속 유지된 것이 아니라는 점입니다. 사용자가 각 드라이브를 따로 연결해 부팅한 후, 두 드라이브 모두 개별적으로 작동 가능했습니다. 두 드라이브를 다시 연결하자 에서/proc/mdstat
이는 RAID 1의 두 구성원이 당시 모두 연결되어 동기화된 상태였다는 뜻입니다.
이후 스레드에서는 SATA/링크/전원 불안정, USB/모니터 장애, 긴급 모드 부팅, NFS 오류, ZimaOS의 다른 시스템 슬롯 전환 문제까지 논의가 확대되었습니다. 데이터는 복구되었지만, 원문에서는 최종 원인 하나를 입증하지 않습니다. 이를 단순한 “디스크 X 교체” 튜토리얼로 만들어서는 안 됩니다.
복구 가능성이 남아 있을 때 분리 또는 포맷을 클릭하지 마세요
이 안전성 측면에서 커뮤니티의 첫 번째 조언은 옳았습니다. 데이터가 중요하고 어레이의 실제 상태를 알 수 없다면, 복구를 더 어렵게 만들 수 있는 파괴적인 UI 작업은 피해야 합니다. 먼저 읽을 수 있는 데이터를 백업하세요.
각 디스크는 단독으로 테스트했을 때 작동했습니다
원글 작성자는 드라이브를 한 번에 하나씩 분리했으며, 각각 작동 가능한 시스템/데이터 경로를 제공했다고 말했습니다. 이는 한 디스크가 물리적으로 고장 났다는 가정을 즉시 약화시켰습니다.
두 드라이브를 다시 연결하자 정상적인 [UU] md 어레이가 생성되었습니다 md0 : active raid1 ... [2/2] [UU]. 당시 Linux md 계층은 두 구성원이 모두 연결된 것으로 판단했습니다.
이 때문에 이후 논의는 RAID 메타데이터만이 아니라 케이블, SATA 포트, 컨트롤러, 어댑터/백플레인 및 전원 안정성으로 옮겨갔습니다.
SATA/전원 불안정은 RAID 장애처럼 보일 수 있습니다
이후 원문에서는 SATA, USB 및 디스플레이 동작에 영향을 미치는 더 광범위한 장애가 보고되었습니다. 커뮤니티에서는 SATA 케이블 교체, 다른 포트 테스트, 불안정한 분배기/어댑터 사용 자제, I/O 리셋 발생 여부를 확인하면서 부하 테스트 수행 등을 제안했습니다.
이는 커뮤니티의 진단 시도였으며, IceWhale이 확인한 하드웨어 결함은 아니었습니다.
이후 발생한 긴급 모드/NFS 문제는 별개의 계층이었습니다
케이블을 변경하고 재부팅한 후 시스템은 긴급 모드로 진입했으며 NFS/RPC 관련 오류를 표시했습니다. 커뮤니티에서 NFS 상태를 초기화하거나 NFS를 비활성화하려고 했지만, 수리가 확인되지는 않았습니다.
NFS가 원래 RAID에 접근할 수 없었던 원인이라고 추정해서는 안 됩니다. NFS 문제는 이미 시스템 전반에 불안정성이 나타나고 있던 상황에서 나중에 발생했습니다.
시스템이 다른 ZimaOS 슬롯으로도 전환되었습니다
사용자는 A가 아닌 Block/Slot B에서 부팅되었다고 보고했습니다. 현재 ZimaOS는 복구를 위해 이중 시스템 슬롯을 사용하므로, 대체 슬롯으로 부팅되었다는 것은 RAID의 사용자 데이터가 사라졌다는 의미가 아니라 시스템 슬롯 중 하나가 상태/부팅 검사를 통과하지 못했음을 나타낼 수 있습니다.
현재 ZimaOS 이중 슬롯 복구 모델을 참조하세요.
현재 ZimaOS에는 공식 RAID 1 복구 워크플로가 있습니다
ZimaOS 1.4.4에는 성능이 저하되거나 손상된 어레이를 위한 RAID1 복구 기능이 추가되었으며, 복구 중 이전에 사용하던 디스크를 사용할 수 없었던 문제가 수정되었습니다.
기존의 수동 mdadm 변경 명령을 적용하기 전에 공식 RAID1 복구 기능을 사용하세요.
최신 ZimaOS 릴리스에서는 RAID 메타데이터의 복원력이 향상되었습니다
ZimaOS 1.6.0에는 OS 재설치 또는 장치 교체 후 원래 어레이를 자동으로 다시 식별하고 마운트하도록 설계된 RAID 메타데이터 저장 메커니즘이 추가되었습니다. 이는 1.5.x 당시 소스보다 복구 경로를 개선합니다.
현재 권장되는 복구 순서
- 어레이를 포맷하거나 해제하지 마세요.
- 읽기 전용 진단으로 디스크 모델/일련번호와 현재 RAID 상태를 확인하세요.
- 접근 가능한 데이터를 즉시 백업하세요.
- 케이블, 포트, 전원, SMART 및 커널 I/O/재설정 로그를 확인하세요.
- 어레이가 실제로 성능 저하 상태일 때는 현재 RAID 복구 UI를 사용하세요.
- OS 슬롯 복구와 RAID 데이터 복구를 별도로 처리하세요.
복구 과정은 결국 ZimaOS 초기화/복구 옵션에 도달했습니다
[UU] md 상태는 당시 RAID 1의 두 멤버가 모두 존재했음을 의미합니다
두 디스크를 다시 연결한 후, 소스에서는 두 멤버가 포함된 활성 상태의 어레이가 표시되었고 [UU]. 이는 당시 미러 자체가 성공적으로 다시 조립되었다는 강력한 증거였습니다.
이는 어레이가 이전에 접근할 수 없는 상태로 나타났던 이유나, 이후 SATA/USB/모니터 불안정이 계속된 이유를 설명하지 않습니다.
읽기 전용 진단은 수동 mdadm 복구 명령보다 안전합니다
커뮤니티에서는 변경을 제안하기 전에 어레이 및 상태 정보를 요청했습니다. 이것이 올바른 순서입니다. 구성원 추가·제거 또는 메타데이터 재생성 전에 어떤 장치가 어레이에 속하는지, 어레이가 활성 상태인지 성능 저하 상태인지, 커널이 무엇을 보고하는지 확인해야 합니다.
다음을 복사하지 마세요 mdadm --create다른 Linux 사례에서 가져온 강제 어셈블리 또는 슈퍼블록 삭제 명령을 데이터의 유일한 사본이 들어 있는 RAID에 복사하지 마세요.
어레이를 읽을 수 있게 되면 중요한 데이터를 한 번 복사하세요
소스의 사용자는 액세스 권한을 복구했습니다. 이 시점에서는 케이블, 컨트롤러, 시스템 슬롯, NFS 또는 재설치를 계속 실험하기 전에 복구할 수 없는 데이터를 독립된 스토리지에 복사하는 것이 우선입니다.
RAID 1은 이중화를 제공하지만 호스트나 컨트롤러가 불안정하면 두 구성원이 동시에 사용할 수 없게 될 수 있습니다.
SATA, USB, 디스플레이 문제가 함께 나타나면 진단 범위를 넓히세요
이후 증상은 더 이상 단순한 디스크 하나의 고장으로 설명되지 않았습니다. 간헐적인 SATA 인식 문제, USB 동작 문제, 모니터 및 부팅 문제는 케이블, 전원, 컨트롤러, 메인보드 펌웨어 또는 기타 플랫폼 불안정을 가리킬 수 있습니다.
RAID를 반복해서 재구축하기 전에 정상 작동이 확인된 전원과 케이블을 테스트하고 하드웨어 구성을 단순화하세요.
시스템 슬롯 복구와 RAID 복구는 별개입니다
ZimaOS는 OS 복구를 위해 다른 시스템 슬롯에서 부팅할 수 있습니다. Slot B로 전환하면 OS 슬롯 문제를 복구하거나 우회할 수 있지만, 성능이 저하된 어레이 자체를 복구하지는 않습니다.
OS 슬롯도 정상적으로 작동하지 않는 경우, 현재 ZimaOS 시스템 복구 모델을 사용하세요.
복구 계획에 해당하는 경우 OS 재설치 시 데이터 디스크 분리
소스 커뮤니티에서는 잘못된 드라이브를 선택하거나 수정할 가능성을 줄이기 위해 OS를 새로 설치하는 동안 RAID 디스크를 분리할 것을 권장했습니다. 현재 IceWhale 지원팀에서 재설치 계획을 제공하는 경우, 먼저 모든 디스크에 라벨을 붙이고 스토리지 메타데이터와 백업을 보존하세요.
RAID 1 복구 FAQ
소스에서 한 디스크가 확실히 고장 났다고 했나요?
아니요. 이후 두 디스크 모두 독립적으로 작동했고 어레이에는 다음과 같이 표시되었습니다 [UU] 다시 연결했을 때.
소스에서는 최종 원인 하나를 확인했나요?
아니요. RAID, SATA/전원 불안정, NFS 시작, OS 슬롯 문제가 서로 겹쳐 있었습니다.
현재 ZimaOS에는 RAID1 복구 기능이 있나요?
예. IceWhale은 1.4.4에서 공식 RAID1 복구 절차를 추가했습니다.
