WordPressのバックアップ方法：取り方・復元手順と運用ルール

WordPressのバックアップは、保存ファイルがあるだけでは十分とはいえません。障害、更新ミス、設定変更などが起きたときに、必要な時点のデータを選び、影響を把握したうえで復元できる状態になっているかが重要です。特に、投稿や画像だけでなく、データベース、外部サービスの設定、バックアップデータ自体へのアクセス権も確認する必要があります。

この記事では、保存対象、プラグイン・サーバー機能・手動取得の使い分け、安全な復元フロー、頻度・世代管理、委託先への確認項目を整理します。自社の体制と復旧要件に合った、復元できるバックアップ運用を決められるようになります。

バックアップ運用は、保存対象の整理から復元テスト、担当体制の確認までを一続きで設計します。

01Sectionバックアップは「取得」ではなく「復元できる状態」まで整える

バックアップ運用の目的は、データを保存することではなく、必要な状態へ安全に戻せるようにすることです。取得処理が成功していても、保存先にアクセスできない、ファイルとデータベースの時点が合わない、復元の担当者や承認者が決まっていない、といった状態では緊急時に使えません。

バックアップだけで復旧を保証できない理由

復旧には、保存対象の範囲、保管先へのアクセス、復元する時点と単位、現行データへの影響確認、復元後の動作確認が関わります。フォーム送信、会員情報、受注情報など、サイト運用中に変化するデータがある場合は、復元によって失われる可能性があるデータを事前に見積もる必要があります。

また、WordPressのファイルやデータベースとは別の場所で、DNS、メール、決済、会員管理などが運用されていることもあります。WordPress内のバックアップだけでサイト全体が元に戻るとは限らないため、対象範囲を分けて把握します。

先に決めるべき運用項目

運用を設計する際は、次の5点を一つの流れとして決めます。

• 何を保存するか
• どの方式で、どこへ保存するか
• どの時点・単位まで復元できるか
• 誰が実施・承認し、問題時に誰へ連絡するか
• 取得・保管・復元可能性をどの頻度で点検するか

サイトの更新量、外部連携、保守契約、管理権限によって適切な設計は変わります。固有の操作画面ではなく、この5点を自社で説明できる状態を目標にすると、方式や委託先が変わっても運用を引き継ぎやすくなります。

02SectionWordPressで保存する対象：データベース、ファイル、サイト外の情報

データベースとファイルだけでなく、WordPressの外で管理される設定やデータも、別途復旧経路を確認します。

通常のWordPress構成では、典型的な完全復元にデータベースとWordPress設置ディレクトリ内のファイルの双方が必要です。WordPress公式も、ファイルとデータベースを別の要素として扱い、両方をバックアップ対象とする考え方を案内しています。WordPress公式のバックアップ解説を参照し、自社の構成に照らして範囲を確認してください。

データベースとファイルは対応する一式で保管する

データベースには、投稿、固定ページ、コメント、ユーザー、各種設定、テーマやプラグインが保存するデータなどが含まれ得ます。一方、WordPress設置ディレクトリには、WordPress本体、テーマ、プラグイン、アップロード済みメディア、設定ファイル、独自コードなどがあります。

設置ディレクトリを取得しても、通常は別システムで管理されるデータベースまで含まれるとは限りません。復元候補として保管する際は、ファイル一式とデータベース出力がどの日時に対応するかを記録します。

サイト外で管理される情報も棚卸しする

DNS、SSL、CDN、メール、外部フォーム、決済、会員、予約、アクセス解析などは、WordPressのファイル・データベースのバックアップに含まれないことがあります。それぞれについて、設定値やデータの保存場所、出力・復旧の可否、管理者、緊急時の連絡先を提供元ごとに確認します。

問い合わせ内容や会員情報など個人データを含み得るバックアップは、保管先とアクセスできる人を必要な範囲に限定し、異動や委託終了時に権限を見直す対象です。委託がある場合は、委託先の選定、契約、取扱状況の把握といった観点を示す個人情報保護委員会のガイドラインも確認してください。

