WordPressの管理画面やサーバーで「バックアップ成功」と表示されている。それだけで、障害時に元へ戻せるとは限りません。バックアップの目的は保存することではなく、必要な時点へ安全に復元することです。
この記事では、専門知識がなくても「このバックアップは復元に使えそうか」を確認できる7項目に整理します。プラグイン更新前、サーバー移行前、感染調査前にも使える保存用チェックリストです。
【1. ファイルとデータベースがそろっているか】
WordPressは、大きく分けてファイルとデータベースで構成されています。テーマ、プラグイン、アップロード画像、設定ファイルなどはファイル側にあり、投稿、固定ページ、コメント、多くの設定はデータベース側にあります。
データベースだけ、またはファイルだけでは、元のサイトを完全には再現できない場合があります。同じ時点の一組として両方が保存されているか確認します。
【2. 対象サイトと取得日時を特定できるか】
複数サイトを運用していると、似た名前のバックアップが増えます。ファイル名だけで判断せず、対象ドメイン、取得日時、データベース名、容量を記録します。
「最新」という表示も、障害や感染が起きた後の状態を保存している可能性があります。戻したい時点より前の世代が残っていることが重要です。
【3. 同じサーバー以外にも保管されているか】
本番サイトと同じサーバー内だけに置いたバックアップは、そのサーバーの障害、容量不足、アカウント侵害の影響を一緒に受ける可能性があります。
サーバー側の自動バックアップに加えて、契約の異なる保存先や手元の安全な場所にもコピーがあるか確認します。保存先のアクセス権と保管期限も把握します。
【4. 複数世代が残っているか】
一つのバックアップを上書きする運用では、壊れた状態や不正な変更まで保存されたときに戻る先がありません。更新前、直近、少し前というように複数の時点を残します。
必要な世代数は更新頻度で変わります。毎日注文が入るサイトと月一度更新するサイトでは同じ間隔では足りません。失ってよいデータ量を基準に頻度を決めます。
【5. バックアップファイルを実際に確認できるか】
成功通知だけでなく、保存先にファイルが存在し、容量が極端に小さくないか、圧縮ファイルを開けるかを確認します。暗号化されている場合は、復号に必要なパスワードや鍵の管理場所も必要です。
ただし、本番環境で不用意に展開したり、データベースを上書きしたりしないでください。中身の確認と本番への復元は別作業です。
【6. 復元に必要な権限と手順が分かるか】
バックアップがあっても、サーバー管理画面、SFTP、データベース、ドメインやDNSへ入れなければ復元が止まります。誰がどの契約を管理しているか、緊急時に連絡できるかを整理します。
復元する順序、変更前の現状保全、公開を止める判断、確認項目を短い手順書にします。担当者の記憶だけに頼らないことが大切です。
【7. 本番以外で復元テストをしたことがあるか】
最も確かな確認は、隔離した検証環境へ復元し、ログイン、主要ページ、画像、フォームなどを確認することです。バックアップ作成の成功と、復元後の動作確認は別の工程です。
復元にかかった時間も記録します。「何時間以内に再開したいか」と実測時間に差があれば、保存方法や手順を見直せます。個人情報を含むサイトでは検証環境のアクセス制限にも注意します。
【やってはいけないこと】
・障害発生後、現状を保存せず本番へいきなり復元する
・最新バックアップ一つだけを正常だと決めつける
・同じサーバー内のコピーだけで安心する
・ファイルとデータベースの取得時刻が違うまま戻す
・復元後のフォーム、ログイン、表示確認を省略する
【保存用チェックリスト】
・ファイルとデータベースが同じ時点でそろっている
・対象サイト、取得日時、容量を特定できる
・本番と別の場所にもコピーがある
・不具合前を含む複数世代がある
・保存ファイルを読み出せる
・必要な権限と復元手順が分かる
・隔離環境で復元と動作を確認した記録がある
まとめると、バックアップは「作成済み」ではなく、「必要な時点を選び、安全な手順で戻し、動作確認できる」状態になって初めて役立ちます。まずはファイルとデータベース、別保存、複数世代、復元テストの4点から確認してください。
バックアップの確認や、更新・不具合対応前の安全な切り分けが難しい場合は、この記事に掲載している「WordPress不具合・ちょい修正直します」から、必ず購入前にご相談ください。
関連サービスが受付休止・非公開の場合や、どのサービスが合うか分からない場合は、著者名「たか369」からプロフィールへ移動し、「見積り相談」から現在の状況をお知らせください。