WordPress・ホームページ保守・データ管理
「保存している」から、
「必要な状態へ戻せる」備えへ。
バックアップの対象、取得方法、頻度、復元前の確認事項を、企業サイトの担当者向けに整理します。
WordPressを更新したら表示が崩れた。記事や画像を誤って削除した。管理画面に入れなくなった。こうしたときに備えるのがバックアップです。
ただし、バックアップという名前のファイルがあるだけでは、必要な状態へ戻せるとは限りません。保存対象が不足していたり、古いデータしか残っていなかったりすると、復旧後に情報が欠けることがあります。
この記事では、WordPressのバックアップ方法と保存すべき対象、頻度の決め方、復元前後の確認事項を解説します。
先に結論:保存対象・保存先・戻せる日時・復元担当を確認します
一般的なWordPressサイトでは、ファイルとデータベースの両方を保存します。自動取得の設定に加え、いつの状態へ戻せるか、障害時に誰が復元するかまで決めておきましょう。
WordPressでバックアップする対象は?
WordPressの情報は、大きく「ファイル」と「データベース」に分かれています。どちらか一方だけを保存しても、サイト全体を同じ状態へ戻せない場合があります。
ファイル
WordPress本体、テーマ、プラグイン、アップロードした画像やPDF、設定ファイルなどです。サイトの表示や機能を構成します。
データベース
記事本文、固定ページ、ユーザー情報、各種設定などを保存します。プラグインが管理する情報も含まれる場合があります。
保存対象と確認するポイント
| 対象 |
主な内容 |
確認したいこと |
| 記事・設定 |
投稿、固定ページ、ユーザー、各種設定 |
対象のデータベースが保存されているか |
| 画像・資料 |
アップロードした写真、PDFなど |
メディアの実ファイルが含まれるか |
| テーマ・プラグイン |
デザイン、機能、独自の変更 |
必要なファイルと設定を戻せるか |
| 環境の設定 |
WordPressの接続設定や関連する構成 |
どこまでバックアップ対象に含まれるか |
| 外部サービスの情報 |
外部フォーム、外部ストレージなどのデータ |
WordPressとは別に保存・復旧が必要か |
例えば、記事本文が残っていても、画像ファイルがなければ画像を表示できません。また、問い合わせ情報を外部サービスに保存している場合、その情報がWordPressのバックアップに含まれるとは限りません。
標準の「エクスポート」は、サイト全体のバックアップとは異なる
WordPressの「ツール」にあるエクスポート機能は、投稿や固定ページなどを移すためのデータを書き出す機能です。テーマ、プラグイン、画像の実ファイルなど、サイトを構成するすべてを一式で保存するものではありません。
記事を書き出せたことと、サイト全体を復元できることは分けて確認します。
記事の移行や補助的な保存にはエクスポートを使えますが、障害からの復旧に備える場合は、ファイルとデータベースを含むバックアップ方法を確認してください。
WordPressをバックアップする3つの方法
主な方法は、サーバーの機能、プラグイン、手動取得です。現在使える機能と、障害時に操作できる人を踏まえて選びます。
取得方法ごとの特徴
| 方法 |
特徴 |
導入前に確認すること |
| サーバーのバックアップ機能 |
契約サービスの管理画面などから取得・復元する |
保存対象、取得間隔、保存期間、復元費用 |
| バックアップ用プラグイン |
WordPress側で取得や保存先を設定する |
対応環境、保存対象、外部保存、復元手順 |
| 手動で取得 |
ファイルとデータベースをそれぞれ保存する |
必要な権限、取得範囲、整合性、担当者の経験 |
サーバーのバックアップ機能を使う
最初に、契約中のサーバーで利用できるバックアップ機能を確認しましょう。「自動バックアップあり」と書かれていても、保存期間や復元できる単位はサービスによって異なります。
自社で復元できるのか、サーバー会社へ依頼するのか、データを取り出す際に費用がかかるのかまで確認しておくと、障害時の判断がしやすくなります。
バックアップ用プラグインを使う
WordPress側で取得日時や保存先を管理したい場合は、バックアップ用プラグインが候補になります。
選ぶ際は、現在のWordPressやサーバーに対応しているか、必要なデータを保存できるか、復元方法を理解できるかを確認します。すでに別の方法で取得している場合は、役割が重なっていないかも見直してください。
ファイルとデータベースを手動で取得する
手動では、サーバー上のファイルを取得し、データベースも別途書き出します。対象の取り違えや保存漏れを防ぐため、構成を把握した担当者が行う方法です。
記事の投稿権限だけでは、必要なデータへアクセスできない場合があります。外部の制作会社が管理している場合は、取得できる範囲と依頼方法を確認しましょう。
バックアップ取得から確認までの基本手順
ボタンや画面の名称は利用するサービスによって異なりますが、確認する順序は共通しています。
-
対象のサイトと保存範囲を確認する
本番サイトか検証サイトかを区別し、ファイルとデータベースの対象を確認します。
-
保存先と必要な容量を確認する
保存先へアクセスできるか、容量不足になっていないかを確認します。
-
バックアップを実行する
利用するサービスの手順に従って取得します。複数のデータを保存する場合は、対応する一組として管理します。
-
完了結果と保存物を確認する
実行履歴だけでなく、保存日時、対象、ファイルの存在などを確認します。エラーや除外されたデータも見直します。
-
取得記録と復元方法を残す
いつ、どの方法で、何を保存したかと、復元を依頼・実行する方法を記録します。
別々の時点のデータを、無条件に組み合わせないようにします。
ファイルとデータベースの保存時点が大きくずれていると、記事が参照する画像がないなどの不整合が起こる場合があります。更新が多いサイトは、整合性を保って取得できる方法を確認してください。
「完了」と表示されても、復元できるかは別に確かめる
保存ファイルが存在するだけでは、復元が成功することまでは分かりません。可能であれば本番とは別の検証環境で復元を試し、必要な情報と機能が戻るか確認します。
検証環境では、検索への公開、メール送信、決済や外部サービスとの連携が本番と同じように動かないように、環境に応じた制御も必要です。
バックアップ頻度と保存期間はどう決める?
頻度は「どれくらい更新するか」に加えて、「どこまでのデータ消失なら業務上対応できるか」で決めます。
頻度を考える例
毎日記事を更新するサイトで、バックアップが1週間前のものだけなら、その後に追加した記事を戻せない可能性があります。注文や予約を受け付けるサイトでは、1日前へ戻すことでも影響が大きくなります。
記事、注文、予約など、失いたくない情報ごとに許容できる範囲を考え、取得間隔と復旧方法を決めましょう。
サイトの使い方に合わせた検討例
| サイトの状況 |
頻度を考える視点 |
追加で確認すること |
| 更新が少ない会社案内サイト |
定期取得に加え、変更前後の状態を残す |
記事以外に増えるデータがないか |
| 記事を頻繁に更新するサイト |
日々の更新をどこまで失わず戻したいか |
画像と記事が対応して保存されるか |
| 注文・予約を受け付けるサイト |
短時間でも失えない記録があるか |
復元後の注文・予約の突き合わせ方法 |
| 大きな更新・移行の前 |
作業直前の状態を別途確保する |
元に戻す手順と判断する担当者 |
※表は頻度を決めるための検討例です。すべてのサイトに共通する取得間隔を示すものではありません。
最新の一つだけでなく、過去の状態も残す
不具合にすぐ気づくとは限りません。異常が起きた後のデータで毎回上書きされると、正常だった時点へ戻せなくなる場合があります。
複数の時点のバックアップを残し、保存期間と自動削除の条件を確認してください。更新前の取得分を、定期バックアップとは別に残す運用も考えられます。
サイトと同じ場所だけに保存しない
同じサーバーにしか保存していない場合、そのサーバーへアクセスできなくなるとバックアップも取り出せない可能性があります。
独立した保存先を用意する場合は、担当者が必要なときにアクセスできるかも確認します。バックアップには利用者情報や設定情報が含まれることがあるため、公開リンクで共有せず、閲覧できる人を管理しましょう。
WordPressを復元する前に確認すること
復元は、保存されている過去の状態へ戻す操作です。対象と方法によっては、バックアップ取得後に追加された情報が上書きされます。
1.どの時点へ戻すか
不具合が起きた日時と、最後に正常だった日時を整理します。最新のバックアップが正常とは限らないため、更新履歴や発生状況と照合してください。
2.復元で失われる可能性がある情報
バックアップ取得後に追加された記事、問い合わせ、注文、予約などを確認します。保存場所はサイトの構成によって違うため、どの情報が影響を受けるかを特定しましょう。
必要に応じて現在の状態も別途保全し、復元後に差分を戻す方法を検討します。注文情報だけを安易に上書きするなど、業務データの不整合を招く操作は避けてください。
3.サイト全体を戻す必要があるか
記事一つの編集ミスなら、リビジョンなどで対応できる場合があります。サイト全体の復元が必要か、対象を絞った修正で対応できるかを確認します。
4.再発の原因が残っていないか
問題を起こす更新や、不正アクセスの原因が残っていれば、復元後も同じ問題が起こる可能性があります。元に戻す作業と、原因を取り除く作業を分けて考えましょう。
本番サイトで、復元を試すためだけの操作をしないようにします。
利用中のサイトへ影響する場合は、対象データ、作業時間、公開を止める必要性、問題が起きた場合の対応を整理してから進めます。
復元後は表示だけでなく、主要機能まで確認する
トップページが表示されても、記事、画像、フォームなどが正しく動くとは限りません。業務に必要な画面と操作を確認しましょう。
- トップページと主要な固定ページが表示される
- 必要な記事・画像・資料が戻っている
- スマートフォンでも表示を確認した
- 管理画面に必要な担当者がログインできる
- 問い合わせフォームの送信・受信を確認した
- 注文・予約などの主要機能を必要な範囲で確認した
- 検索公開設定や正規URLなどを確認した
- バックアップ後に増えた情報との整合性を確認した
- 復元した日時・対象・確認結果を記録した
保守を外注する場合は、復元対応の範囲まで確認する
「バックアップ取得」と「障害時の復元」は、契約上別の作業になっている場合があります。取得頻度だけでなく、復元を依頼できる時間帯、追加費用、復旧後の確認範囲も確認してください。
WordPressのバックアップについてよくある質問
サーバーに自動バックアップがあれば十分ですか?
保存対象、取得間隔、保存期間、復元方法が自社の必要条件を満たしているかで判断します。自動バックアップがあることだけでなく、必要な日時のデータを取り出せるかを確認してください。
バックアップ用プラグインは必須ですか?
必須とは限りません。サーバー側の機能などで必要な取得と復元に対応できる場合もあります。現在の方法で不足している点を確認してから、追加の仕組みを検討しましょう。
記事のリビジョンがあればバックアップは不要ですか?
リビジョンは記事などの編集履歴を戻すための機能で、サイト全体の復旧を代替するものではありません。画像ファイルやテーマ、プラグインなども含めて備える必要があります。
自動バックアップを設定した後も確認が必要ですか?
必要です。保存先の容量不足や接続の問題などで取得できなくなる場合があります。最終成功日時とエラーの有無を確認し、復元確認も定期的に行いましょう。
バックアップは、復元まで含めて運用を決めましょう
WordPressのバックアップでは、ファイルとデータベースの保存対象を確認し、更新量と業務への影響に合わせて頻度を決めます。
保存先や過去のデータの保持に加え、復元する担当者、手順、復元後の確認項目まで共有しておくことが大切です。まずは現在のバックアップについて、「何が、いつ、どこに保存され、誰が戻せるか」を確認してみましょう。
自社サイトのバックアップ、内容まで把握できていますか?
3Bros.worksでは、ホームページの保守・運用についてご相談を承っています。現在の管理体制やお困りごとを伺い、必要な確認事項と対応範囲を一緒に整理します。
ホームページの保守について相談する
参考情報・WordPress公式ドキュメント
公式情報確認日:2026年9月11日。取得・復元の手順や保存範囲は、利用するサーバー、プラグイン、サイト構成によって異なります。本文の運用例は、自社の必要条件を整理するための参考です。