R2とresticのバックアップ監視：保存成功から復元確認まで

バックアップの定期処理が終わっても、必要なデータを取り戻せるとは限りません。R2とresticを使った社内運用から、保存、整合性確認、復元、サービス復旧を別々に評価する考え方を一般化して紹介します。既存の別サービスからの移行完了を示す事例ではありません。

復元試験はsnapshot IDと一つの利用目的を固定する

最初の試験では検証するsnapshot IDを記録し、空の隔離先へ必要なファイルを取り出します。設定なら参照先と権限、DBなら隔離環境への読込みまで確かめ、所要時間を記録してください。定期試験を同じ確認項目で続けると、保存の鮮度と復旧に使える範囲を比べられます。

restic：隔離した場所への復元手順

保存対象と成功の定義を決める

resticの暗号化・重複排除を使い、R2のS3互換APIへ保存する構成です。S3互換でもすべての操作が同一ではないため、必要な操作を対応表で確認します。稼働中のデータベースなどは、ダンプやアプリケーションの静止化を含む、整合性を保った取得方法を設計します。

ジョブの終了と保存の鮮度を分ける

最新の成功スナップショットの時刻、予定からの遅延、処理の失敗、検査と復元確認の結果を別々に監視します。ジョブが起動しただけでは成功扱いにせず、通知の失敗もバックアップ自体の失敗と区別して追跡します。

整合性と取り出しを確かめる

restic check の通常検査と、データ実体を読む検査は範囲が異なります。--read-data は全データを読み、部分検査なら確認した範囲を記録します。公式の整合性検査を参照し、別の作業場所への復元と、ファイル内容やハッシュの照合を組み合わせます。ファイルを取り出せてもアプリケーションの起動を確認したことにはなりません。

保持処理はリポジトリを理解する道具で行う

保持対象はresticのポリシーで選び、forget、prune、checkを使って整理と検査を進めます。実行前に残すスナップショットを確認します。R2側で古いオブジェクトを一律に削除する方式は、残すスナップショットが共有するデータを失わせるおそれがあります。resticの保持・削除手順に従い、画像配信など別用途のオブジェクト整理と混同しません。

完全復旧に必要な残りの確認

定期運用、監視・通知、保持処理、対象データの取り出しと整合性確認を実施しました。一方、すべてのアプリケーションの起動、設定や依存データを含む復旧手順、認証情報を別に保管して取り出す手順は、全体としての実証が残っています。復旧時間や失えるデータの範囲も実測で定める必要があり、完全な災害復旧や費用削減の達成を主張する記事ではありません。

1. 1 成功snapshotと鮮度 実際に成功したsnapshotの時刻と予定からの遅延を確認します。ジョブの起動だけでは成功としません。
2. 2 整合性と隔離復元 検査範囲を記録し、別の場所で restore --verify。対象ファイルとhashを照合してからpruneを検討します。
3. 3 完全な災害復旧 全アプリの起動、依存データ、別管理の認証情報回復は未実証です。復旧時間や許容データ損失も未測定です。

2026年10月6日追記：古いlockと復元検査の占有

追加改修では、同じホストで処理の占有を確認してから通常の restic unlock を実行し、古いlockだけを扱いました。稼働中のlockまで消す --remove-all は使いません。競合には上限のある --retry-lock を使い、復元検査やpruneが失敗時に無限に再起動しないようにしました。ホスト内の占有だけで別ホストの競合が無いと証明できるわけではありません。

隔離した一時ディレクトリへ restore --verify で取り出し、対象に必要なファイルと整合性を確認した後、検証したsnapshotと設定の対応を記録しました。対象データの復元確認を先に行い、その後で保持対象を確認してpruneへ進みます。バックアップの鮮度は起動や再試行ではなく、実際に成功したsnapshotで評価します。

対象データの取り出しを確認した範囲と、全アプリの起動・認証情報の回復を含む完全復旧は引き続き別です。保守時間と取得失敗の扱いは監視・障害調査の記事も参照してください。