バックアップを取っている「つもり」が一番危険！本当にデータ復元できるか確認するポイント
目次
【AIによる要約】
– バックアップの価値は「取っていること」ではなく「復元できること」。復元テスト未実施のバックアップは保証外と同じです。
– よくある失敗は「DBとファイルの非同期」「リストアテスト未実施」「同サーバー保存」「世代管理不足」「属人化」の5パターンです。
– まずバックアップの保存先・取得範囲・頻度を棚卸しし、テスト環境で一度復元を試してください。自力で難しければプロに依頼できます。
はじめに：一番怖いのは「バックアップがない」ではなく「戻せない」
WebサイトやECサイトの運営において、セキュリティ対策と並んで重要なのがバックアップです。多くの担当者の方が「バックアップは取っているから大丈夫」と考えています。
しかし、当社は業界歴10年以上で300社以上の企業サイト・Webシステムの支援に携わってきましたが、その現場で最も多く目にしてきたのは「バックアップは存在していたのに、いざという時に復元できなかった」というケースです。
サーバー会社の管理画面に「バックアップ済み」の表示がある。レンタルサーバーの自動バックアップ機能がONになっている。社内の誰かが定期的に手動でダウンロードしている。——どれも「取っているつもり」であって、「復元できる保証」ではありません。
そして、改ざん被害やランサムウェア、サーバー障害が起きた瞬間に、その差が「数時間で復旧」と「コンテンツゼロからの再構築」の差として跳ね返ってきます。
「復元できない」現場でよくある5つの失敗パターン
パターン1：データベースと画像ファイルの同期が取れていない
WordPressやEC-CUBEなどCMSで構築されたサイトは、データベース（記事・商品データ・設定） と ファイル類（画像、テーマ、プログラム） がセットで初めて「サイト」として機能します。
ところが、よくあるのが「データベースだけ自動バックアップ」「画像は別の誰かがときどき手動コピー」というバラバラ運用です。この状態で古いバックアップから復元すると：
- 記事本文はあるのに、本文中の画像だけ消えている
- 商品データは新しいのに、商品画像がない
- 復元時点がデータベースとファイルでズレていて、サイトが不整合を起こす
といった「部分的に壊れたサイト」が出来上がってしまいます。
パターン2：リストア（復元）テストを一度もやっていない
バックアップデータの多くは、書き込みは自動、検証はされていない状態です。ディスクの不良や保存時のエラーで「データが壊れたまま保存されている」ケースは実際に存在します。
万一の際に本当に復旧できるかを確認する唯一の方法は、テスト環境に実際に復元してみること（リストアテスト） です。「取っています」と言える運用でも、「復元してみたことがあります」と言える運用は少ないのが実情です。
パターン3：バックアップ保存先が同じサーバー内にある
本体サイトが被害を受けるシーンを想像してください。サーバー障害でディスクが壊れた場合、同じサーバー内のバックアップも一緒に失われます。ランサムウェアに感染した場合、サーバー内のバックアップファイルも暗号化されるのが典型的な手口です。
バックアップの基本は「3-2-1ルール」——データを3つ保存し、2つの異なる媒体に、1つは別の場所（サーバー外）に保管することとされています。少なくとも、本体とは別のサーバーや外部ストレージに「切り離されたバックアップ」が1つは必要です。
パターン4：世代管理がなく、壊れた状態が上書きされている
常に同じ1ファイルに上書き保存する運用だと、ある時点でバックアップが壊れていれば、以後ずっと壊れたバックアップしか残らないことになります。また、改ざん被害の場合、「被害に気づくまでの数週間」に取ったバックアップすべてが改ざん後のデータになっていることもあります。
世代を複数保持し、「いつ時点に戻れるか」を日数で確保しておくことが重要です。目安としては、被害の検知遅れを考慮して最低でも2〜4週間前の状態に戻れる世代管理を推奨します。
パターン5：バックアップの「認知」が属人化している
「サーバーの誰かが設定した」バックアップが、担当者の退職とともに誰も内容を把握できない状態になる——これはシステムの引き継ぎトラブルで当社がよく目にするパターンです。バックアップの有無、保存先、復元手順は属人化ではなく「管理名簿」として文書化しておく必要があります。
まず確認したいチェックリスト
以下を1つでも「わからない」「やっていない」があるなら、バックアップは実質「白紙」だと思ってください。
- 取得範囲 — データベースとファイル（画像・テーマ・プログラム）の両方を取得しているか
- 頻度 — サイトの更新頻度に対して、失っても良いデータ量の範囲で頻度は十分か（毎日更新するECなら毎日以上）
- 保存先 — 本体サーバー以外に切り離した保存先があるか
- 世代管理 — 数週間前の状態に戻れる世代を保持しているか
- リストアテスト — 実際にテスト環境へ復元して、正常に表示・動作することを確認したことがあるか
- 文書化 — バックアップの仕組みと復元手順が、担当者以外にもわかる形で記録されているか
「自動バックアップ機能」に安心しきらない
レンタルサーバーの自動バックアップ機能は有用ですが、注意点があります。
- 保存期間の上限（例：過去14日間のみ）が決まっており、それより古い状態には戻せない
- 復元はサーバー会社の規約・対応範囲に依存し、自己責任で行う場合は手順や技術的な知識が必要
- 復元作業そのものが本番環境への影響を伴うため、いきなり本番で戻すのは危険
つまり「自動バックアップ機能がON」はゴールではなくスタートです。取得範囲・保存期間・復元手段の3点を確認した上で、足りない部分を自分たちの運用で補う必要があります。
復元テストを自力でやるか、プロに任せるか
リストアテストには「テスト環境の用意」「データベースの復元」「URLや設定の調整」「表示・動作確認」といった工程があり、Webサーバーやデータベースの知識が前提になります。無理に本番環境へ直接復元して「サイトが真っ白になった」という事故は、残念ながらよくある話です。
当社の考える判断の境界線は明快です。
- 自社で判断・実施できる範囲：バックアップの現状把握（取得範囲・保存先・頻度の確認）、管理名簿の作成
- プロに依頼すべき範囲：テスト環境への復元検証、障害時の実際の復旧作業、保守運用を含めた仕組みづくり
当社カジヤは、これまで300社以上の企業サイト・Webシステムの支援と、何度もの攻撃・障害からの復旧に現場として立ち会ってきました。そして当社自身も複数のWebサービス・EC事業を運営しています。「サイトが止まって売上が消える1日」の重みは、当事者だからこそ肌で知っています。
代理店を挟まない直接取引で、社内の専任エンジニアがバックアップ設計からリストア検証まで一貫して対応しています。「バックアップは取っているつもりだが、本当に戻せるか自信がない」——その違和感は正しい感覚です。まずは現状の確認からでも、お気軽にWebサイト保守管理サービスにご相談ください。
まとめ
- バックアップの価値は「取っていること」ではなく「復元できること」で決まる
- よくある失敗は「DBとファイルの非同期」「リストアテスト未実施」「同サーバー保存」「世代管理不足」「属人化」の5パターン
- チェックリストで現状を把握し、復元検証は自力の限界を見極めてプロに相談する
- 「いつ時点に戻れるか」を社内で共有できる状態にしておくことが、経営リスクの低減に直結する
