この記事の対象: WordPressサイトを制作・納品しているWeb制作者
読了時間: 約12分
サイトが壊れたとき、何分で元に戻せるか。バックアップ体制の良し悪しは、この一点で決まります。
WordPressのバックアップ手段は大きく3つ。プラグイン、サーバーの標準機能、外部サービス。どれを使っても「バックアップを取る」こと自体はできます。問題は、いざ復旧が必要になったとき、手元のデータで本当に戻せるかどうかです。
この記事では、3つの方式を「復旧の速さ」「管理の手間」「サーバー障害への耐性」で整理します。案件の規模や体制によって最適解は変わるので、条件ごとにどれを選ぶかを明示していきます。
3つのバックアップ方式と、それぞれの限界
プラグイン方式
UpdraftPlus、BackWPupといったバックアッププラグインを使う方法です。WordPress管理画面から設定でき、導入のハードルが低いのが特徴です。
向いている場面
- 案件数が少なく、サイトごとに個別管理できる
- クライアント自身がバックアップの状況を確認したい
- Google Drive、Dropbox、Amazon S3など外部ストレージへの自動保存を設定できる
注意すべき制約
- プラグイン自体がWordPressの一部なので、WordPress本体が壊れるとバックアップ機能も動かなくなる
- 無料版ではスケジュール設定や保存先に制限があるものが多い
- サイトの容量が大きくなるとバックアップ処理がサーバーに負荷をかけ、タイムアウトすることがある
- 復旧時はプラグインの復元機能を使うため、管理画面にログインできる状態が前提
UpdraftPlusの有料版（UpdraftPlus Premium）は復元機能が充実しており、差分バックアップにも対応しています。一方のBackWPupはバックアップの取得に特化しており、復元は手動でファイルとデータベースを戻す作業になります。この違いは復旧にかかる時間に直結します。
料金はプラグインごとに異なり改定もあるため、各プラグインの公式サイトで最新情報を確認してください。
サーバーの標準バックアップ機能
エックスサーバー、さくらのレンタルサーバー、ConoHa WINGなど、主要なレンタルサーバーには自動バックアップ機能が標準で付いています。
向いている場面
- 追加コストをかけずに最低限のバックアップを確保したい
- プラグインを増やしたくない
- 保守契約がなく、「何もしないよりはマシ」な状態を作りたい
注意すべき制約
- バックアップの保持期間はサーバー会社ごとに異なる（7日〜14日程度が一般的）
- 復元の単位がサーバー会社によって違う。ファイル単位で戻せるところもあれば、アカウント全体のロールバックしかできないところもある
- バックアップデータはサーバー会社のインフラ内に保存されるため、データセンター障害時には一緒に失われるリスクがある
- 復元にはサーバーの管理画面からの操作が必要で、WordPressの知識だけでは完結しないことがある
サーバーのバックアップは「最後の砦」として機能しますが、能動的に管理できるバックアップとは性質が異なります。保持期間が短いため、改ざんや不具合に気づくのが遅れると、正常なバックアップがすでに上書きされている可能性もあります。
外部サービス方式
ManageWP、BlogVault、MainWPなど、WordPress専用の外部管理サービスを使う方法です。
向いている場面
- 複数のWordPressサイトを一括で管理している
- クライアントのサーバーに直接触れない状況でもバックアップの確認・復旧をしたい
- サーバー障害時にも独立してデータを保持したい
注意すべき制約
- 月額費用がサイト単位で発生する（サービスにより異なるため公式サイトで最新料金を確認）
- サービス側の障害やサービス終了リスクがある
- サイトにエージェントプラグインをインストールする必要があり、クライアントへの説明が必要になる
- サービスを乗り換える場合、バックアップ履歴の移行はできないことが多い
ManageWPはGoDaddy傘下のサービスで、無料プランでも基本的なバックアップ機能を利用できます。有料プランではバックアップの頻度を上げられるほか、ワンクリック復元にも対応しています（プランの詳細は公式サイトで確認してください）。BlogVaultはバックアップと復元に特化しており、ステージング環境の作成にも対応しています。MainWPはセルフホスト型で、自分のサーバーにダッシュボードを設置する方式です。サブスクリプション費用を抑えられる反面、管理用サーバーの維持が必要になります。
「何分で戻せるか」で選ぶ比較表
方式選びで最も重要なのは、壊れたときに何分で復旧できるかという観点です。バックアップを「取れている」ことと「すぐ戻せる」ことはまったく別の話です。
| 比較項目 | プラグイン | サーバー機能 | 外部サービス |
|---|---|---|---|
| 復旧の目安 | 10〜30分（管理画面から） | 30分〜数時間（サーバー会社による） | 5〜15分（ワンクリック復元の場合） |
| サーバー障害時 | 外部保存設定済みなら安全 | 一緒に失われるリスクあり | サービス側に保持されている |
| 複数サイト一括管理 | 不可（サイトごとに個別） | 不可 | 対応 |
| 導入コスト | 無料〜（有料版は年額課金） | 追加費用なし | 月額課金（サイト単位） |
| 管理画面に入れないとき | 手動復旧が必要 | サーバー管理画面から操作 | サービスのダッシュボードから操作 |
| 乗り換えやすさ | プラグインを入れ替えるだけ | サーバー移転時に自動切替 | 履歴は移行不可 |
注目してほしいのは「管理画面に入れないとき」の行です。WordPressが真っ白になった、ログイン画面が出ない——そういう場面でプラグイン方式は弱い。復元機能もWordPress上で動いているためです。
外部保存
- サーバー障害でもデータは残る
- 別環境への復旧も可能
- プラグイン＋外部連携 or 外部サービスで実現
サーバー内保存
- サーバー障害で一緒に消えるリスク
- 同一筐体のバックアップは保険として弱い
- サーバー標準機能・プラグイン初期設定が該当
バックアップの保存場所がサーバーの中か外かで、障害時の安全性は決定的に変わります。プラグインを使う場合でも、保存先を外部ストレージに設定していなければ、サーバー機能と同じリスクを抱えることになります。
案件タイプ別：どの方式を選ぶか
「どれも一長一短です」では選べません。案件の条件ごとに、どの方式を軸にするかを整理します。
小規模サイト（5〜10ページ）・更新頻度が低い
サーバーの標準機能 ＋ プラグイン（外部保存設定）の組み合わせを推奨します。
更新が少ないサイトは壊れる頻度も低く、外部サービスの月額費用をかけるほどではありません。プラグインでGoogle DriveやDropboxに定期バックアップを取っておけば、万が一のときに自力で復旧できます。
中〜大規模サイト・定期的に更新がある
外部サービスを主軸にするのが現実的です。
更新頻度が高いサイトでは、バックアップの「どの時点に戻すか」の選択肢が重要になります。外部サービスはバックアップの取得頻度を細かく設定でき、ダッシュボードから複数サイトの状態を一覧で確認できます。
複数サイトを一括管理している制作会社・フリーランス
外部サービス一択です。
5サイトを超えたあたりから、プラグインの個別管理は破綻しやすくなります。「あのサイトのバックアップ、ちゃんと動いてるかな」と不安になる時点で、管理体制として機能していません。ダッシュボードで全サイトの状態を一画面で確認できる価値は、月額費用を十分に正当化します。
保守契約がない案件
サーバーの標準機能に頼るしかないのが現実です。ただし、それだけでは不十分なので、納品時にやっておくべきことがあります。次の章で詳しく解説します。
保守契約がない案件をどう扱うか
制作者にとって最も悩ましいのが、保守契約を結んでいない案件のバックアップ体制です。納品して終わりの案件でも、半年後に「サイトが壊れた」と連絡が来ることはあります。
納品時に最低限やっておくこと
- サーバーの自動バックアップが有効になっているか確認する。レンタルサーバーによっては初期設定でオフになっていることがあります
- WordPressの自動更新設定を意図的に決める。マイナーアップデートのみ自動にするか、すべて手動にするか。放置されることを前提に考えます
- 納品時のフルバックアップを外部に1つ取っておく。All-in-One WP Migrationなどで丸ごとエクスポートし、クライアントに渡します。「これが最後の正常な状態です」と伝えておくのが重要です
「壊れたら有償対応」のラインを明確にする
保守契約がないということは、壊れたときの対応義務もないということです。ただし、何も伝えていないと「作った会社が直してくれるはず」というトラブルになりやすい。
納品時に書面で以下を伝えておくと、あとのトラブルを防げます。
- バックアップの管理責任はクライアント側にあること
- WordPressやプラグインのアップデートによる不具合は保守契約の範囲であること
- 復旧対応が必要な場合は有償になること
乗り換えのコストと、あとから効いてくる制約
バックアップ体制は一度構築すると変えにくいものです。選ぶ前に知っておきたい制約をまとめます。
プラグインの乗り換え
比較的簡単です。新しいプラグインをインストールして設定し直せば移行できます。ただし、旧プラグインで取得したバックアップの形式が独自の場合、新プラグインでは復元できません。乗り換え前に、旧プラグインの最新バックアップを別途保管しておいてください。
外部サービスの乗り換え
ここが厄介です。外部サービスに蓄積されたバックアップ履歴は、基本的にそのサービス内でしか使えません。サービスを解約した時点で履歴は消えます。乗り換え先ではゼロからバックアップの蓄積が始まります。
乗り換えリスクを減らすには、外部サービスを使いつつも四半期に一度はプラグインかWP-CLIで独立したフルバックアップを取っておくことです。サービスへの依存度を下げられます。
サーバーや制作会社ごと変える場合は、バックアップ以外にも確認すべきことが多くあります。以下の記事で引き継ぎ時の確認事項を整理しているので、あわせて読んでみてください。
サーバー移転時のバックアップ体制
サーバーを移転すると、サーバーの標準バックアップは当然リセットされます。移転直後はバックアップの蓄積がない状態なので、移転前に手動でフルバックアップを取得しておくことが必須です。
バックアップが「動き続けている」かを確認する
仕組みを作って安心してしまうのが一番危険です。バックアップは動き続けてこそ意味があります。
月に一度は確認すべきこと
- 最終バックアップ日時の確認：プラグインのログ、外部サービスのダッシュボード、サーバーの管理画面で直近のバックアップ日時を見る
- ストレージ容量の確認：サイトの成長に伴いバックアップの容量も増えます。上限に達してバックアップが止まっていた、という事故は珍しくありません
年に一度はやるべきこと
- テスト環境での復元テスト：バックアップファイルが壊れていた、形式が古くて復元できなかった、という事態は実際に起きます。年に一度は本当に復元できるかを確かめておくと安心です
サイト公開後の運用全般の考え方はこちらの記事でも整理しています。バックアップに限らず、更新が止まりやすい構造的な原因については運用が続かない原因も参考になります。
よくある質問
無料のバックアッププラグインだけで十分ですか？
小規模で更新頻度の低いサイトなら、無料プラグインに外部ストレージ保存を設定すれば実用上は問題ありません。ただし復元機能が制限されているプラグインでは復旧に時間がかかります。復旧の速さを重視するなら有料版か外部サービスの検討をおすすめします。
サーバーの自動バックアップがあればプラグインは不要ですか？
不要とは言い切れません。サーバーのバックアップはサーバー内に保存されるため、サーバー障害時には一緒に失われるリスクがあります。保持期間も短いため、不具合の発見が遅れると正常なバックアップが残っていない可能性もあります。サーバー機能とプラグインの併用が安全です。
バックアップの頻度はどのくらいが適切ですか？
更新頻度しだいです。毎日記事を更新するサイトなら日次、月に数回の更新なら週次で十分です。ECサイトのように注文データが常に動いている場合はリアルタイムに近いバックアップが求められます。「最悪、何日分のデータなら失っても再現できるか」を基準に決めてください。
保守契約の必要性をクライアントに理解してもらうには？
「バックアップが必要です」という抽象的な説明では伝わりません。「WordPressの更新で表示が崩れた場合、保守契約がなければ復旧は都度の有償対応になります。月額の保守費用と比べてどちらが合理的か」という具体的なコスト比較で説明するほうが伝わります。
WP-CLIでのバックアップはどういう場面で使いますか？
サーバーにSSH接続できる環境で、cronと組み合わせて自動バックアップの仕組みを自作したいときに使います。プラグインの動作が不安定になるほど大容量のサイトや、管理画面にアクセスできない状態での復旧にも有効です。ただし設定・運用にサーバーの知識が必要なので、全案件に適用するものではありません。
まとめ
バックアップ方式の選択は「どれが優れているか」ではなく「自分の案件でどう使うか」で決まります。
- 案件数が少なく個別管理できるなら、プラグイン ＋ 外部ストレージ保存
- 複数サイトを管理しているなら、外部サービスで一元管理
- 保守契約がない案件は、サーバーの標準機能を有効にし、納品時にフルバックアップを渡しておく
どの方式を選んでも、「バックアップが本当に動いているか」を定期的に確認する運用まで含めて、はじめてバックアップ体制と呼べます。仕組みを作って終わりではなく、復元テストまでを習慣にしてください。
