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