03Sectionバックアップ方法は3つ：プラグイン・サーバー機能・手動の選び方

方式の選定では、自動化の可否だけでなく、障害時に使える復元経路と代替経路を確認します。

取得方法は、プラグイン方式、サーバー機能方式、手動取得方式に大別できます。どれか一つを一律に選ぶのではなく、自社の権限、日常の運用負荷、必要な復元経路を基準に役割を分けます。WordPress公式は、ホスト提供機能、手動取得、プラグインによる自動化をバックアップ方法として案内しています。WordPress公式のバックアップ方法も確認しましょう。

日常の定期取得と更新前取得を分ける

日常の定期取得は、通常運用で発生する更新を一定の間隔で保全するためのものです。これとは別に、WordPress本体、テーマ、プラグインの更新や大きなコンテンツ変更の前には、任意に取得する運用を設けます。更新前に取得した一式があれば、変更後の不具合に対して、戻す候補日時を判断しやすくなります。

プラグイン方式を検討する場合は、WordPress管理者権限、プラグインの追加可否、保存先アカウントと容量、失敗通知先、サーバー制約を確認します。個別の互換性、更新状況、サポート情報はWordPress公式プラグインディレクトリの各ページで確認できます。

バックアップ用プラグインの定番としてよく挙がる例

バックアップ用のプラグインとしては、UpdraftPlus、BackWPup、Duplicatorなどが、公式ディレクトリで配布され利用数の多い代表例として知られています。いずれも定期取得や外部ストレージへの保存に対応する機能を持ちますが、対象範囲、保存先、復元経路、無償版と有償版の機能差はプラグインごとに異なります。

これらは配布状況・更新状況・利用規模を公式ディレクトリで確認できる代表例であり、特定のプラグインの採用を推奨するものではありません。導入前に、データベースとファイルの双方を対象にできるか、保存先と復元手順が自社の運用に合うか、更新とサポートが継続しているかを、各プラグインの公式ページで確認してください。

管理画面に入れない場合の代替経路を確保する

WordPress管理画面を起点とする方式だけでは、管理画面自体に入れない障害時に復元を始められない可能性があります。サーバー管理画面からの復元可否、保守先への依頼方法、必要な承認者と連絡先を事前に確認し、少なくとも一つの代替復元経路を決めておくことが重要です。

サーバー機能の対象範囲、保持期間、復元単位、任意取得、受付時間、追加費用、反映条件はサービスや契約で異なります。利用中サービスの公式マニュアル、契約条件、保守先への確認で確定してください。

04Sectionバックアップから安全に復元する共通フロー

復元は、候補日時の選定と現行データへの影響確認を行い、検証・承認を経て本番へ反映します。

復元では、最初に操作を急ぐのではなく、「どの範囲を」「いつの状態へ」戻すかを決めます。サイト全体、ファイル、データベースなどの復元単位と、障害や誤更新が混入する前の候補日時を明確にし、現行データを失う影響を確認してから進めます。

手動で復元する場合は、対応する時点のファイル一式とデータベースを扱います。WordPress公式では、典型例としてファイルを復元した後にデータベースをインポートする流れが案内されています。ただし、実際の操作や接続情報は環境ごとに異なるため、WordPress公式のデータベース復元手順と利用中環境の手順を確認してください。データベースのインポートは現行データをバックアップ時点へ戻す操作になり得るため、対象の取り違えや上書き影響を判断できない場合は本番で実施しません。

05Section頻度と世代は許容損失時間・復旧時間から決める

取得頻度や保持世代に一律の正解はありません。まず、どこまでの更新を失っても許容できるか、どのくらいで業務を再開する必要があるかを決めます。NISTが示すコンティンジェンシープランニングの考え方でも、復旧能力はバックアップだけでなく、目標、手順、役割、技術的措置を組み合わせて設計するものとされています。NISTのコンティンジェンシープランニングを復旧計画の確認先として活用できます。

RPOとRTOをWordPress運用に置き換える

