PHPアプリケーションにおける選択的データ復元では、データベース全体を置き換えることなく、誤削除や誤変更の後に特定のレコードを復元できます。難しいのは過去のコピーを取得することだけではありません。どの状態に戻すのかを判断し、その後に発生した有効な変更を保護する必要があります。
この手順は、定例的なインポートではなく、本番データに対する制御された操作として扱うべきです。実行前に、対象範囲を定め、復元可能な状態と現在の状態を比較し、計画をリハーサルして、承認者を決めておきます。これにより予期せぬ事態を減らし、何を戻せて何を戻せないのかを明確にできます。
サービス復旧、全体復元、選択的復元から選ぶ
サービス復旧の目的は、アプリケーションを再び利用可能にすることです。インフラの復元、レプリカへの切り替え、バックアップからの復旧などを伴う場合がありますが、どのデータを保持すべきかまで解決するとは限りません。全体復元では、広範囲のデータを過去の状態に置き換えます。広範囲の損傷があり、システムを特定の時点まで復旧することが目標であれば適していますが、その後に行われた正当な変更が失われるおそれがあります。
選択的復元は、対象となるエンティティや操作を限定します。たとえば、削除された一連の請求書を復元する、変更されたフィールドを修正する、特定のリレーションに属するレコードを再構築するといったケースです。アプリケーションの他の部分が稼働し続け、後続データを保持する必要がある場合に有効です。ただし、古い行をコピーするだけではありません。依存関係を特定し、現行状態との差異を解決する必要があります。
選択は、インシデントの原因と範囲によって異なります。何が変更されたのか分からない場合は、まず調査し、証拠を保全してください。見切りで復元すると、原因究明が難しくなるおそれがあります。多数の関連エンティティに影響する場合や、広範囲に破損がある場合は、全体復旧または特定時点への復旧のほうが安全なことがあります。選択は操作のしやすさではなく、確認された損害に基づいて行う必要があります。
対象レコード、リレーション、保護する操作を特定する
「何を復元するか」を定めるには、インシデントを検証可能な条件に落とし込む必要があります。影響を受けたテーブルまたは集約、レコードのキー、該当期間、破損とみなす操作を明確にしてください。「昨日のデータすべて」のような曖昧な条件は避けましょう。その期間には、取り消してはならない正常なトランザクションが含まれる可能性があります。
- エンティティ：主要なレコードと、同一の業務単位を構成する従属データを特定します。
- 期間：エラーが発生した日時と、候補を絞り込むために使えるタイムスタンプ、監査記録、識別子を記録します。
- 除外対象：確定済みの支払い、注文の状態、ユーザーが入力したデータなど、保持すべき後続の変更を明示します。
- 技術的な対象範囲：対象環境、データベース、テーブルに加え、それらへ書き込むプロセスを記録します。
PHPアプリケーションでは、Webリクエスト、バックグラウンドタスク、連携システム、コンソールコマンドを通じてデータが変更されることがあります。復元前にそれらの書き込み元を特定し、一時停止または制限すべきか評価してください。操作中も同じエンティティが更新され続けると、変更を適用する前に比較結果が古くなる可能性があります。
書き込み前に依存関係と競合を解決する
行同士は、外部キーや業務ルールを介して依存していることがよくあります。請求書は顧客に依存し、明細、支払い、監査記録などを持つ場合があります。主レコードだけを復元すると参照が壊れる可能性があります。一方、分析せずに一式を復元すると、処理結果が重複したり、すでに終了した状態が再び開かれたりするおそれがあります。
依存関係のマップを作成し、制約に適合する順序を決めてください。一般に、参照先のエンティティを先に復元し、その後で従属するエンティティを復元します。データを削除または置換する場合は、順序が逆になることがあります。テーブルの並び順が業務上の順序を反映しているとは限りません。データベース制約は不整合の検出に役立ちますが、アプリケーションの検証に取って代わるものではありません。
復元可能なコピーを適用する前に、候補ごとに現行状態と比較してください。そのコピーは過去の状態を示す証拠であり、必ずしも最終的な正解ではありません。たとえば、レコードが存在しない、コピー以降変更されていない、コピー以降に変更された、コピー後に作成された、といったケースに分類します。その後に行が変更されていたら、自動的に上書きしないでください。異なるフィールドを確認し、復元するか、統合するか、そのままにするか判断します。
安全な方法では、解決を強制するのではなく、確認用の競合一覧を作成できます。PHPでは、アプリケーションロジックで計画を準備し、ドメインルールを検証する一方、エンジンと操作が許す範囲でデータベーストランザクションにより一連の書き込みを保護できます。処理量や所要時間が単一トランザクションで扱うのに適さない場合は、冪等性のあるバッチに分割し、制御された形で再開できるよう進捗を記録します。
リハーサル、承認、実行を追跡可能にする
リハーサルには、機密データを適切に保護した、隔離済みで本番を代表するコピーを使用してください。本番で予定しているのと同じ手順を実行し、プレビューを生成します。プレビューには、候補レコード数、提案する変更、除外対象、競合、失敗した検証を含めます。プレビューはSQLだけでなく、業務への影響を理解している人が確認できるものでなければなりません。
- 現行状態を保全する：復元可能なコピーが存在することを確認し、作業前の状態を記録します。そのコピーにアクセスでき、予定した環境に対応することも確認してください。
- 計画を準備する：具体的なキー、依存関係、操作順序、処理を停止する条件を特定します。
- リハーサルする：非本番環境で実行し、合意した条件と結果を比較します。後続の変更があるケースや、リレーションが欠けているケースも含めます。
- 確認して承認する：対象範囲を検証する人と、実行を承認する人を記録します。想定外の競合が見つかった場合は、自動的に範囲を広げず、再分析してください。
- 実行して検証する：管理された時間帯に変更を適用し、エラーを監視して、復元したデータを業務ルールに照らして確認します。
依頼、担当者、承認、使用したコピー、影響を受けたキー、検証結果、手作業による介入を記録してください。技術ログに不要な機密情報を保存しないようにします。この追跡記録は監査を容易にし、復元された状態とその後の変更を区別するのに役立ちます。
整合性を検証し、ロールバックに備える
書き込みが成功しても、操作はまだ終わりではありません。孤立参照、予期しない重複、制約違反がないことを確認してください。また、整合した合計値、許可された状態、データベース制約として表現されていない可能性のあるリレーションなど、業務上の不変条件も検証します。検索インデックス、キャッシュ、保留中のイベント、外部システムといった派生先への影響も確認してください。行を復元しても、送信済みの通知が取り消されるとは限らず、古くなったプロジェクションが修正されるとも限りません。
停止またはロールバックの意味を事前に定義してください。トランザクションを開いている間は書き込みを取り消せますが、すでに発生した外部への影響は自動的には戻りません。バッチ実行では、以前の値の記録と補償処理が必要になる場合があります。最初の復元に対して、その場しのぎの二度目の復元を実行しないでください。さらに多くの変更を上書きするおそれがあります。状態を確認し、同等の承認を得たうえで、リハーサル済みのロールバックを適用してください。
手順を訓練し、限界を把握する
誤削除、一部の誤変更、コピー取得後に変更されたレコード、従属するリレーションを持つエンティティなど、代表的なシナリオを試してください。準備と実行にかかる時間を測定し、権限を確認し、競合時の判断者を記録します。理想的な手順だけを説明したガイドでは不十分です。停止基準、担当者の連絡先、連絡手順も含める必要があります。
選択的復元には限界があります。十分に新しい復元可能なコピーがない場合、信頼できる識別子が不足している場合、または追跡できないまま誤変更が外部システムに伝播した場合は、実施できないことがあります。その場合は、別の情報源からデータを再構築するか、より広範囲の復旧を選ぶ必要があるかもしれません。何を保持し、何を失い、どのような不確実性が残るかを明示して判断してください。
検証済みの手順があれば、リスクの高い操作を監査可能な判断へと変えられます。データと除外対象を限定し、状態を比較し、競合を明らかにし、インシデントを終了する前に結果を検証できます。重要なデータを扱うPHPアプリケーションを保守するチームにとって、こうした準備はバックアップを用意することと同じくらい重要です。
