バックアップが正常に取れていても、それだけでアプリケーションがサービスを再開できるとは限りません。鍵や外部依存関係、データベースに付随するファイル、あるいは復旧の順序を示す手順が欠けている可能性があります。PHPアプリケーションの災害復旧テストでは、データの消失や破損が発生し、切迫した状況で復旧を実行せざるを得なくなる前に、プロセス全体を検証できます。
目的は、停止が決して起こらないと保証することではありません。何を復旧できるのか、どれくらい時間がかかるのか、どのような障害が残っているのかを示す根拠を得ることです。演習を有効なものにするには、対象範囲を定め、環境を隔離し、インフラとアプリケーションの動作の両方を検証するとともに、必要な改善の担当者を決める必要があります。
バックアップの検証とサービスの復旧は異なる
バックアップの検査では、ファイルが存在すること、サイズに問題がなさそうなこと、あるいはツールで読み取れることを確認できます。これは重要なチェックですが、必要なコンポーネントを復元し、それらを使ってアプリケーションが動作することを実証するのとは別のものです。
完全な復旧には、データベース、ユーザーがアップロードしたファイル、コードや設定に加え、ジョブキュー、オブジェクトストレージ、キャッシュ、スケジュールタスクなどのサービスが含まれる場合があります。また、DNS、証明書、権限、PHP拡張機能、外部サービスに依存することもあります。これらの要素が一つでも欠けていたり、ほかの要素と整合していなかったりすれば、バックアップ自体は有効でも、サービスは復旧していない可能性があります。
アプリケーションごとに「復旧」の定義を決めておきましょう。PHPプロセスが起動すること、認可されたユーザーがログインして重要なフローを完了できること、あるいはバックグラウンドジョブの処理が再開することなどが該当します。ホームページが表示されることだけを基準にしてはいけません。
開始前に対象範囲と成功基準を定める
テストするシナリオを記録します。たとえば、データベースの消失、ファイルの破損、環境全体の停止などです。1回のセッションですべてのインシデントを模擬する必要はありません。シナリオを限定すれば、復元が必要なコンポーネントと、演習の対象外とするものを特定できます。
ビジネス、技術、運用の各部門と、検証可能な基準について合意します。実務上、確認すべき問いには次のようなものがあります。
- どの機能を再び利用可能にする必要があり、どの機能は後回しにできますか？
- どの時点までのデータを復旧できればよく、どれだけの変更の損失が許容されますか？
- 影響が許容できなくなるまで、サービスの停止はどれくらい許されますか？
- 復旧対象に含める依存関係は何ですか？安全な代替手段で置き換えるものは何ですか？
- 誰が実行を承認し、結果を検証し、問題を報告しますか？
目標復旧時点（RPO）と目標復旧時間（RTO）は、データ損失とサービス停止に対する許容範囲を表すのに役立ちます。各サービスのニーズと能力に応じて合意する必要があり、すべてに適用できる値はありません。テストでは、観測された所要時間とデータの状態をこれらの目標と比較できます。ただし、単一の結果を将来の保証とみなしてはいけません。
安全な隔離環境を準備する
本番環境から分離した環境で復元し、演習によって実データが変更されたり、顧客にメッセージが送信されたりしないよう制御します。可能な場合はネットワークを隔離し、課金の実行、メール送信、イベントの公開、外部システムの変更につながる連携を無効化するか、代替手段に置き換えます。参加者にはテストであることを伝えてください。
復元したデータには機密情報が含まれる可能性があります。該当するアクセス、保存、データ保護の方針を適用し、環境にアクセスできる人と期間を制限します。本番環境の認証情報を使い回さないでください。テスト用シークレットは管理された方法で扱い、復元したファイルによってログ、リポジトリ、一般公開されたディレクトリに漏えいしないことを確認します。
初期条件を記録します。バックアップの日付と復旧時点、必要なコードと設定のバージョン、利用可能なリソース、テスト環境と本番環境の差異などです。PHPのバージョン違い、拡張機能の不足、異なる権限は結果に影響する可能性があります。こうした差異は記録し、バックアップの成功や失敗と混同しないようにします。
必要なすべてのコンポーネントを復旧する
より速い方法を知っていても、文書化された手順に従ってください。別の担当者でもサービスを復旧できるだけの指示があるかを確認することが、まさにこのテストの目的です。各手順の順序と所要時間、手動コマンド、判断した内容、想定外の介入を記録します。
アーキテクチャに応じた調整が必要ですが、実行手順の一例として、インフラと設定の復元、データベースとファイルの復旧、互換性のあるコードバージョンのデプロイ、必要な依存関係への接続が挙げられます。PHPでは必要に応じて、WebサーバーとPHP-FPMの設定、必要な拡張機能、環境変数、書き込み権限、スケジュールタスクを確認します。アプリケーションが依存している場合は、キュー、オブジェクトストレージ、ワーカープロセスも確認してください。
復元したコピーに対する影響を把握せずに、マイグレーションやデータ再構築プロセスを自動実行しないでください。認証情報がテスト用サービスだけを参照していること、cronタスクが外部に影響を及ぼさないことを確認します。復旧に手動介入が必要な場合は、実際の所要時間の一部として、また改善候補として記録します。
起動だけでなく、整合性と動作を検証する
検証では、データと機能上の操作フローを確認します。まず、データベースへの接続、プロセスの状態、利用可能な容量、エラーログ、内部サービスの応答といった技術的なチェックを行います。次に、保存されたファイルと参照先が一致していること、データベースの重要なリレーションや制約に整合性が保たれていることを確認します。
実際の利用状況に沿った、代表的なクエリや操作フローを選びます。たとえば、既知のエンティティを検索できること、テストアカウントでログインできること、外部に影響しない操作を完了できることを確認します。アップロードファイルがある場合は、取得でき、対応するレコードに関連付けられていることを検証します。キューがある場合は、保留中のジョブが想定どおりに処理され、誤って二重処理されないことを確認します。
評価を再現するのに十分な根拠を保存します。クエリの結果、実施した手順、発生したエラー、開始時刻と終了時刻などです。「動作する」と記録するだけでは不十分です。演習を合格とするチェック項目と、ブロッカーとなる項目をあらかじめ定めます。応答するアプリケーションでも、データが不完全だったり、重要な操作を処理できなかったりする場合、より厳しい基準に照らせば復旧したとはみなせません。
有効な頻度で測定し、修正して再テストする
データベースの復元時間だけでなく、合意した開始時点から復旧基準を満たすまでの時間を測定します。分析に役立つ場合は、待ち時間、自動処理、手動作業、検証を分けて記録します。結果を合意済みの目標と比較し、利用できない権限や古くなった文書など、満たされなかった前提を特定します。
レポートには、対象範囲、復旧時点、各チェックの結果、観測した所要時間、問題、判断、是正措置の担当者を含めます。手順の自動化、手順書の更新、権限の修正、依存関係の確認、バックアップ戦略の改善など、障害を減らす対策を優先します。フォローアップ日を設定し、該当部分を再テストして、修正によって問題が解決したかを確認します。
実施頻度は、リスク、アーキテクチャの変更、運用能力によって異なります。データベースやファイルなどを対象とした部分的な復元を定期的に行いながら、完全復旧の演習や異なるシナリオのテストを組み合わせることができます。バックアップシステム、インフラ、依存関係に重要な変更を加えた後も、テストを繰り返すとよいでしょう。テストの成功によって得られるのは、特定のシナリオと条件に関する根拠です。将来発生するすべてのインシデントの結果を保証するものではありません。
