ZimaOS 백업은 의도적으로 미러가 아닙니다. 소스에서 파일을 삭제했다고 해서 백업 사본이 즉시 사라져야 하는 것은 아닙니다. 기본 제공 백업 앱은 복구 지점을 보존하고 실수로 인한 삭제를 방지하도록 설계된 반면, 동기화 소프트웨어는 삭제를 포함한 변경 사항을 전파하도록 설계되었습니다.
이 구분은 2025년 포럼 논쟁의 핵심이었습니다. IceWhale은 소스에서 파일이 사라지는 즉시 백업 대상에서도 삭제하는 방식에 명확히 반대했습니다. 파일 삭제를 백업 대상에 그대로 반영하면 백업의 안전성이 약화되기 때문입니다. 현재 2026년 ZimaOS 문서에도 같은 원칙이 직접 명시되어 있습니다. 클라우드 동기화는 삭제를 미러링하지만, 백업은 버전과 복원 지점을 유지합니다.
삭제한 소스 파일이 백업에 남을 수 있는 이유
백업은 실수, 손상, 랜섬웨어 또는 원치 않는 변경으로부터 복구하기 위해 존재합니다. 소스 파일을 삭제하는 즉시 모든 백업 사본까지 삭제된다면, 실수로 인한 삭제가 나를 구해 줘야 할 위치까지 전파됩니다.
현재 ZimaOS 3-2-1 백업 가이드에도 백업은 버전을 유지하며 클라우드 미러처럼 동작하지 않고 변경 사항을 누적한다고 명시되어 있습니다.
백업, 단방향 동기화, 양방향 동기화는 서로 다릅니다
| 모드 | 소스 파일을 삭제하면 어떻게 되나요? | 가장 적합한 용도 |
|---|---|---|
| 백업 | 복구를 위해 이전 사본이나 버전이 남을 수 있습니다 | 데이터 손실과 실수로부터 보호 |
| 단방향 미러/동기화 | 삭제 내용이 대상에 전파될 수 있습니다 | 정확히 동일한 보조 작업 사본 유지 |
| 양방향 동기화 | 일반적으로 양쪽에서 삭제 내용이 서로 전파됩니다 | 여러 기기에서 활성 폴더를 동일하게 유지 |
2025년에 대상에서 파일을 삭제해 달라고 요청한 사용자는 백업에서 작업을 생성했지만, 실제로는 미러/동기화 정책을 요청한 것이었습니다.
계속 증가하는 백업이 실제로 문제가 될 수 있는 이유
사용자의 우려는 타당합니다. 삭제된 파일을 모두 영구적으로 보관하면 대상 저장 공간이 무한히 증가할 수 있습니다. 따라서 성숙한 백업 시스템에는 삭제를 단순히 미러링하는 대신 버전 수, 기간 기반 만료 또는 저장 공간 할당량과 같은 보존 제어 기능이 필요합니다.
현재 ZimaOS 백업을 구성할 때는 사용하는 대상의 작업 보존 정책과 복원 동작을 확인하세요. UI에서 필요한 보존 정책을 제공하지 않는다면 대상 저장 공간에 여유를 두고 증가 추이를 모니터링하세요.
정확한 미러를 원한다면 동기화를 사용하세요
목표가 “대상이 소스와 정확히 같아야 한다”는 것이라면 파일 생성, 수정, 이름 변경 및 삭제를 전파하도록 설계된 동기화 도구를 사용하세요. Syncthing, rsync 기반 작업 방식 또는 다른 전용 동기화 도구가 백업 작업보다 더 적합할 수 있습니다.
미러 작업의 이름을 “백업”으로 바꾼 뒤 삭제로부터 보호해 줄 것이라고 생각하지 마세요. 미러는 복구하려던 실수까지 충실하게 재현할 수 있습니다.
작업 파일, 사진 및 대체할 수 없는 문서에는 백업을 사용하세요
업무 파일, 가족 사진, 세금 기록, 창작 프로젝트 및 애플리케이션 데이터의 경우, 마지막으로 복구 가능한 사본을 즉시 삭제하지 않는 대상을 하나 이상 유지하세요.
백업 전략 개요에서는 빠른 사본과 실제 복구용 사본을 구분하는 방법을 안내합니다.
한 가지 모드에 두 가지 역할을 강요하지 말고 백업과 동기화를 함께 사용하세요
강력한 홈 서버 구성에서는 다음을 함께 사용할 수 있습니다.
- 현재 작업 폴더를 위한 동기화 작업
- 버전과 복원 지점을 위한 예약 백업
- 재해 복구를 위한 오프사이트 백업
이렇게 하면 기록 기반 복구 기능을 포기하지 않으면서도 파일 동기화의 편리함을 누릴 수 있습니다.
백업 정책을 테스트하는 방법
작은 테스트 파일을 만들고 백업을 실행한 다음 파일을 수정하고 다시 백업을 실행하세요. 그런 다음 소스에서 파일을 삭제하고 복원 인터페이스를 열어 이전 사본을 계속 사용할 수 있는지 확인하세요. 이렇게 하면 실제 데이터를 맡기기 전에 현재 버전이 실제로 어떻게 동작하는지 알 수 있습니다.
자동 정리가 필요하다면 어떻게 해야 하나요?
대상 파일을 수동으로 삭제하기보다 보존 또는 버전 정리 설정을 찾으세요. 수동 정리는 복원 기록을 손상시키거나 유일하게 정상인 사본을 제거할 수 있습니다.
백업 대상의 저장 공간이 부족하다면 용량을 추가하거나, 지원되는 경우 보존 기간을 줄이거나, 오래된 아카이브를 다른 저장 계층으로 이동하세요. 유일한 백업을 동기화 미러로 바꾸지는 마세요.
FAQ
삭제한 소스 파일이 ZimaOS 백업에 남아 있는 이유는 무엇인가요?
백업은 복구 지점을 보존하기 위한 것이기 때문입니다. 현재 ZimaOS 문서에서도 백업과 삭제를 미러링하는 동기화를 명확히 구분합니다.
이것은 ZimaOS 1.5의 버그인가요?
포럼 논의에 따르면 이러한 동작은 설명되지 않은 삭제 버그가 아니라 백업 안전성을 고려해 의도적으로 설계된 것입니다.
대상을 소스와 동일하게 유지하려면 어떻게 해야 하나요?
보존이 목적이므로, 백업 작업에 의존하지 말고 단방향 미러 또는 동기화 작업 방식을 사용하세요.
삭제된 파일을 계속 보관하면 백업 디스크가 가득 차지 않나요?
보존 기간이나 버전 제한이 없다면 그럴 수 있습니다. 유일한 복구 기록을 삭제하는 대신 버전, 기간, 할당량 또는 아카이브 계층을 관리하세요.
