2026.08.28

ホームページのバックアップは何世代必要？データ消失・改ざんから確実に復元するための世代管理と防衛策

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】

直近1世代だけは絶対NG：サイバー攻撃による改ざんやマルウェア感染は発覚までに平均数十日〜数ヶ月かかるため、直近1世代だけだと「汚染されたデータ」で上書きされ復旧不能になる。

プロの推奨世代数：コーポレートサイトでも「最低7世代（日次）＋過去1ヶ月分（週次・月次）」の世代管理（合計7〜14世代以上）を別拠点・外部クラウドへ隔離保管することが必須。

鉄則「3-2-1ルール」の実践：データは3つ保持、2種類の異なるストレージに保存、1つは遠隔地（AWS S3や外部クラウド等）へオフサイトバックアップを行う。

カジヤのスタンス：業界歴10年・300社以上の支援実績と自社事業運営の経験から、「復元テストを行っていないバックアップは存在しないのと同じ」と断言します。データ消失による事業停止を防ぐ実践的な保守体制を推奨。

「自社のホームページは、サーバー会社の自動バックアップがあるから大丈夫」
「プラグインで毎日バックアップを取っているから安心」

そう考えている企業担当者様や経営者様は非常に多くいらっしゃいます。しかし、いざサイバー攻撃による改ざんや誤削除、サーバー障害が発生した際、「バックアップを取っていたはずなのに、元の状態に復元できない」という致命的なトラブルが後を絶ちません。

その最大の原因が、「バックアップの世代管理（何日分・何世代過去のデータを残すか）」の認識不足です。

結論から申し上げますと、ホームページのバックアップは「直近1世代（前日分など）」だけでは全く不十分であり、最低でも「日次7世代＋過去1ヶ月分」の世代管理が必要です。

私たちカジヤは、業界歴10年以上・これまで300社を超える企業サイトやWebシステムの構築・運用・保守に直接携わってきました。また、受託開発だけでなく自社でも複数のWebサービスやEC事業を運営しているため、サイトが停止したりデータが消滅したりした際の「売上と社会的信用の損失の重み」を誰よりも深く理解しています。

本記事では、過去に数多くの改ざん被害やシステムトラブルの復旧現場に立ち会ってきた専門家の視点から、なぜ直近1世代では防げないのか、具体的に何世代残すべきなのか、そして事業を守るための確実な防衛策（3-2-1ルール）について分かりやすく解説します。

1. なぜ「直近1世代」のバックアップでは会社を守れないのか？

多くのレンタルサーバーが提供している「日次自動バックアップ」や、簡易的なWordPressプラグインの標準設定では、「毎日夜間に前日分のデータを取得し、翌日には上書きされる（保持世代数：1世代）」という仕様が少なくありません。

しかし、この「直近1世代のみ保持」という体制には、現場で最も恐れられている落とし穴が存在します。

バックアップ世代数が不足している場合の改ざん上書きリスク

理由①：サイバー攻撃や改ざんは「発覚までに平均数十日」かかる

Webサイトへの不正アクセスやマルウェア（悪意あるプログラム）の埋め込みは、画面を派手に書き換えるものばかりではありません。管理者が気づかないよう裏側で不正なスクリプトを潜伏させ、数週間〜数ヶ月かけてじわじわと迷惑メールをばら撒いたり、特定の検索流入者だけを詐欺サイトへ転送（リダイレクト）させたりする手口が主流です。

もし改ざん被害に遭ったのが「2週間前」で、発覚したのが「今日」だった場合どうなるでしょうか？

直近1世代（昨日分）しかバックアップを残していなければ、保管されているバックアップデータそのものがすでに「ウイルス感染・改ざんされた状態」で上書き保存されてしまっています。結果として、「正常だった過去のデータ」がどこにも残っておらず、復元が完全に不可能になってしまうのです。

【公的機関の一次情報】脅威の潜伏とバックアップの重要性

