WordPressのバックアップは復元できる？保存対象・頻度・復元確認の決め方

WordPressのバックアップを設定したあと、「必要なデータが保存されているか」「障害時に取り出せるか」「実際にサイトを戻せるか」まで確認できていますか。

バックアップの成功通知が届いていても、復元先がない、保存先へログインできない、サイトの一部しか保存されていないといった理由で、必要な場面に使えないことがあります。大切なのは、プラグインを入れることだけではありません。何を、どの時点まで戻したいかを決め、その手順を安全な場所で試しておくことです。

この記事では、すでに使っているホスティングサービスやWordPressの機能も含めて、バックアップの状態を確認する順番を説明します。特定の製品を一律に推奨したり、全サイト共通の保存頻度を決めたりはしません。サイトの更新内容、業務への影響、契約中の保存機能に合わせて判断してください。

この記事は、保存済みバックアップの確認と、安全に復元できるかの判断に絞ります。取得製品を選ぶときも、既存の保存対象・権限・復元方法を先に確認し、製品の公式資料と自分の環境を照らしてください。複製時のデータと送信先の扱いは、テスト環境へ複製する前の確認表も合わせて確認してください。

先に確認したい5つのこと

保存対象と取り出せる人を確かめる

WordPressの一般的な構成では、データベースとサイトファイルは別に保存されます。データベースには投稿や設定などが含まれ、画像・テーマ・プラグインなどのファイルは別の場所にあります。通常のサイトを復元するには、両方の状態が対応したバックアップとしてそろっているか確認します。WordPress公式のバックアップガイドも、ファイルとデータベースの両方を扱っています。

決済、予約、会員管理などを外部サービスで行っている場合、WordPressのバックアップだけではそのサービスのデータまで戻せないことがあります。対象のサービスとデータの保存先を別に確認してください。

どこまで戻せれば業務を再開できるか決める

まず「何時間・何日分の更新なら失っても対応できるか」と「サイトをどのくらい停止できるか」を、サイトの担当者と業務の担当者で確認します。

たとえば、直近のバックアップが午前9時で障害が午後3時に起きた場合、午前9時以降に登録された内容は、そのバックアップから戻すと反映されない可能性があります。記事の修正なら再入力できても、問い合わせ、注文、予約、顧客情報の変更は同じように扱えないことがあります。復元前に、失われる可能性がある情報を誰が確認するか決めておきましょう。

保存の頻度や保持する世代数に、すべてのサイトへそのまま当てはまる数字はありません。更新の量と重要度、復元にかかる見込み時間、保存先の容量、ホスティング契約の条件を見ながら決めます。更新前に個別のバックアップを取る運用が必要かも、更新作業の内容と合わせて検討します。

業務上の優先順位は、管理者だけで決めないようにします。広報担当にとっては記事を再入力できても、営業担当が対応中の問い合わせを失うと、返信の重複や漏れが起こるかもしれません。予約や注文では、外部サービス側に残った記録とWordPress側の状態が食い違うことも考えられます。保存頻度の設定より先に、何を照合して再開するかを業務担当者と決めます。

次は説明用の記入例です。実在の顧客の保存状況や復旧実績ではありません。

「問い合わせ記録」が必ずデータベースへ保存されるとは限りません。利用中のフォームの保存機能、送信経路、外部サービスを個別に確認してください。メール通知だけで受け付けている場合は、サイトのバックアップから受信メールを復元できるとは扱いません。

既存のバックアップを調べる

新しいプラグインを追加する前に、現在の仕組みを一覧にします。ホスティングサービスの自動保存、WordPressのプラグイン、外部ストレージ、制作会社や保守会社の作業など、複数の保存方法がすでに使われている場合があります。

次の項目を管理画面や契約情報、作業記録で確認してください。不明なものは「未確認」と記録し、設定済みとみなさないことが大切です。

• データベースとファイルのどちらが保存されているか
• 画像、テーマ、プラグイン、独自開発ファイルが含まれるか
• 最後に成功した日時と、その後も同じ設定で動作しているか
• 保存先と、バックアップを取り出せるアカウント・担当者
• 保存期間、容量上限、復元依頼に必要な手順や費用
• 復元すると現在のデータが上書きされるか

