2026년 4월에 시작된 이 스레드는 백업과 자체 호스팅 이메일을 다룬 “ZimaOS를 처음 사용하는 사용자가 압도된” 상황의 게시물로 시작했습니다. 이메일 문제는 결국 부차적인 문제가 되었습니다. 사용자는 자신의 요구에 충분할 정도로 Mailcow를 작동시켰습니다. 해결되지 않은 기술적 문제는 ZimaOS 백업이었으며, 표시된 크기가 일관되지 않았고 첫 실행은 대체로 완료되었지만 이후 실행에서는 추가 디스크 활동 없이 멈출 수 있었습니다.
이 사례가 특히 유용한 이유는 사용자가 ZimaBoard 2 한 대뿐 아니라 여러 대와 여러 내부 및 외부 드라이브, Synology 네트워크 대상을 테스트했고, 이후 ZimaOS 1.6.1도 사용했기 때문입니다. 따라서 이 문제를 단순히 불량 USB 디스크 하나나 잘못된 네트워크 경로 하나의 문제로 요약해서는 안 됩니다.
사용자는 아카이브 형식이 아닌 간단한 재해 복구용 백업을 원했습니다
원했던 작업 방식은 간단했습니다. 1:1 방식의 백업을 수동으로 시작하고, 알아보기 쉬운 폴더 구조를 유지하며, 암호화나 불투명한 패키지를 사용하지 않고, ZimaBoard 2 전체에 장애가 발생해도 신속하게 복구할 수 있어야 했습니다.
이러한 기대는 과거 버전을 의도적으로 보관하는 버전 관리 백업 소프트웨어와는 다릅니다. 버전 보존이 활성화되면 대상 사용량이 현재 소스 데이터 세트의 크기를 합법적으로 초과할 수 있습니다.
메일 서버 측 문제는 결국 분리되었습니다
원문 게시물에는 Synology Mail Plus를 대체하는 데 어려움을 겪었다는 내용도 있었습니다. Zima-Jerry는 Stalwart를 제안했지만, 사용자는 특히 POP3 가져오기가 필요했습니다. 4월 16일에는 Mailcow가 작동하고 다른 애플리케이션도 만족스럽다고 보고했습니다.
이 결과는 이후 백업 논의가 Mailcow 자체가 저장 공간 문제를 일으켰다는 증거로 잘못 해석되는 것을 막아 주므로 기록해 둘 가치가 있습니다.
백업 대상 크기가 실제와 일치하지 않음
한 보드에서는 소스의 약 800GB가 대상 디렉터리에서 약 2.7TB에 해당했습니다. 다른 보드에서는 소스의 약 105GB 중 약 2GB가 대상에서 누락된 것으로 나타났습니다.
버전 보존은 일부 용량 증가를 설명할 수 있지만, 멈춘 두 번째 실행까지 설명하지는 못합니다
Zima-Jerry는 “버전 보존” 기능이 활성화되어 있는지 물었습니다. 이전 버전을 유지하면 백업 대상이 현재 라이브 소스보다 커지는 것은 정상적으로 발생할 수 있습니다.
그러나 이후 소스 사용자는 새로 포맷한 외장 USB 디스크로 테스트를 다시 설정하고 다른 문제를 기록했습니다. 첫 번째 백업은 완료되었지만, 두 번째 백업은 일부 데이터를 복사한 후 더 이상 진행되지 않았습니다.
클린 USB 테스트에서 두 번째 실행 실패 재현
사용자는 기존 작업을 삭제하고 ZimaBoard 2를 다시 시작한 뒤 외장 드라이브를 포맷하고 버전 보존을 활성화한 새 수동 백업을 생성했습니다. 첫 번째 실행에는 거의 이틀이 걸렸으며 약 1.25TB가 성공적으로 복사되었습니다.
Files를 통해 드라이브를 분리했다가 다시 연결한 후, 두 번째 실행에서는 일부 변경 사항이 복사되었지만 진행률 표시줄이 멈추고 USB 활동 LED가 꺼졌습니다. Synology를 대상으로 했을 때도 같은 동작이 발생했습니다.
IceWhale, 백업 동작을 상위 팀에 전달
Zima-Jerry는 통제된 테스트를 진행해 준 사용자에게 감사를 표하고, 이 문제를 조사를 위해 개발팀에 전달하겠다고 말했습니다.
이후 IceWhale 관련 답변에서는 알려진 두 가지 문제 영역을 구분했습니다. 즉, 전체를 백업하는 것과 /media/ZimaOS-HD 이전에는 Docker 파이프/소켓 콘텐츠도 포함했으며, 백업 진행률 표시의 정확성도 여전히 개선이 필요했습니다.
시스템 드라이브 전체를 백업하는 것은 복원 가능한 시스템 이미지와 다릅니다
이후 논의는 재해 복구로 이어졌습니다. 팀의 답변에 따르면 시스템 디스크 전체를 무작정 백업하면 폐기 가능한 Docker/런타임 파일까지 포함되며, 폴더를 복원하면 ZimaOS 전체 시스템이 이전과 정확히 동일하게 돌아오는, 공식적으로 지원되는 워크플로가 자동으로 제공되는 것은 아닙니다.
재해 대비를 위해 사용자 데이터, 애플리케이션 데이터, 데이터베이스, 구성 및 교체 가능한 컨테이너 이미지를 구분하세요.
ZimaOS 1.6.0에서 저장소 복구 메타데이터 변경
이후 공식 답변에서는 ZimaOS 1.6.0부터 저장 장치를 어떻게 마운트해야 하는지 설명하는 정보도 저장 장치 자체에 기록된다고 했습니다. 이는 시스템 디스크 문제 발생 후 RAID 또는 단일 디스크 저장소를 다시 쉽게 인식할 수 있도록 하기 위한 것입니다.
이렇게 하면 어레이 복구 기능은 향상되지만, RAID가 백업으로 바뀌는 것은 아니며 소스 사용자의 두 번째 실행 백업 멈춤 문제도 그 자체로 해결되지 않습니다.
사용자는 ZimaOS 1.6.1에서도 여전히 문제를 재현했습니다
4월 27일 원 게시자는 첫 백업은 여전히 작동했지만, 두 번째 및 이후 실행이 추가 쓰기 작업 없이 6시간 넘게 멈췄다고 보고했습니다. Backup을 닫았다가 다시 열면 대상이 0B로 표시될 수 있었습니다.
그들은 이 패턴을 내부 드라이브 4개, 외장 USB 드라이브 2개, ZimaBoard 2 시스템 3대에서 테스트했다고 말했습니다.
현재 백업 워크플로는 발전했습니다
현재 ZimaOS 문서에서는 3-2-1 전략의 일부로 로컬, USB, NAS 및 클라우드 대상에 대한 예약 백업 작업을 설명합니다.
오늘날 1.5.x/1.6.1 인터페이스가 동일하게 작동한다고 가정하지 말고 현재 ZimaOS 백업 워크플로와 대상 옵션을 사용하세요.
현재 가이드만으로는 이 스레드에서 과거에 발생한 모든 두 번째 실행 버그가 해결되었다고 입증할 수 없으므로, 사용 중인 버전에서 실제 복원 동작을 확인하세요.
진행률 표시줄 외부에서 백업 확인
- 가능한 경우 소스와 대상의 파일 수를 비교합니다.
- Backup UI만 확인하지 말고 실제 대상 용량을 확인합니다.
- 두 번째와 세 번째 증분/버전 관리 실행을 테스트합니다.
- 대표적인 파일을 다른 위치로 복원합니다.
- 어떤 애플리케이션 데이터베이스와 설정을 별도로 백업해야 하는지 문서화합니다.
ZimaOS 백업 FAQ
소스 문제는 Synology NAS에서만 발생했나요?
아니요. 사용자는 외장 USB 드라이브에서도 비슷한 멈춤 현상을 재현했습니다.
첫 백업이 실패했나요?
통제된 첫 실행은 완료되었지만, 반복되는 문제는 이후 실행에서 나타났습니다.
ZimaOS 1.6.1에서는 문제가 사라졌나요?
아니요. 원 게시자는 그곳에서도 여전히 문제가 재현된다고 명시했습니다.
백업 대상이 현재 소스보다 실제로 더 클 수 있나요?
예, 버전 보존이 활성화된 경우에는 그렇지만, 그렇다고 해서 스레드의 모든 표시 문제나 작업 멈춤 증상이 설명되지는 않습니다.
