WordPressのバックアップ方法を比較｜プラグイン・手動取得・ホスト機能

WordPressのバックアップは、ファイルを保存しただけ、または記事データを保存しただけでは、サイト全体を元どおりに戻せないことがあります。何をどの時点に戻したいのか、保存先へアクセスできるのは誰か、復元後に何が失われるのかを確認しておきましょう。

この記事では、バックアップで保存する対象、プラグイン・手動取得・ホスト機能の違い、保管先と頻度の決め方を説明します。どれか一つを全サイトの正解とはせず、更新量や担当者、管理画面が使えない場合の手段に合う方法を選びます。保存済みバックアップの点検、復元テスト、障害時にどの日付へ戻すかは、復元判断と確認手順の記事で詳しく扱います。

1. まず確認するのは「いつ、何を戻したいか」

バックアップを選ぶ前に、次の問いへ答えられる範囲で記録してください。

• 記事、画像、添付ファイル、フォーム、注文や予約など、日々変わるデータは何か
• どれくらい前の状態へ戻れれば業務を再開できるか
• バックアップを取得・保管・復元する人は誰か
• 管理画面に入れないときに使えるホストの管理画面や連絡先はあるか
• 既存の保存データを別の場所へダウンロードできるか
• 復元によって消える更新や受付データを、別に取り出せるか

「毎日更新するか」だけでは、必要なバックアップ頻度は決まりません。フォームや注文が頻繁に届くサイトと、年に数回だけ更新する案内サイトでは、失ってよいデータや復旧の優先順位が違います。WordPress公式資料も、ファイルとデータベースの両方を保存し、更新頻度や許容できる損失に応じてバックアップを計画するよう案内しています。WordPress公式バックアップ資料

2. 保存対象：ファイルとデータベース

一般的なWordPressサイトには、別々に保存される二つの大きな要素があります。

通常はファイルとデータベースを近い時点で保存し、一組のバックアップとして扱います。画像を毎日追加しながら、データベースだけを毎日、ファイルは週に一度だけ保存すると、保存時点の違いによって記事と画像がそろわない可能性があります。

また、サイトによっては注文・予約・フォームの記録が外部サービスや別データベースに保存されています。WordPressのファイルとデータベースを戻しても、外部サービスのデータまで戻るとは限りません。受付機能や連携先、サーバー上のメールも保存対象か別に確認します。

3. 取得方法を比較する

プラグイン、ホストの自動バックアップ、手動取得にはそれぞれ条件があります。ひとつの方式がすべてのサイトで最も安全とは限りません。

プラグインを使う場合

プラグインは、スケジュール設定や外部ストレージ連携を管理画面から操作できる場合があります。導入前に、その時点の機能・利用条件・必要な権限を公式ページと管理画面で確かめます。特定の製品名や無料プランの機能は更新されるため、記事上の説明だけで契約条件を判断しないでください。

設定したら、ファイルとデータベースのどちらを取得するか、取得先、古い世代の削除条件、失敗通知の担当を記録します。保存先の認証切れ、容量不足、スケジュール実行の停止が起きても気付けるよう、通知メールの宛先と確認方法を用意します。

プラグインから復元できるのは、サイトの管理画面に入れて、対象のバックアップファイルを読み込める場合に限られることがあります。管理画面が停止したときの復元経路をプラグインだけに頼らず、ホストの手順や保守担当への連絡先も確認してください。

ホストの自動バックアップを使う場合

ホスト側のバックアップは、WordPressの管理画面へ入れない場合にも利用できる可能性があります。ただし、保存日数や対象、取得時刻、復元が直接本番へ反映されるか、いったん別ファイルとして取得するかはサービスごとに異なります。契約中のサーバーと管理画面の最新案内を確認してください。

たとえば、2026年10月4日に確認したXServerビジネスの案内では、復元可能期間は過去14日分とされています。一方で、復元対象のディレクトリ・ファイルはバックアップ内容へ上書きされ、そのバックアップに存在しない後日のファイルは削除されると注意されています。XServerビジネスの復元説明

