OS 재설치 후 ZimaOS RAID 1 복구

ZimaOS를 재설치한 후 기존 RAID 1이 사용되지 않는 디스크로 표시되더라도 Create RAID를 즉시 클릭하지 마세요. 배열을 다시 만들거나 포맷하면 구성원 디스크에 아직 남아 있는 데이터가 손상될 수 있습니다.

첫 번째 복구 경로는 현재 공식 ZimaOS 방법인 저장된 파일을 복원하는 것입니다. local-storage.db 이 페이지의 기반이 된 커뮤니티 튜토리얼은 해당 데이터베이스를 백업하지 않은 더 까다로운 경우를 위한 보다 침습적인 대체 절차를 설명합니다. 이 대체 절차는 ZimaOS 1.6.1에서 테스트되었지만 파괴적인 RAID 작업이 포함되어 있으므로 원본 데이터를 별도로 복사하고 검증한 후에만 고려해야 합니다.

첫 번째 선택: local-storage.db 복원

ZimaOS는 다음 위치에 스토리지 구성 정보를 보관합니다.

/ZimaOS-HD/.casaos/db/local-storage.db

현재 공식 복구 가이드에서는 시스템을 재설치하기 전에 이 파일을 다운로드한 다음, 새 ZimaOS 설치 후 같은 디렉터리에 다시 넣고 재부팅할 것을 권장합니다.

재설치 후 ZimaOS의 공식 RAID 복구

기존 시스템 디스크에 아직 액세스할 수 있다면 RAID 구성원 디스크를 건드리기 전에 이 데이터베이스를 복구해 보세요.

데이터 배열이 여전히 온전할 수 있는 이유

ZimaOS는 Linux 소프트웨어 RAID를 사용합니다. 새 ZimaOS 설치에서 기존 스토리지 데이터베이스를 더 이상 사용하지 않더라도 구성원 디스크에는 RAID 메타데이터가 남아 있을 수 있습니다. 따라서 디스크가 물리적으로 연결되어 있어도 UI에서는 기존 풀이 더 이상 인식되지 않을 수 있습니다.

ZimaOS 1.6에서는 RAID 메타데이터 복구 및 재식별 동작도 개선되었으므로, 한 시스템에서 원래 발생한 문제가 이후의 모든 버전에서 동일하게 발생한다고 단정해서는 안 됩니다.

복구 여부가 결정될 때까지 새 RAID를 생성하지 마세요

디스크에 필요한 데이터가 포함되어 있다면 다음 작업을 피하세요.

구성원 디스크 중 하나를 포맷하기
동일한 디스크 위에 새 RAID를 생성하기
실행 wipefs 또는 mdadm --zero-superblock 성급하게 실행하지 마세요.
어떤 것인지 추측하여 /dev/sdX 어떤 장치인지.

복구 작업을 시작하기 전에 장치 문자에만 의존하지 말고 모델, 일련번호, 용량으로 디스크를 식별하세요.

RAID 메타데이터를 읽기 전용으로 확인

커뮤니티 작성자는 먼저 읽기 전용 검사를 사용해 두 RAID 1 구성원이 여전히 동일한 배열에 속해 있는지 확인했습니다.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

정상적인 RAID 1에서는 두 구성원이 동일한 배열 UUID와 호환되는 RAID 메타데이터를 보고해야 합니다. 한 구성원이 누락되었거나 성능이 저하된 상태이거나 다른 메타데이터를 보고하면 중지하고 일반적인 재구축 절차를 따르는 대신 복구 지원을 받으세요.

기존 어레이를 읽기 전용으로 조립 및 마운트

고급 복구의 경우 읽기 전용으로 어레이를 조립하면 파일에 액세스할 수 있는지 확인하는 동안 소스가 수정될 가능성을 줄일 수 있습니다.

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

그런 다음 파일 시스템을 확인합니다.

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

위의 장치 이름은 예시일 뿐입니다. 해당 이름이 자신의 하드웨어와 일치하는지 확인하지 않았다면 그대로 붙여 넣지 마세요.

파괴적인 작업을 수행하기 전에 전체 오프로드 복사본 생성

소스 워크플로에서는 사용 중인 모든 RAID 데이터를 저장할 수 있을 만큼 큰 외장 ext4 드라이브를 사용했습니다. Linux 애플리케이션 데이터의 경우 ext4는 일반적인 소유권, 권한, 링크, ACL 및 확장 속성을 보존할 수 있어 유용합니다.

일반적인 아카이브 방식의 복사 명령은 다음과 같습니다.

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

다음에서 복사 작업을 실행합니다. tmux 또는 SSH 연결이 끊겨도 작업이 중단되지 않는 다른 영구 터미널에서 실행합니다.

계속 진행하기 전에 백업 확인

rsync 종료 메시지만 신뢰하지 마세요. 파일 개수를 비교하고 주요 디렉터리 크기를 확인하세요.

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

대체할 수 없는 데이터라면 두 번째 독립 백업을 권장합니다. RAID 자체는 백업이 아닙니다.

최후의 수단: 오프로드하고 기존 RAID 메타데이터를 제거한 후 UI에서 다시 생성

