WordPressのバックアップは、ファイルをZIPにした時点では完了ではありません。必要なデータがそろい、別環境へ戻せて、投稿・画像・設定・ログインを確認できて初めて、復旧手段として頼れます。
WORK EDITとしての結論
データベースとWordPressファイルを近い時刻の1セットで保存し、本番とは別の環境で定期的に復元テストを行うのが基本です。自動処理の「成功」表示だけで判断せず、復元後の画面と主要機能まで確認します。
向く人
- 更新、テーマ変更、HTTPS化の前に戻せる状態を作りたい人
- 投稿や画像の更新頻度が高いサイト運営者
- ホスティングの自動バックアップを使っているが、復元したことがない人
向かない人
- 本番サイトをそのまま復元テストの場所にしようとしている人
- データベースやファイルを上書きする権限・影響範囲を確認できない人
- ECや会員サイトで、復元中に増える注文・会員データの扱いを設計していない人
公式情報：保存対象は「データベース」と「ファイル」の両方
WordPress公式のAdvanced Administration Handbookは、一般的なWordPressサイトを完全に戻すには、データベースとファイルの両方が必要だと説明しています。データベースには投稿、コメント、各種設定などがあり、ファイル側にはテーマ、プラグイン、アップロード画像、wp-config.php、.htaccessなどがあります。サーバー上のWordPressディレクトリをダウンロードしただけでは、通常は別システムにあるデータベースまでは含まれません。
公式文書は、両者を近い時刻に作成した「バックアップセット」として扱う考え方も示しています。自動バックアップがあっても、ときどき手動で確認し、複数世代を異なる場所へ保管することが推奨されています。
取得前に決める4項目
- 復旧時点：障害発生時に何時間・何日分まで失ってよいか。
- 対象：DB、
wp-content、設定ファイル、独自コードなど何を含めるか。 - 保管先：同じサーバーだけに置かず、別ストレージにも複製するか。
- 復旧担当：ホスティング会社、自分、保守担当の誰が戻すか。
更新頻度が高いほど取得間隔は短くする必要があります。ただし頻度はサイトごとに異なり、固定の正解はありません。
実務手順：バックアップを1セットで残す
1. 変更を止める時間帯を選ぶ
取得中に投稿や注文が増えると、DBとファイルの時点がずれることがあります。更新の少ない時間を選び、EC・会員サイトでは必要に応じてメンテナンス方法を保守担当と決めます。
2. データベースを書き出す
ホスティングの管理画面、phpMyAdmin、バックアップ機能など、その環境で正式に提供される方法を使います。WP-CLIを管理できる環境ではDBのexport/importも可能ですが、コマンドを使えることと復元設計ができていることは別です。
3. ファイルを保存する
少なくともwp-content内のテーマ、プラグイン、uploadsと、サイト固有の設定ファイルを確認します。ホスティングの「サイト全体」バックアップが、DBを含むのか、メールや別サイトまで含むのかも仕様で確認します。
4. 同じ識別子を付ける
DBとファイルに取得日時、サイト名、環境名を付け、組み合わせを取り違えないようにします。暗号化の有無、保存期限、復元に必要な認証情報の管理先も記録します。認証情報そのものをバックアップ名や共有メモへ平文で書かないでください。
復元確認は本番と分離する
空の検証環境または隔離したステージングへ、まずファイルを配置し、次にDBを読み込みます。接続先が変わる場合はwp-config.phpのDB情報を合わせます。ドメインやパスが変わる検証では、シリアライズされたデータを壊さない方法でURLを置換する必要があります。
復元後は、次を合格条件として確認します。
- トップ、投稿、固定ページ、カテゴリ、404ページが開く
- 管理画面へログインでき、投稿の作成・下書き保存ができる
- 新旧の画像とPDFが表示・取得できる
- 有効化されるテーマとプラグインが想定どおり
- パーマリンク、フォーム、検索、メールなど重要機能が動く
- PHPエラーや無限リダイレクトがなく、画面崩れがない
- バックアップの取得日時と復元したデータの時点が一致する
WORK EDITの分析：ログより「復旧時間」を測る
ここからは公式仕様の転載ではなく、運用上の分析です。バックアップ製品の成功率だけでなく、復元開始から主要ページが使えるまでの時間を記録すると、障害時の現実的な判断材料になります。手順書に「誰が、どの権限で、どこまで確認したか」を残すと、担当者が変わっても再現しやすくなります。
また、復元テスト用環境を検索エンジンや一般利用者へ公開しない設計も必要です。個人情報を含むDBの複製では、アクセス制限と保存期間を別途決めてください。
最大の注意点
本番DBへのimportやファイル上書きを、復元テストとして試さないことです。実行前に対象ホスト、DB名、環境名を再確認し、戻す直前の現状データも退避します。EC・予約・会員サイトでは、古いバックアップへ戻すことで新しい取引データが失われるため、単純な全上書きでよいとは限りません。
未確認事項
本記事では、特定ホスティング会社やバックアッププラグインの保存期間、料金、暗号化方式、復元保証、画面操作は確認していません。実際の復元可否は、契約プラン、サーバー構成、DB容量、外部ストレージ権限、マルチサイト構成などで変わります。実行前に利用中サービスの公式手順とサポート範囲を確認してください。
次に読む
バックアップを用意できたら、HTTPからHTTPSへ切り替える前の確認で、移行時の取りこぼしを点検できます。復元や更新を本番から分離して試す場合は、WordPressのステージング環境も参照してください。
