이 스레드는 이후 기본 제공 기능으로 발전한 실제 제품 기능 공백을 기록합니다. ZimaOS 1.4.1에서는 750GB 드라이브 하나가 고장 난 후 2디스크 RAID 1이 성능 저하 및 읽기 전용 상태로 전환되었습니다. 교체 디스크는 별도의 정상 HDD로 표시되었지만, 스토리지 UI에는 명확한 “교체 및 재구축” 작업이 제공되지 않았습니다.
IceWhale은 처음에 엔지니어링 지원과 CLI 진단을 통해 영향을 받은 사용자들을 지원했습니다. 이후 Zima-Giorgio는 ZimaOS 1.4.4에서 더욱 종합적인 RAID 1 복구 프로세스를 제공할 것이라고 발표했습니다. 현재 공식 1.4.4 릴리스 노트에서도 성능이 저하되거나 손상된 어레이에 RAID1 복구 기능이 추가되었다고 확인됩니다.
소스 RAID가 보호 / 읽기 전용 상태로 전환됨
교체 HDD는 별도로 감지됨
1.4.1 스토리지 페이지에서 새 디스크가 필요하다고 경고
IceWhale, 사용자들에게 위험한 자체 복구를 피하라고 권고
Zima-Giorgio는 엔지니어링 지원을 제공하고 숙련된 사용자들에게 수집해 달라고 요청했습니다 lsblk 및 mdadm -D /dev/md0 출력했습니다. 그는 파괴적인 재구축 절차를 공개하지 않았습니다.
엔지니어들이 이후 다른 사용자의 어레이를 비공개로 복구한 뒤, 그는 충분한 지식이나 엔지니어의 직접적인 지시 없이 루트 수준의 RAID 작업을 수행하지 말라고 명확히 경고했습니다.
ZimaOS 1.4.4, WebUI에 RAID 1 복구 기능 추가
2025년 9월 4일, Zima-Giorgio는 1.4.4에서 더욱 종합적인 RAID 1 복구 프로세스를 제공할 것이라고 말했습니다. 다른 사용자가 1.4.4의 CLI 지원을 요청하자 Giorgio는 1.4.4에서 WebUI를 통해 복구를 수행할 수 있다고 답했습니다.
현재 IceWhale 릴리스 노트에는 다음과 같이 명시되어 있습니다. “RAID1 복구 기능 추가: RAID1 배열이 성능 저하 또는 손상 상태일 때 복구를 수행할 수 있습니다.”
기존의 root/mdadm 실험을 재현하는 대신 공식 ZimaOS 1.4.4 RAID 1 복구 기능을 사용하세요.
1.4.4에서 복구 중 이전에 사용된 디스크 문제도 수정됨
동일한 릴리스 노트에 RAID 복구 중 이전에 사용된 디스크를 선택할 수 없던 문제가 ZimaOS에서 수정되었다고 나와 있습니다. 디스크에 기존 서명이 남아 있거나 별도로 초기화되어 있을 수 있는 교체 드라이브 작업과 직접적으로 관련된 내용입니다.
고장 난 구성원과 최소한 같은 크기의 교체 디스크를 사용하세요
RAID 1 복구에는 배열의 기존 데이터 레이아웃을 수용할 만큼 충분히 큰 교체 구성원이 필요합니다. 명목상 동일한 “750 GB” 또는 “2 TB” 드라이브라도 섹터 수가 약간 다를 수 있으므로, 사용 가능한 용량이 더 작은 드라이브는 거부될 수 있습니다.
가능하다면 위험한 복구를 수행하기 전에 읽을 수 있는 데이터를 백업하세요
성능이 저하된 RAID 1은 이미 중복성을 잃은 상태입니다. 복구 중 남은 디스크까지 고장 나면 배열을 잃을 수 있습니다. 배열을 읽을 수 있고 데이터가 아직 백업되지 않았다면, 침습적인 복구를 수행하기 전에 대체할 수 없는 데이터를 독립된 드라이브에 복사하세요.
기존 구성원 디스크 위에 RAID 생성을 클릭하지 마세요
ZimaOS에서 기존 RAID 구성원이 사용되지 않거나 별도의 디스크로 표시된다면, 새 RAID를 생성하는 과정에서 메타데이터를 덮어쓸 수 있습니다. 진행하기 전에 기존 성능 저하 배열을 복구하는 것인지, 아니면 의도적으로 비어 있는 새 배열을 생성하는 것인지 확인하세요.
RAID 1 복구는 남은 디스크에 높은 부하가 걸리는 기간입니다
복구 중에는 ZimaOS가 교체 디스크에 데이터를 쓰는 동시에 정상적으로 남아 있는 구성원을 광범위하게 읽어야 합니다. 남은 기존 디스크가 이미 한계 상태라면, 이 과정에서 읽을 수 없는 섹터나 기타 고장이 드러날 가능성이 가장 높습니다.
따라서 성능이 저하된 배열을 여전히 읽을 수 있다면, 복구 작업에 앞서 대체할 수 없는 데이터를 외부에 백업해야 합니다.
교체 디스크가 별도의 저장 공간으로 표시된다는 이유만으로 포맷하지 마세요
소스 사례에서 사용자는 이미 새 디스크를 포맷했고 ZimaOS에는 해당 디스크가 HDD-Storage로 표시되었습니다. 이후 1.4.4의 수정 사항에서는 이전에 사용된 디스크를 RAID 복구에 사용할 수 없었던 문제가 구체적으로 해결되었습니다.
현재 시스템에서는 RAID 복구 절차를 따르고 ZimaOS가 선택한 교체 디스크를 준비하도록 하세요. 먼저 다른 저장 공간을 포맷하거나 생성하면 복구 UI가 추가된 메타데이터를 처리해야 할 수 있습니다.
읽기 전용 진단이 수동 RAID 변경보다 안전합니다
Zima-Giorgio가 요청한 명령은 다음과 같습니다—lsblk 및 mdadm -D /dev/md0—장치와 어레이 상태를 확인하기 위해 진단용 읽기 명령을 사용했습니다. 이는 구성원을 추가하거나 슈퍼블록을 초기화하거나 강제로 어셈블하거나 어레이를 다시 생성하는 명령과는 전혀 다릅니다.
지원팀에서 CLI 출력을 요청하면 요청한 읽기 전용 정보를 정확히 수집하고, 관련 없는 Linux 튜토리얼을 참고해 파괴적인 mdadm 작업을 임의로 수행하지 마세요.
재구축 완료 후 어레이 확인
교체 디스크가 승인되는 순간 복구가 완료되었다고 생각하지 마세요. 동기화/재구축이 끝날 때까지 기다리고, RAID가 정상/보호 상태로 돌아왔는지 확인한 뒤, 대표적인 파일을 열어 보고 풀에 의존하는 애플리케이션이 정상적으로 작동하는지 확인하세요.
이러한 확인이 완료될 때까지 외부 백업을 변경하지 마세요.
어레이가 정상일 때 다음 디스크 장애에 대비하기
RAID 1은 장애가 발생한 구성원을 교체할 시간을 제공하지만 백업의 필요성을 없애 주지는 않습니다. 중요한 데이터의 독립적인 사본을 보관하고 디스크 모델 및 일련 번호를 기록하며, 상태를 정기적으로 확인하여 두 번째 구성원이 고장 나기 전에 성능 저하 상태를 파악할 수 있도록 하세요.
RAID 1 복구 FAQ
ZimaOS 1.4.1 UI에서 RAID 1 복구 기능이 누락되어 있었나요?
소스의 사용자는 성능이 저하된 어레이와 교체 디스크는 볼 수 있었지만, 일반적인 복구 작업을 실행할 수는 없었습니다.
IceWhale은 나중에 WebUI 복구 절차를 추가했나요?
예. IceWhale은 1.4.4에서 WebUI를 통해 RAID 1을 복구할 수 있다고 밝혔으며, 공식 릴리스 노트에도 RAID1 복구가 새로운 기능으로 명시되어 있습니다.
현재 사용자는 이전 스레드의 루트 mdadm 명령을 실행해야 하나요?
아니요. IceWhale은 사용자가 위험을 이해했거나 엔지니어의 안내를 받은 경우가 아니라면 루트 수준의 RAID 작업을 수행하지 말라고 명시적으로 경고했습니다.
