テストリストア：バックアップを事前に確認する

復元したことのないバックアップはバックアップではありません。それは希望です。四半期に一度、1時間かけて復元訓練を行えば、希望は検証済みの事実になります。

確認すべきこと

インシデント発生前に答えておくべき3つの問いがあります。

1. 完全性。 バックアップには起動に必要なものがすべて含まれているか。データ、設定、鍵、証明書、スケジュール。
2. 可読性。 アーカイブは開けるか。データベースダンプはエラーなく復元できるか。
3. 時間。 完全な復元に何時間かかるか。この数字は事前に把握しておく必要があります。いざというときに知るのでは遅すぎます。

訓練の実施方法

最も誠実な方法は、本番機ではなく別のマシンで行うことです。VDS-1を1か月借りて、そこへゼロから復元し、時間を計測します。

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

データベースを復元します。

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

アプリケーションを起動し、ブラウザで開きます。これが最終ステップです。ページが開くまで、復元は完了していません。

より手軽で、それでも役立つ方法もあります。同じマシン上の別コンテナにデータベースだけを復元し、データが存在して最新であることを確認します。

展開が成功したかだけでなく、データの日付も確認してください。確実に作成されていても、1か月前から必要なディレクトリを含まなくなったバックアップは、スナップショット一覧ではまったく正常に見えます。テーブルのレコード数と最新ファイルのタイムスタンプを比較してください。

たいてい明らかになること

• .envファイルを忘れている。 データはありますが、そのデータへのパスワードがありません。
• 証明書を忘れている。 サイトは起動しますが、HTTPSで応答しません。
• スケジュールを忘れている。 すべて動作していますが、バックアップが作成されなくなっています。そして気づくのは1か月後です。
• 起動順序が書かれていない。 アプリケーションがデータベースより先に起動してクラッシュします。
• リポジトリのパスワードが失われたマシンにしかなかった。 バックアップは存在しますが、アクセスできません。
• 復元に2時間ではなく10時間かかる。 受信帯域またはディスクシェルフの問題です。ディスク速度を参照してください。

手順を書き残す

訓練の結果をもとに、短い手順書を作成し、マシンの外に保管してください。

1. 同じかそれ以上のティアのマシンを注文します。プロビジョニングには約1分かかります。
2. Dockerをインストールし、バックアップから/opt/myappを復元します。
3. データベースダンプを復元し、レコード数を確認します。
4. /etc/nginxと証明書を復元し、Webサーバーを起動します。
5. ドメインを新しいアドレスに向けます。
6. crontab.txtからスケジュールを復元します。
7. 確認します。サイトが開き、ログインが機能し、バックアップが再び作成されていること。

項目5は最も過小評価されています。DNSレコードは即座に更新されません。移行を想定するなら、事前にレコードのTTLを300秒に下げておいてください。

頻度

本番サービスでは四半期に一度、それ以外では半年に一度です。さらに、大きな変更の後には必ず行います。新しいデータベース、新しいサービス、ディレクトリの移動などです。訓練をカレンダーに入れてください。そうしなければ、決して実施されることはありません。

バックアップに何を含めるべきかは何をバックアップするかを参照してください。どこに保管するかはオフサイトバックアップを参照してください。すでにインシデントが発生している場合はデータが失われたを参照してください。