バックアップ保存先と保管コストの考え方

自動バックアップが付いているから大丈夫だと思っていても、そのコピーが本番サーバーと同時に失われる場所にあれば、障害時には役に立ちません。反対に保存先を増やしすぎると、転送・暗号化・権限管理・復元確認の負担も容量と一緒に増えていきます。

バックアップの保存先は、安い場所を探すことから始めるのではありません。どの事故からどの時点までを何時間で戻したいか決めると、必要な保存先と費用の輪郭が見えてきます。

容量を数える前に復旧したいものを決める

WordPressサイトは、画像やテーマなどのファイルだけでは元の状態へ戻りません。記事、設定、利用者情報などを持つデータベースも必要です。WordPress公式のバックアップ資料でも、一般的な復元にはファイルとデータベースの両方が必要だと説明されています。片方だけの保存は、バックアップ容量を小さく見せても復旧の目的を満たしません。

サイト以外も同時に止まる障害へ備えるなら、対象はさらに広がります。DNSレコード・メールアカウント・サーバー設定・外部サービスの接続情報は、WordPressのバックアップへ含まれないことがあります。すべてを同じ方法で保存する必要はありませんが、復旧に必要な情報の所在と取得日を一覧にしておかないと、サイトデータだけ戻ったところで作業が止まります。

最初に決めたいのは、データ量ではなく業務上の復旧点です。毎日更新するサイトと、月に一度しか更新しない会社案内では、許容できる消失期間が異なります。問い合わせ情報をサイト内へ保存している場合は、その取り扱いと復旧順も含め、何を失うと業務が止まるのかから対象を決めます。

保存先は本番環境からの距離で考える

同じサーバー内のコピーは、操作ミスから素早く戻す用途には便利です。しかし契約停止・ストレージ故障・管理アカウントの侵害まで起きると、本番と一緒に触れなくなる可能性があります。同じ事業者の別領域も運用しやすい一方、請求アカウントや管理権限が共通なら、完全に独立した保存先とは言えません。

外部ストレージへ送ると、サーバー障害から距離を取れます。ただし、本番と同じ認証情報で常時書き換えられる状態では、侵入者による削除や暗号化が保存先まで及ぶ余地が残ります。CISAのランサムウェア対策資料は、重要データについてオフラインかつ暗号化したバックアップを維持し、復旧時の可用性と完全性を定期的に試すよう勧めています。

現実的には、一つの保存先ですべての事故を受け持たせません。短時間で戻すコピーと、別の認証で守る外部コピー、通常時には書き換えられない世代を組み合わせます。この分け方なら、日常的な誤削除では速さを優先し、アカウント侵害時には独立したコピーへ切り替えられます。

保管世代は更新頻度と発見の遅れから決める

最新の一世代だけでは、壊れたデータを正常なものとして上書き保存することがあります。改ざんやフォーム不具合は発生当日に気づくとは限らないため、保管期間は更新頻度だけでなく、問題を発見するまでの遅れも踏まえて決めます。契約や社内規程で保存条件があるデータは、その要件を先に確認します。

日次・週次・月次といった階層は考え方の一例であり、すべてのサイトへ同じ日数を当てはめるものではありません。更新が多い期間は取得間隔を短くできます。制作作業の前には別世代を残し、個人情報を含む古いコピーには削除期限を設けるなど、業務の変化に合わせる方が実用的です。

差分バックアップや圧縮を使うと保存量は抑えられますが、復元時に複数の世代が必要になる方式もあります。費用を下げるために方式を複雑にした結果、担当者が復元できなくては意味がありません。世代数と同時に、どの順序で何を用意すれば戻るのかも記録します。

月額料金に現れない費用まで見積もる

保管コストの中心は保存容量ですが、見積もりは「サイト容量×世代数」だけでは終わりません。初回転送・日々の増分・古い世代の削除・データの取り出しにも条件があります。API利用や暗号鍵の管理、監視通知にも費用が生じることがあります。障害時の大量取り出しや復元代行が別料金なら、平常時の月額が安くても復旧時の支出は大きくなります。

人の作業も保管コストです。取得失敗の通知を見る担当、退職者の権限を外す担当、復元テストを実施する担当が必要です。

外部会社へ依頼する場合は、保存と復元のどこまでを担うか確認します。休日対応の有無も別に確かめます。「自動」という表現は、成功確認や復元判断まで無人で行われることを意味しません。

年間費用は、保存料金・転送料金・復元支援費・社内の確認時間を同じ表へ置くと比較しやすくなります。変動する料金を記事や引き継ぎ資料へ固定値で書くより、契約画面の確認日と計算条件を残す方が、翌年の見直しにも使えます。

復元テストまで終えて保存設計になる

バックアップ画面に成功と表示されても、ファイルが壊れていることがあります。データベースとの時点が合わない場合や、暗号鍵が見つからない場合もあります。公開中のサイトへ直接戻さず、隔離した確認環境で一部または全体を復元します。ログイン・主要ページ・画像・フォームの順に確かめます。

テストでは、復元できたかだけでなく所要時間も記録します。データの取り出し時間・外部サービスを戻す順番・必要な承認が分かれば、想定する復旧時間が現実的か判断できます。必要な時間を満たせなければ、保存先の階層や取得間隔を見直します。

運用記録には対象データ・保存先・認証の管理者を残します。保管期間に加え、最終成功日と最終復元テスト日も必要です。容量を減らすときも、古いコピーを場当たり的に消すのではなく、決めた削除規則に沿って処理します。保存先を選ぶ判断は、復元テストの結果を受けて更新されてはじめて、会社の復旧計画として機能します。