ウェブサイトのバックアップで、何を復元できるべきか

バックアップ処理が正常に終わっても、復元が試されていないことがあります。成功レポートだけでは、そのコピーから事業に必要なウェブサイトの要素を戻せるかはわかりません。トップページが復元されても、スタッフがログインできるか、顧客記録を見つけられるか、アップロードした書類を開けるかは判断できません。

まず、実際の仕事から考えます。ウェブサイトを失った後、そこで何をする必要がありますか。その作業を可能にするには、何を戻す必要があるのか、サービス提供者に確認しましょう。

予約と添付書類は一緒に必要です

予約をデータベースに保存し、顧客の書類をアップロードファイルとして保存する予約サイトを想像してください。これは仮の例ですが、状況は簡単に思い浮かびます。予約は戻ったのに、添付ファイルを開くと書類が見つかりません。

予約の詳細はあります。それでも、書類が必要な仕事は進められません。

一般的な WordPress サイトについて、WordPress のバックアップガイドは、データベースとファイルの両方が重要で、一貫した一式として保管すべきだと説明しています。ほかのサイトは構成が異なる場合があります。ひとつのフォルダーをバックアップすればすべて含まれると思い込まず、記録やアップロードファイルが実際にどこに保存されているかを確認してください。

ウェブサイトのソフトウェアや設定、復元して利用するために必要なアクセス権も重要です。接続しているサービスも同様です。オーストラリア信号局のシステム管理ガイドは、データ、アプリケーション、設定を同じ時点の状態に復元し、事前に依存関係を把握することを求めています。事業者の立場では、各要素が一緒に動くのか、復元に必要なアクセス権を誰が持っているのかを確認することです。

直近の作業はどれほど失われる可能性があるか

復元したコピーは、過去のある時点のウェブサイトを表しています。その後に作成された予約は、復元が予定どおりに行われても含まれない可能性があります。

どの時点まで復元できるのか、必要になったときにその情報がどれほど古くなるのかを、サービス提供者に確認しましょう。そして、作業が失われると何が起きるのかを考えます。スタッフは別の記録から再現できますか。顧客への連絡が必要ですか。許容できる範囲は、ウェブサイトの役割によって異なります。

仕事に戻るまでの時間も考える必要があります。データをコピーし直すだけでは終わりません。ほかの要素も復元し、重要な作業ができるかを確認する人が必要です。AWS の復旧テストガイドは、復元を個別にテストし、復元データにアクセスして使えることを確かめ、事業の必要性に照らしてデータの古さや復元・検証にかかる時間を測ることを勧めています。

テストでは各手順にどれくらいかかったかを尋ねましょう。具体的な話し合いの材料になります。ただし、問題の発見や対応の判断も含め、将来の事故全体が同じ時間で終わるという約束ではありません。

支払いはすでに完了しているかもしれません

予約の例に戻りましょう。顧客が外部の決済サービスで予約金を支払ったとします。古いウェブサイトのコピーを復元しても、その支払いは取り消されません。また、ウェブサイトの記録が決済サービス側の記録と一致する保証にもなりません。

予約自体が外部の予約サービスに保存されていれば、ウェブサイトのバックアップには含まれない可能性があります。スタッフが正として扱う記録をどのシステムが持っているのか、そのサービスでは何を復元できるのか、誰が記録を照合するのかを確認しましょう。ウェブサイトを復元しても、接続しているすべてのものが過去の状態に戻るわけではありません。

安全な復元テストを見せてもらう

次の有効な一歩は、権限を持つ担当者が隔離された環境で計画的に復元することです。誰が何を確認するかを事前に決めます。復元したコピーでは個人情報と事業情報を保護し、外部に公開せず、本番の記録に手を加えないようにします。

実際のメール送信、決済、ほかのサービスへの自動リクエスト、実際の予約作成も防ぐ必要があります。利用できる場合は、管理されたテスト用アカウントや接続を使えます。あるサービスを安全にテストできない場合は、その制限を記録し、役割を別途確認してください。

仮の例では、サービス提供者が一貫性のあるコピーを復元し、制限されたアクセス権でログインして、選んだ予約と添付書類を開き、復元時点で存在するはずの内容と照合します。トップページのスクリーンショットだけを見るより、はるかに役立ちます。

この確認が大切な理由を示す過去の事例として、GitLab が2017年1月のデータベース障害について公開した報告があります。当時、想定されていたデータベースのバックアップが利用できず、障害通知メールも拒否され、別のスナップショットから復旧しました。影響を受けたのは GitLab.com のデータベース情報で、リポジトリデータやセルフマネージドの顧客は影響を受けませんでした。この事例は、バックアップの手配があることと、実際に使える復旧手段があることの間に差が生じうると示しています。

結果を見て、何を変えるか決める

何をどの時点から復元し、どの作業を確認して、どんな結果だったかを簡潔に記録してもらいましょう。復元した情報の古さ、復元と確認にかかった時間、必要なアクセス権や接続サービス、失敗した確認や未テストの項目も記録します。

予約を確認できたなら、そのテスト条件でその作業ができたことを示します。すべての記録が完全であること、すべての機能が動くこと、今後の復元に同じ時間がかかることの証明にはなりません。隔離したコピーだけでは、復元したサイトが安全であることや攻撃を受けていないことも確認できません。

その結果を事業に必要なことと照らし合わせます。合意した保守範囲で十分だと判断できる場合もあります。アップロードファイルがない、アカウントにアクセスできないといった具体的な不足が見つかる場合もあります。重要な作業ができるか答えが出ず、追加の確認が必要なこともあります。

LINK-V とウェブサイトの保守について相談する際は、復旧後にスタッフや顧客が行う必要のある作業をお伝えください。ウェブサイトに合わせて、保守の範囲や復元テストの有無を相談できます。