RPOは「許容できるデータ損失時間」です。障害時に、投稿、問い合わせ、会員登録、受注などを、どの時点まで失っても許容できるかを時間で表します。RTOは「許容できる復旧時間」であり、障害発生から必要なサイト機能を再開するまでに許容できる時間を表します。

RPOが短いほど、取得間隔だけでなく、外部サービスにある重要データの保存方法も重要になります。RTOが短いほど、復元経路、権限保有者、承認者、時間外連絡、復元テストが整っていなければ目標を満たしにくくなります。

複数世代を持つ目的は、最新のバックアップが常に正しいとは限らないためです。誤更新や改ざんが起きた後の時点しか残っていなければ、戻したい状態を選べません。保存期間や世代数は、容量、個人データの取扱い、契約条件、更新量を踏まえて決めます。WordPressの更新前には、定期取得とは別に任意取得を行うルールも有効です。

06Section取得・保管・復元可能性を分けて点検する

バックアップの「成功」は、取得処理が終わったことを意味するにとどまります。保存データが必要な世代数で残っているか、権限を持つ担当者がアクセスできるか、実際に復元して主要機能が動くかは別々に確認します。WordPress公式も、バックアップの妥当性を確認し、復元できる状態を維持する重要性に触れています。WordPress公式のセキュリティ運用ガイドを確認しながら、点検を定常業務に組み込みましょう。

取得確認は取得ごと、保管確認と復元確認は定期的に行います。さらに、WordPress、PHP、テーマ、プラグイン、サーバー、保存先、外部連携、担当者が変わった後は、対象範囲、通知先、権限、復元手順を見直してください。

07Section保守会社・制作会社へ委託している場合の確認項目

保守を委託していても、バックアップの対象、取得、保管、復元、テストを誰が担うかは、契約と実運用で一致している必要があります。保守範囲全体を見直す際は、WordPress保守の基本と確認ポイントもあわせて確認してください。

契約書、SLA、運用手順書、月次報告、サーバー仕様を並べ、同じ質問への回答が一致するかを確認します。記載がない項目や資料間で異なる項目は、保守先またはサーバー提供元へ書面で確認することが重要です。

個人データを含む可能性がある場合は、保管先、アクセス権、委託先・再委託先の取扱状況、委託終了時の返却・削除条件も確認対象です。個別の契約内容や取扱実態によって必要な対応は変わるため、資料上の記載と実際の運用に差がないかを確認します。

08Section自社対応を続ける条件と、相談へ切り替える条件

自社で運用や復元を進めやすいのは、保存対象、復元経路、必要権限、復元候補日時、検証環境、実施者・承認者、切り戻し条件が明確な場合です。この条件がそろっていれば、日常の定期取得、更新前の任意取得、点検記録を自社の運用ルールに組み込みやすくなります。

一方で、次のような場合は本番操作を続けず、保守先、サーバー提供元、または専門家へ相談する判断が安全です。

• WordPress管理画面、サーバー管理画面、DB管理画面のいずれかにアクセスできない
• 復元単位、候補日時、ファイルとデータベースの対応関係を判断できない
• 現行状態を退避できず、投稿、問い合わせ、受注、会員データへの影響を評価できない
• 不正アクセス、改ざん、ランサムウェア、個人データへの影響が疑われる
• 決済、会員、予約、受注など重要機能への影響範囲を切り分けられない

相談時は、発生日時、症状、直前の変更、影響範囲、利用可能なバックアップの候補日時、保有している権限、契約上の連絡先を整理して共有します。情報がそろっているほど、復元の要否、適切な復元単位、関係者への連絡を判断しやすくなります。

WordPressの保守・復元体制を相談する

バックアップの対象範囲、復元経路、権限、検証環境、保守契約の責任分界を自社だけで整理しにくい場合は、WordPressの保守対応を行う会社へ相談し、支援範囲や緊急時の対応条件を確認しましょう。

WordPress制作・保守2949社掲載

WordPress制作・保守の相談先を探す