広告・PR:この記事にはアフィリエイト広告が含まれます。リンク先で申し込みがあると、当サイトが報酬を受け取る場合があります。
WordPressのバックアップは、更新失敗、誤操作、不正アクセス、サーバー障害などが起きたときに、サイトを正常な状態へ戻すための備えです。ただし、バックアップファイルが存在するだけでは十分とはいえません。必要なデータがそろい、復元方法を確認できて初めて役に立ちます。
初心者の方が特に注意したいのは、WordPressのサイトが「データベース」と「ファイル」の2種類で構成されている点です。どちらか一方だけでは、記事、画像、設定、デザインを元どおりに戻せないことがあります。
この記事では、バックアップの対象、サーバー・プラグイン・手動による方法の違い、保存先と頻度、復元前後の確認事項まで解説します。レンタルサーバーやプラグインによって画面や保存対象が異なるため、実際の操作では契約中サービスの公式マニュアルも確認してください。
最初に押さえたいバックアップの4原則
- データベースとファイルの両方を保存する
- WordPressを置いているサーバーとは別の場所にも保存する
- 最新版だけでなく、複数の日時のバックアップを残す
- 定期的に保存結果と復元手順を確認する
この4点を満たすと、「バックアップを設定したつもりだった」「障害と一緒にバックアップも消えた」「壊れた状態だけが上書き保存されていた」といった失敗を減らせます。
WordPressで保存すべきデータ
| 種類 | 主な内容 | 保存漏れで起きること |
|---|---|---|
| データベース | 投稿、固定ページ、カテゴリー、コメント、ユーザー情報、各種設定 | 記事や設定が古い状態になる、ログイン情報や構成が一致しない |
| ファイル | 画像、PDF、テーマ、子テーマ、プラグイン、設定ファイル | 画像が表示されない、デザインや追加機能が戻らない |
データベースに保存されるもの
WordPress管理画面から入力した記事本文やサイト設定の多くは、MySQLまたはMariaDBなどのデータベースに保存されます。記事だけをバックアップしたい場合でも、通常はデータベースの保存が必要です。
ファイルとして保存されるもの
画像やPDFは一般にwp-content/uploads、テーマはwp-content/themes、プラグインはwp-content/pluginsに保存されます。さらに、wp-config.phpや.htaccessなど、環境や動作に関係する設定ファイルもあります。
WordPress本体は公式配布ファイルから用意し直せる場合がありますが、アップロード画像、独自に変更した子テーマ、設定ファイルはサイト固有です。自分のサイトに固有のデータがバックアップ対象に含まれているかを確認してください。
3つのバックアップ方法を比較
| 方法 | 取り組みやすさ | 長所 | 注意点 |
|---|---|---|---|
| レンタルサーバー | 高い | 自動取得されることが多く、管理画面から復元できる場合がある | 保存日数、対象、復元料金、障害時の利用方法を確認する |
| バックアップ用プラグイン | 比較的高い | 日時や保存先を設定しやすい | 容量不足、処理失敗、サイトへの負荷、保存先との接続切れに注意する |
| 手動 | 低い | 対象や保存時点を自分で管理できる | データベースとファイルの保存漏れ、操作ミスが起きやすい |
レンタルサーバーの自動バックアップ
初心者の方は、最初に契約中のレンタルサーバーで自動バックアップが有効か確認しましょう。確認するのは、取得間隔、保存期間、対象となるファイルとデータベース、復元手順、復元にかかる費用です。
サーバー側のバックアップは便利ですが、同じ事業者の環境だけに依存します。大きな更新や設定変更の前には、別の場所にも自分で保存しておくと選択肢を増やせます。
新規契約・乗り換えを検討している方へ(広告・PR)
現在のサーバーで必要なバックアップが取れているなら、この機能だけを理由に乗り換える必要はありません。これからWordPressを始める方や、別の理由で乗り換えを検討している方は、自動バックアップを全プランで標準提供するエックスサーバーも比較候補になります。
対象データや保存期間、復元手順は、契約するサーバーの公式案内で確認してください。自動バックアップはデータの完全性を保証するものではないため、サーバーとは別の保存先へのバックアップも併用しましょう。
参考:エックスサーバー公式「自動バックアップ」(紹介部分の確認日:2026年10月3日)
バックアップ用プラグイン
プラグインを使うと、WordPress管理画面から定期実行や外部ストレージへの保存を設定できます。選ぶ際は、現在のWordPress・PHPとの互換性、更新状況、保存対象、復元機能、外部保存先への対応を確認します。
導入しただけで安心せず、初回バックアップが完了したか、予定日時に新しいファイルが作られているか、エラー通知が届いていないかを定期的に確認してください。プラグインの安全な選び方は「WordPressプラグインの入れ方|追加・停止・削除と安全な選び方」で解説しています。
手動バックアップ
手動では、サーバーのファイルマネージャーやSFTPなどでWordPressのファイルを保存し、サーバーのデータベース管理画面からデータベースを書き出します。自由度は高いものの、初心者には保存漏れや復元時の判断が難しい方法です。
手動で行う場合は、ファイル一式とデータベースを同じ日時のセットとして管理します。接続情報やデータベース名を公開場所へ保存しないことも重要です。
バックアップ頻度の決め方
適切な頻度は、「障害発生時に、何時間または何日分の更新までなら失っても運営を再開できるか」から逆算します。更新回数だけでなく、注文、予約、会員登録、問い合わせなど、データが追加される頻度も考慮してください。
| サイトの状況 | 頻度の目安 | 追加で取るタイミング |
|---|---|---|
| 月に数回更新する小規模ブログ | 週1回程度 | 記事や設定を大きく変更する前 |
| ほぼ毎日更新するメディア | 1日1回程度 | テーマやプラグインの更新前 |
| 注文・予約・会員情報を扱うサイト | より短い間隔を検討 | システム変更やキャンペーン開始前 |
表はあくまで出発点です。毎日バックアップしても、24時間分の注文が失われると困るサイトには不足します。一方、更新が月1回のサイトで数分おきに保存すると、容量や管理の負担が増えます。
定期保存とは別にバックアップするタイミング
- WordPress本体、テーマ、プラグインを更新する前
- 新しいプラグインやテーマを導入する前
- CSS、PHP、
wp-config.php、.htaccessなどを編集する前 - サーバー移転、ドメイン変更、HTTPS化などを行う前
- 大量の記事や画像を一括変更・削除する前
更新作業の安全な順序は「WordPressの更新方法|本体・テーマ・プラグインを安全にアップデートする手順」も参考にしてください。
保存先はサイトと分ける
バックアップをWordPressと同じサーバーだけに置くと、サーバー障害、契約上の問題、不正アクセスによって、サイト本体とバックアップを同時に失う可能性があります。少なくとも1つは、別のクラウドストレージ、管理用パソコン、外付けストレージなど、サイトとは異なる場所に保管します。
3-2-1を小規模サイト向けに考える
バックアップの一般的な考え方に「3-2-1」があります。元データを含めて3つのコピーを、性質の異なる2種類の保存先に置き、そのうち1つを離れた場所に保管する考え方です。
小規模なWordPressサイトなら、「稼働中のサイト」「レンタルサーバーの自動バックアップ」「別サービスまたは管理用端末に保存したバックアップ」の組み合わせから始められます。費用や重要度に合わせて、無理なく継続できる構成にしてください。
Googleドライブを保存先に使う場合は、共有範囲を広げないよう注意します。「Google ドライブの共有設定|権限と安全な使い方」も確認してください。
複数世代を分かりやすく管理する
最新の1世代だけでは、破損や不正な変更を含んだ状態で上書きされると、正常な時点へ戻れません。日次・週次・月次など複数の世代を残し、保存期間を決めて管理します。
ファイル名や保管フォルダには、サイト名、取得日時、データベースかファイルか、更新前などの目的を含めると識別しやすくなります。例はbizitguide-20260911-before-update-files.zipとbizitguide-20260911-before-update-database.sql.gzです。
データベースとファイルを別々に取得した場合は、同じ日時のセットだと分かるように管理します。個人情報や設定情報を含むバックアップは、公開リンクを作らず、必要な管理者だけがアクセスできる場所へ保存してください。
バックアップが成功しているか確認する方法
- 管理画面や通知メールで、直近の処理が成功しているか確認します。
- 保存先を開き、予定した日時のファイルが実際に存在するか確認します。
- ファイルサイズが0バイトや極端に小さくないか確認します。
- データベースとファイルの両方が対象になっているか確認します。
- 圧縮ファイルが開けるか、一覧を表示できるか確認します。
- 可能であれば、本番サイトとは別の検証環境で復元テストを行います。
復元テストは、バックアップの中身と手順を確かめる最も確実な方法です。ただし、本番環境への上書きは現在のデータを失う危険があります。テスト環境の用意が難しい場合は、レンタルサーバーのサポートへ安全な確認方法を相談してください。
小規模サイトの運用例
| タイミング | 行うこと |
|---|---|
| 毎日 | サーバーまたはプラグインの自動バックアップを実行する |
| 週1回 | 成功履歴、保存日時、ファイルサイズ、外部保存先を確認する |
| 更新作業の直前 | データベースとファイルを同じ時点で追加保存する |
| 月1回 | 不要な古い世代、保存容量、共有権限、復元手順を見直す |
| 半年に1回など | 検証環境で復元できるか確認する |
この例は、更新頻度が高くない情報サイトを想定しています。注文や予約を扱うサイトでは、より短い間隔や専門家による設計が必要です。
復元を始める前の確認事項
- 障害が始まった日時と直前に行った作業を記録する
- どの日時のバックアップへ戻すか決める
- データベースとファイルが同じ時点の組み合わせか確認する
- 障害が起きている現在の状態も別途保存する
- 復元によって失われる記事、注文、問い合わせなどを確認する
- 管理画面、サーバー、SFTPなど必要な接続手段を確認する
原因が分からないまま古い状態へ戻すと、同じ不具合が再発したり、必要な新しいデータを失ったりします。操作に不安がある場合は、何度も復元を試さず、レンタルサーバーのサポートやWordPressに詳しい担当者へ相談してください。
一般的な復元の流れ
- 障害の原因と影響範囲を確認し、必要ならサイトをメンテナンス状態にします。
- 現在のファイルとデータベースを保存します。
- 正常だった日時のバックアップを選びます。
- 利用中のサーバーまたはバックアップ機能の手順に従って、ファイルとデータベースを復元します。
- 表示、管理画面、フォーム、画像、主要機能を確認します。
- 問題の原因を取り除き、必要な更新やセキュリティ対策を実施します。
実際の復元手順はサーバーやプラグインによって異なります。データベースを上書きすると、バックアップ取得後に追加された記事や注文などが失われる可能性があります。
復元後に確認する項目
| 確認場所 | 主な確認内容 |
|---|---|
| 公開ページ | トップページ、記事、画像、メニュー、スマートフォン表示 |
| 管理画面 | ログイン、投稿一覧、ユーザー、更新状態 |
| 機能 | お問い合わせフォーム、検索、メール送信、予約や購入機能 |
| 設定 | URL、HTTPS、パーマリンク、アクセス制限 |
| 記録 | 復元日時、使用したバックアップ、原因、実施した対策 |
一部のページだけを見て完了にせず、利用者が行う主要な操作を一通り確認します。キャッシュが残っていると古い表示に見える場合もあるため、利用中のキャッシュ機能も確認してください。
不正アクセス後の復元で注意すること
不正アクセスやマルウェアが疑われる場合、単に古いバックアップへ戻すだけでは不十分です。侵入経路、改ざんされた範囲、管理者アカウント、プラグインやテーマの脆弱性を確認しなければ、復元後に再び被害が起きる可能性があります。
感染前と判断できるバックアップを選び、WordPress本体・テーマ・プラグインを安全な状態に更新し、パスワードや認証情報の変更も検討します。詳しくは「WordPressの初期セキュリティ設定|初心者向け7項目」を確認してください。原因の特定が難しい場合は専門家へ相談しましょう。
バックアップファイル自体も安全に管理する
バックアップには、記事だけでなく、メールアドレス、ユーザー情報、設定値などが含まれる場合があります。公開ディレクトリへ放置したり、「リンクを知っている全員」で共有したりしないでください。
- アクセスできる人を管理者など必要最小限にする
- クラウドストレージの共有範囲を定期的に確認する
- 管理用アカウントで2段階認証を利用する
- 不要になった古いバックアップを安全に削除する
- 暗号化や保管期限について、利用中サービスの機能と社内ルールを確認する
よくある失敗
- データベースだけを保存し、画像やテーマが戻らない
- ファイルだけを保存し、記事や設定が戻らない
- 同じサーバー内だけに保存し、障害時に取り出せない
- 最新版1つだけを残し、正常だった世代がない
- 自動処理のエラーや容量不足に気づかない
- 一度も復元方法を確認していない
- バックアップを公開リンクで共有している
「設定済み」と「復元可能」は同じではありません。保存日時、中身、保存先、世代数、復元手順を定期的に確認することが重要です。
よくある質問
サーバーの自動バックアップだけで十分ですか?
保存対象、保存期間、復元方法が用途に合っていれば有力な手段です。ただし、同じサービスだけに依存しないよう、重要な変更前のバックアップなどを別の場所にも残すと安全性を高められます。
バックアップは何世代残せばよいですか?
サイトの更新頻度、問題に気づくまでの期間、保存容量によって異なります。最初は日次・週次・月次を組み合わせ、少し前の正常な状態を選べるようにします。保存期間を決め、古いデータを放置しないことも大切です。
記事のエクスポートだけで復元できますか?
WordPressのエクスポート機能は記事などの移行に役立ちますが、通常はテーマ、プラグイン、設定ファイル、すべての画像を含む完全なバックアップとは異なります。サイト全体を戻す目的では、データベースとファイルの両方を確認してください。
バックアップを取れば更新は必ず元に戻せますか?
必ず戻せるとは限りません。バックアップの破損、対象漏れ、環境差、復元手順の誤りなどがあるためです。更新前に保存し、更新後の確認に加えて、復元可能性も定期的に確かめます。
復元作業を自分で行うのが不安です
無理に本番環境へ上書きせず、まず契約中のレンタルサーバーが提供する復元機能とサポート範囲を確認してください。EC、予約、会員サイトなど重要なデータを扱う場合は、専門家への依頼も検討します。
まとめ
WordPressを元の状態へ戻すには、原則としてデータベースとファイルの両方が必要です。レンタルサーバーの自動バックアップを土台にしながら、サイトとは別の場所にも保存し、複数世代を残しましょう。
バックアップは作成して終わりではありません。予定どおり保存されているか、中身がそろっているか、どの手順で復元するかを定期的に確認してください。「必要なときに安全に戻せる状態」を維持することが、安定したWordPress運用につながります。
参考:公式情報
- WordPress公式:WordPress Backups
- WordPress公式:Backing Up Your WordPress Files
- WordPress公式:Backing Up Your Database
- WordPress公式:Updating WordPress
最終確認日:2026年9月11日。レンタルサーバーやプラグインの仕様は変更されることがあります。実行前に利用中サービスの公式マニュアルをご確認ください。
