WordPressのバックアップは復元できる？本番と分けて確認するテスト項目
バックアップファイルが作られたことと、必要な状態へ戻せることは別です。記事が戻っても画像が欠ける、フォームが別の宛先へ送る、設定が古いという場合があります。復元テストでは、対象の時点と、戻したい機能を先に決めます。
ファイルとデータベースの両方を確認する
通常のWordPressサイトでは、記事などのデータを持つデータベースと、テーマ・プラグイン・画像などのファイルが別にあります。公式資料も、復元には両方が必要で、同じバックアップセットとして扱うことを説明しています。［出典1］ ファイルをダウンロードしただけで、記事のデータも保存されたと決め付けないでください。
| 確認対象 | 確かめること |
|---|---|
| 記事・ページ | 本文、公開状態、URL、更新時点 |
| 画像等のファイル | 記事から参照できるか |
| テーマ・プラグイン | 必要な版と組合せがそろうか |
| 設定 | URL、フォーム、通知、外部接続の扱い |
| バックアップ時点 | ファイルとDBが整合した時点か |
本番の上書きではなく、隔離した確認環境を用意する
復元テストを本番へ直接行うと、最新の記事や問い合わせが失われるおそれがあります。対象のコピーを確認環境で扱う設計にし、アクセス制限、外部送信、決済、検索エンジンへの公開などを先に管理者と確認します。顧客情報を含むデータを誰でも見られる場所へ置かないことも必要です。
以下は発注・検収のチェック表で、復元コマンドや本番設定を変更する指示ではありません。実際の作業は使用するホスティングとバックアップ製品の手順へ合わせます。
架空のメモサイトを戻す検収例
| ケース | 期待結果 | 結果欄 |
|---|---|---|
| 指定した記事3件を開く | 本文と公開状態が対象時点に一致 | 確認後に記入 |
| 画像を含む記事を開く | 画像が取得でき、参照先が正しい | 確認後に記入 |
| 管理画面の操作 | 必要な役割の管理者が操作できる | 確認後に記入 |
| フォーム | 確認用の宛先・送信条件でテストできる | 確認後に記入 |
| URL・転送 | 意図した環境内でページを辿れる | 確認後に記入 |
3件という数は教材の例です。実サイトでは重要な機能と異なる記事形式を選びます。成功した項目だけでなく、未確認の機能も一覧へ残してください。
復旧時間と復旧時点を混ぜない
「作業に何時間かかったか」と「何日前のデータまで戻れたか」は別です。障害を想定するなら、許容する停止時間と失ってよい期間を業務側で決め、その条件にバックアップと復元手順が合うかを確認します。実測していない所要時間を、復旧保証として書かないでください。
担当者へ渡す記録
- 対象のバックアップ日時と識別子。
- ファイル・DBの範囲、確認環境、復元手順の参照先。
- 成功・失敗・未確認の検収項目。
- 実際に測った場合の開始・終了時刻。
- 次回の担当と、手順を再確認する条件。
個別適用や説明の拡張時に確認する事項：バーニングトライブへ保守を依頼する際も、保存の有無だけでなく復元の検収条件を決めると、何を確認したかを説明できます。この原稿ではバックアップ取得や復元テストを実施していません。