バックアップ設計の決め方 — 3-2-1ルールとRPO/RTOから逆算する

「日次でスナップショットを取っています」——では、なぜ日次なのですか？ 保持は何日で、なぜその日数ですか？ バックアップの相談で最初に詰まるのは、取り方の手順ではなく「決め方」の根拠です。業界標準の3-2-1ルールとAWS公式のベストプラクティスを軸に、RPO/RTOから逆算する筋道を示します。

バックアップの個別機能——スナップショット、世代管理、クロスリージョン、Vault Lock——の設計はAWS Backupで統合バックアップで、何がどこで守られるかの全体像はAWSバックアップ全体地図で扱いました。本記事はその手前、「頻度・保持・方式を何を根拠に決めるか」という意思決定そのものに絞ります。順番はいつも同じです——守るものを特定し、失ってよい時間(RPO)と止まってよい時間(RTO)を数字で置き、そこから方式が決まります。

01出発点：3-2-1ルールとそのAWS翻訳

クラウド以前から続くバックアップの古典が3-2-1ルールです。「データのコピーを3つ持ち、2種類の異なる保管に分け、うち1つは物理的に離れた場所に置く」。テープ時代の知恵ですが、クラウドでも本質は変わりません。AWSに翻訳すると自然にこうなります。

クラウドで特に効くのが「1つは離れた場所へ」の解釈です。物理的な遠隔地は別リージョンで満たせますが、現代の脅威はリージョン障害だけではありません。ランサムウェアや誤操作・内部不正に備えるなら、離すべきは距離だけでなく権限の境界——別アカウントの隔離Vaultです。3-2-1の「1」を「別リージョン＋別アカウント」の二軸で捉えるのが、いまの実務解です(具体的な組み方は運用設計編とマルチリージョンDR設計へ)。

02その前に — 「そのデータ、本当にバックアップが要るか」

3-2-1を全データに機械適用する前に、AWS公式が最初に問うのは意外な一手です。Well-Architectedフレームワークの信頼性の柱、バックアップの最初の原則REL09-BP01の正式名称は「バックアップすべき全データを特定してバックアップする、または、ソースから再生成できるようにする」。つまり「バックアップしない」も公式に認められた設計判断なのです。

判断の順番はこうです。まず、失うと二度と作れないデータ(=一次データ)を洗い出し、重要度で分類する。その上で各データについて問います——これは他から再生成できるか？

• 再生成できる：リードレプリカで復元できるデータ、元ログから再構築できる集計結果、ETLで作り直せる中間テーブル、キャッシュ。これらはバックアップしないという選択が正しいことがあります。守るのはコピーではなく「再生成の手順」です。
• 再生成できない：ユーザーが投入した一次データ、決済記録、監査ログ。ここに3-2-1と後述のRPO/RTO設計を集中投下します。

この「特定 → 再生成可能性の判定 → 要る分だけ守る」の順序は、全体地図で示した「データか構成か」「流れるデータは再処理で守る」という分類とそのまま噛み合います。全部を守ろうとするとコストも運用も破綻します。守らない判断を先にするのが、良い設計の入口です。

03RPO/RTOから方式を逆算する

「要る」と決めたデータについて、頻度と方式を決めます。ここで主語になるのが2つの数字です。

• RPO(目標復旧時点)：どこまでのデータ喪失を許容できるか。「最大1時間分は失ってよい」ならRPO=1時間。これがバックアップ頻度を規定します。
• RTO(目標復旧時間)：どれだけの時間で復旧すればよいか。「4時間以内に再開」ならRTO=4時間。これが方式と復旧手順を規定します。

設計は必ずこの2数字から方式へという向きで流れます。「日次スナップショット」から始めるのは逆走です。RPOを起点に方式を逆引きすると、AWSの選択肢はきれいに整列します。

