WordPressで「バックアップ済み」と聞いても、データベースだけ、画像だけ、サーバー会社の自動保存だけなど内容はさまざまです。障害や改ざんが起きたときに必要なのは、バックアップファイルの存在ではなく、必要な時点へ安全に復元できることです。
何を、どの頻度で、どこへ、何世代保存し、誰が復元するかを決める方法を解説します。
WordPressを構成する二つのデータ
WordPressサイトは大きく「ファイル」と「データベース」で構成されます。どちらか一方だけでは完全に復元できない場合があります。
ファイル
- WordPress本体
- テーマ
- プラグイン
- アップロード画像・PDF・動画
- 設定ファイル
- 独自プログラム
- サーバー上の補助ファイル
データベース
- 固定ページと記事
- タイトル、本文、公開状態
- ユーザー情報
- コメント
- WordPress設定
- テーマ・プラグイン設定
- フォーム保存データ
- カスタム投稿や独自データ
復元時に同じ時点のファイルとデータベースを組み合わせることが重要です。
サイト以外に保存すべき情報
WordPressのバックアップだけでは、ドメインや外部サービスを復旧できません。次の情報も管理します。
- ドメイン・DNS設定
- サーバー契約と管理情報
- SSL設定
- 会社メールのDNS設定
- GA4・GTM・Search Consoleの権限
- フォーム、予約、決済、CRMの設定
- 有料テーマ・プラグインのライセンス
- 外部連携のAPI設定
- 復旧手順と連絡先
パスワードは安全な管理ツールへ保管し、バックアップ資料へ平文で並べないようにします。
バックアップ頻度の決め方
頻度は、失っても許容できる更新量から逆算します。
- 更新が月1回：更新前と月次
- ブログを週数回更新：日次または更新ごと
- 問い合わせデータを保存：より短い間隔
- EC・予約・会員サイト：業務要件に応じて高頻度
「毎日」が十分とは限りません。障害発生から検知までの時間と、失えるデータ量を決めます。
更新前バックアップ
定期バックアップとは別に、次の作業前に手動または即時バックアップを取ります。
- WordPress・テーマ・プラグイン更新
- PHP・サーバー環境変更
- デザイン・コード改修
- 大量の記事移行
- URL・DNS変更
- 不要プラグイン削除
- データベース整理
作業前の状態へ戻せるよう、バックアップ名と作業内容を対応させます。
保存世代を決める
直近1回だけでは、気づかないまま改ざんや誤削除を含むバックアップへ上書きする可能性があります。日次、週次、月次を組み合わせ、複数時点を保存します。
例として、日次7世代、週次4世代、月次12世代などがありますが、更新量、容量、法的要件に合わせます。
サーバーと別の場所へ保存する
同じサーバー内だけでは、サーバー障害、契約停止、侵入、誤削除時に一緒に失う可能性があります。別のクラウドストレージや管理環境へコピーします。
自社も取得できる場所を用意し、制作会社だけが保管する状態を避けます。
3-2-1の考え方
重要データでは、3つのコピーを、2種類以上の媒体に置き、1つを別拠点へ保存する考え方があります。WordPressでも、稼働中データ、サーバー側バックアップ、別クラウド・社内保管などへ分散できます。
サービス障害やアカウント停止が同時に影響しない構成にします。
バックアップを暗号化する
データベースにはユーザー情報やフォーム内容が含まれる場合があります。保存先、通信、ファイルを適切に暗号化し、アクセス権を限定します。
退職者や契約終了者の権限を削除し、ダウンロードしたバックアップを個人端末へ放置しないようにします。
フォームの個人情報に注意する
問い合わせプラグインが送信内容をデータベースへ保存していると、バックアップにも個人情報が含まれます。保存目的、保持期間、削除方針、アクセス者を確認します。
不要なら管理画面保存を無効にし、必要なデータだけ適切に保管する方法を検討します。
自動バックアップの監視
設定しただけで安心せず、成功・失敗の通知、ファイル容量、最終日時を確認します。容量不足、認証切れ、外部ストレージ制限で停止することがあります。
月次保守では、複数回連続で成功しているかを記録します。
復元テストが必要な理由
バックアップファイルが破損している、必要ファイルが含まれない、暗号鍵が分からない、復元手順が古いと、本番障害時に使えません。
検証環境へ定期的に復元し、ログイン、主要ページ、画像、フォーム、プラグイン設定を確認します。
復旧目標を決める
二つの指標を考えます。
どこまでのデータ損失を許容するか
最後のバックアップ以降に失う可能性のある時間です。更新頻度や問い合わせ量から決めます。
何時間で復旧したいか
障害発生から公開再開までの目標です。必要な人員、連絡、バックアップ取得速度、DNSなどの条件に影響します。
経営上の影響が大きいサイトほど短い目標が必要です。
復旧手順書に含める内容
- 障害を判断する担当者
- 制作会社・サーバー会社の連絡先
- バックアップの保存先
- 必要な権限と復旧コード
- 最新正常時点の選び方
- ファイル・データベースの復元順序
- DNS・SSL・メールの確認
- フォームと計測のテスト
- 社内・顧客への案内
- 作業記録と再発防止
担当者が不在でも進められる内容にします。
サーバー会社のバックアップだけで十分か
自動バックアップは有効ですが、保存期間、対象、復元料金、復元方法、契約終了後の取得可否を確認します。同じ障害やアカウント停止の影響を受ける可能性もあります。
重要サイトでは、別系統のバックアップを組み合わせます。
プラグインのバックアップだけで十分か
プラグインは自動化に便利ですが、WordPress自体へログインできない障害や、プラグインの脆弱性・認証切れも考えます。サーバーや外部ストレージの手段と組み合わせます。
バックアップ処理がサイト速度や容量へ与える影響も確認します。
制作会社へ確認する質問
- ファイルとデータベースの両方が対象か
- 頻度と保存世代は何か
- 保存先は本番サーバーと別か
- 暗号化とアクセス制限はあるか
- 失敗通知を誰が確認するか
- 復元テストをいつ行ったか
- 復元作業と料金は契約に含まれるか
- 自社もバックアップを取得できるか
- 解約時にどの形式で受け取れるか
「バックアップあり」ではなく、復旧までの責任範囲を確認します。
バックアップ台帳
- 対象サイト
- 対象データ
- 実行頻度
- 保存先
- 保持世代
- 暗号化
- 管理者
- 最終成功日時
- 最終復元テスト
- 復旧目標
- 次回見直し日
複数サイトがある場合は、同じ形式で一覧にします。
公式情報の確認先
WordPress公式のサイト保守ガイドでは、定期的なバックアップを案内しています。更新手順でも、更新前にデータベースとファイルのバックアップが推奨されています。
まとめ
WordPressのバックアップは、ファイルとデータベースの両方に加え、ドメイン・サーバー・外部サービスの管理情報を対象にします。
更新量から頻度と世代を決め、本番サーバーとは別の場所へ暗号化して保存しましょう。定期的な復元テストと復旧手順があって初めて、障害時に使えるバックアップになります。