WordPressでサイトを運営していると、「サーバー会社がバックアップしているなら、自分では何もしなくてもよいのでは」「記事はWordPressの中にあるのだから、消えることはないのでは」と考えることがあります。しかし、バックアップは単にデータを複製する作業ではありません。トラブルが起きたときに、サイトを元の状態へ戻すための準備です。
WordPressのサイトは、記事本文だけでできているわけではありません。画像、テーマ、プラグイン、各種設定などのファイルと、投稿や固定ページ、コメント、ユーザー情報などを持つデータベースが組み合わさって表示されています。どちらか一方だけを保存しても、元どおりに復元できない場合があります。
この記事では、WordPressのバックアップが必要な理由、保存する対象、保存先の考え方、頻度の決め方、バックアップを「使える状態」に保つ確認ポイントを初心者向けに整理します。特定のプラグインを比較する記事ではなく、どの方法を選ぶ場合にも共通する基礎知識に絞って解説します。
WordPressのバックアップとは
バックアップとは、現在のサイトを構成するデータを別の場所に保存し、障害や操作ミスが起きたときに戻せるようにすることです。コピーを作っただけでは十分とは限りません。必要なデータがそろっていること、保存した時点が分かること、必要なときに取り出せること、復元方法を確認できることまで含めて考える必要があります。
WordPress公式の「Backups」では、一般的なWordPressサイトを完全に復元するには、データベースとファイルの両方が必要だと説明されています。ファイルとデータベースは別の場所に保存されるため、サーバー上のフォルダをダウンロードしただけでは、記事や設定が入ったデータベースまで保存できないのが通常です。
バックアップは、トラブルそのものを防ぐ仕組みではありません。更新失敗、誤操作、故障、不正アクセスなどが起きた後に、損失を小さくして再開を早めるための仕組みです。セキュリティ対策や更新管理と役割が異なるため、どちらか一方で代用するのではなく、組み合わせて運用します。
バックアップが必要になる主な理由
サイトが壊れる原因は、悪意のある攻撃だけではありません。日常的な更新や編集でも、条件の組み合わせによって問題が起きます。原因を完全に予測するのは難しいため、「問題を起こさない」対策だけでなく、「起きても戻せる」準備が必要です。
更新や設定変更で表示が崩れることがある
WordPress本体、テーマ、プラグインは、それぞれ別の開発者や更新周期で動いています。単体では正常でも、更新後に相性の問題が表面化することがあります。管理画面に入れなくなったり、一部の機能だけ動かなくなったりするケースもあります。
更新前の状態を保存しておけば、原因を調べる間に元へ戻す選択肢を持てます。ただし、バックアップが古すぎると、更新後に追加した記事や受け付けたフォーム情報が失われる可能性があります。更新前に取るバックアップと、定期バックアップは別々の役割を持ちます。
誤操作で記事や設定を失うことがある
固定ページを削除した、ウィジェットやメニューを変更した、テーマの設定を初期化した、ファイルを上書きしたといった操作ミスは、経験に関係なく起こり得ます。WordPressにはリビジョンやゴミ箱がありますが、すべての設定やファイルを元に戻せる万能な仕組みではありません。
リビジョンは記事編集の履歴を戻すために便利ですが、テーマのファイル、アップロード画像、プラグイン設定、データベース全体の破損には対応できません。部分的な履歴機能と、サイト全体のバックアップを混同しないことが大切です。
サーバー障害や契約上の問題に備える必要がある
サーバー会社は安定運用に努めていますが、機器故障、作業事故、アカウント停止、契約終了など、利用者側では制御できない事態も考えられます。バックアップが同じサーバー内にしかないと、サーバーへアクセスできない状況では一緒に取り出せなくなるおそれがあります。
サーバー会社のバックアップは心強い仕組みですが、保存期間、取得間隔、復元対象、復元費用、利用者が直接ダウンロードできるかどうかはサービスによって異なります。契約中のサービスの仕様を確認し、自分で管理するコピーも持つと安心です。
不正アクセスやマルウェアの影響を小さくする
不正アクセスを受けると、ファイルの改ざん、管理者ユーザーの追加、不要なスクリプトの設置、データベースの変更などが起きる場合があります。問題が発覚した時点のバックアップにも改ざんが含まれている可能性があるため、直近の1世代だけでなく、複数の時点を残す考え方が必要です。
安全な復旧では、単に古いデータへ戻すだけでなく、侵入経路を調べ、パスワードや認証情報を変更し、WordPress本体や拡張機能を安全な状態に整えます。バックアップは復旧材料の一つであり、感染原因を取り除く作業の代わりではありません。
移行や大きな改修の失敗に備える
サーバー移行、ドメイン変更、テーマ変更、大規模なデザイン改修などでは、ファイルとデータベースの両方が変わります。作業前の状態を一式で保存しておけば、切り戻しの判断がしやすくなります。
ただし、移行用コピーを一度作っただけで、日常のバックアップ運用が完成するわけではありません。移行作業用、更新前、定期保存という目的ごとに、いつ作成したものか分かるよう管理します。
WordPressで保存する対象
WordPressのバックアップでは、「ファイル」と「データベース」をセットで考えるのが基本です。作成時刻が大きくずれた別々のデータを組み合わせると、画像はあるのに記事から参照されない、設定とプラグインの状態が合わないといった不整合が起きることがあります。なるべく近い時刻に取得し、一組として管理します。
データベースに入っているもの
一般的なWordPressのデータベースには、投稿、固定ページ、コメント、カテゴリー、タグ、ユーザー情報、サイト設定などが保存されています。テーマやプラグインによっては、独自の設定やフォームの履歴、EC機能の注文情報などもデータベースへ保存されます。
そのため、記事本文だけを別の文書へコピーしても、サイト全体のバックアップにはなりません。記事が少ないサイトでも、ナビゲーションやウィジェット、プラグイン設定など、再設定に時間がかかる情報が含まれています。
ファイルに入っているもの
ファイル側には、WordPress本体、テーマ、プラグイン、アップロードした画像やPDF、設定ファイルなどがあります。特に、通常は「wp-content/uploads」配下にある画像や資料は、データベースを保存しただけでは戻りません。
WordPress本体や公開配布されているテーマ、プラグインは再入手できる場合がありますが、同じ版がすぐ手に入るとは限りません。子テーマの編集内容、独自に追加したコード、サーバー固有の設定ファイルは、手元のコピーがなければ再現が難しくなります。
WordPressのエクスポートとの違い
WordPress管理画面の「ツール」から使えるエクスポート機能は、投稿などをXMLファイルとして書き出すための機能です。別サイトへコンテンツを移す用途には便利ですが、テーマやプラグイン、すべての設定、画像ファイルそのものを含む完全なサイトバックアップとは役割が異なります。
エクスポートファイルを補助的に持つのは有効ですが、それだけで復元できると思い込まないようにしましょう。使っているバックアップ方法が、データベースとファイルのどこまでを含むのかを確認する必要があります。
バックアップの保存先を分ける理由
バックアップの保存先は、一つに絞らないことが重要です。サイト本体と同じ場所にあるコピーだけでは、その場所自体に障害が起きたときに利用できません。保存先ごとの弱点を補い合うように組み合わせます。
同じサーバー内だけに置く場合の弱点
同じサーバー内のバックアップは、取得や復元が速く、日常的な操作ミスに対応しやすい利点があります。一方で、サーバー障害、アカウント停止、容量不足、不正アクセスなどの影響をサイト本体と同時に受ける可能性があります。
同一サーバーのコピーを否定する必要はありません。素早い復旧に役立つ第一の保存先として使い、別の場所にもコピーを持つのが現実的です。
クラウドストレージへ保存する
クラウドストレージは、サーバーとは別の場所に自動転送しやすく、複数端末から確認できる利点があります。ただし、容量上限、同期ミス、アカウントの乗っ取り、誤削除の同期などには注意が必要です。
保存先のアカウントには強いパスワードと多要素認証を設定し、共有範囲を必要最小限にします。バックアップにはユーザー情報や設定情報が含まれる可能性があるため、公開リンクを作らず、不要な人に共有しないことが基本です。
パソコンや外付け媒体へ保存する
パソコンや外付けストレージへダウンロードしておけば、サーバーやクラウドサービスへ接続できない状況でもコピーを保持できます。ただし、端末の故障、紛失、ランサムウェア、容量不足といった別のリスクがあります。
外付け媒体は、バックアップ後に常時接続しない運用にすると、端末上の障害やマルウェアの影響を分けやすくなります。機密性の高い情報を含む場合は、媒体やバックアップファイルの暗号化も検討します。
複数の場所と複数の世代を持つ
バックアップ運用では、複数のコピーを異なる種類の保存先に置き、そのうち一つをサイト本体とは別の場所にする考え方がよく使われます。「3-2-1」という呼び方を見かけることもありますが、数字を守ること自体が目的ではありません。同じ事故で全部を失わない構成にすることが目的です。
また、最新の一つだけを残すと、破損や改ざんに気付かないまま正常なバックアップを上書きする可能性があります。日次、週次、月次など複数の時点を残せるようにし、保存容量と復旧したい期間のバランスを決めます。
バックアップ頻度の決め方
すべてのサイトに共通する唯一の正解はありません。基準になるのは、「どれくらいのデータを失うまでなら許容できるか」です。毎日記事や注文が増えるサイトと、月に一度だけ更新する案内サイトでは、必要な頻度が異なります。
更新頻度から考える
記事、コメント、会員情報、問い合わせ履歴、注文情報などが頻繁に増えるほど、バックアップ間隔を短くする必要があります。最後のバックアップから障害発生までに追加された情報は、復元しても戻らない可能性があるためです。
閲覧が中心で更新の少ないサイトでも、放置してよいわけではありません。プラグインの自動更新や外部環境の変化により、管理者が操作していない間にも状態が変わる場合があります。定期取得が動いているかを確認する日を決めます。
重要な作業の直前に取得する
定期バックアップとは別に、WordPress本体、テーマ、プラグインの更新前、大きな設定変更前、テーマ変更前、サーバー移行前には、その時点のバックアップを取ります。作業名や日付を付けておくと、戻す候補を判断しやすくなります。
作業直前のバックアップでは、保存成功の表示だけでなく、ファイルサイズ、作成日時、保存先への到達可否も確認します。バックアップ中に容量不足や通信切断が起きると、ファイルが存在していても不完全な場合があります。
復旧目標から考える
どれくらい前の状態へ戻る可能性があるか、復旧までどれくらい待てるかも判断材料です。更新の多い事業サイトでは、失えるデータ量が小さく、短時間で戻す必要があります。一方、更新の少ない個人ブログでは、頻度を抑えても許容できる場合があります。
難しい用語を使わなくても、「一日分の記事や問い合わせが消えてもよいか」「復旧に半日かかってもよいか」と具体的に考えると、必要な間隔と方法を決めやすくなります。
自動バックアップだけに任せない
自動化は、取り忘れを減らすために有効です。ただし、設定した時点で終わりではありません。認証切れ、保存容量不足、プラグイン停止、サーバー設定変更などにより、知らない間に取得できなくなることがあります。
定期的に成功状況を確認する
管理画面の「成功」という表示だけでなく、保存先に新しいファイルがあるか、作成日時が更新されているか、容量が極端に小さくないかを確認します。通知メールがある場合も、成功通知だけでなく失敗通知を見逃さないようにします。
確認日をサイトの保守日と一緒に決めると、忘れにくくなります。毎回すべてを復元する必要はありませんが、少なくとも定期的にファイルを開けるか、一覧を取得できるかを確かめます。
手動取得を補助として使う
大きな変更の直前や、自動バックアップの設定を変えた直後には、手動バックアップを併用すると安心です。自動と手動を対立する方法として考えるのではなく、定期運用と重要作業前という役割で分けます。
ただし、手動取得したファイルをデスクトップへ置いたままにすると、世代や用途が分からなくなります。サイト名、取得日、取得時刻、作業目的が分かる名前を付け、決めた保存先へ移します。
使えるバックアップにする確認ポイント
バックアップは、復元できて初めて役に立ちます。保存ファイルの存在だけで安心せず、必要な情報がそろい、復元手段が分かる状態を保ちます。
ファイルとデータベースがそろっている
バックアップの一覧で、データベースだけ、またはファイルだけになっていないか確認します。方法によっては、画像を除外したり、一部のテーブルを除外したりできます。容量節約のための除外設定が、復元に必要なデータまで外していないかを見直します。
ファイルとデータベースを別々に取得する場合は、同じバックアップセットだと分かる名前やフォルダで管理します。取得時刻が近いことも確認します。
保存先から取り出せる
クラウドストレージや外部サービスへ自動保存していても、ログインできなければ利用できません。管理者が変わったときに個人アカウントへしか保存されていないと、必要な人が取り出せないことがあります。
誰が保存先を管理するか、二段階認証の復旧手段をどう保管するか、退職や担当変更時にどう引き継ぐかを決めます。バックアップファイルそのものだけでなく、アクセス手段も運用の一部です。
復元方法と権限を確認する
サーバー会社のバックアップは、管理画面から利用者が復元できるもの、サポートへの依頼が必要なもの、特定の範囲だけ戻せるものなど、仕様が異なります。作業が必要になってから調べるのではなく、復元の入口と必要な権限を事前に確認します。
プラグインで作成したバックアップも、同じプラグインを用意しなければ戻せない場合があります。利用している方法の名称、設定、保存先、簡単な復元手順を記録しておきます。
安全な環境で復元テストを行う
本番サイトへいきなり上書きして試すのは危険です。可能であれば、ステージング環境やローカル環境など、公開サイトと分けた場所で復元できるか確認します。テストでは、トップページだけでなく、記事、画像、問い合わせフォーム、ログイン、主要な機能も確認します。
初心者が復元テストを難しいと感じる場合は、無理に本番環境で試さず、サーバー会社や制作者へ相談します。その場合でも、バックアップの保存場所と取得日時を説明できるようにしておくと、復旧作業が進みやすくなります。
バックアップでよくある誤解
サーバー会社が保存しているから十分
サーバー会社の仕組みは重要ですが、それだけに依存すると、保存期間外の状態へ戻したい場合や、契約・アカウントの問題で管理画面へ入れない場合に困る可能性があります。仕様を確認したうえで、利用者側でも別の保存先を持つとリスクを分けられます。
最新の一つがあれば十分
不具合や改ざんに気付くまで時間がかかることがあります。最新のバックアップにも問題が含まれていれば、その一つだけでは正常な状態へ戻せません。異なる時点の複数世代を残し、保存期間を決めます。
バックアップファイルがあれば必ず戻せる
取得失敗、容量不足、除外設定、暗号化パスワードの紛失、対応ツールの不足などにより、ファイルがあっても復元できない場合があります。定期的な確認とテストが必要です。
記事だけ保存すればよい
記事本文は大切ですが、画像、テーマ設定、プラグイン設定、ユーザー、コメントなどもサイトの一部です。WordPressのエクスポートや原稿ファイルは補助的な保存として活用し、サイト全体のバックアップとは分けて考えます。
バックアップはセキュリティ対策の代わりになる
バックアップがあっても、脆弱なパスワードや古いプラグインを放置すれば、復元後に同じ問題が起きる可能性があります。更新、権限管理、多要素認証、監視などの予防策と、バックアップによる復旧策を組み合わせます。
初心者が最初に決めておきたい運用
複雑な仕組みを一度に作る必要はありません。まず、現在使っているサーバーのバックアップ仕様を確認し、自分で管理できる別の保存先を一つ用意します。そのうえで、次の項目を紙や共有文書に記録します。
- バックアップする対象にファイルとデータベースの両方が含まれるか
- 定期バックアップの頻度と保存する世代数
- サーバー外の保存先と管理者
- 更新や大きな変更の前に手動取得するルール
- 成功状況を確認する日
- 復元を始める入口と、困ったときの連絡先
運用を始めたら、最初のバックアップが保存先に届いていることを確認します。次回の自動取得後にも日時が更新されているかを見ます。数か月後に初めて確認するのではなく、設定直後に一度確認することが重要です。
また、サイトの規模や更新頻度が変わったら、バックアップ設定も見直します。問い合わせや注文を受ける機能を追加した、投稿頻度が増えた、担当者が変わったといった変化は、保存頻度や保存期間を見直すきっかけです。
バックアップ方法を選ぶときの判断軸
サーバー機能、プラグイン、手動ダウンロードなど、方法にはそれぞれ特徴があります。初心者は「有名だから」だけで決めず、自分の環境で次の点を満たすかを確認しましょう。
サイトの役割に合っているか
同じWordPressでも、情報を読むだけのブログ、問い合わせを受ける企業サイト、会員がログインするサイト、商品を販売するサイトでは、失ったときの影響が異なります。ブログなら記事や画像の再作成が主な負担ですが、問い合わせや注文を扱うサイトでは、障害発生後に増えたデータをどう保全するかも考えなければなりません。
バックアップの頻度や保存期間は、サイトの規模よりも、更新される情報の重要性に合わせて決めます。アクセス数が少なくても、代わりのない原稿や顧客から受け取った情報があるなら、失ったときの影響は小さくありません。
必要な対象を一式で保存できるか
ファイルとデータベースの両方を取得できるか、画像や独自ファイルが除外されていないかを確認します。複数サイトを運営している場合は、どのサイトのバックアップか識別できることも必要です。
サーバー外へ保存できるか
同じサーバー内だけで完結する方法の場合は、別途ダウンロードや外部転送を組み合わせます。外部保存先へ接続するときは、権限を必要最小限にし、認証情報を安全に管理します。
失敗を通知できるか
自動処理は、失敗に気付ける仕組みがあることが大切です。メール通知、管理画面の履歴、保存先の更新日時など、少なくとも一つの方法で異常を確認できるようにします。
復元手順が現実的か
作成は簡単でも、復元に専門的な操作が必要な場合があります。自分で対応するのか、サーバー会社や制作者に依頼するのかを決め、緊急時に連絡できる情報を用意します。復元の難しさも、バックアップ方法を選ぶ基準です。
バックアップを安全に保管する注意点
バックアップには、公開記事だけでなく、ユーザー情報、サイト設定、場合によっては問い合わせや注文に関する情報が含まれます。通常の公開ファイルより慎重に扱う必要があります。
- 推測されにくいパスワードと多要素認証を使う
- 共有リンクを公開状態にしない
- 不要な担当者のアクセス権を外す
- 持ち運ぶ媒体やファイルを必要に応じて暗号化する
- 古いバックアップを廃棄するときも安全に削除する
- 暗号化パスワードや復旧コードをバックアップと同じ場所だけに置かない
バックアップを増やすほど、情報の置き場所も増えます。保存先の一覧を作り、誰が管理しているか、いつまで残すかを決めておくと、不要なコピーの放置を防げます。
担当者が変わっても困らない記録を残す
バックアップの仕組みが一人の担当者にしか分からないと、その人が不在のときに復元できません。専門的な手順書でなくても、使っている機能やプラグインの名前、保存先、実行時刻、保存期間、通知先、復元を依頼する連絡先を一枚にまとめておくと役立ちます。
保存先のパスワードを文書へ直接書く必要はありません。認証情報をどの管理方法で保管しているか、誰が取り出せるかを記録します。個人のメールアドレスや私物のクラウドストレージだけに依存せず、事業やサイトの管理体制に合うアカウントを使います。
引き継ぎ時には、説明を聞くだけでなく、担当者が実際に最新バックアップの日時と保存先を確認できるかを試します。確認結果を記録すれば、設定が残っているだけで動いていない状態を発見しやすくなります。
バックアップ運用を見直すきっかけ
一度決めた設定がずっと適切とは限りません。記事の投稿頻度が増えた、問い合わせフォームを追加した、EC機能や会員機能を導入した、サーバーを変更した、担当者が増えたといった変化があれば、取得対象と頻度を見直します。
バックアップファイルの容量が急に小さくなったり、逆に増え続けたりした場合も確認が必要です。小さすぎる場合は一部が取得できていない可能性があり、増え続ける場合は保存容量を圧迫して新しいバックアップが作れなくなる可能性があります。通常時のおおよその容量を知っておくと、異常に気付きやすくなります。
復元テストで手順が変わっていた、通知先へメールが届かなくなった、外部保存先の認証が切れた場合は、その場で記録も更新します。仕組みと手順書を同時に直すことで、緊急時に古い情報を参照する事故を防げます。
困ったときに自己判断で復元しないほうがよいケース
復元は現在のデータを上書きする作業になることがあります。次のような場合は、作業前にサーバー会社や制作者へ相談したほうが安全です。
- どの時点から不具合が始まったか分からない
- 最新の問い合わせ、注文、会員情報を失いたくない
- バックアップにファイルとデータベースがそろっているか不明
- 不正アクセスやマルウェア感染が疑われる
- 復元先のサーバーやドメイン構成が以前と異なる
- 本番サイト以外でテストできる環境がない
相談するときは、問題が起きた日時、直前に行った操作、利用しているバックアップ方法、保存先、取得日時を伝えます。情報がそろっていれば、戻すべき時点や作業範囲を判断しやすくなります。
まとめ
WordPressのバックアップは、データを念のため保存するだけの作業ではありません。更新失敗、誤操作、サーバー障害、不正アクセスなどが起きたときに、損失を抑えてサイトを再開するための準備です。
基本は、ファイルとデータベースを近い時刻に取得し、一組として管理することです。保存先はサイト本体と同じサーバーだけにせず、クラウドストレージや手元の媒体など、異なる場所へ分けます。最新の一つだけではなく、問題が起きる前へ戻れるよう複数の時点を残します。
自動バックアップを設定した後も、成功状況、保存先、容量、復元手順を定期的に確認しましょう。バックアップは「作ったか」ではなく、「必要なときに取り出して戻せるか」で評価します。まずは契約中のサーバーの仕様を確認し、ファイルとデータベースの両方がサーバー外にも保存される状態を整えることから始めてください。
