아키텍처 목표는 타당합니다. 최대 처리량이 정말 필요한 워크로드에만 RAID 0 SSD를 사용하고, 독립적인 HDD 백업으로 이 고위험 작업 풀을 보호하며, 최소 한 개의 사본은 오프사이트에 보관하는 방식입니다. RAID 0에는 중복성이 없으므로 SSD 하나만 고장 나도 전체 작업 어레이를 사용할 수 없게 됩니다.
2025년 커뮤니티 답변에서는 독립적인 순환 HDD와 야간 rsync 사용을 권장했지만, 원 게시자는 중요한 이의를 제기했습니다. ZimaOS에는 이미 Backup의 자동 모드가 있었고, 기존 HDD를 같은 베이에 다시 장착하면 자동으로 인식되는지 알고 싶었던 것입니다. 해당 스레드는 이 질문에 답변하기 전에 끝났습니다. 현재 IceWhale 문서에서는 지원되는 기준선을 더 명확하게 제시합니다. Backup 앱은 예약 작업, 여러 독립 대상, 재개 및 오류 허용, 버전이 지정된 복원 지점을 지원합니다. 그러나 현재 공개 문서에는 “이전에 사용하던 HDD를 같은 베이에 장착하면 디스크 ID를 기준으로 자동 조정한다”는 보장된 워크플로가 설명되어 있지 않습니다.
RAID 0에는 실제 백업 계획이 필요합니다
RAID 0은 패리티나 미러링 없이 SSD를 결합해 용량과 성능을 높입니다. 구성원 디스크 하나만 고장 나도 어레이 전체가 손상될 수 있습니다. 전문 작업에서는 백업을 나중에 추가하는 기능이 아니라 설계의 일부로 다뤄야 합니다.
독립 백업 HDD가 RAID 1보다 순환 운용에 적합합니다
커뮤니티에서는 26TB HDD 두 개를 RAID 1로 묶기보다 각각 독립적으로 유지할 것을 권장했습니다. 이렇게 하면 각 디스크가 완전한 이동식 오프사이트 사본이 되며, 드라이브를 교체할 때마다 미러를 재구축할 필요가 없습니다.
이는 커뮤니티의 설계 권장 사항이지 IceWhale의 요구 사항은 아닙니다. 두 HDD가 모두 장착된 동안에는 RAID 1이 가용성을 높일 수 있지만, 물리적으로 순환시키거나 오프사이트에 보관하는 방식으로는 불편합니다.
현재 ZimaOS Backup은 핵심적인 3-2-1 워크플로를 지원합니다
현재 IceWhale 문서에 따르면 하나의 Backup 앱에서 Zima, USB, LAN 또는 클라우드를 소스와 대상으로 사용할 수 있고, 예약된 시간에 작업을 실행하며, 중단된 전송을 재개하고, 버전 및 복원 지점을 유지하며, 하나의 소스에서 여러 대상에 이르는 여러 작업을 관리할 수 있습니다.
현재 ZimaOS Backup 모델을 사용하세요.
2025년의 “모든 변경 사항에 즉시 실행”이라는 자동 모드 설명을 그대로 확정하지 마세요
원 게시자는 파일이 변경될 때 Zima/USB 소스가 즉시 실행될 수 있다는 UI 문구를 인용했습니다. 같은 시기의 다른 공식 커뮤니티 논의에서는 ZimaOS Backup 자동 모드가 특정 시간, 일반적으로 이른 아침에 실행된다고 설명했습니다. 원문 자체에서는 이 두 설명을 조정하지 않았습니다.
현재 공개 문서는 예약 백업을 설명하며, 모든 변경 사항 이후 파일 시스템 이벤트를 기반으로 복제한다고 약속하지 않습니다. 운영 환경을 계획할 때는 오래된 UI 문구에 의존하지 말고 현재 문서에 설명된 예약 방식을 사용하세요.
rsync는 미러링 및 전송 도구이지, 자동으로 버전 관리 백업이 되는 것은 아닙니다
커뮤니티 스크립트는 다음을 사용했습니다.
rsync -avh --delete ...--delete 플래그는 RAID 0 소스에서 삭제된 항목을 대상에도 반영해 대상 미러를 만듭니다. 미러에는 유용할 수 있지만, 실수로 삭제한 파일이 백업 디스크에서도 삭제될 수 있습니다.
rsync를 사용한다면 파괴적인 플래그 없이 시작하고, --dry-run을 사용하며, 대상 경로를 확인하고, 삭제된 파일을 복구해야 한다면 스냅샷 및 버전 관리 방식을 별도로 설계하세요.
드라이브 순환에는 안정적인 식별과 명시적인 확인이 필요합니다
디스크를 하나의 물리적 베이에 교체해 장착한다고 해서 삽입된 디스크가 항상 동일한 마운트 이름이나 경로를 받는 것은 아닙니다. 견고한 순환 절차에서는 안정적인 장치 또는 스토리지 ID로 디스크를 식별하고, 예상 대상이 마운트되었는지 확인한 다음 백업을 시작해야 합니다.
이전 대상 경로에 “무언가”가 마운트되어 있다는 이유만으로 파괴적인 미러 작업을 실행하지 마세요.
중요한 작업은 몇 달에 한 번보다 더 자주 오프사이트 사본을 순환시키세요
3~4개월마다 순환하면 온사이트 작업 풀과 로컬 백업을 함께 잃었을 때 복구 지점에 큰 공백이 생깁니다. 적절한 간격은 변경 빈도와 업무상 허용 가능한 손실 범위에 따라 달라지지만, 중요한 전문 데이터라면 일반적으로 더 빈번한 오프사이트 보관 주기가 필요합니다.
순환 방식을 신뢰하기 전에 복원을 테스트하세요
각 백업 HDD에서 대표적인 프로젝트나 파일을 복원하고, 체크섬 또는 애플리케이션에서의 정상 열림 여부를 확인하세요. 그런 다음 디스크를 오프사이트로 가져가기 전에 마지막으로 성공한 백업 날짜를 기록하세요.
RAID 0 백업 FAQ
백업 HDD를 RAID 1로 구성하는 것이 독립 백업을 순환시키는 것과 같은가요?
아니요. RAID 1은 두 드라이브가 미러의 일부로 함께 있을 때 가용성을 높이며, 독립 디스크는 각각 별도의 사본으로 쉽게 분리해 오프사이트에 보관할 수 있습니다.
현재 ZimaOS 문서는 실제 변경별 실시간 복제를 보장하나요?
현재 공개 Backup 문서는 보장된 파일 시스템 이벤트 기반 미러링이 아니라 예약 작업, 재개 및 오류 허용, 버전을 설명합니다.
rsync --delete가 ZimaOS Backup보다 자동으로 더 안전한가요?
아니요. 이 명령은 삭제를 의도적으로 미러링하므로 대상 확인이 신중하게 필요하며, 실수로 인한 손실을 복구하려면 별도의 버전 관리가 필요합니다.