サイバー攻撃による被害の長期潜伏や、オフライン・世代管理バックアップの必要性は、国の公的機関からも強く警告されています。

IPA「中小企業の情報セキュリティ対策ガイドライン」
情報処理推進機構（IPA）が策定するガイドラインにおいて、ランサムウェアや改ざん攻撃から事業を再開するためには、バックアップデータを単一の場所に置かず、世代管理およびネットワークから切り離した隔離保管を行うことが重要対策として明記されています。
出典：中小企業の情報セキュリティ対策ガイドライン（IPA 独立行政法人情報処理推進機構）
JPCERT/CC「インシデント報告対応レポート」
国内のサイバーセキュリティインシデントを収集・分析するJPCERT/CCの報告書によると、Webサイト改ざんや不正侵入を受けた組織において、侵入から発覚までに長期間を要するケースが多数報告されており、被害発生前のクリーンな状態へのロールバック（巻き戻し）手段の確保が不可欠とされています。
出典：インシデント報告対応レポート（JPCERT/CC）

理由②：プログラムの不整合や誤削除（論理障害）の発見遅れ

「担当者が誤って過去の重要なお知らせページを削除してしまった」「プラグインの自動更新によって特定の機能が動かなくなっていた」といったトラブルも、発生当日に気づけるとは限りません。

数日〜1週間後に社内やユーザーからの指摘で気づいた際、数日前の世代が残っていなければ、手作業でゼロから復元するか諦めるしかなくなります。

2. 【結論】ホームページのバックアップは何世代必要か？プロの判断基準

サイトの運用規模や更新頻度によって求められる体制は異なりますが、企業の事業用サイトにおけるプロの推奨基準は以下の通りです。

【推奨するバックアップ世代管理モデル】
・日次バックアップ（Daily）  ：直近 7世代（7日分）
・週次バックアップ（Weekly） ：過去 4世代（4週間分）
・月次バックアップ（Monthly）：過去 3〜6世代（3〜6ヶ月分）

サイト種別	推奨バックアップ頻度	推奨保持世代数	保管場所
一般的なコーポレートサイト（月数回更新）	日次（毎日1回）	最低7世代〜14世代（過去1ヶ月程度まで復元可能）	サーバー外の外部クラウド（AWS S3等）
オウンドメディア・ブログ（週数本更新）	日次（毎日1回）	14世代〜30世代（過去1〜2ヶ月分）	サーバー外の外部クラウド＋ローカル
ECサイト・会員制サイト（日々注文・会員登録発生）	日次＋リアルタイムDB	30世代以上（DBは数時間ごとまたは即時レプリケーション）	堅牢なクラウド冗長化＋多重暗号化保管

なぜ「日次＋週次＋月次」の組み合わせなのか？

すべてを日次で365日分保存すると、ストレージ（サーバー容量）を圧迫しコストが跳ね上がります。

そのため、「直近1週間は1日単位で細かく戻せる（日次7世代）」状態を維持しつつ、「1ヶ月前、2ヶ月前の状態にもポイントで巻き戻せる（週次・月次アーカイブ）」という世代管理設計を行うのが、コストパフォーマンスと安全性を両立させる現場のベストプラクティスです。

3. データ消失を確実に防ぐ「3-2-1バックアップルール」

世代数を確保するだけでは万全とは言えません。「どこにバックアップを保存しているか」が極めて重要です。

世界的なデータ保護の標準指標として知られる「3-2-1ルール」をWebサイト運用にも適用する必要があります。

Webサイト運用の3-2-1バックアップルール

3-2-1ルールとは？

3つのデータ（3 Copies）：オリジナルデータ（本番稼働中のサイト）に加えて、2つのバックアップコピーを作成する（合計3つ）。
2つの異なるメディア（2 Different Media）：同じサーバーや同一ディスク内ではなく、異なる種類のストレージや媒体に保存する（例：本番サーバーとクラウドストレージ）。
1つの遠隔地保管（1 Off-site Backup）：火災・自然災害・データセンターの大規模障害・サーバー会社のアカウント乗っ取りに備え、最低1つは地理的・システム的に完全に隔離された遠隔地（AWS S3、Wasabi、Google Cloud Storage等）に保管する。