2026年10月4日に確認したConoHa WINGの案内では、過去14日間の自動バックアップを操作画面から復元する説明のほか、Web・メールの復元ファイルは24時間後に削除されること、再度復元すると前の復元ファイルが削除されること、一定回数を超えると一時的に制限される場合があることが記載されています。ConoHa WINGの復元案内

これは確認日時点の各社案内の例で、他のホスト、契約、サーバー世代にそのまま当てはまるとは限りません。保存期間が14日と書かれていても、その間のファイルをすべて安全に戻せる、復元後のサイトが正常に動く、メールやDBも同じ時点へ戻る、という保証にはなりません。

ホストへ問い合わせる前に、契約プラン/サーバー世代、Web・DB・メールそれぞれの保存期間、復元が本番を直接書き換えるか、対象日以降のデータが上書き/削除されるか、保管期間と操作制限、追加費用、誤操作時に戻す方法を確認します。自社の契約で使える機能を管理画面やサポートへ照会してください。

手動で取得する場合

手動取得は、FTP/SFTPやサーバーのファイル管理画面でファイルを保存し、phpMyAdmin等でデータベースをエクスポートする方法です。作業する人が保存対象を理解し、ファイルとDBが同じサイトのものか識別できる場合に検討します。

WordPress本体の全ファイルを保存せず、一部だけをコピーすると、テーマ、プラグイン、設定、アップロード画像などが抜けることがあります。データベースも、正しいDBと必要なテーブルが含まれているか確認します。接続情報を含む設定ファイルや顧客情報のエクスポートは機密データとして扱い、不要な共有や公開場所への保管を避けます。

手作業ができる人が一度取得するだけでは、次回の保存が保証されません。定期取得の担当、保管先、失敗に気付く手順も決めてください。

4. 方式を選ぶときの3つの質問

管理画面が使えない場合にも取り出せるか

WordPressの管理画面へ入れない障害では、プラグインの復元操作を開始できないことがあります。ホストの管理画面へ入る契約者、サーバーへアクセスする担当者、プラグインのクラウド保存先を管理する担当者を整理し、異なるログイン先のうち誰が何を復旧できるかを確認します。権限が一人にしかない場合は、その人が不在のときの連絡方法も用意します。

バックアップがサイトと同時に失われる場所にないか

ホスト内のバックアップは操作が簡単でも、同じアカウントへアクセスできなくなるケースに備えるため、別の保管先を持つ必要があるか検討します。外部保管を使うなら、誰のアカウントへ保存するか、退職や契約終了時に引き継げるか、保存ファイルへ誰がアクセスできるかを決めます。保存先の共有設定を公開にせず、認証やアクセス権を定期的に見直します。

取得成功の通知を誰が確認するか

自動処理でも、容量不足、認証切れ、スケジュール停止などで保存に失敗する可能性があります。成功/失敗通知の宛先が現在の担当者か、通知を見逃したときに管理画面から実行履歴を確認できるかを試します。未確認の状態が続いたら、設定を追加するより先に、現在どの方法が動いているか調べます。

サイトの使い方に合わせて組み合わせる

これはそのまま設定を選ぶ表ではありません。環境と契約の事実を整理し、ホストや実装担当者へ質問するための入口です。

5. 保存先と世代を決める

バックアップは、サイト本体と同じサーバーに一つ置くだけでは、そのサーバーやアカウントへ入れなくなったときに使えない可能性があります。契約しているホストとは別の保管先、または別の管理権限・媒体を組み合わせ、誰が取得できるか、認証情報をどう保護するかを決めます。

保存世代の数は、障害や改ざんに気付くまでの期間、更新量、保管容量、業務上許容できる損失で決めます。最新一つだけでは、すでに不具合や不正変更を含む状態へ気付かず戻す恐れがあります。古い世代をいつ削除するかも含め、保存方針を書き残してください。

サーバーや保存先の契約を変えるときは、旧サービスにあるバックアップがいつまで取得可能か、解約後に復元権限が残るかを確認します。移行前に必要なデータを新しい保管先へ移し、担当者がアクセスできることを確かめてから、旧サービスの契約や認証を整理してください。

6. 運用記録を残す

次の項目を保守記録や社内の引継ぎ資料へまとめます。パスワード、APIキー、復旧コードや顧客情報そのものは記録表に書かず、アクセス管理された保管場所を別に決めます。

