이 커뮤니티 튜토리얼의 2페이지에서는 “dd를 어떻게 실행하지?”라는 결정이 “실제로 무엇을 보호할 가치가 있지?”라는 질문으로 바뀝니다. 사용자는 이미 대용량 라이브 NVMe를 사용하고 있었고, 부팅 가능한 OS를 잃는 것보다 DATA를 잃는 일을 훨씬 더 우려했습니다. gelbuilding의 조언은 라이브 부팅 NVMe를 재파티션하지 말고, 먼저 DATA/AppData를 보호하며, 복구 시간 단축 효과가 추가 백업 공간을 사용할 만한 가치가 있을 때만 원시 시스템 복제본을 보관하라는 것이었습니다.
이 우선순위는 현재 ZimaOS 아키텍처에 부합합니다. OS에는 빠른 복구를 위한 A/B 시스템 슬롯이 있는 반면, 대체할 수 없는 사용자 데이터, AppData, 스토리지 메타데이터는 이러한 변경 불가능한 시스템 이미지 외부에 저장됩니다. 전체 디스크 복제본을 사용하면 시스템을 특정 시점의 정확한 상태로 빠르게 되돌릴 수 있지만, 독립적이고 버전이 관리되는 DATA 백업을 대신할 수는 없습니다.
dd는 작은 OS 슬롯만이 아니라 장치 전체를 복제합니다
원래 튜토리얼에서는 개념적으로 다음과 같은 명령을 사용합니다.
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gz시스템이 1TB NVMe에 설치되어 있다면 원시 이미징 과정에서는 여전히 전체 블록 장치를 읽습니다. 압축을 통해 파일 크기를 줄일 수는 있지만, 백업 대상과 과정은 ZimaOS 시스템 파티션에서 사용 중인 몇 기가바이트가 아니라 물리 디스크 레이아웃에 따라 결정됩니다.
dd 크기를 줄이기 위해 정상적으로 작동하는 라이브 시스템을 재파티션하지 마세요
gelbuilding은 실수로 인해 가동 중단이나 데이터 손실이 발생할 수 있으므로 라이브 부팅 NVMe의 재파티션을 고위험 작업으로 보았습니다. 현재 레이아웃이 정상적으로 작동한다면 파티션 경계를 변경하기 전에 검증된 데이터 백업을 먼저 만드세요.
OS 복제본보다 먼저 DATA와 AppData를 보호하세요
복구 가능성을 우선한다면 다음을 백업하세요.
- 사용자 파일과 스토리지 풀
- 쉽게 재생성할 수 없는 AppData/데이터베이스/구성
- 중요한 애플리케이션별 내보내기 파일
- 필요한 경우
local-storage.db와 같은 ZimaOS 스토리지 메타데이터 - 그다음 선택적으로 전체 시스템 디스크
현재 ZimaOS 3-2-1 지침은 독립적인 대상에 예약 백업을 수행하고 버전이 관리되는 복원 지점을 만드는 방식을 지원합니다.
현재 ZimaOS 3-2-1 백업 모델을 사용하세요.
현재 ZimaOS에는 이미 A/B 시스템 복구 기능이 있습니다
ZimaOS는 각각 약 6GB인 두 개의 시스템 슬롯을 사용합니다. 한 슬롯에 문제가 발생하면 현재 복구 가이드에 따라 GRUB에서 다른 슬롯으로 부팅할 수 있습니다.
현재 A/B 시스템 복구 경로를 사용하세요.
클린 재설치로 OS는 복구할 수 있지만 정확한 설정이 자동으로 재현되지는 않습니다
constgen이 지적했듯이 변경 불가능한 OS는 대개 간단히 재설치할 수 있습니다. gelbuilding의 반론은 복구 시간에 관한 것이었습니다. 디스크 복제본을 사용하면 캡처한 앱/구성/시스템 상태를 정확히 복원할 수 있지만, 재설치 후에는 AppData를 다시 매핑하고 앱을 재설치하며 스토리지 메타데이터를 다시 연결해야 할 수 있습니다.
두 방법 모두 유효한 복구 전략이지만, 각각 최적화하는 대상이 다릅니다.
전용 소형 부팅 디스크를 사용하면 전체 디스크 복제가 간단해집니다
gelbuilding은 장기적으로 ZimaOS를 32~64GB 전용 장치로 옮기고, 대용량 NVMe/RAID 스토리지는 DATA/AppData로 유지할 것을 권장했습니다. 현재 ZimaOS 설치에 필요한 정확한 최소 용량은 25GB 이상입니다.
이렇게 하면 일회성으로 취급할 수 있는 OS와 대용량 데이터 스토리지가 분리되어 전체 시스템 이미지도 훨씬 작아집니다.
원시 복원 명령은 파괴적입니다
dd 이미지를 복원하면 대상 디스크에 직접 덮어씁니다. 잘못된 /dev/... 대상을 선택하면 다른 드라이브의 데이터가 파괴될 수 있습니다. 원래 튜토리얼은 테스트를 위해 공유된 것이었으며, 이러한 명령은 디스크를 모델명과 일련번호로 식별하고 DATA를 다른 곳에 보존한 후에만 사용해야 합니다.
백업 생성뿐 아니라 복구 경로도 테스트하세요
복원 방법을 알고 있을 때만 백업이 유용합니다. DATA의 경우 대표적인 파일을 복원해 보세요. 원시 시스템 이미지의 경우 실제 장애가 발생했을 때 장치와 경로 가정을 확인하게 되지 않도록, 가능하다면 예비 미디어에서 복구 절차를 테스트하세요.
ZimaOS 복제본과 백업 FAQ
ZimaOS 데이터를 보호하려면 전체 시스템 디스크 복제본이 반드시 필요한가요?
아니요. DATA/AppData 백업과 스토리지 메타데이터는 A/B 시스템 파티션과 별개이며, 대체할 수 없는 정보에 대해서는 더 높은 우선순위를 가집니다.
그렇다면 원시 OS 복제본을 보관하는 이유는 무엇인가요?
시스템과 앱 구성을 수동으로 다시 구축하는 대신 캡처한 정확한 상태를 복원할 수 있어 복구 시간을 줄일 수 있습니다.
복제본 크기를 줄이기 위해 라이브 NVMe를 재파티션해야 하나요?
원래 권장 사항은 아니었습니다. 먼저 DATA를 백업하고 불필요한 라이브 파티션 변경을 피하세요.