RTO側も同じ発想で方式に効きます。「数分で戻したい」なら、スナップショットからの復元では初期化の遅延(復元直後のブロック遅延ロード)が壁になり、ウォームスタンバイや継続レプリケーションが要る。「翌営業日でよい」なら日次スナップショットで十分で、コールドストレージに逃がしてコストを削れる。RTO/RPOとコストは必ずトレードオフになるので、DR類型(Backup&Restore / Pilot Light / Warm Standby / Active-Active)まで含めた整理はマルチリージョンDRのRPO/RTO設計を参照してください。

04Well-Architected REL09の4原則で自己点検する

方式が決まったら、AWS公式の骨格で抜けを点検します。信頼性の柱のREL09「データのバックアップ」は4つの原則で構成されます。これをチェックリストとして使うのが実務的です。

特にBP02の「本番と同じセキュリティドメインに置かない」は、ランサム対策の要です。バックアップを消せる権限が本番運用者と同一なら、本番を破壊できる者はバックアップも破壊できます。AWS公式も、イミュータブル化(Vault Lock/S3 Object Lock)、本番と論理的に隔離したエアギャップVault、重要な復旧操作への多者承認(multi-party approval)を、サイバー耐性の追加策として挙げています。個々の設定手順は運用設計編の該当章(Vault Lock・復旧テスト)へ接続します。

05公式が挙げるアンチパターン集

REL09の各原則には、AWS自身が「よくある反面教師」を列挙しています。設計レビューのチェックにそのまま使えるので、現場語に訳して並べます。1つでも当てはまったら、そこが今日埋める穴です。

• そもそも全データソースを把握していない(BP01)。どこに一次データがあるか棚卸しできていない。
• 重要度を基準にせず、一部だけ何となくバックアップしている(BP01)。守る/守らないの判断が場当たり。
• RPOが定義されていない、または頻度がRPOを満たせていない(BP01)。「日次」だけが独り歩きしている。
• バックアップと本番のデータに同じ権限でアクセスできる(BP02)。復旧の自動化権限が本番と同一。
• 暗号化していない/イミュータブル化していない(BP02)。改ざん・削除に無防備。
• 手動でバックアップを取っている(BP03)。取り忘れが構造的に起きる。
• 復元はするが、データを取り出して中身を確認していない(BP04)。「ジョブ成功=復旧可能」と思い込む。
• バックアップが存在すると思い込んでいる/復元がRTO内に収まると思い込んでいる(BP04)。検証なき前提。
• 復旧をrunbookや自動手順なしで、その場対応でやっている(BP04)。障害時に再現できない。

並べると分かるとおり、最頻出は「思い込み」系(BP04)です。取ることより戻すことのほうが検証されないまま放置される。この非対称を埋めるのが、定期的な復旧テストの自動化です。

—まとめ

バックアップ設計は「取り方」を選ぶ前に、決める順番があります。

• 3-2-1を土台に：3コピー・2種類の保管・1つは遠隔。クラウドでは「遠隔」を別リージョン＋別アカウントの二軸で読む
• まず守らない判断:REL09-BP01は「特定 または 再生成」。再生成できるデータは守らないのが正解
• RPO/RTOから逆算:失ってよい時間が頻度を、止まってよい時間が方式を決める。データ重要度ごとに段を分ける
• REL09の4原則で点検:特定・暗号化と隔離・自動化・復旧検証。特に「思い込み」を復旧テストで潰す

「日次スナップショットを取っています」から始まる相談を、「このデータはRPO○時間だから、この方式で、この保持で、別アカウントに逃がして、四半期ごとに復元テストします」まで翻訳するのがEMWの仕事です。要件定義から設計・復旧訓練の仕組み化まで、お問い合わせください。実績は導入事例をご覧ください。

—参考(一次情報)

• REL09-BP01 Identify and back up all data, or reproduce the data from sources - AWS Well-Architected
• REL09-BP02 Secure and encrypt backups - AWS Well-Architected
• REL09-BP03 Perform data backup automatically (RPO別の頻度) - AWS Well-Architected
• REL09-BP04 Perform periodic recovery to verify backup integrity - AWS Well-Architected
• Restore testing - AWS Backup (復旧検証の自動化)