WordPressのバックアップを取っていても、本番環境で復元できるとは限りません。別サイトのデータベースを保存していたり、SQLファイルが途中で欠けていたりすると、必要なときに初めて問題へ気づきます。復元方法を一度も試していない状態も同じです。
安全な運用では、取得件数より「どの時点へ戻せるか」を重視します。対象データベースを確認し、ファイルと同じ時点でバックアップを取ります。そのデータを本番とは別の環境へ復元し、WordPressが動くところまで確かめて初めて、使えるバックアップと判断できます。
最初に対象データベースと復元時点を確定する
一つのサーバーで複数のWordPressを運用していると、MySQLのデータベースも複数に分かれていることがあります。バックアップ前に wp-config.php のデータベース名を確認し、サーバー管理画面の表示と照合します。マルチサイトや同じデータベースを共有する構成では、テーブルの接頭辞も確認が必要です。
次に、いつの状態へ戻す可能性があるかを考えます。ブログ中心のサイトと、注文や予約が毎日追加されるサイトでは、許容できるバックアップ間隔が違います。保存世代が一つしかないと、異常に気づく前の正常な状態まで戻れないことがあります。
バックアップ名には取得日時・対象ドメイン・データベース名を含めます。作業担当者と取得方法も台帳に残すと、似た名前のファイルを取り違えにくくなります。時刻はサーバーと社内で基準が違う場合があるため、タイムゾーンも決めておきます。
データベースとファイルを同じセットにする
MySQLへ保存されるのは、記事・設定・ユーザー情報などです。画像の実体・テーマ・プラグイン・WordPress本体・wp-config.php はファイル側にあります。データベースのSQLファイルだけでは、元のWordPressを完全には再現できません。
データベースとファイルは、できるだけ近い時刻に取得します。更新が続くサイトでは、バックアップ中だけ投稿や受注処理を止めるか、サーバー会社が用意する一貫性のあるバックアップ機能を使います。取得時間が離れると、データベースが参照する画像がファイル側にないといった不整合が生じます。
一組のバックアップには同じ識別名を付け、別々の場所へ散らさないようにします。ただし、保存先を公開ディレクトリの下に置いてはいけません。SQLファイルには記事だけでなく、メールアドレスや設定情報が含まれることがあります。
SQLファイルは取得直後に検証して保管する
phpMyAdminやサーバー管理画面でエクスポートしたら、処理が完了した表示だけで判断しません。ファイルサイズが0バイトでないことを確認し、圧縮されている場合は正常に展開できるかを調べます。SQLを開ける環境では、テーブル作成やデータ挿入の記述が含まれているかも確認します。
WP-CLIを利用できる環境では、wp db export で wp-config.php の接続先からSQLを書き出せます。便利な一方、実行した場所や接続設定が誤っていれば、意図しないデータベースを対象にします。コマンドを記録し、出力先と対象名を照合します。
バックアップはWebから直接ダウンロードできない場所へ移し、閲覧できる担当者を限定します。外部ストレージへ保存する場合は、アクセス権と暗号化を確認します。保管期限を過ぎたファイルは、社内ルールに沿って安全に削除します。
検証環境へ先に復元する
本番データベースへいきなりインポートすると、現在の投稿や設定を失うおそれがあります。まずは空の検証用データベースと、本番から隔離したWordPress環境を用意します。検証環境も外部公開せず、個人情報を含む場合は本番と同じようにアクセスを制限します。
基本の流れは次のとおりです。
- 検証先に残っているデータがあれば、上書き前に退避する
- バックアップしたWordPressファイルを検証先へ配置する
- 空のデータベースと接続ユーザーを用意する
- 管理画面・phpMyAdmin・WP-CLIのいずれかでSQLをインポートする
wp-config.phpの接続先を検証用データベースに合わせる- 検証用URLへの変更をWordPress対応の方法で行う
wp db import は、設定されたデータベースへSQLを実行するコマンドです。データベース自体を新しく作る機能ではなく、SQLに含まれる削除や上書きもそのまま実行します。接続先が本番でないことを、実行直前にもう一度確認します。
ドメインが変わる検証環境では、データベース内のURL変更が必要になる場合があります。WordPressの設定にはシリアライズされたデータが含まれるため、テキストエディターの一括置換は避けます。サーバー会社の移転機能やWP-CLIなど、WordPressのデータ構造を扱える方法を使います。
本番復元ではバックアップ以後の更新を扱う
検証で問題がなくても、本番復元には業務上の判断が残ります。バックアップ時点より後に公開した記事や受け付けた注文は、古いデータベースへ戻すと失われます。復元対象と失われる可能性がある情報を整理し、関係者の了承を得てから作業時間を決めます。
作業中は新しい投稿やフォーム受付が増えないように、必要に応じてメンテナンス表示へ切り替えます。障害が起きている現在の状態も、復元前にファイルとデータベースを退避します。原因調査や、一部データを後から取り出す手掛かりになるためです。
本番では検証時と同じ手順を使い、対象名を読み替えます。手順を途中で変えると、検証した意味が薄れます。復元に失敗した場合の連絡先と、作業を中止する時刻も先に決めておきます。
復元後はWordPressの業務機能まで確認する
トップページが表示されたことだけで復元完了とは判断できません。管理画面へログインし、想定した日時の記事や設定へ戻っているかを確認します。画像・テーマ・プラグインが読み込まれ、内部リンクや固定ページが開けることも見ます。
問い合わせフォームはテスト送信し、完了画面と通知メールを確認します。ECや予約サイトでは、商品・顧客・受付記録の整合性を業務担当者にも見てもらいます。定期処理や外部サービス連携がある場合は、認証情報と次回実行予定も確認対象です。
最後に、復元したバックアップ名・作業日時・確認したURL・担当者を記録します。今回見つかった不足は取得手順へ反映し、一定の間隔で検証環境への復元テストを繰り返します。バックアップは保管するだけでなく、復元確認までを運用に組み込むことで価値が生まれます。
