バックアップは「取っているか」ではなく「困ったときに、必要な時点のデータを、別の場所から戻せるか」で価値が決まります。その目安になるのが、データを3つ持ち、2種類の保存先に分け、1つは離れた場所に置くという3-2-1ルールと、何日前・何週前の状態まで戻れるようにするかを決める世代管理です。この記事では、2つの考え方の中身と、WordPressサイトに当てはめたときの具体的な構成、保持する世代数の決め方、運用で崩れやすい点を説明します。
3-2-1ルールとは
3-2-1ルールは、バックアップの置き方についての経験則です。
- 3：データのコピーを合計3つ持つ（本番のデータ＋バックアップ2つ）
- 2：そのうち少なくとも2種類の異なる保存先・媒体を使う
- 1：少なくとも1つは本番とは別の場所（オフサイト）に置く
狙いは、1つの原因で全部が同時に失われる状況を避けることです。サーバーのディスク故障なら同じサーバー内のバックアップも一緒に失われますし、データセンターの障害やレンタルサーバーの契約トラブルなら、同じ事業者の中にあるコピーにも手が届かなくなることがあります。
「2種類の媒体」は、テープとディスクを使い分けていた時代の言い方です。現在のサーバー運用では、「故障や事故の原因を共有しない保存先」と読み替えると実態に合います。たとえば同じVPSのディスク上に2つ置いても、媒体が分かれたことにはなりません。
3-2-1-1-0 という拡張
最近は、ランサムウェアへの対策を意識して「3-2-1-1-0」と言われることもあります。追加の「1」は書き換えや削除ができない状態（オフライン、またはイミュータブル）のコピーを1つ持つこと、「0」は復元テストでエラーがない状態を保つことを指します。バックアップ製品のベンダーが広めた言い方で、厳密な定義が決まっているわけではありませんが、考え方としては取り入れる価値があります。
本番サーバーが乗っ取られたとき、そのサーバーから書き込みも削除もできるバックアップ先は、一緒に消されたり暗号化されたりするおそれがあります。オブジェクトストレージの削除禁止機能（S3 のオブジェクトロックなど）を使う、本番からは書き込みだけを許可して削除権限を与えない、バックアップサーバー側から本番へ取りに行く（プル型）といった方法で、本番の権限だけでは消せないコピーを作っておくと安心です。
世代管理とは
世代管理は、バックアップを上書きせずに複数の時点の分を残しておくことです。1世代しかないと、気づかないうちに改ざんされたデータや、壊れたデータベースをそのままバックアップして上書きしてしまいます。マルウェアの混入やプラグイン更新による不具合は、発覚までに数日から数週間かかることも珍しくありません。
世代管理で決めるのは、次の2つです。
- どのくらいの間隔で取るか：最大で何時間分のデータを失ってよいか（RPO：目標復旧時点）から決まります。毎日取るなら、最悪で約1日分の投稿やコメント、注文が失われます。
- どこまでさかのぼれるか：問題が発覚するまでの期間を見込んで決めます。
GFS方式で世代数を抑える
毎日のバックアップを90日分すべて残すと、容量がかさみます。よく使われるのが GFS（Grandfather-Father-Son）方式で、新しい時点ほど細かく、古い時点ほど粗く残します。
- 日次（Son）：直近7日分
- 週次（Father）：直近4週分（各週の1つ）
- 月次（Grandfather）：直近6〜12か月分（各月の1つ）
これなら約20世代程度で、1年近く前までさかのぼれます。数字は一例で、更新頻度の高いECサイトなら日次を厚く、更新の少ないコーポレートサイトなら週次中心にするなど、サイトの性質で調整します。
WordPressサイトに当てはめる
WordPressで戻せるようにしておくべきものは、データベース、wp-content 配下（アップロード、テーマ、プラグイン）、wp-config.php の3つです。コアファイルは公式から入れ直せますが、バージョンをそろえて素早く戻すために、まとめて取っておく運用も一般的です。
よくある構成例
レンタルサーバーやVPSで運用している場合、3-2-1は次のように組むと現実的です。
- コピー1：本番サーバーのデータ
- コピー2：同じ事業者の自動バックアップやスナップショット（すばやく戻せるが、事業者単位の障害やアカウント停止には弱い）
- コピー3：別事業者のクラウドストレージ（オフサイト。復元に時間はかかるが、本番側の事故と切り離せる）
コピー2は「媒体が違う」とまでは言えない場合もあるので、コピー3を別の事業者・別のアカウントに置くことが、このルールの要になります。
保持世代の設定
バックアップ用プラグインを使う場合、UpdraftPlus や BackWPup、WPvivid Backup などは、保持する世代数や外部ストレージへの送信を設定できます。ファイルとデータベースで別々に保持数を指定できるものもあります。画面の表記や、無料版でできる範囲はバージョンによって変わるため、導入時に各プラグインのドキュメントで確認してください（2026年10月現在）。
プラグインの多くは保持数を「世代の数」で指定する仕組みで、GFSのような日次・週次・月次の組み合わせには対応していない場合があります。その場合は、日次の世代数を多めにし、月に1回は手動で別の保存先に取り分けておく、といった補い方があります。
サーバー側で組むなら、restic や BorgBackup のような重複排除型のツールが、GFS形式の保持を標準で扱えます。
# restic：日次7・週次4・月次12を残し、それ以外を削除して容量を回収
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
# BorgBackup：同様の保持ルール
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 /path/to/repo削除系のコマンドは、最初は --dry-run（どちらのツールにもあります）を付けて、どの世代が消えるかを確認してから実行してください。
容量の見積もり
世代を増やすほど、保存先の容量は増えます。毎回丸ごと圧縮ファイルを作る方式なら、おおよそ「1回分のサイズ × 世代数」になります。アップロード画像が多いサイトでは、この方式だとすぐに容量が足りなくなります。
restic や BorgBackup のように変更されたデータだけを保存する方式なら、2世代目以降は差分の分しか増えません。プラグインでも、データベースは毎日、ファイルは週1回といったように頻度を分けると容量を抑えられます。投稿や注文はデータベースに入るため、データベースの間隔を短くするのが効果的です。
運用で崩れやすい点
3-2-1と世代管理は、設定した直後よりも、運用が続くうちに崩れることが多い仕組みです。
- 外部への送信が止まっているのに気づかない：保存先の認証情報の期限切れや容量不足で、外部へのコピーだけが失敗し続けることがあります。最新のバックアップがいつのものかを定期的に見る、失敗時に通知を受け取る、といった仕組みを用意します。
- すべての保存先に同じ認証情報を使っている：1つの漏えいで全部のコピーに触られてしまいます。保存先ごとに権限を分けます。
- 復元を試したことがない：バックアップのファイルがあっても、展開できない、データベースの文字コードが合わない、といった問題は戻すまで分かりません。少なくとも数か月に1回、ステージング環境などに実際に戻して表示を確認します。
- サイトの規模が変わったのに設定が昔のまま：画像やデータが増えるとバックアップの時間も延び、タイムアウトで途中終了しやすくなります。サイズと所要時間の推移も見ておきます。
まとめ
- 3-2-1ルールは「3つのコピー、2種類の保存先、1つはオフサイト」。原因を共有しない場所に分けることが目的
- 本番の権限では消せないコピーを1つ持つと、乗っ取りやランサムウェアにも備えられる
- 世代管理は、失ってよい時間（取得間隔）と、さかのぼりたい期間（保持期間）から決める
- GFS方式なら、少ない世代数で長い期間をカバーできる
- 外部への送信の失敗検知と、定期的な復元テストまで含めて運用する