サーバー内だけにあるバックアップは、そのサーバーやアカウントへアクセスできないと取り出せない可能性があります。別の保存先を使う場合も、ログイン権限、保存容量、バックアップの暗号化や共有範囲を確認します。バックアップには個人情報やサイトの設定が含まれることがあるため、保存先を増やすときは閲覧できる人も見直してください。

保存先が複数あっても、同じログイン権限に依存しているなら、その権限を失うとまとめて取り出せなくなる可能性があります。担当者個人のアカウントにしかない場合は、担当交代や退職時の引き継ぎも確認します。数を増やすことだけを目的にせず、誰がどの条件で取り出せるかを残してください。

保存状況の管理表には、秘密情報そのものを書き込む必要はありません。対象サイト、取得日時、保存方法、保管場所を示す識別名、確認者、取り出す窓口、復元の公式手順、未確認項目を記録します。パスワードや認証用の値は、共有範囲を決めた別の管理方法で扱います。

「成功通知」だけで終わらせない

定期バックアップが成功したら、記録に日時と対象を残し、保存先にデータがあることを確認します。エラー通知の有無だけでなく、ファイル容量や保存先の状態、取得権限も確認します。確認の方法は製品やホスティングサービスによって異なるため、利用中の公式マニュアルと契約内容に従ってください。

さらに、バックアップから復元できるかを、本番サイトを上書きしない環境で試します。WordPress公式資料は、バックアップの整合性や復元できることを確かめる重要性を説明しています。WordPress公式のセキュリティ対策ガイドも、復元可能性を確認したバックアップ計画に触れています。

復元テストの基本的な進め方

1. 対象を決める：どの日時の、どのバックアップを、何の確認に使うか記録します。
2. 作業場所を分ける：本番とは分離した検証環境を用意します。用意できない場合は、先にホストや保守担当へ方法を確認し、本番で試しません。
3. 外部への影響を止める：検証環境からメール、決済、予約、外部APIなどが本番の相手へ送られない設定か確認します。
4. 復元する：選んだファイルとデータベースを、利用中の仕組みの手順に沿って戻します。復元は既存データを上書きする場合があるため、画面の案内と対象を確認してから操作します。
5. 必要な動作を確かめる：トップページだけで終えず、ログイン、画像、主要ページ、フォームの入力から完了まで、業務で使う機能を確認します。通知の実送信が必要なら、合意した試験宛先を使います。
6. 結果を残す：使用した日時、バックアップの場所、成功・失敗、未確認の機能、次回に直すこと、担当者を記録します。

検証環境から検索エンジンや一般の訪問者がアクセスできない状態も確認してください。確認後はテスト用データやアクセス権を、あらかじめ決めた手順で片付けます。

試験結果は「ページが見えた」だけで完了にしません。画像の欠落、リンク先、編集後の保存、必要な問い合わせ経路、外部機能の接続条件を、事前の確認票と照らします。実際の通知を止めて試験した場合は「入力と表示まで確認、実受信は未確認」のように、確認した範囲を分けて記録します。未確認を残すことは失敗を隠すこととは違い、次に合意する作業を明確にします。

復元に失敗したら、別の古いバックアップを次々に上書きして試す前に、対象、エラー、試した操作と時刻を残します。保存データの取得不良、構成の不一致、権限不足など、原因の確認が必要です。原因が確定できない場合は、試験環境と記録を保ち、契約中のホストや実務担当へ相談してください。

障害が起きたときに、すぐ古いデータへ戻さない

サイトの表示が崩れた、ログインできない、データが消えたなどの問題が起きたとき、古いバックアップの復元は現在のデータを上書きする可能性があります。注文・予約・問い合わせなど、障害後に受け取った情報を先に確認し、復元で失われる内容がないか関係者と共有してください。

まず、発生した時刻、影響を受けるページや機能、直前の更新や変更、画面に出たエラーを記録します。ホスティングサービスの障害情報やバックアップ復元の条件を確認し、保守担当者がいる場合は連絡します。原因が分からないまま複数の復元や設定変更を続けると、調査や切り戻しが難しくなることがあります。