見直し時期はサイト構成、担当者、契約、受付データ、保存先が変わったときにも設定します。構成変更や移行の前には、過去の世代に加えて作業直前の状態を別に保存し、保存先へアクセスできることを確認します。

頻度は「失ってよい期間」から決める

バックアップの間隔を決めるときは、サイトの更新内容と業務を確認します。

• 受付や注文が日々増えるなら、最後に受付データを失わずに済む時点を担当者と相談する
• 画像、添付、テーマ、プラグインを更新するなら、その変更後のファイルをどう保存するか決める
• 重要な更新・移行・設定変更の前は、作業直前の状態を別に保存する
• サイトがほとんど更新されない場合も、ホストの契約やシステム更新時に復元できるか試す

「データベースは毎日、ファイルは週一回」といった固定表だけでは、追加画像やコードを含むサイトに必要な復旧時点を決められません。記事、画像、設定、注文、フォームのどれをどこまで戻したいかに合わせます。

7. 取得後に、使えるバックアップかを確認する

保存完了の通知だけでは、必要なファイルとデータベースがそろい、実際に読み出せることまで分かりません。まず取得日時、対象、保存先、失敗時の通知を記録し、別環境で復元を試せるか確認します。具体的な復元テスト、受付データへの影響、障害時の切戻しは復元判断と確認手順の記事を参照してください。

ホストの復元画面に対象日が表示されても、復元先へ何が上書き・削除されるかを確認せず、本番で実行しないでください。XServerビジネスはバックアップ取得後の対象ファイルが復元処理で置き換わる/削除される場合を説明し、ConoHa WINGは取得した復元データの保持や再取得に条件を設けています。自社の管理画面の最新説明と対象契約を優先します。

8. 自分で確認する範囲と、依頼時に伝える情報

管理画面に表示される最終取得日、バックアップ通知メール、保存先、ホストの契約画面は自分で確認できます。パスワードやAPIキー、復旧コードをフォームやメールへ記載せず、契約者用の窓口から問い合わせてください。

バックアップの設定や復元を実務担当へ任せたい場合は、次の情報があると、対象と影響を整理しやすくなります。

• サイトURLと契約中のホスティング会社
• サイト上で受け付けている問い合わせ、予約、注文などの機能
• 現在確認できるバックアップ日時、対象、保管先
• 最後に正常だったと確認できた時点と、現在起きている症状
• どの作業を任せたいか、社内や別の制作会社で担当する範囲

自力で復元できる場合は、テスト結果と不足分だけを引き継ぎます。変更や復旧の影響が大きい場合は、ホスト・制作会社・社内管理者の責任範囲を確かめ、作業内容、復元先、確認項目を合意します。

Acquaへ相談する場合

バックアップの取得や復元、WordPressの更新・保守を実務として頼みたい場合は、サイトURL、困りごと、守りたい機能、希望する作業を共有してください。Acquaが引き受ける範囲、利用する環境、確認内容、費用、期間は、対象サイトと依頼内容を確認してから合意します。すべてのサーバーで復元できることや、緊急駆け付けを一律に約束する案内ではありません。

• 企業向けWeb制作・運用支援では、サイト制作・更新・保守を相談できます。
• 制作会社向けパートナー案内では、WordPress実装などの工程支援を相談できます。
• 保守・運用サービスでは、現在案内されている保守業務を確認できます。
• お問い合わせでは、相談の目的と希望する作業を伝えられます。

バックアップ方法を決めた後の状態

どの方法で何を保存するか、取得失敗を誰が見つけるか、ファイルとデータベースをどの保管先から取り出すかが記録されている。復元手順や障害時の判断まで確認したい場合は、バックアップからの復元ガイドへ進んでください。保存完了表示ではなく、担当者が方法と残る制約を説明できることを確認します。

参考にした資料

• WordPress公式：Backups
• XServerビジネス公式：自動バックアップからのデータ復元
• ConoHa WING公式：自動バックアップからリストアする
• Acqua：企業向けWeb制作・運用支援
• Acqua：制作会社向けパートナー案内
• Acqua：保守・運用サービス
• Acqua：お問い合わせ