Duplicati에서 다음과 같은 메시지가 표시되었습니다. .dblock.zip.aes 파일이 누락되었다는 메시지는 백업 손상처럼 들리지만, 원본 스레드는 왜 파괴적인 복구를 첫 대응으로 삼아서는 안 되는지 보여줍니다. 백업 대상은 ZimaOS 호스트에 존재했고 Samba를 통해 보였지만, Duplicati 컨테이너는 Docker 볼륨 매핑을 통해 해당 HDD를 실제로 볼 수 없었습니다.
사용자가 실제 호스트 HDD를 컨테이너에 매핑하고 새로운 컨테이너 측 대상을 선택한 후, 작동하는 것 같다고 답했습니다. 따라서 이 사례의 결론은 손상된 백업을 purge한 것이 아니라, 확인된 Docker 경로 매핑 해결책이었습니다.
처음 오류는 손상된 Duplicati 저장소처럼 보였습니다
Duplicati는 백업 저장 대상에 특정 암호화된 파일이 누락되어 Repair에 실패했다고 보고했습니다. dblock 파일. 이 메시지는 두 가지 복구 방향을 제시했습니다. 로컬 원본 데이터에서 누락된 블록 파일을 다시 만들거나, 더 이상 복원할 수 없는 백업 항목을 제거하는 것입니다.
이러한 옵션은 실제 Duplicati 기능이지만, 검사 중인 백업 대상이 정확하고 완전한 대상인지 확인한 후에야 의미가 있습니다.
사용자는 한 로컬 디스크에서 다른 로컬 디스크로 백업하고 있었습니다
의도한 구성은 다음과 같았습니다.
- 로컬 SSD에 있는 원본 데이터;
- 별도의 HDD에 있는 백업 대상;
- ZimaOS App Store에서 설치되어 Docker에서 실행 중인 Duplicati.
사용자는 애플리케이션의 폴더 선택기를 통해 경로를 선택하고, 컨테이너에서도 동일한 호스트 저장소를 볼 수 있다고 생각했습니다.
ZimaOS 호스트 경로와 Duplicati 컨테이너 경로는 서로 다릅니다
Docker 앱은 컨테이너에 마운트된 호스트 폴더만 볼 수 있습니다. 해당 디스크가 앱의 볼륨 구성에 포함되어 있지 않으면 ZimaOS는 Files나 Samba를 통해 디스크에 접근할 수 있어도 Duplicati에는 아무것도 보이지 않습니다.
따라서 연결 테스트만으로는 오해가 생길 수 있습니다. 대상 유형 자체는 유효하더라도 컨테이너 네임스페이스에서 의도한 폴더의 내용이 실제로 보이지 않을 수 있기 때문입니다.
임시 파일 테스트로 실제 문제가 드러났습니다
사용자는 temp.txt 대상 폴더의 파일. Samba에서는 보였지만 Duplicati의 파일 브라우저에서는 보이지 않았습니다. 이는 Duplicati가 실제 호스트 HDD의 내용을 보고 있지 않다는 강력한 증거였습니다.
그 시점에 커뮤니티 답변자는 아직 purge나 rebuild를 실행하지 말라고 명확히 방향을 바꿔 조언했습니다.
해결 방법은 HDD를 컨테이너에 매핑하는 것이었습니다
답변자는 사용자에게 ZimaOS 앱 설정을 열고 HDD를 호스트 볼륨으로 추가한 뒤, 다음과 같은 간단한 컨테이너 경로에 매핑하라고 안내했습니다. /backup컨테이너를 다시 시작한 다음 해당 컨테이너 경로 아래에서 대상 위치를 선택합니다.
원 게시자가 답변했습니다: “이제 작동하는 것 같습니다.”
볼륨 매핑이 실질적인 해결책임을 확인했습니다.
추가 소스 드라이브에는 각각 별도의 매핑이 필요합니다.
그 후 사용자는 하나의 Duplicati 작업에 여러 소스 폴더를 포함할 수 있는지 물었습니다. 모든 소스 경로가 컨테이너 안에서도 표시된다면 가능하다는 것이 커뮤니티의 답변이었습니다.
두 번째 디스크가 앱의 Docker 볼륨을 통해 노출되지 않으면 호스트 경로가 아무리 유효해도 Duplicati에 올바르게 표시되지 않습니다.
추측한 원시 경로 대신 현재 ZimaOS 앱 볼륨 매핑을 사용하세요
현재 ZimaOS는 앱 설정에서 호스트 및 컨테이너 경로를 표시하며, 영구 저장소가 Docker 앱에 매핑되는 방식을 문서화합니다.
백업 소스나 대상을 추가할 때 현재 ZimaOS Docker 경로 모델을 사용하세요.
Duplicati Repair를 사용해야 하는 경우
Duplicati의 현재 명령줄 문서에 따르면 Repair는 원격 저장소에서 로컬 데이터베이스를 다시 구축하거나, 필요한 로컬 소스 콘텐츠를 아직 사용할 수 있는 경우 누락된 원격 데이터를 재구성하려고 시도할 수 있습니다.
고급 --rebuild-missing-dblock-files 이 옵션은 로컬 소스 데이터에서 누락된 블록 파일을 다시 생성하려고 시도하지만, Duplicati는 데이터가 변경되었을 수 있으며 복구가 불완전하거나 느릴 수 있다고 경고합니다.
purge-broken-files는 복원 기록을 파괴합니다
현재 Duplicati 문서에는 다음과 같이 나와 있습니다. purge-broken-files 더 이상 복원할 수 없는 백업 버전의 파일을 제거하여 백업 세트를 계속 사용할 수 있게 합니다. 원격 데이터가 복구 불가능한 경우에만 사용해야 합니다.
삭제하기 전에 현재 Duplicati 복구 명령과 그 결과를 확인하세요. 백업 기록을 무작정 삭제하는 것보다 시험 실행이나 손상된 파일 목록을 사용하는 편이 안전합니다.
오류 메시지는 실제였지만, 기본 대상이 잘못되었습니다
Duplicati는 자신이 확인할 수 있는 저장소 보기에 예상된 파일이 없다고 올바르게 보고한 것입니다. 오해를 불러일으킨 부분은 해당 저장소 보기가 실제 HDD를 나타낸다고 가정한 것이었습니다. Docker 경로 매핑으로 인해 애플리케이션이 불완전하거나 다른 파일 시스템 보기를 참조하고 있었습니다.
Duplicati dblock FAQ
소스 백업 저장소가 손상된 것으로 확인되었나요?
아니요. Docker 볼륨 매핑을 수정한 후 소스 문제가 해결되었습니다.
purge-broken-files를 첫 단계로 실행해야 하나요?
아니요. 파괴적인 복구를 수행하기 전에 올바른 전체 대상이 마운트되어 표시되는지 확인하세요.
하나의 Duplicati 작업에서 여러 ZimaOS 드라이브를 백업할 수 있나요?
예. 하지만 모든 소스 드라이브를 Duplicati 컨테이너에 매핑해야 합니다.
