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

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

ブラウザで復元の確認を試す

バックアップと復元のLabを開く。ローカルのPython環境は不要である。ブラウザの新しい一時領域に合成テキストとSQLiteレコードを作り、SQLiteのbackup API、圧縮ZIPへの保存、既知の2ファイルの展開を実行する。その後、実際にハッシュ・DB整合性・SQL読取を確認し、実行後に一時ファイルを削除する。サーバーやホスト上のファイル、認証情報、サービスには触れない。

正常な条件をAに保存し、テキスト欠落、テキスト変更、DBの切り詰め、保存前から誤っているレコードと比較する。最初の3つの障害はZIP展開後に加える。合成レコード数は1〜50件の範囲で変えられるが、本番データ量や復旧時間をモデル化するものではない。

保存前のレコード誤りでは、保存時と復元後のハッシュが一致し、SQLiteの整合性も合格する。しかし既知レコードの値は期待値restore-checkと異なる。ハッシュの一致は今回保存したコピーとの同一性を示すだけで、保存内容の正しさやアプリ全体の整合性は保証しない。アプリ読取の対象はnotes.id=1だけである。別途示す総レコード数も、全レコードの内容を検証するものではない。

結果は「合格」「不一致」「エラー」「未実行」を区別する。DBを切り詰めるとハッシュは不一致、SQLiteはエラーとなり、依存するアプリ読取は未実行となる。テキストが欠落しても、独立したDB確認は続ける。「—」はSQL結果の未取得であり、0件ではない。段階図と結果表でA/Bを比較し、ファイル表とJSON出力で保存時・復元後のSHA-256を確認できる。SQLiteのバイト表現は実行環境の版によって異なり得るため、固定の正解ハッシュではなく、各実行の保存時マニフェストと照合する。

この演習は一時領域の合成データだけを対象とし、永続バックアップ、実サービスの再起動、整合性の証明、RPO/RTOの計測、災害復旧試験ではない。ブラウザ用アダプターは任意で単体のローカル再現に使える。変更していない参照コードも公開している。元の演習と異なり、アダプターは一時ファイルを削除して証跡をJSONで返す。後述の実サービスの手順には、サービスごとの検証が別途必要である。

何を戻せれば成功か

図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を誤って送らない構成にする。復元後の認証とファイル閲覧まで通って初めて、自宅サーバー基盤の各サービスに対する復旧手順へ近づく。