WordPressのバックアップ｜保存先と復元の確認ポイント

WordPressのバックアップを自動で取っていても、「いつの状態に、どう戻せるか」まで把握できていますか。

バックアップは、保存されていることに加え、必要なデータを取り出して復元できることが大切です。

Webuzzでは、自サイトにはサーバーの自動バックアップを、管理を担当するサイトにはプラグインの定期バックアップを利用しています。

また、サーバーの侵害による被害の復元を依頼され、残っていたバックアップに助けられた経験もあります。

この記事では、その経験を交えながら、保存対象・保存期間・保存先・復元方法の確認ポイントを紹介します。

まず、今のバックアップの仕組みを確認する

最初に、自分のWebサイトが、どの方法でバックアップされているかを確認しましょう。

主な方法には、サーバー事業者の機能、WordPressのプラグイン、手動での保存があります。

方法	保存の仕組み	確認すること
サーバーの機能	事業者が用意した機能で自動・手動保存する	対象データ、保持期間、取得・復元の方法
プラグイン	設定した内容やスケジュールで保存する	保存対象、実行結果、保存先、残す世代数
手動保存	ファイルやデータベースを自分で取得する	取り忘れがないか、保存日時が対応しているか

ちなみに、Webuzzのサイトでは、エックスサーバーの自動バックアップを利用しています。更新のたびに手動保存しているわけではありません。

管理を担当するサイトでは、プラグインによる週1回などの定期保存も利用しています。

ただし、これは実際の運用例です。
必要な頻度は、記事の更新や申し込みの受付など、サイトでどれくらいデータが変わるかによって異なります。

「自動保存を設定したか」だけでなく、「何が、いつ、どこに保存されたか」を確認しましょう。

プラグインなら実行履歴や保存済みデータ、サーバー機能なら取得できるバックアップの一覧を見ます。

予定どおりに処理が終わっているか、直近の保存データが存在するかまで確認します。

保存対象・保存期間・保存先を確認する

バックアップの設定を見るときは、対象・期間・保存先を分けると整理しやすくなります。

容量や世代数だけでなく、自分が戻したい状態を保存できているかを確かめましょう。

保存対象は、ファイルとデータベースの両方を見る

WordPressのデータは、大きくファイルとデータベースに分かれます。

保存対象	主な内容
ファイル	WordPress本体、テーマ、プラグイン、アップロード画像、設定ファイルなど
データベース	投稿、固定ページ、コメント、ユーザー情報、各種設定など

WordPress公式資料（英語）でも、一般的なサイト全体の復元には、両方が必要と説明されています。

WordPressのフォルダをダウンロードするだけでは、通常、データベースまでは保存されません。

プラグインの設定でデータベースだけを保存している場合、画像やテーマのファイルは別途必要になります。

反対に、画像やテーマだけを保存しても、投稿や設定を含めた復元には足りません。

除外設定にも目を向けましょう。

例えば、エックスサーバーのデータベースの公式マニュアルには、テーブル数が1,000を超えるものや、破損などで処理できないものは対象外になると記載されています。

バックアップ機能があることと、自分のデータがすべて保存されていることは同じではありません。

保存頻度と、過去のデータが残る期間を分ける

保存頻度は「どれくらいの間隔で取るか」、保持期間や世代数は「過去のデータをどこまで残すか」です。

例えば、週1回のバックアップでは、保存後に書いた記事や変更した設定が、次の保存まで含まれません。

毎日保存していても、古いデータが順次消える仕組みなら、問題に気づいた時点で必要な日のデータが残っていない可能性があります。

エックスサーバーの現行マニュアルでは、サーバー領域の自動バックアップは14日間、一部の旧サーバーは7日間と案内されています。

保持日数はサーバーパネルで確認できます。

また、データベースの復元可能なデータは、過去14日分までとされています。

これは公式マニュアルの仕様であり、Webuzzの契約環境の画面で確認した日数ではありません。

利用中のサービスについても、一般的な案内だけでなく、実際に選択できる保存日を確認しましょう。

プラグインでは、保存する世代数によって、残る期間が変わる場合もあります。

保存先は、取り出しやすさと保護の両面で確認する

バックアップファイルには、サイトの設定や、データベース内の情報が含まれます。

保存できればよいというものではなく、誰が取得できる状態なのかも確認が必要です。

Web公開用のフォルダ内に保存する場合は、URLを知っている第三者が、認証なしでダウンロードできない設定になっているかを確認します。

保存場所の名前だけで安全性を判断せず、利用する機能の公式説明やアクセス制限を確かめましょう。

また、稼働中のサイトと同じサーバー内だけに保存していると、そのサーバーのデータを失った際に、バックアップも使えなくなるおそれがあります。

WordPress公式の学習資料（英語）でも、Webサーバーとは別の場所にコピーを保管することが勧められています。

外部ストレージや手元にコピーを保管する場合も、共有設定やアクセス権を確認します。

