復元テストをしていないバックアップは機能するか誰も知らない 実際の復元手順

バックアップは設定してある。しかし実際に復元したことは一度もない。この状態は、消火器を買ったが使い方を知らないのと同じです。本番で初めて復元を試みて、ファイルが壊れていた、手順が分からない、対応できる人がいない、と気づくのが最悪のパターンです。この記事では、復元の実際の手順と、平時に行う復元テストのやり方を解説します。

復元には3つの経路がありそれぞれ手順が異なる

まず自社がどの経路で復元できるかを把握します。

経路	復元にかかる時間	必要な知識	注意点
バックアッププラグイン	30分〜数時間	低い	管理画面に入れることが前提
レンタルサーバーの復元機能	数時間〜数営業日	低い	保持期間が7〜14日と短い
手動での復元	数時間	高い	FTPとデータベース操作が必要

管理画面に入れるかどうかで経路が変わる

プラグインでの復元は、WordPressの管理画面にログインできることが前提です。サイトが真っ白になって管理画面にも入れない場合、この経路は使えません。その場合はサーバー側の復元機能か、手動復元になります。

サーバーの復元機能は先に条件を確認しておく

レンタルサーバーの自動バックアップからの復元は、手数料が発生する場合や、申請から完了まで数営業日かかる場合があります。緊急時に「3日後です」と言われてから知るのでは遅すぎます。契約中のサーバーの条件を、平時のうちに確認してください。

プラグインからの復元手順

最も一般的な経路です。

基本的な流れ

1. 現在の状態をバックアップする（復元に失敗した場合に戻すため）
2. バックアッププラグインの管理画面を開く
3. 復元したい時点のバックアップを選ぶ
4. 復元対象を選ぶ（ファイル・データベース・両方）
5. 復元を実行する
6. 完了後、サイトの表示とフォームを確認する

復元前に現状をバックアップする理由

復元作業自体が失敗することがあります。その場合、元の状態にも戻せなくなると打つ手がなくなります。壊れている状態であっても、作業前に保存しておいてください。（壊れた状態にも、戻れることに価値があります）

どの時点に戻すかの判断

改ざんされた場合、いつ侵入されたか分からないため、確実に正常だった時点まで遡る必要があります。直近のバックアップに戻して同じ症状が出るなら、さらに古い世代を試します。この作業のために、複数世代を保持しておく必要があります。

ファイルとデータベースの両方を復元する

片方だけ復元すると、記事はあるのに画像が出ない、あるいはその逆の状態になります。WordPress公式も、バックアップの対象としてこの2要素を示しています（出典 WordPress Developer Resources Backing Up Your WordPress Site）。

復元テストは本番とは別の場所で行う

平時にやるべき検証です。

本番サイトで試してはいけない

復元テストを本番環境で行うと、テストのつもりが本番を壊すことになります。必ず別の場所で実施してください。

テスト環境の作り方

• サーバーのサブドメインにテスト用の領域を作る
• レンタルサーバーのステージング機能を使う（対応プランの場合）
• ローカル環境構築ツールをPCに入れて再現する
• テスト環境には検索エンジンをブロックする設定を必ず入れる

テスト環境が検索結果に出ないようにする

テスト用のサイトが検索結果に表示されると、本番サイトと内容が重複し、閲覧者も混乱します。WordPressの表示設定で検索エンジンをブロックし、可能ならアクセス制限もかけてください。

テストで確認すること

1. バックアップファイルが破損せずダウンロードできるか
2. 復元処理が最後まで完了するか
3. 復元後、トップページと下層ページが表示されるか
4. 画像が正しく表示されるか
5. 管理画面にログインできるか
6. 問い合わせフォームが動作するか
7. 作業にかかった実際の時間

かかった時間を記録する

復元にどれだけ時間がかかるかを知っておくと、緊急時に関係者へ復旧見込みを伝えられます。「いつ直るか分からない」と答えるしかない状態は、それ自体が信用を損ないます。

テストで発覚する典型的な問題

実際に試すと出てくる問題です。

バックアップが途中で失敗していた

ファイルは存在するのに、中身が不完全というケースがあります。容量の大きいサイトで、処理が時間切れになっている場合に発生します。失敗時にメール通知が届く設定にしておいてください。

データベースだけしか保存されていなかった

設定を確認したつもりが、ファイルが対象外になっていたというケースです。復元してみて初めて、画像が1枚も戻らないことに気づきます。

保存先の容量が上限に達していた

クラウドストレージの無料枠が上限に達し、数ヶ月前からバックアップが保存されていなかった、という状態です。プラグインの画面では正常に見えるため、保存先を直接確認しないと気づけません。

復元できる人が社内にいなかった

手順を知っている人が退職している、あるいは制作会社に依存している状態です。これは技術的な問題ではなく、体制の問題です。

復元手順を紙で残す

緊急時に参照できる形にしておきます。

サイトが止まっていると社内の資料も見られない場合がある

手順書を自社サイト内やサーバー上に置いていると、障害時に参照できません。クラウドと紙の両方に保管してください。

手順書に含める内容

• バックアップの保存先と、そこへのアクセス方法
• 使用しているバックアッププラグインの名称
• サーバーの管理画面URLとログイン情報の保管場所
• サーバー会社のサポート窓口と契約番号
• 復元の手順（画面名と操作を順に）
• 復元後に確認する項目
• 対応できない場合に連絡する保守会社の連絡先

年1回、実際にやってみる日を決める

手順書を作っただけでは、いざというとき使えません。年に1度、実際に復元テストを行う日をカレンダーに登録してください。この1時間が、事故時の数日を救います。

最後に

バックアップは、取得できていることと復元できることが別問題です。復元テストをしていないバックアップは、機能するかどうか誰も知らない状態にすぎません。テスト環境を用意し、実際に復元し、かかった時間を記録し、手順を紙で残す。年1回1時間の作業で、いざというときの復旧が「試したことがある作業」に変わります。本番で初めて復元を試みる事態だけは、避けてください。

Web管理では、月額1万円からホームページの運用保守を代行しています。バックアップ体制の構築、定期的な復元テスト、障害時の復旧作業まで対応可能です。「バックアップはあるが復元できるか分からない」という状態の診断からでも承ります。お気軽にご相談ください。