ZimaOS 서버를 다른 NAS에 백업하는 가장 안전한 방법은 전체 운영 체제를 복제하는 것이 아니라, 재설치 후에도 반드시 남아 있어야 하는 데이터를 보호하는 것입니다. 사용자 폴더, 영구 Docker 앱 데이터, 애플리케이션 데이터베이스를 LAN 대상에 백업하고, 서로 다른 미디어나 오프사이트에 최소 한 개의 추가 복사본을 보관하세요.
ZimaOS는 복구를 위해 두 개의 시스템 슬롯을 사용하는 경량 어플라이언스형 시스템입니다. 따라서 복구 모델은 Synology DSM 마이그레이션 백업과 다릅니다. 운영 체제는 별도로 복구하거나 재설치할 수 있으며, 중요한 데이터는 스토리지 볼륨과 매핑된 앱 폴더에 저장됩니다. 그러므로 목표는 실행 중인 시스템의 바이트 단위 이미지가 아니라 복구 가능한 서버를 만드는 것입니다.
ZimaOS 백업에는 실제로 무엇을 포함해야 할까요?
유용한 백업 계획은 다시 만들 수 있는 소프트웨어와 대체할 수 없는 데이터를 구분하는 것에서 시작합니다. Docker 컨테이너와 App Store 패키지는 대개 다시 만들 수 있습니다. 하지만 파일, 앱 설정, 데이터베이스, 미디어 라이브러리는 대체할 수 없습니다.
사용자 폴더와 공유 데이터
Documents, Media, Photos, 프로젝트 폴더, 웹사이트 데이터 및 사용자나 애플리케이션이 활발하게 수정하는 기타 디렉터리를 백업하세요. 현재 ZimaOS 3-2-1 백업 가이드는 LAN, USB, 클라우드, Zima 간 소스와 대상 위치를 지원합니다.
영구 Docker 앱 데이터
App Store 컨테이너는 일회용이지만, 매핑된 폴더는 그렇지 않습니다. ZimaOS 문서에 따르면 설정과 영구 파일은 구성된 App Data 위치의 컨테이너 외부에 저장됩니다. 백업에 포함할 항목을 결정하기 전에 ZimaOS 앱 스토리지 경로를 확인하세요.
데이터베이스와 상태 저장 서비스
Nextcloud, WordPress, Home Assistant, Immich, MariaDB 또는 PostgreSQL 기반 애플리케이션과 같은 서비스의 경우, 실행 중인 데이터 디렉터리를 복사하는 것만으로는 충분하지 않을 수 있습니다. 상위 애플리케이션에서 데이터베이스 덤프, 내보내기 또는 유지 관리 절차를 제공한다면 이를 사용하세요. 정상적으로 생성된 데이터베이스 백업과 앱 설정 폴더를 함께 보관하는 편이, 활발하게 기록 중인 데이터베이스를 일관성 없이 복사하는 것보다 일반적으로 이식성이 높습니다.
LAN 백업 작업을 설정하는 방법
1단계: 대상 장치 결정
Synology, 다른 NAS, 파일 서버 또는 다른 Zima 장치는 ZimaOS가 쓰기 가능한 공유 폴더에 접근할 수 있다면 모두 LAN 대상으로 사용할 수 있습니다. 공유 폴더에 충분한 여유 공간이 있는지 확인하고, ZimaOS가 사용하는 계정에 보존 정책에 따라 필요한 파일 생성, 수정, 삭제 권한이 있는지 확인하세요.
2단계: 데이터 유형별로 별도의 백업 작업 생성
특별한 이유가 없다면 모든 데이터를 하나의 거대한 작업에 넣지 마세요. 중요한 문서, 미디어, 앱 데이터 및 기타 범주별로 독립적인 작업을 생성하세요. 이렇게 하면 오류를 더 쉽게 진단할 수 있고, 대체 가능한 미디어보다 대체할 수 없는 데이터에 더 적극적인 일정을 적용할 수 있습니다.
3단계: 작업 예약 및 테스트
처음에는 백업을 수동으로 실행하고, 대상 위치에 예상한 파일이 있는지 확인한 다음 일정을 활성화하세요. 작업 상태가 정상으로 표시되는 것만으로는 충분하지 않습니다. 복원한 파일 몇 개를 열어 권한, 파일 이름, 타임스탬프가 적절한지 확인하세요.
Docker 앱은 어떻게 백업해야 할까요?
핵심은 임시 컨테이너 파일 시스템이 아니라 컨테이너에 매핑된 호스트 경로를 백업하는 것입니다. 현재 ZimaOS 가이드는 App Data를 작은 시스템 드라이브가 아닌 주 스토리지 풀에 보관할 것을 권장합니다. 이렇게 하면 백업 범위를 파악하기도 쉬워집니다.
사용자 지정 Docker Compose 스택을 사용하는 경우 Compose YAML, 환경 변수, 사용자 지정 설정 파일 및 비밀 정보를 보호된 위치에 보관하세요. 설정 화면의 스크린샷에 의존하지 마세요. Compose 파일과 영구 데이터 폴더가 있으면 새 하드웨어에서 훨씬 쉽게 다시 구축할 수 있습니다.
ZimaOS 백업 개요는 각 복사본을 어디에 보관할지 계획할 때 유용하며, Docker 스토리지 기초에서는 컨테이너와 데이터의 경계를 설명합니다.
ZimaOS 시스템 자체는 어떻게 해야 할까요?
ZimaOS에는 듀얼 슬롯 시스템 설계가 적용되어 있습니다. 현재 시스템 복구 가이드에서는 한 파티션에 문제가 발생했을 때 다른 시스템 슬롯으로 부팅하는 방법을 설명합니다.
이 복구 경로는 일부 운영 체제 오류로부터 시스템을 보호하지만 데이터 백업을 대신할 수는 없습니다. 시스템 디스크 자체에 장애가 발생하면 실질적인 복구 계획은 ZimaOS를 재설치하거나 복구하고, 스토리지를 다시 연결하거나 재생성한 다음, 영구 앱 데이터와 사용자 파일을 복원하는 것입니다.
단일 LAN 복사본 대신 3-2-1 규칙을 사용하세요
다른 NAS에 보관한 LAN 백업은 유용하지만, 두 장치 모두 도난, 정전, 랜섬웨어 사고 또는 사용자 실수의 영향을 받을 수 있습니다. 대체할 수 없는 데이터에는 3-2-1 방식을 따르세요. 복사본 3개, 서로 다른 스토리지 유형 2개, 오프사이트 복사본 1개를 유지하는 것입니다.
예를 들어 ZimaOS에 운영 복사본을 보관하고, Synology에 예약된 복사본을 저장하며, 지원되는 클라우드 대상이나 다른 장소에 보관한 교체형 USB 드라이브에 암호화된 오프사이트 복사본을 유지할 수 있습니다.
피해야 할 일반적인 백업 실수
- Docker 이미지만 백업하기. 이미지는 다시 다운로드할 수 있습니다. 중요한 것은 AppData와 데이터베이스입니다.
- RAID를 백업으로 간주하기. RAID는 드라이브 장애에는 도움이 되지만, 실수로 인한 삭제, 손상 또는 랜섬웨어는 방지하지 못합니다.
- 호스트 수준 백업 에이전트를 호환성 확인 없이 설치하기. ZimaOS는 일반적인 변경 가능한 Debian 서버가 아니므로 시스템 에이전트가 보호된 운영 체제 설계와 충돌할 수 있습니다.
- 복원을 한 번도 테스트하지 않기. 복원해 보지 않은 백업은 가정에 불과합니다.
- 모든 복사본을 같은 섀시나 방에 보관하기. 이렇게 하면 장치 수준 또는 장소 수준의 손실을 막을 수 없습니다.
ZimaOS 백업이 복구 가능한지 테스트하는 방법
대표성을 갖는 소규모 항목을 선택하세요. 예를 들어 문서 폴더 하나, 미디어 파일 하나, 앱 설정 디렉터리 하나, 데이터베이스 내보내기 파일 하나를 선택할 수 있습니다. 이를 임시 위치에 복원하고 파일을 열어 본 다음, 앱이 복원된 데이터를 읽을 수 있는지 확인하세요. 주요 스토리지 또는 애플리케이션 변경 후에도 이 과정을 반복하세요.
중요한 서버라면 스토리지 이름, 앱 포트, 사용자 지정 Compose 스택, 데이터베이스 복원 명령, 도메인 또는 리버스 프록시 종속성을 기록한 간단한 복구 문서도 보관하세요. 이러한 문서는 원시 시스템 이미지보다 더 많은 시간을 절약해 주는 경우가 많습니다.
FAQ
ZimaOS에서 Synology Hyper Backup과 같은 전체 시스템 이미지를 만들 수 있나요?
현재 ZimaOS 문서는 다른 하드웨어에서 전체 운영 체제, 모든 앱, 모든 설정을 재현하는 원클릭 마이그레이션 이미지보다는 데이터 백업과 시스템 슬롯 복구에 중점을 둡니다.
Synology를 ZimaOS 백업 대상으로 사용할 수 있나요?
예. 접근 가능한 SMB/LAN 공유 폴더를 백업 설계의 일부로 사용할 수 있습니다. 이를 신뢰하기 전에 자격 증명, 여유 공간 및 복원 접근 권한을 확인하세요.
Docker 컨테이너 자체를 백업해야 하나요?
대개는 필요하지 않습니다. Compose 정의, 애플리케이션 설정, 매핑된 AppData 및 데이터베이스를 보존하세요. 컨테이너와 이미지는 일반적으로 대체할 수 있습니다.
ZimaOS 시스템 복구로 삭제된 사용자 파일도 복원되나요?
아니요. 슬롯 복구는 운영 체제 계층을 대상으로 합니다. 삭제되거나 손상된 사용자 데이터에는 별도의 백업이 필요합니다.