同一サーバー内のバックアップは「共倒れ」する

WordPressのプラグイン等でバックアップを取っている場合、同じWebサーバー内の別ディレクトリ（例：wp-content/uploads/backups/）にバックアップファイルを保存しているケースが散見されます。

しかし、これでは本番サーバーがランサムウェアに感染したり、サーバー会社のハードウェア故障やアカウント凍結が起きた際に、本番データとバックアップが同時に消滅（共倒れ）します。

必ず「本番サーバーとは完全に独立した外部クラウドストレージへ自動転送する仕組み」を構築してください。

4. 現場で頻発するバックアップの「4大落とし穴」チェックリスト

カジヤがこれまでに数多くのトラブル相談を受ける中で目にしてきた、「バックアップを取っていたつもりの致命的な失敗事例」をまとめました。自社のサイトが当てはまっていないか今すぐ確認してください。

[ ] 落とし穴1：ファイルだけ保存して「データベース（DB）」が抜けている
WordPressの投稿本文、固定ページ、設定情報、ユーザー情報などはすべてデータベース（MySQL / MariaDB）に格納されています。画像やテーマファイル（FTPファイル）だけを保存していても、データベースがなければ記事やページは一切復元できません。「ファイル一式＋データベース（SQL）」の完全セットで取得されているか確認が必要です。
[ ] 落とし穴2：サーバー容量オーバーで「ある日突然停止」していた
世代数を増やした結果、サーバーのディスク容量上限に達し、バックアップ処理がエラーで停止したまま何ヶ月も放置されていたケースです。定期的な容量監視と古い世代の自動ローテーション（世代削除）設定が必須です。
[ ] 落とし穴3：バックアップファイル自体が一般公開（URL直打ちでDL可能）になっている
セキュリティ設定が甘いプラグインを使用していると、バックアップファイル（顧客の個人情報やサイト全体のプログラムを含むzip等）のURLが外部から推測・直接ダウンロード可能な状態になっており、深刻な情報漏洩事故につながる危険があります。
[ ] 落とし穴4：「リストア（復元）テスト」を一度もやったことがない
最も多い盲点です。バックアップファイルは存在するものの、いざテスト環境に復元しようとしたら「ファイルが破損していた」「PHPやMySQLのバージョン違いでエラーが出て動かない」という事態です。「復元できることを実証していないバックアップは、バックアップではない」と認識しましょう。

5. カジヤが提供する安心のWebサイト保守体制

株式会社カジヤでは、これまで300社以上の企業サイト構築・Webシステム開発を手掛けてきた経験から、「有事の際に100%復旧できること」を前提としたWebサイト保守管理サービスを提供しています。

なぜカジヤのバックアップ・保守管理が選ばれるのか？

完全外部クラウドへの日次・多世代自動バックアップ
本番サーバーとは物理的・ネットワーク的に完全に隔離されたセキュアな外部クラウド（AWS等）へ、ファイルおよびデータベースを暗号化して毎日自動転送。日次・週次・月次の多世代管理を標準実装しています。
専任エンジニアによる「定期復元（リストア）テスト」の実施
バックアップを取るだけでなく、ステージング（検証）環境にて実際にデータが完全に復元できるかを定期的に検証。不測の事態でも迅速な復旧をお約束します。
当事者目線と直接取引による迅速な初動対応
当社は代理店を挟まない「直接取引」にこだわり、社内の専任エンジニアが一貫対応します。また、自社でもWebサービスやEC事業を複数運営しているからこそ、障害時のダウンタイムを1分1秒でも短縮するための迅速な体制を整えています。

「自社のバックアップが何世代残っているか分からない」「改ざんやデータ消失に備えてプロにバックアップ体制を点検・構築してほしい」という企業様は、ぜひお気軽にご相談ください。