不正アクセスや改ざんが疑われる場合は、表示を戻すだけで解決したと判断しないでください。どの時点のバックアップが安全か、再発防止の確認が必要かを、ホストやセキュリティの担当者と相談します。原因調査、データ復元、再発防止は別の確認事項として、実際の環境と契約に応じて進めてください。

BackWPupなど復元機能のある製品でも、復元できるバックアップの種類や操作方法は製品・プラン・バージョンによって異なります。例として、BackWPup公式の復元手順では、無料版とPro版でバックアップの選択・アップロード手順が異なると説明されています。古い画面キャプチャや他サイトの手順をそのまま使わず、利用中の公式説明を確認してください。

同公式資料の復元機能は、BackWPupで作成したバックアップを対象にしています。別製品の保存ファイルも同じ画面でそのまま戻せる、と推定しないでください。データベースのみの復元と全体の復元も区別し、選んだ対象が何を上書きするか、現在の業務データと合わせて確認します。これは提供元の仕様説明であり、Acquaが読者の環境で復元成功を確認したという意味ではありません。

自社で確認する場合と、外部に依頼する場合

企業のWeb担当者・経営者の場合

社内で確認できるなら、バックアップの保存先、最終成功時刻、重要な業務データ、復元の連絡先を一覧にし、担当者が変わっても追える場所に保管します。自力で検証環境を用意できない場合や、何を戻すと業務に影響するか判断しにくい場合は、契約中のホスト・制作会社・保守会社へ確認してください。

企業としてWebの更新や保守を任せる範囲は企業向け案内で確認できます。Acquaの保守・運用へ相談する場合は、現状の構成、バックアップの取得対象と保存状況、検証や復元確認で必要な作業を分かる範囲で伝えてください。対応できる範囲と費用は、サイトの状態と契約条件を確認してから整理します。個別の障害復旧や復元試験が、定期保守へ一律に含まれるという意味ではありません。復元時間や結果も一律に約束するものではありません。

制作会社・広告会社の場合

保守や納品後の運用を引き受ける制作会社は、保存対象、保管先、復元権限、テスト環境、本番承認者、検収する機能、障害時の連絡範囲を依頼元と決めます。月額保守に含める定期作業と、個別の調査・復元・セキュリティ対応を分けておくと、依頼元への説明と見積もりの範囲が明確になります。

WordPress実装や保守の一部を外部へ頼みたい制作会社は、制作会社向けの対応工程で、支給物・権限・バックアップ・公開承認などの確認項目を見られます。対応可否や条件は案件ごとに確認してください。

バックアップ運用の確認リスト

• [ ] データベースと必要なファイルが保存対象に含まれている
• [ ] 直近の成功日時と保存先を担当者が確認できる
• [ ] 保存データを取り出せる権限と連絡先が分かる
• [ ] 許容できるデータ損失と停止時間を業務側と共有している
• [ ] 本番を上書きしない復元試験の方法がある
• [ ] 表示、ログイン、フォーム、予約・注文など必要な機能を確認する
• [ ] 復元後の切り戻しや、障害時に相談する相手が決まっている

すべてにチェックがつかない場合も、どの項目が未確認か分かれば次の作業を決められます。分からないところを無理に操作せず、ホスティング会社や保守担当へ確認してください。

相談するときに整理しておくこと

相談前に、サイトURL、困っている症状、最後にバックアップが成功した日時、保存先、重要な機能、現在の管理担当が分かる範囲で整理します。情報が分からない場合は、そのまま「未確認」と伝えてください。

パスワードやバックアップファイルそのものを、公開フォームや通常のメール本文へ添付しないでください。アクセス権の共有が必要な場合は、対象・権限・安全な共有方法を先に確認します。

社内で復元手順を確かめられたなら、その記録と担当者を更新し、以後の変更後も同じ方法で確認できるようにします。実務支援が必要なら、保守・運用を相談するか、サイトURLと状況を添えてAcquaへお問い合わせください。相談後に何を調べ、どこまで作業するか、費用と確認方法を着手前に決めます。