バックアップは、既知の状態で、許容可能な時間内に、新たなエラーを持ち込まずサービスを復旧できて初めて保護をもたらします。バックアップファイルが存在すること、アラートなしに生成されたこと、別のストレージへ送信されたことは、それを復元できること、必要なすべてのコンポーネントを含むこと、またはPHPアプリケーションがそのデータで動作することを証明しません。
PHPアプリケーションのバックアップを確認する方法という問いには、再現可能な復元テストで答える必要があります。目的は単にデータベースを復旧することではありません。一貫性のあるサービスを再構築し、そのビジネスルールを検証し、実際のインシデント前に手順を修正できる証跡を残すことです。
バックアップの存在は復旧可能性を保証しない
復旧の失敗は、依存関係の欠落によって生じることがよくあります。データベースを正しく復元しても、その後でユーザーアップロードファイル、情報を復号する鍵、環境変数、または外部サービスの設定が不足していると判明する場合があります。バックアップが破損している、技術アカウントに復元権限がない、またはその形式が移行先インフラと互換性がないこともあります。
2つの運用目標を分けて考えることが重要です。
- 目標復旧時点（RPO）：最後に復旧可能な状態から測定した、許容される最大データ損失量。
- 目標復旧時間（RTO）：サービスを運用可能な状態に戻すまでの許容最大時間。
両目標は、バックアップ頻度、保持期間、トランザクションログの使用、テスト設計を左右します。変更の少ないカタログには夜間バックアップで十分な場合がありますが、インシデントに近い時点への復帰を要するトランザクションには不十分です。後者では、データ技術とその設定が許す場合、計画にポイントインタイムリストアを含める必要があります。
データダンプだけでなく、復旧可能なインベントリを作成する
インベントリでは、アプリケーションの最小状態を構成する要素と、そのバックアップ先を記述する必要があります。PHPアプリケーションではデータベースが中心となることが多い一方で、永続コンポーネントがそれだけであることはほとんどありません。
- トランザクションデータ：リレーショナルデータベース、ドキュメント、関連するマイグレーションファイル、該当する場合はポイントインタイムリストアに必要なログ。
- 永続ファイル：添付ファイル、画像、エクスポート、生成ドキュメント、およびデータベース外に保存されるすべてのコンテンツ。
- 設定：実行パラメータ、ドメイン、ストレージパス、メール設定、決済サービス、API接続。バージョン管理されたコードは役立ちますが、運用設定の代わりにはなりません。
- シークレット：暗号鍵、認証情報、証明書、トークン、セッションシークレット。レポートやリポジトリにコピーするのではなく、管理された仕組みで復旧する必要があります。
- 非同期処理：キュー、スケジュールジョブ、コンシューマー、リトライポリシー。保留中メッセージを復元するか、パージするか、安全に再構築するかを決める必要があります。
- 派生データ：キャッシュ、検索インデックス、マテリアライズドビュー、サムネイル、集計値。通常は信頼できる唯一の情報源ではありませんが、運用前に再構築が必要になることがあります。
各要素について、所有者、場所、復元方法、依存関係、機密性を文書化してください。シークレットを管理された形で復旧またはローテーションできない場合、手順は完全ではありません。
シナリオを定義し、復元時点を選ぶ
すべてのインシデントに同じ対応が必要なわけではありません。誤って削除されたレコード、大規模な破損、データを改変した脆弱性、環境全体の停止には、それぞれ異なる手順が必要です。シナリオを定義すれば、限定的な修正で済む状況で完全復元を適用したり、問題発生後の時点を選んで汚染されたデータを復元したりすることを防げます。
テストすべきシナリオ
- エクスポート、監査、または一時インスタンスへの復元による、1件のレコードまたは限定されたデータセットの復旧。
- 整合性のあるバックアップからのデータベース全体の復旧。
- その機能がある場合、トランザクションログを使用したインシデント前の時点への復元。
- データ、ファイル、設定、シークレット、アプリケーション、補助プロセスを含む完全なサービスの復旧。
- 信頼できる唯一の情報源を変更せずに行う、インデックス、キャッシュ、その他の派生データの再構築。
復元前に、目標時点を定め、許容するデータ損失を記録してください。たとえば02:00のバックアップを復旧する場合、その後のすべての操作は、決済記録やサードパーティシステムなどの正当な他の情報源から照合が必要になることがあります。その状態を、含まれていないトランザクションまで含むかのように扱ってはなりません。
副作用を抑える復旧順序を守る
管理された復元には、隔離と明確な順序が必要です。テスト環境では、実際のメール送信、課金実行、本番連携の呼び出し、アクティブなサービスとのキュー共有を行ってはなりません。このテストには安全な認証情報と宛先を使用してください。
- 移行先インフラを準備します。ネットワーク、ストレージ、データエンジンのバージョン、権限、十分な容量を確認します。
- 認可されたチャネルを通じて設定とシークレットを復旧またはプロビジョニングします。必要な暗号鍵が復元したデータの状態に対応していることを確認します。
- データベースと永続ファイルを復元します。タイムスタンプ、バックアップ識別子、使用したコマンドまたはタスクを記録します。
- 互換性のあるアプリケーションバージョンをデプロイします。デプロイはソフトウェアアーティファクトをインストールしますが、それ自体はユーザーが利用可能にすることを意味しません。
- シナリオによって正当化される場合にのみマイグレーションを実行します。不可逆なマイグレーションは、元の状態との比較を難しくしたり、復旧したデータを不適切に変更したりする可能性があります。
- 検証が完了するまで、コンシューマー、スケジュールタスク、外部効果を持つ連携を無効にしておきます。
- 派生データを再構築し、重複、エラー、リトライを監視しながらプロセスを段階的に有効化します。
キューには特別な注意が必要です。状態を検証する前にコンシューマーを再有効化すると、重複通知の送信、操作の繰り返し、または復旧データに対応しなくなったメッセージの処理を招く可能性があります。ポリシーでは、保持するメッセージ、破棄するメッセージ、二重実行を防ぐ方法を定義する必要があります。
技術的整合性とビジネス整合性を検証する
アプリケーションがHTTP 200を返すことは、それが復旧可能であることを証明しません。チェックでは、技術的完全性、機能的な挙動、ドメインの制約を組み合わせる必要があります。各テスト後に繰り返せるよう、安定した検証は自動化してください。
- ユーザー、注文、請求書、ファイル、イベントなど、関連エンティティの件数を復元時点に期待される値と比較します。
- データベースとオブジェクトストレージ間の壊れた参照を探します。存在しないファイルを指すレコードや、既知の所有者を持たないファイルが該当します。
- 新しい書き込みに影響する場合、制約、リレーション、エンコーディング、タイムゾーン、識別子シーケンスを確認します。
- テストアカウントで機能フローを実行します。認証、データ読み取り、レコードの管理された作成、保護されたファイルへのアクセスを確認します。
- ロールと権限を検証します。シークレットの復元が誤っていると、アクセスを妨げたり、より悪いことに権限を拡大したりする可能性があります。
- 保留、失敗、または停止中のジョブを確認し、それらの再開が不適切な外部アクションを発生させないことを確認します。
アプリケーションテストでは、適切に保護されたデータを使用する必要があります。個人データを隔離環境へコピーする場合は、該当するアクセス制御、保持、最小化の管理策を適用してください。可能な場合は、識別可能な情報を必要としない検証にマスキングデータを使用します。
キャッシュ、インデックス、派生物を再構築可能なコンポーネントとして扱う
キャッシュは、サービス復旧に必要な情報の唯一の格納場所であってはなりません。信頼できる唯一の情報源を復元した後、復旧時点より前の値を含む可能性があるキャッシュを無効化してください。その後、制御されたウォームアップを許可するか、手段があれば明示的な生成を実行します。
検索インデックスおよびその他の派生ストアは、削除または再生成する前に、そのようなものとして識別する必要があります。再構築は復元済みデータから開始し、インデックス済みドキュメント数、エラー、保留要素、確認クエリという検証可能なメトリクスを生成しなければなりません。インデックスに機密フィールドが保存される場合、その権限と保持ポリシーも検証の一部です。
各テストを運用上の証跡に変える
隔離環境で復元をテストすることは、危機時の即興対応ではなく、計画された活動であるべきです。実行、監視、ビジネス検証、手順変更の承認を担う責任者を割り当ててください。見積もりではなく、フェーズごとの実測時間を計測します。
各演習の後に、簡潔で有用な証跡を保存してください。
- テストしたシナリオ、日付、責任者、選択した復旧時点。
- 使用した各バックアップの識別子と経過時間。
- シークレットを公開しない、移行先の関連バージョンと設定。
- 復元、検証、派生物の再構築に要した実測時間。
- 整合性チェックと機能テストの結果。
- インシデント、下した決定、許容したデータ損失、是正措置。
データスキーマ、ファイルストレージ、シークレット、連携、キューアーキテクチャ、デプロイプロセスが変更されたら、手順を見直してください。履歴証跡により、RTOを満たさなくなったこと、バックアップがコンポーネントを含まなくなったこと、または依存関係が手作業になったことを検出できます。
バックアップ戦略を無効にするエラー
データベースだけを復元することは最も目立つエラーですが、それだけではありません。バックアップが正しく完了することを確認しないこと、単一の場所に依存すること、ポイントインタイムリストアを確認しないこと、環境を混在させること、復元アカウントの権限を省略すること、手順を一人の知識だけに委ねることも、よくあるリスクです。
是正とは、基準なくバックアップを増やすことではありません。復旧可能な状態を定義し、復元を隔離し、データとプロセスを検証し、結果を測定し、計画を更新することです。これにより、バックアップは運用上の約束ではなく、実証可能なサービス復旧能力になります。