원래 커뮤니티 작성자는 복구된 어레이를 정상적인 ZimaOS UI 관리 상태로 되돌리고자 했습니다. 최후의 수단으로 사용한 방법은 다음과 같습니다.

기존 어레이를 읽기 전용으로 확인합니다.
모든 데이터를 외장 드라이브에 복사합니다.
복사본을 확인합니다.
기존 md 어레이를 중지합니다.
기존 RAID 메타데이터를 제거합니다.
ZimaOS Storage UI를 사용하여 새로운 RAID 1을 생성합니다.
복사한 파일을 복원합니다.
복원된 데이터를 확인합니다.

이 절차는 기존 RAID 메타데이터를 의도적으로 삭제합니다. 이 단계를 수행하면 오프로드 복사본이 복구 소스가 됩니다. 복사본이 불완전하거나 장치 식별 정보가 확실하지 않다면 이 방법을 사용하지 마세요.

소스 워크플로의 되돌릴 수 없는 명령

커뮤니티에서 사용한 절차:

mdadm --zero-superblock /dev/sda /dev/sdb

이는 문제 해결 명령이 아닙니다. 지정한 디스크에서 RAID 메타데이터를 제거합니다. 잘못된 장치 경로를 지정하면 심각한 데이터 손실이 발생할 수 있습니다.

따라서 ZimaOS UI가 RAID를 인식하지 못한다는 이유만으로 실행하는 것은 권장하지 않습니다. 복원 local-storage.db현재 ZimaOS 복구 동작을 확인하고, 어레이에 중요한 데이터가 포함된 경우 먼저 지원팀에 문의하세요.

ZimaOS UI를 통해 어레이를 다시 생성하는 이유

이 소스 워크플로의 목적은 Storage UI 외부에서 수동으로 조립한 md 장치를 영구적으로 사용하는 것이 아니라, ZimaOS가 정상적으로 관리하는 스토리지 풀로 마무리하는 것입니다.

기존 데이터를 안전하게 오프로딩하고 디스크를 의도적으로 초기화한 후, 현재 Storage 인터페이스를 사용하여 RAID 1을 생성하고 초기 동기화가 완료될 때까지 기다리세요.

새 풀에 파일 복원

새 풀이 생성되고 마운트되면 오프로딩 디스크에서 복원하세요.

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

바꾸기 /media/Storage 시스템에 표시된 실제 대상 경로로 바꾸세요.

복원된 풀 검증

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

RAID 동기화가 완료되고 ZimaOS 파일 인터페이스와 해당 데이터에 의존하는 애플리케이션을 통해 정상적으로 액세스할 수 있음을 확인할 때까지 오프로딩 드라이브를 변경하지 말고 그대로 두세요.

다음 재설치 전에 local-storage.db 백업하기

가장 쉬운 복구는 미리 준비해 둔 복구입니다. 다음 파일의 최신 사본을 보관하세요.

/ZimaOS-HD/.casaos/db/local-storage.db

시스템 드라이브 외부에 있습니다. 이제 공식 문서에서 이 파일을 사용한 직접 복원 절차를 제공합니다.

어떤 복구 경로를 선택해야 하나요?

상황	권장 작업
local-storage.db를 백업함	공식 데이터베이스 복원 방법을 사용하세요
기존 시스템 디스크를 아직 읽을 수 있음	RAID 디스크를 수정하기 전에 local-storage.db를 복구하세요
데이터베이스 백업 없음, RAID 메타데이터는 정상으로 보임	데이터를 파괴할 수 있는 작업을 중단하고 지원 또는 복구 조언을 구하세요
완전히 검증된 오프로딩 복사본이 있으며 의도적으로 UI에서 관리하는 새 어레이를 원함	커뮤니티의 오프로딩/재생성/복원 방법을 고려하세요
RAID 멤버에 메타데이터 불일치 또는 성능 저하가 표시됨	중단하고 전문 복구 안내를 따르세요

ZimaOS RAID 복구 FAQ

ZimaOS를 재설치하면 RAID 데이터가 자동으로 삭제되나요?

시스템 디스크 재설치는 RAID 멤버 디스크 포맷과 다릅니다. RAID 구성은 손실될 수 있지만 멤버 디스크의 RAID 메타데이터와 데이터는 남아 있을 수 있습니다.

기존 디스크가 사용되지 않음으로 표시되면 RAID 생성 버튼을 클릭해야 하나요?

기존 데이터를 복구할 필요가 없음을 확인하기 전까지는 안 됩니다. 새 RAID를 생성하면 데이터가 파괴될 수 있습니다.

local-storage.db를 백업했다면 가장 안전한 복구 방법은 무엇인가요?

현재 공식 ZimaOS 절차를 사용하여 해당 데이터베이스를 복원한 후 재부팅하세요.

mdadm 슈퍼블록을 0으로 초기화해도 안전한가요?

RAID 메타데이터를 의도적으로 파괴합니다. 데이터가 다른 곳에 안전하게 복사되었음을 확인한 복구 계획의 일부로만 사용하세요.