取り出せる場所に残すことと、他人に取得されないよう守ることを、合わせて考えましょう。

サーバーのバックアップに助けられた復元事例

過去には、サーバーが侵害され、その中のサイトに大量の不審なファイルが置かれたケースで、復元を依頼された経験があります。

その環境にはバックアップ用プラグインが入っていませんでしたが、幸いにも、サーバー側のバックアップが残っていました。

復元元を選ぶ際には、不審なファイルの更新日時を、被害が始まった時期を考える手がかりの一つにしました。

それより前のバックアップが残っていたため、復元に利用できました。

ただし、ファイルの更新日時だけで、侵入した日や、バックアップが安全な状態かを確定できるわけではありません。
更新日時は書き換えられる場合もあり、復元元にすでに不審なデータが含まれていないかも考える必要があります。

この対応では、使われていないテスト用WordPressが侵入口とみられました。

テスト用という理由で、ユーザー名とパスワードが安易なものになっていた、という当時の判断です。

復元に加えて、不要なテストサイトの削除、不要なファイルの除去、ログの監視も行いました。

これは個別の対応経験であり、侵害されたサイトが、同じ作業だけで復旧できるという意味ではありません。

侵害時には、原因や被害範囲の調査、再侵入を防ぐ対応も必要になります。

この経験で助かったのは、最新のデータだけでなく、過去の状態へ戻す候補が残っていたことです。

問題に気づくまで時間がかかれば、その間にも保存データは入れ替わります。

保持期間や世代数を確認しておくことは、復元できる可能性を残す備えになります。

更新前に、戻すデータと復元方法を確かめる

更新前には、保存データの有無と、問題が出た場合の戻し方を確認します。

WordPress公式資料（英語）では、定期的な保存に加え、アップグレード前のデータベースのバックアップを勧めています。

自動バックアップを利用している場合も、その保存後に何が変わったかを見ます。

戻した際に失うと困る変更があれば、更新直前の状態を追加で保存しましょう。

いつの状態に、どの範囲を戻すか確認する

例えば、昨夜のバックアップへ戻すと、今朝追加した記事や画像、変更した設定が失われる場合があります。

注文や予約などをサイト内に保存している場合は、そのデータへの影響も確認が必要です。

ファイルとデータベースを組み合わせて戻す場合は、保存日時や対象を合わせ、対応する一組のデータとして扱います。

復元する範囲にも注意しましょう。

エックスサーバーの復元マニュアルでは、対象をドメイン・ディレクトリごとに指定できます。

同マニュアルには、対象のファイルはバックアップの内容に上書きされ、バックアップに存在しない新しいファイルなどは削除されると記載されています。

復元は、現在のデータを書き換える操作です。保存日と対象を確認し、戻す前に残すべき現状のデータがないか整理します。

誰が、どこから復元するか決めておく

バックアップを取ったプラグインがあっても、WordPressの管理画面に入れない状況では、別の復元方法が必要になる場合があります。

問題が起きる前に、次の点を確認しておきましょう。

確認項目	確認する内容
操作する担当者	自分、制作・管理担当者、サーバー事業者の誰が行うか
操作する場所	サーバーパネル、プラグイン、別の復元ツールなど
必要なもの	ログイン情報、バックアップデータ、公式の復元手順
作業の条件	必要な空き容量、所要時間の目安、サービス停止への影響

復元手順を試すなら、本番サイトを上書きせず、テスト環境などで確認します。

ここで紹介しているのは、事前に確認したい一般的な進め方です。

復元後は、表示だけでなく機能も確かめる

復元の処理が完了しても、必要なデータや機能が戻ったかを確認します。

確認対象	見ること
ページ・画像	主要ページが開き、画像やデザインが表示されるか
投稿・設定	戻した時点の内容になっているか
管理画面	ログインと必要な操作ができるか
フォーム	送信と、自動返信・通知メールの受信ができるか
業務に必要な機能	予約や購入など、サイト固有の機能が動くか

更新後の不具合から戻した場合と、侵害された環境を復旧する場合では、必要な確認が異なります。

侵害時は、画面が元に戻ったことだけで対応完了とは判断できません。

バックアップは、戻せる状態まで整えよう

バックアップで確認したいのは、「何を・いつまで・どこに保存し・どう戻すか」です。

自動保存は、日々の負担を減らしてくれる仕組みです。

一方で、保存対象や保持期間、実行結果まで把握しておかなければ、必要なデータが残っているか判断できません。

今回の復元依頼では、サーバー側に過去のバックアップが残っていたことに助けられました。

また、復元に加えて、不要なサイトやファイルの整理、ログの監視も行いました。

まずは、利用中のバックアップ一覧を開き、最新の保存日時、戻せる範囲、復元の操作方法を確認してみましょう。

更新前には保存後の変更も見直し、必要な状態へ戻せる準備を整えておくことが大切です。