커뮤니티에서 논의하는 복구 목표는 실제로 서로 다른 세 가지입니다. 대체할 수 없는 파일 보호, 애플리케이션 설정 보존, 전체 ZimaOS 시스템 디스크 복제입니다. 이들은 동일한 백업 작업이 아닙니다.
교체 가능한 시스템 계층보다 먼저 영구 데이터를 백업하세요
현재 ZimaOS 지침은 컨테이너 런타임과 영구 데이터를 분리합니다. 앱 스토어 컨테이너는 다시 만들 수 있지만, 해당 컨테이너의 설정과 데이터베이스는 영구 폴더에 저장됩니다. ZimaOS 데이터 마이그레이션에서는 ZimaOS가 관리하는 앱 데이터가 저장되고 이동되는 위치를 설명하며, ZimaOS 백업 워크플로에서는 현재 기본 제공되는 백업 워크플로를 제공합니다.
3-2-1 백업 전략은 더 광범위한 전략입니다. 복사본을 두 개 이상 보관하고, 다시 만들 수 없는 데이터는 오프사이트 복사본도 포함하는 것입니다.
ZimaOS 백업 작업은 전체 디스크 이미지와 다릅니다
원문의 사용자는 Clonezilla도 고려했습니다. 공식 Clonezilla 디스크 이미징은 디스크 이미지 수준에서 작동하며, 이미지를 대상 디스크에 복원할 수 있습니다. 이는 전체 시스템 디스크의 특정 시점 복사본을 원할 때 유용합니다.
반면 기본 제공되는 ZimaOS 백업 워크플로는 선택한 폴더와 반복적인 데이터 보호에 더 적합합니다. 전체 디스크 이미징은 교체 가능한 운영 체제 및 컨테이너 데이터를 대량으로 복사할 수 있으며, 일상적인 복구에는 이러한 데이터가 필요하지 않을 수 있습니다.
파일 수준의 제어가 필요할 때 rsync가 유용합니다
rsync 파일 백업은 올바르게 구성하면 권한과 속성을 보존할 수 있는 파일 복사 및 미러링 도구입니다. 선택한 애플리케이션 폴더를 고급 예약 복사 방식으로 백업할 때 유용하지만, 어떤 영구 폴더를 복원해야 하는지 알고 있을 때만 백업의 가치가 있습니다.
실용적인 복구 계획
- 먼저 사용자 파일과 데이터베이스를 백업합니다.
- 영구 애플리케이션 설정과 앱 데이터를 포함합니다.
- 별도의 미디어에 최소 한 개의 백업을 보관합니다.
- 대체할 수 없는 데이터는 오프사이트 복사본을 보관합니다.
- 정확한 시스템 디스크 상태를 복원하는 것이 추가 용량과 유지 관리 비용을 감수할 만큼 중요한 경우에만 전체 시스템 이미지를 사용합니다.
- 백업이 완전하다고 가정하기 전에 복원을 테스트합니다.
결론
일반적으로 운영 체제 장애에서 복구하기 위해 수 테라바이트 규모의 ZimaOS 시스템 드라이브를 바이트 단위로 복사할 필요는 없습니다. 다시 만들 수 없는 파일, 데이터베이스, 애플리케이션 설정을 우선적으로 백업하세요. 정확한 시스템 상태 복구가 실제 요구 사항일 때만 전체 디스크 이미지를 추가하면 됩니다.
