WordPress のバックアップ方法：ファイル、データベース、復元の練習

プラグイン更新前にバックアップを押し、緑の成功メッセージが出ても、サイトが壊れたときに必ず復元できるとは限りません。ファイルが同じサーバーにしか残っていない、データベースが一緒に保存されていない、バックアップ用アカウントへのログインさえ停止したサイトに依存している、といったこともあります。必要なのは、最後まで実行できる復元手順です。

バックアップは引っ越しの荷造りにたとえられます。投稿や設定は中身の一覧、画像やプログラムは箱、外部保管先は別の倉庫、復元練習は箱を開けて中身が使えるか確かめる作業です。このガイドでは一般的な単一の WordPress サイトを例に、日々確認でき、トラブル時に別の担当者へ引き継げる流れを作ります。

まず、どの程度のデータ損失を許容できるか書く

週に一度更新する個人サイトと毎日予約が入る事業所では、許容できるデータの欠落期間が違います。まず「どのくらいの期間の内容なら作り直せるか」を書き、その後で頻度を決めます。例えば毎晩保存していて午後に問題が起きると、当日追加された問い合わせはバックアップに含まれない可能性があります。これはスケジュール上の制約であり、後から復元を押しても埋められません。

サイトのファイルには通常テーマ、プラグイン、アップロードしたメディアが含まれ、データベースには投稿、ユーザー、多くの設定が入ります。完全な復旧には、両方が近い時点のものであることが必要になる場合が多いです。メールボックス、DNS、外部フォームのデータ、外部ストレージは、それぞれのサービスで保存方法を確認し、サイトのプラグインがすべて保存するとは考えないでください。

1. 投稿、メディア、会員、フォーム、外部サービスと担当者を一覧にする。
2. 許容できるデータの欠落期間と、障害後にサービスを復旧したい時間を記録する。
3. 通常のスケジュール、大きな変更前の追加バックアップ、保存する世代数を決める。

外部コピーを確実に元のサーバーから離す

サイト自身のフォルダーに保存すればすぐ取り出せますが、ホスティングアカウントの失効、ディスク故障、サイト全体の削除が起きるとコピーも一緒に失われる恐れがあります。少なくとも別サービスの保存先を用意し、そこへ直接ログインしてファイルを取得できることを確認します。クラウドアカウントの復旧方法は、適切な管理者に引き継いでください。

初めてクラウドに接続したら手動バックアップを実行し、クラウド側で同じ時刻のファイルを確認します。存在するだけで検証完了とはせず、分割アーカイブの欠けがないか、データベースファイルをダウンロードできるか、保存ルールが必要な世代をすぐ消していないかも確かめます。バックアップには個人情報やキーが含まれる場合があるため、共有リンクのアクセスを制限しましょう。

UpdraftPlus：範囲、スケジュール、復元項目を別々に確認

確認時点の公式資料では、「設定」から UpdraftPlus Backups を開き、Settings でファイルとデータベースのスケジュール、保存世代数、リモートストレージを設定します。クラウドの保存先を選んだら認証を完了して保存し、Backup / Restore に戻って Backup Now を実行します。ファイル、データベース、リモートへの送信を含む設定か確認してください。

復元するときは Existing backups で日付を選びます。表示されないコピーは、保存元に応じてリモートを再スキャンするかバックアップファイルをアップロードします。Restore を押して復元対象を選び、事前チェックの結果を読んでから進めてください。同じ URL への通常の復元と新しい URL への移行は別の場面です。画面を先に進めるためだけに URL 置換を有効にしないでください。

無料版と Premium では対象範囲が異なり、例えば WordPress コアファイルのバックアップは有料機能です。プラグインに表示されるバックアップ一式を、そのままサーバー全体のイメージとは呼べません。復元先の環境、コアのバージョン、独自設定も記録します。このガイドで実際にこれらの操作を行ったわけではなく、公式資料を基に手順を整理しています。

WPvivid：バックアップ完了と復元完了を分けて考える

WPvivid Backup Plugin の Backup & Restore では、データベースとファイル、ファイルのみ、データベースのみを選べます。外部保管が必要なら、先に Remote Storage で保存サービスを設定・接続し、バックアップ設定でリモート保存先を選んで Backup Now を押します。完了後は一覧、ログ、ダウンロード可能なファイルを照合してください。

リモートのコピーを復元する場合、公式手順では先にサイトのサーバーへコピーを取得し、その後 Restore を実行します。ここでの取得は、自分のパソコンにダウンロード済みという意味ではありません。復元は現在のデータを上書きし、新しい内容が失われることがあります。また公式資料は、復元中にページを閉じたり、再読み込みしたり、別のページへ移動したりしないよう求めています。

WPvivid の公式資料は、設定の衝突を避けるため、無料版でも Pro でも復元時に wp-config.php と .htaccess を上書きしないと明記しています。独自のデータベース接続、環境設定、リダイレクト規則は別途保存し、一つずつ確認します。バックアップが複数の圧縮ファイルに分かれているなら、見た目で最大のものだけを選ばず、一式すべてを残してください。

復元できると信じる前に、隔離環境で練習する

アクセス制限のあるテスト環境を用意し、ツールが対応する復元または移行方法でコピーを作ります。URL が違えば追加処理が必要な場合があり、通常の復元をそのまま移行とはみなせません。練習前に本番の決済、通知、外部同期を無効にし、複製サイトが注文通知を再送したり、テストデータを元のサービスへ送ったりしないようにします。

投稿に画像を追加した直後のバックアップなど、識別しやすい時点を選びます。復元後、その画像、投稿内容、関連設定がそろっているか確認し、権限を制限したテストアカウントでログインします。トップページが開くことは一部の経路が正常というだけです。検索、個別の投稿、メニュー、フォームも順に操作してください。

1. バックアップ時刻、ツールのバージョン、復元先、予定する上書き範囲を記録する。
2. テスト環境の隔離と外部連携設定を確認し、現在の状態を保存してから復元する。
3. 内容、メディア、ログイン、主要機能を検証し、実際の所要時間と問題点を記録する。

担当者のいる定例作業にする

主担当と引き継げる人を決め、最後の成功時刻と外部コピーを定期的に確認します。アクセスが少ないサイトでは、WordPress のスケジュールに依存する処理が遅れる場合があります。時刻にずれがあれば、頻度を上げるだけでなく、プラグインのログとサーバーのスケジュールを調べてください。

大規模な改修前に識別できる旧版を残し、改修後に新版を作ることで、問題が起きた後のコピーしかない状態を避けます。練習ごとに、足りなかった設定、クラウド権限を持つ人、再接続が必要なフォームなど、失敗の理由を記録へ追加します。次の障害時には、成功画面の画像よりその記録が役立ちます。

詳しい説明を読む

ファイルとデータベースを確認し、完全な外部コピーを保存して隔離環境で復元し、最後にサイト機能を操作して結果を記録するオリジナルのフロー図。

サイトの日常保守を計画する

ローカルに WordPress テスト環境を作る

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress