「バックアップは取っているから大丈夫」の落とし穴

WordPressのバックアップは取っていますか?と伺うと、多くの方が「プラグインが自動で取ってくれています」と答えます。ところが実際のトラブル現場では、バックアップを取っていたのに、戻れる状態のデータがひとつも残っていなかったというケースが起こります。

この記事では、WordPressのバックアップの基本と、エックスサーバーなら標準の自動バックアップでほぼ完結するという現実的な考え方を解説します。あわせて、まさに「プラグインのバックアップが全滅していた」お客様サイトを復旧した実例も紹介します。

WordPressのバックアップ対象は「ファイル」と「データベース」の2つ

まず基本からです。WordPressのサイトは、大きく2種類のデータでできています。

  • ファイル:WordPress本体・テーマ・プラグイン・アップロードした画像など、サーバー上に置かれているファイル一式
  • データベース:記事本文・固定ページ・各種設定・ユーザー情報などが保存されたMySQL(MariaDB)のデータ

大事なのは、どちらか片方だけではサイトを復元できないということです。「バックアップが取れている」と言えるのは、ファイルとデータベースの両方が、同じ時点のセットでそろっている状態を指します。

WordPressサイトを構成するファイルとデータベースのイメージ

エックスサーバーなら標準の自動バックアップでほぼ完結する

「だからバックアッププラグインを入れましょう」と続くのが定番ですが、私はエックスサーバーをお使いのお客様には、まずサーバー標準の自動バックアップを基本に据えることをおすすめしています。理由はシンプルで、何も設定しなくても最初から動いていて、内容も十分だからです。

項目 エックスサーバーの自動バックアップ
対象 サーバー領域データ(Web・メール)+MySQLデータベース
保存期間 過去14日分(毎日自動)
設定 不要(契約時から自動で有効)
費用 無料(データの取得・復元も無料)

特に見逃せないのが、WordPressの外側(サーバー会社側)の仕組みとして動いている点です。プラグインによるバックアップはWordPressの中で動くため、サイト本体が壊れるとバックアップの取得や復元まで巻き込まれることがあります。標準バックアップはサイトの状態に関係なく毎日淡々と保存されるので、サイトが完全に壊れた後でも取り出せます

実際の画面がこちらです。復元したい日付を過去14日分から選ぶだけ、という分かりやすい作りになっています。

実例:プラグインのバックアップが「全滅」していた税理士事務所サイト

ここで、当社が実際に対応した事例を紹介します。お客様は税理士事務所。サイトの移行作業をご自身で行った際に、表示が崩れてページが見られなくなってしまったというご相談でした。

原因を調べると、WordPressはもともと public_html/wp/ というサブディレクトリにインストールされていました。ところが、バックアップを取ってリストアしたときに誤って public_html 直下に復元してしまい、設置場所の不整合でサイトが表示されなくなったのです。さらにお客様はネットで調べながらご自身で操作を重ねてしまい、状況は悪化。いわゆる「ドツボにハマった」状態でご連絡をいただきました。

ここで頼みの綱になるはずだったのが、導入されていたバックアッププラグインです。ところが保存されていたのは直近7日分だけ。不具合が出てから日が経っていたため、7世代すべてが「壊れた後」の状態で、健全な時点のバックアップは1つも残っていませんでした。バックアップは毎日きちんと動いていたのに、戻れる場所がない――「取っているのに戻せない」の典型例です。

それでも復旧できたのは、エックスサーバーの標準バックアップが14日分残っていたからです。壊れる前にあたる10日前のバックアップデータを使い、サーバーパネルの復元機能でサイトを復旧できました。この事例の教訓は明確です。

  • 世代の深さが命:不具合に気づくのが遅れるほど、浅い世代のバックアップは「壊れた後」で埋まっていく
  • サイトの中だけに置かない:プラグイン頼みのバックアップは、サイトと運命をともにすることがある
  • 「取れているか」より「壊れる前に戻れるか」:バックアップの価値は、戻りたい時点が残っているかで決まる

それでもバックアッププラグインが役に立つケース

標準バックアップを基本にしつつ、次のような場合はプラグイン(UpdraftPlusなど)や手動でのバックアップを組み合わせる価値があります。

  • 14日より前に戻りたい可能性がある:改ざんやマルウェア感染は発覚が遅れがちで、14日では足りないことがあります
  • サーバーの外に保管したい:Google Driveなど外部ストレージへ二重に逃がしておくと、サーバー側の障害や契約トラブルにも備えられます。当社の保守プラン(ベーシック以上)の「二重バックアップ」も、この考え方です
  • お使いのサーバーに自動バックアップがない・有料:この場合はプラグインが主役になります

ひとつ注意したいのは、今回の事例の直接の原因はプラグインではなく、復元先(インストール先ディレクトリ)の指定ミスだったことです。バックアップの復元は「戻す場所」を正しく理解して行う必要があり、自信がなければ触る前に専門家へ相談したほうが結果的に早く済みます。

【技術メモ】エックスサーバーでの取得・復元手順

実際の操作は、サーバーパネルの2つのメニューで完結します。ポイントはファイルとデータベースを「同じ日付」でそろえて戻すことです。片方だけ別の日付に戻すと、記事とファイルの内容が食い違う不整合の原因になります。

  1. サーバーパネルにログインし「バックアップ」を開く(ファイル側)
  2. 「自動バックアップデータから復元」タブで対象バックアップ日を選び、復元を実行する(取得だけして中身を確認することも可能)
  3. データベースは別メニューの「MySQLバックアップ」「MySQL復元」から、同じ日付で取得・復元する

取得を申請すると処理状況が履歴に残り、「正常終了」になればデータの用意ができています。取得したバックアップデータは24時間経過すると自動的に削除されるため、ダウンロードするならその日のうちに済ませましょう。

また、サイトを大きく触る予定があるときは、同じ画面の「手動バックアップデータ作成」で直前の状態を確保してから作業すると安心です。WordPressを安全に更新する手順でも解説しているとおり、バックアップは「事故が起きてから探すもの」ではなく「作業の前に用意するもの」です。

まとめ:バックアップは「戻れる時点が残っているか」で考える

WordPressのバックアップは、対象が「ファイル」と「データベース」の2つであること、そして壊れる前の時点に戻れるだけの世代が残っていることが本質です。エックスサーバーなら標準の自動バックアップ(14日分・無料)が最初から動いているので、まずはその存在を知っておくだけでも、いざというときの選択肢がまったく違ってきます。

私たちEdel Heartsは、今回のような復旧対応から、定期バックアップ・二重バックアップを含む日常の保守まで対応するWordPress専門チームです。保守を自分でやるか外注するか迷っている方や、サーバー移転・サイトの引き継ぎを控えている方も、お気軽にご相談ください。

この記事をシェア