自宅サーバーのバックアップから復元まで — 小さなデータで復元演習する

バックアップの終了コードが0でも、そのデータでサービスを再開できるとは限らない。復元先へファイルを戻すこと、データベースとして読めること、アプリの必要な操作ができることを分けて確認する。ここでは本番データに触れない小さな演習から始める。

何を戻せれば成功か

図1 · 横にスクロールして図を読む

写真サービスなら画像だけでなくDBとの対応、認証サービスなら設定や暗号化鍵も復旧に関係する。まず「失ってよい時間幅」と「再開までに許される時間」を決める。前者がRPO、後者がRTOであり、バックアップの間隔と復元の所要時間は別の指標である。

本番から独立した演習を実行する

restore_lab.pyを保存し、python3 restore_lab.pyを実行する。Python 3.12.3の標準ライブラリだけを使う。毎回新しい一時フォルダを作り、テキスト1件とSQLiteのレコード1件を生成する。元のサービスやデータを停止・削除する処理はない。

スクリプトはSQLiteのbackup APIでDBのコピーを取得し、テキストとともにZIPへ保存する。別の空フォルダへ戻した後に、SHA-256、PRAGMA integrity_check、既知レコードの読み取りを検査する。SQLiteのオンラインバックアップの意味は公式API説明を参照。

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

2026年9月7日の実行で上記3項目を確認した。ここでの「アプリ読み取り」は既知のSQL問い合わせのことで、ImmichやNextcloudの起動確認ではない。生成先は出力のdirectoryへ表示され、確認用に残る。この一時フォルダ内のZIPは演習用であり、別媒体への耐障害バックアップではない。

実サービスでは整合した取得方法を選ぶ

稼働中のDBファイルを通常のファイルコピーで集めるだけでは、必要な整合性を確保できない場合がある。PostgreSQLならSQLダンプなど、使用する方式の要件を確認する。DBのスナップショットと、そのDBが参照する外部ファイルの整合性はさらに別の問題である。

ファイルのハッシュ一致は「取得したコピーと同じ」という確認であって、その取得時点のアプリ全体が整合していた証明ではない。

resticを使う場合の追加確認

以下はresticの導入済み環境で使う手順例で、この演習でresticを実行したわけではない。リポジトリと認証は別途設定し、restic versionを記録する。スナップショットIDを選び、空の復元先へ戻す。

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

SNAPSHOT_IDとパスは自分の環境に置き換える。復元コマンドとリポジトリ検査の役割は異なる。--read-dataは保存データも読み取るため、所要時間や転送量を見込む。

復元試験の記録を残す

取得時刻、復元開始・終了、データ量、使った版、ファイルの確認結果、アプリで行った操作を記録する。本番へ戻す前に隔離環境で読むことを確認し、メールやWebhookを誤って送らない構成にする。復元後の認証とファイル閲覧まで通って初めて、自宅サーバー基盤の各サービスに対する復旧手順へ近づく。