WordPressのMySQLバックアップは、phpMyAdminやサーバーの管理画面からデータをSQL形式で書き出して取得できます。復元は、そのSQLを対象のデータベースへ読み込む操作です。記事や設定は戻せますが、画像やテーマは別のファイルなので、そちらも保存が必要です。

特に注意したいのは復元先です。古いSQLを本番へ読み込むと、現在の記事や問い合わせを上書きする場合があります。最初は空の検証用データベースへ戻し、内容を確かめる方法が安全です。

最初に対象データベースと復元時点を確定する

一つのサーバーで複数のWordPressを運用していると、MySQLのデータベースも複数に分かれていることがあります。バックアップ前に wp-config.php のデータベース名を確認し、サーバー管理画面の表示と照合します。マルチサイトや同じデータベースを共有する構成では、テーブルの接頭辞も確認が必要です。

次に、いつの状態へ戻す可能性があるかを考えます。ブログ中心のサイトと、注文や予約が毎日追加されるサイトでは、許容できるバックアップ間隔が違います。保存世代が一つしかないと、異常に気づく前の正常な状態まで戻れないことがあります。

取得日時と対象DBが分かる名前で保存すると、似たファイルの取り違えを減らせます。複数の人で作業する場合は、取得方法と時刻のタイムゾーンも共有できると確実です。

データベースとファイルを同じセットにする

MySQLへ保存されるのは、記事・設定・ユーザー情報などです。画像の実体・テーマ・プラグイン・WordPress本体・wp-config.php はファイル側にあります。データベースのSQLファイルだけでは、元のWordPressを完全には再現できません。

データベースとファイルは、できるだけ近い時刻に取得します。更新が続くサイトでは、バックアップ中だけ投稿や受注処理を止めるか、サーバー会社が用意する一貫性のあるバックアップ機能を使います。取得時間が離れると、データベースが参照する画像がファイル側にないといった不整合が生じます。

一組のバックアップには同じ識別名を付け、別々の場所へ散らさないようにします。ただし、保存先を公開ディレクトリの下に置いてはいけません。SQLファイルには記事だけでなく、メールアドレスや設定情報が含まれることがあります。

phpMyAdminでバックアップを取る場合

phpMyAdminを利用できる場合の基本的な流れは、対象DBを選択し、「エクスポート」でSQL形式を指定して保存する方法です。画面や利用できる設定は、サーバーの提供環境によって異なります。

  1. WordPressの接続先DB名を確認し、phpMyAdminでそのDBを選ぶ
  2. エクスポートの対象テーブルを確認する
  3. テーブル構造とデータを含むSQL形式で取得する
  4. PCなど公開されない保存先へダウンロードする

同じDBに別サイトのデータがある場合は、無条件に全体を配布しないようにします。容量が大きくてブラウザで完了しない場合は、サーバー提供のバックアップ機能やWP-CLIなど別の方法が必要です。

SQLファイルは取得直後に確認して保管する

phpMyAdminやサーバー管理画面でエクスポートしたら、処理が完了した表示だけで判断しません。ファイルサイズが0バイトでないことを確認し、圧縮されている場合は正常に展開できるかを調べます。SQLを開ける環境では、テーブル作成やデータ挿入の記述が含まれているかも確認します。

WP-CLIを利用できる環境では、wp db export で wp-config.php の接続先からSQLを書き出せます。保存先を省略すると作業ディレクトリへ置かれるため、Web公開領域の外にある出力ファイルを明示します。便利な一方、実行した場所や接続設定が誤っていれば、意図しないデータベースを対象にします。コマンドを記録し、出力先と対象名を照合します。

バックアップはWebから直接ダウンロードできない場所へ移し、閲覧できる担当者を限定します。外部ストレージへ保存する場合は、アクセス権と暗号化を確認します。保管期限を過ぎたファイルは、社内ルールに沿って安全に削除します。

検証環境へ先に復元する

本番データベースへいきなりインポートすると、現在の投稿や設定を失うおそれがあります。まずは空の検証用データベースと、本番から隔離したWordPress環境を用意します。検証環境も外部公開せず、個人情報を含む場合は本番と同じようにアクセスを制限します。

基本の流れは次のとおりです。

  1. 検証先に残っているデータがあれば、上書き前に退避する
  2. バックアップしたWordPressファイルを検証先へ配置する
  3. 空のデータベースと接続ユーザーを用意する
  4. wp-config.phpの接続先を検証用DBへ変更し、本番DBを参照していないことを確認する
  5. 管理画面・phpMyAdmin・WP-CLIのいずれかで、検証用DBを明示してSQLをインポートする
  6. 検証用URLへの変更をWordPress対応の方法で行い、メール送信や決済、定期処理を本番と分離したうえで動作確認する

wp db import は、設定されたデータベースへSQLを実行するコマンドです。データベース自体を新しく作る機能ではなく、SQLに含まれる削除や上書きもそのまま実行します。接続先が本番でないことを、実行直前にもう一度確認します。SQL内にUSEなど別のDBを選ぶ記述があると、指定したDB以外へ作用する可能性もあります。内容を確認し、本番DBへの権限を持たない検証専用ユーザーで実行することが重要です。

ドメインが変わる検証環境では、データベース内のURL変更が必要になる場合があります。WordPressの設定にはシリアライズされたデータが含まれるため、テキストエディターの一括置換は避けます。サーバー会社の移転機能やWP-CLIなど、WordPressのデータ構造を扱える方法を使います。

本番復元ではバックアップ以後の更新を扱う

検証で問題がなくても、本番復元には業務上の判断が残ります。バックアップ時点より後に公開した記事や受け付けた注文は、古いデータベースへ戻すと失われます。復元対象と失われる可能性がある情報を整理し、関係者の了承を得てから作業時間を決めます。

作業中は新しい投稿やフォーム受付が増えないように、必要に応じてメンテナンス表示へ切り替えます。障害が起きている現在の状態も、復元前にファイルとデータベースを退避します。原因調査や、一部データを後から取り出す手掛かりになるためです。

本番で使う対象名と、検証にだけ使うURL置換などの操作は分けます。検証用の接続先やメール停止設定を、そのまま本番へ当てはめないようにします。復元に失敗した場合の連絡先と、作業を中止する時刻も先に決めておきます。

復元後はWordPressの業務機能まで確認する

トップページが表示されたことだけで復元完了とは判断できません。管理画面へログインし、想定した日時の記事や設定へ戻っているかを確認します。画像・テーマ・プラグインが読み込まれ、内部リンクや固定ページが開けることも見ます。

問い合わせフォームはテスト送信し、完了画面と通知メールを確認します。ECや予約サイトでは、商品・顧客・受付記録の整合性を業務担当者にも見てもらいます。定期処理や外部サービス連携がある場合は、認証情報と次回実行予定も確認対象です。

SQLを読み込めたことと、WordPressが元どおり動くことは別です。ファイルとDBが同じ時点にそろい、必要な記事や機能が戻っているかを見ると、復元の不足を見つけやすくなります。