自宅ラボのバックアップ実践：同期・暗号化・DB復元を失敗から検証する

バックアップは、ファイルやアーカイブが存在するだけでは完了しません。この記事は4事例の全文を再掲せず、何を失った想定で、どこへ復元し、何を照合するかを決める診断ハブです。実行手順とログが独立記事にあるテーマは、そちらへ進んでください。

症状から読む記事を選ぶ

共通判断：復元先を原本と分ける

正常系は「復元したファイルを読めた」まで

バックアップコマンドの終了コード0は入口です。隔離した復元先へ展開し、期待するファイル名、件数、ハッシュ、またはDBの問い合わせ結果を照合して完了にします。原本へ上書きすると、復元の検証と本番変更が一つになってしまいます。

失敗系はバックアップを壊さずに作る

誤パスワード、誤った復元先、存在しないDB名のように、原本や保存世代を変更しない失敗から始めます。失敗時に非ゼロ終了すること、既存世代が残ること、正しい条件へ戻せることを別々に見ます。

同期はバックアップの代わりにしない

同期は削除や破損も伝播します。Syncthingの隔離検証では2ノードが接続できても、期待した同期完了まで到達しませんでした。接続成立をデータ保全の成功と書かず、未達のまま止めます。

独立記事がない検証の核

BorgBackup：復元成功と誤パスフレーズを分けて確認した

小さなダミーデータを暗号化アーカイブへ入れ、別ディレクトリへの復元を確認しました。誤ったパスフレーズではアーカイブ一覧の取得が終了コード2で失敗し、データ破損ではなく「鍵が違うため読めない」と切り分けられました。pruneは候補確認を先に行い、保存世代を不用意に消さない構成です。

PostgreSQL：成功系は戻せたが、失敗時stderrは採取できていない

Compose上のDBでdumpと別DBへのrestoreを確認しました。誤DB名などの失敗は非ゼロ終了を観測したものの、詳細な標準エラーは元記録に残っていません。この記事では具体的なエラーメッセージを補作せず、「非ゼロになった」範囲だけを根拠にします。

復元テストの最小記録

対象: 失った想定のデータ
保存物: アーカイブまたはdump
復元先: 原本と別の隔離先
照合: 件数・ハッシュ・問い合わせ結果のいずれか
失敗系: 誤パスワードまたは誤った復元先
後始末: 隔離先だけを撤去

保存件数より、最後に復元できた日時を更新してください。復元を一度も通していない保存物は「候補」であって、復旧手段としては未確認です。