Duplicatiで「 .dblock.zip.aes ファイルが見つからないという表示はバックアップの破損を思わせますが、元のスレッドからは、破壊的な修復を最初に行うべきではない理由がわかります。バックアップ保存先はZimaOSホスト上に存在し、Samba経由では見えていましたが、DuplicatiのコンテナはDockerのボリュームマッピングを通じてそのHDDを実際には認識できていませんでした。
ユーザーが実際のホストHDDをコンテナにマッピングし、新しいコンテナ側の保存先を選択すると、「動作しているようだ」と返信しました。したがって、この事例は、バックアップの破棄が確認されたわけではなく、Dockerのパスのマッピングで解決した事例として終わりました。
最初のエラーはDuplicatiリポジトリが破損しているように見えた
Duplicatiは、バックアップストレージの保存先に特定の暗号化されたファイルがないため、修復に失敗したと報告しました。 dblock ファイル。そのメッセージでは、ローカルのソースデータから不足しているブロックファイルを再構築するか、復元できなくなったバックアップエントリを削除するかという、2つの復旧方法が示されていました。
これらは実際にDuplicatiに備わっている機能ですが、調査対象のバックアップ保存先が正しく、完全な保存先であることを確認してからでなければ意味がありません。
ユーザーは1台のローカルディスクから別のディスクへバックアップしていた
想定されていた構成は次のとおりでした：
- ローカルSSD上のソースデータ；
- 別のHDD上のバックアップ保存先；
- ZimaOS App Storeからインストールされ、Docker上で実行されているDuplicati。
ユーザーはアプリケーションのフォルダーピッカーでパスを選択し、それによってコンテナから同じホストストレージが見えると思い込んでいました。
ZimaOSのホストパスとDuplicatiのコンテナパスは同じものではない
Dockerアプリから見えるのは、コンテナにマウントされたホストフォルダーだけです。ZimaOSではFilesやSamba経由でディスクにアクセスできても、そのディスクがアプリのボリューム設定に含まれていなければ、Duplicatiからは何も見えません。
そのため、接続テストだけでは誤解を招くことがあります。保存先の種類が有効でも、意図したフォルダーの内容がコンテナの名前空間から実際には見えていない可能性があります。
一時ファイルのテストで本当の問題が明らかになった
ユーザーは temp.txt 保存先フォルダー内のファイル。Samba経由では表示されましたが、Duplicatiのファイルブラウザーからは表示されませんでした。これは、Duplicatiが実際のホストHDDの内容を認識していないことを強く示していました。
その時点で、コミュニティの回答者は方針を明確に変更し、まだpurgeや再構築を実行しないよう助言しました。
HDDをコンテナにマッピングすることが有効な解決策だった
回答者はユーザーに、ZimaOSのアプリ設定を開き、HDDをホストボリュームとして追加し、次のようなシンプルなコンテナパスにマッピングするよう指示しました： /backup、コンテナを再起動してから、そのコンテナパスの下にある保存先を選択します。
元の投稿者は次のように返信しました：「現在は動作しているようです。」
それにより、ボリュームマッピングが実用的な解決策であることが確認されました。
追加のソースドライブには、それぞれ独自のマッピングが必要です。
その後、ユーザーは1つのDuplicatiジョブに複数のソースフォルダーを含められるか尋ねました。コミュニティの回答は、すべてのソースパスがコンテナ内からも見えることを条件に、可能だというものでした。
2台目のディスクがアプリのDockerボリュームを通じて公開されていない場合、ホストパスがどれほど正しくても、Duplicatiには正しく表示されません。
推測した生のパスではなく、現在のZimaOSアプリのボリュームマッピングを使用する
現在のZimaOSでは、アプリケーション設定にホストパスとコンテナパスが表示され、永続ストレージをDockerアプリにマッピングする方法が文書化されています。
バックアップのソースまたは保存先を追加する際は、現在のZimaOSのDockerパスモデルを使用してください。
Duplicatiの修復が適切な場合
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を最初の手順にすべきですか？
いいえ。破壊的な修復を行う前に、正しい完全な保存先がマウントされ、認識されていることを確認してください。
1つのDuplicatiジョブで複数のZimaOSドライブをバックアップできますか？
はい。ただし、すべてのソースドライブをDuplicatiコンテナにマッピングする必要があります。
