バックアップ設計の判断 — どこまで戻せる構築にするか

バックアップは「取っている」だけでは機能しません。障害が発生した瞬間に問われるのは、どこまで・どれだけの速さで・何を戻せるかという設計判断です。RPO/RTOの目標を先に定め、守る対象をデータ・構成・状態の三層で分類し、リストア訓練を設計に組み込む。この三つの軸を押さえることが、バックアップが「飾りにならない」構築の出発点になります。

「取っているのに戻せない」バックアップが生まれる構造

バックアップが「飾り」になる3つのパターン

本番環境でバックアップが機能しなかったという話は、現場では珍しくありません。多くの場合、問題は取得処理そのものではなく、設計の前提にあります。典型的なパターンは三つあります。

一つ目は「取得は成功しているが、リストア先の環境が存在しない」ケースです。バックアップジョブが正常終了していても、復旧時に書き戻す先のストレージやサーバーが確保されていなければ意味をなしません。二つ目は「整合性が保証されていない」ケースです。データベースとアプリケーション設定ファイルを別々のタイミングでバックアップしており、障害時に両者の世代が噛み合わない状況がこれにあたります。三つ目は「媒体が読めない」ケースです。テープや外部ストレージの劣化・移行が未対応のまま放置されており、いざという時に参照できない状態になっています。これら三つは全て、「取得すること」と「戻せること」を同一視した設計が招く問題です。バックアップ設計は取得フローと並行して、リストアフローを同等の優先度で設計しなければなりません。

設計フェーズで見落とされる前提条件

構築プロジェクトの初期フェーズでは、バックアップの要件がざっくりとした形で定義されることが多いです。「毎日取る」「1週間保持する」といった粒度で合意され、具体的な復旧シナリオは後回しになります。この段階で見落とされやすい前提条件が三つあります。

まず「何の障害を想定するか」という障害シナリオの定義です。人為的な誤操作なのか、ストレージ障害なのか、ランサムウェアなのかによって、必要なバックアップの種類と保存場所が大きく変わります。次に「誰が復旧操作を行うか」という実施者の定義です。深夜障害時に対応できる人物が限られる場合、手順の複雑なリストアは現実的ではありません。最後に「復旧に使える時間と許容できるデータ損失の範囲」です。これが定まらないと、バックアップ方式の選定根拠が持てません。いずれも、設計フェーズで関係者と合意しておくべき前提条件です。

「取ること」と「戻せること」は別の設計

バックアップ設計を「取得設計」と「リストア設計」に分けて考えることが重要です。取得設計はスケジュール・対象・圧縮・暗号化・保存先を決める作業であり、リストア設計は手順・実施者・所要時間・検証方法・切り替えシーケンスを決める作業です。この二つは全く異なる設計領域です。

実際の構築では、取得設計に工数の大部分を割き、リストア設計が後付けになることが多いです。これが「取っているのに戻せない」構造の根本原因です。設計フェーズでリストア設計を先行させ、そこから逆算して取得設計を決める順序が望ましいです。リストアに必要な条件を先に定義しておくことで、取得の頻度・形式・保存先が自然に絞り込まれます。

何を守るか（データ/構成/状態）で変わる設計

データ・構成・状態の三層を整理する

バックアップの対象は大きく「データ」「構成」「状態」の三層に分類できます。それぞれ性質が異なり、守り方も変わります。

データとはデータベースの内容・ファイルシステム上のユーザーデータ・ログ等、サービスが生成・蓄積するものです。更新頻度が高く、損失した場合のビジネス影響が直結します。構成とはサーバー設定ファイル・ミドルウェアの設定・アプリケーションコード・IaCのコードベース等、環境を再現するための情報です。データほど頻繁には変わりませんが、これがなければ復旧は成立しません。状態とはセッション情報・キャッシュ・処理中のジョブ・一時ファイル等、ある時点における「動作中の文脈」です。失われた場合の影響はシステムによって大きく異なるため、設計に含めるかどうかの判断が必要です。

守る対象を誤ると設計全体がずれる

守る対象の分類を誤ると、バックアップ全体の設計がずれます。よくある失敗は、データだけを守りながら構成の管理を無視するケースです。

たとえば、データベースのダンプは毎日取得しているが、NginxやPHPの設定ファイルは構成管理されておらず、サーバー再構築時に担当者の記憶と手作業に頼るという状況があります。この場合、データの復旧は数時間以内に完了できても、構成の再現に想定外の工数がかかり、結果として復旧目標を大きく超える事態になります。構成はGitリポジトリやIaCツールで管理し、そのリポジトリ自体もバックアップ対象に含める判断が必要です。状態については「失って許容できるか」を基準に、設計に含めるかどうかを決めます。

対象別の設計方針

対象	変更頻度	主な特性	代表的な管理手段
データ	高い（随時更新）	損失がビジネス損失に直結する	DBダンプ・スナップショット・CDP
構成	低〜中（変更時のみ）	欠落すると環境再現が不可能になる	Git / IaC / 構成管理ツール
状態	揮発的（常時変化）	損失許容度はシステムによって異なる	セッションDB・キューの永続化設定

復旧目標（RPO/RTO）から逆算するバックアップ方式

RPOとRTOの現場における意味

RPO（Recovery Point Objective）とRTO（Recovery Time Objective）はバックアップ設計の基本概念ですが、現場での扱い方が表面的になりやすいです。数字だけが一人歩きし、その根拠が関係者間で共有されていないケースが多く見られます。

RPOは「どの時点まで戻るか」、つまり許容できるデータ損失の時間範囲です。RPO=1時間であれば、直近1時間以内のデータが失われることを許容するという設計上の合意を意味します。RTOは「どれだけの時間で復旧するか」という目標値です。RTO=4時間であれば、障害発生から4時間以内にサービスを再開できる設計が求められます。この二つの目標値は「ビジネス上どれだけの損失を許容できるか」に基づいて定義されるものです。設計者が単独で決めるのではなく、サービスオーナーや利害関係者と合意することが前提になります。この合意なしにバックアップ方式を選定すると、後から「間に合わない」「足りない」という問題が生じやすくなります。

目標値から方式を決める逆算

RPOとRTOが定まると、バックアップ方式の候補が絞られます。目標値を起点に、実現可能な方式を逆算するのが設計の正しい順序です。

RPO=24時間・RTO=8時間であれば、日次フルバックアップと手動リストアの組み合わせという比較的シンプルな構成で対応できます。RPO=1時間・RTO=2時間になると、差分・増分バックアップの組み合わせか、継続的データ保護（CDP）の導入が視野に入ります。RPO=15分・RTO=30分であれば、データベースレプリケーションとホットスタンバイが必要になり、バックアップだけでなく高可用性設計との統合が不可欠になります。重要なのは、目標値が厳しくなるほど設計コストと運用負荷が大きく増えることです。全てのシステムに最も厳しい目標を適用するのではなく、システムの重要度に応じて目標値を変える判断がここで効いてきます。

方式別の特性比較

方式	RPO目安	RTO目安	主な適用場面
フルバックアップ（日次）	24時間	数時間〜半日	許容損失が広い・変更頻度が低い環境
増分・差分バックアップ	数時間〜12時間	1〜4時間	中程度の重要度・汎用業務システム
CDP（継続的データ保護）	数分〜1時間	30分〜2時間	高頻度更新・厳格なRPO要件がある環境
レプリケーション＋ホットスタンバイ	秒〜数分	数分〜30分	高可用性が必要な基幹システム

世代管理・保存先分散をどこまでやるかの判断

世代数の根拠はどこに置くか

「何世代保持するか」という問いに対して、「とりあえず7世代」「1ヶ月分」と根拠なく決めているケースが多いです。しかし世代数は、リストアシナリオを起点に根拠を持って判断する必要があります。

根拠となる観点は二つあります。一つは「どれだけ遡って発見されるか」という問題発生の検知遅延です。ランサムウェアや静かなデータ破損は、発生から数日〜数週間後に発覚することがあります。この場合、7世代（1週間分）では足りず、30世代（1ヶ月分）以上が必要になります。もう一つは「どの時点に戻る必要があるか」というビジネス上の要件です。月次処理のやり直しが発生する可能性があるなら、月をまたいで2ヶ月分の保持が必要な場合もあります。世代数はストレージコストに直結します。たとえば1日あたり50GBのデータが増加する環境で30世代を保持しようとすると、バックアップだけで1.5TB以上のストレージが必要になります。このような試算を設計段階で行い、現実的な世代数を決定します。

保存先分散の設計判断

3-2-1ルール（3つのコピー・2種類の媒体・1つはオフサイト）は広く知られていますが、全てを厳密に守ることが難しい場合もあります。判断のポイントは「何の障害に備えるか」という一点に集約されます。

同一データセンター内の障害に備えるならローカルバックアップで十分ですが、火災・水害・電源障害など施設全体の障害に備えるにはオフサイト保管が必要です。クラウド環境では、リージョン障害に備えて別リージョンへのレプリケーションが選択肢になります。ランサムウェア対策としてはオフライン（エアギャップ）保管が有効ですが、リストアにかかる時間が増えるトレードオフがあります。全ての障害シナリオに対応しようとすると設計が複雑化し、コストも工数も膨らみます。どのシナリオを優先するかを明確にした上で、分散の範囲を決めることが重要です。

コストと実現性のバランス

保存先分散はコストと実現性の観点からも判断が必要です。オフサイト保管にクラウドストレージを使う場合、データ転送コストと保存コストが発生します。大容量データを高頻度で転送するような設計は、コスト面で現実的でないことがあります。

現実的な落とし所は「クリティカルなデータのみオフサイト・フルバックアップはローカル」という分層設計です。システム全体を同一の基準でバックアップするのではなく、データの重要度に応じて保存先の数と場所を変える設計が効果的です。この分層の基準を設計フェーズで決めておくことが、後の運用を単純にする鍵になります。

「戻せること」を検証する設計（リストア訓練）

リストア訓練が設計の一部である理由

バックアップ設計の最も見落とされやすい要素が、リストア訓練です。訓練は「運用フェーズの仕事」として設計フェーズで後回しにされることが多いですが、これは設計上の誤りです。

訓練なしでは、バックアップが本当に機能するかどうかを確認する手段がありません。また、訓練を通じてはじめて発見される問題も多いです。リストア手順の不備・担当者不在時の対応・リストア完了の確認方法・切り替え後の動作検証など、設計段階では見えなかった問題が訓練で表面化します。設計フェーズでリストア訓練のスケジュールと手順を定義し、本番稼働前に少なくとも1回の訓練を実施することが望ましいです。

訓練の設計と実施頻度

リストア訓練を設計する際は、まず「どの障害シナリオを再現するか」を決めます。全シナリオを訓練するのは現実的でないため、発生可能性が高いシナリオと、発生時のビジネス影響が最も大きいシナリオを優先して選びます。

次に実施頻度です。環境変更（システム更新・インフラ変更・担当者交代）があるたびに実施することが理想ですが、少なくとも年2回を基準とする環境が多いです。担当者が交代してから半年後に訓練を実施して初めて手順が引き継げていないことが判明する、という話は現場でよく聞きます。インフラ担当が3名以下のチームでは、特定の担当者に手順が集中しやすく、訓練を通じた手順の分散が特に重要になります。

訓練で発見される典型的な問題

訓練で発見される問題には一定のパターンがあります。手順書と実際の環境の差異・バックアップファイルの場所や認証情報の管理場所が文書化されていない・リストア中に別システムへの影響が発生する・リストア後の整合性確認が不十分でデータ破損が後から発覚するといった問題が代表的です。

これらの問題を訓練なしで本番障害時に初めて直面した場合、対応に通常の数倍の時間を要します。訓練は「問題を安全に発見するための機会」として設計に組み込み、発見した問題を手順書に反映して次の訓練で解消を確認するサイクルを回すことで、バックアップ設計は継続的に改善されていきます。

やりすぎ・足りないの境界の見極め

「全部取る」が引き起こす問題

バックアップは多いほど安全だと考えがちですが、過剰なバックアップ設計は別の問題を生みます。設計の複雑化が、結果として「戻せない」状況を招くことがあります。

全ディスクを毎時間フルバックアップするような設計は、ストレージを圧迫し、ネットワーク帯域を消費し、バックアップ処理がシステムのパフォーマンスに影響を与えることがあります。また、管理する世代・ファイル・ストレージが増えるほど、リストア時にどのバックアップを使うかの判断が複雑になります。結果として「バックアップはある」が「どれを使えばよいか分からない」という状況が生まれます。過剰設計はコストだけでなく、運用の複雑さを通じた人的ミスのリスクも高めます。

システムの重要度でグレードを分ける

バックアップ設計を効率化する有効な方法は、システムを重要度でグレード分けし、グレードごとに異なる基準を適用することです。

たとえば、グレードAの基幹業務システムにはRPO=1時間・RTO=2時間・世代30日・オフサイト保管、グレードBの社内業務システムにはRPO=24時間・RTO=8時間・世代7日・ローカル保管、グレードCの開発・検証環境にはRPO=1週間・RTO=翌営業日・世代3日・ローカル保管という形です。管理する環境数が20を超えるような組織では、全環境を同一基準でバックアップしようとすると設計・運用コストが大きく膨らみます。このグレード分けが現実的な判断基準として機能します。

判断の基準をどこに置くか

「やりすぎ」と「足りない」の境界は、「そのシステムが停止した場合に何が失われるか」から逆算して決めます。金銭的損失・サービス停止影響・規制上の要件・データの再現不可能性の観点で評価し、各システムが本当に必要とするバックアップの水準を定義します。

設計時に「最悪のシナリオ」を一度明示的に書き出すことが有効です。障害が発生し、バックアップが使えなかった場合に何が起きるかを具体化することで、必要なバックアップの最低水準が明確になります。この最低水準を定義してから、コストと運用負荷を考慮して上方に調整する手順が、「足りない」を防ぎながら「やりすぎ」を抑える設計アプローチになります。

バックアップ設計チェックリスト

以下のチェックリストを設計・実装・運用の各フェーズで活用し、「戻せる構築」になっているかを確認します。手を動かす前の確認には向きませんが、設計判断の抜け漏れを防ぐための軸として使えます。

設計フェーズ

• 守る対象（データ・構成・状態）を分類し、それぞれの重要度を定義した
• システムの重要度グレードを定め、グレード別のRPO/RTO目標値を関係者と合意した
• 想定する障害シナリオ（誤操作・ストレージ障害・ランサムウェア等）を明記した
• リストア操作の実施者と必要な権限・アクセス手段を定義した
• リストア設計（手順・所要時間・確認方法）をバックアップ取得設計より先に定めた

実装フェーズ

• 世代数の根拠（問題検知遅延・ビジネス要件）を試算し、ストレージ容量と照らし合わせた
• 保存先分散の範囲と優先する障害シナリオを対応させ、3-2-1ルールの適用判断を文書化した
• データ・構成・状態それぞれのバックアップ手段を実装した
• バックアップの整合性（同一時点のデータと構成）を確保する仕組みを組み込んだ
• バックアップの取得成否・世代数・ストレージ残量を確認する監視を設定した

運用フェーズ

• リストア訓練のスケジュールを定め、本番稼働前に少なくとも1回実施した
• 訓練で発見した問題を手順書に反映し、次回訓練で解消を確認するサイクルを設けた
• 担当者交代・環境変更のタイミングで訓練を再実施する判断基準を設けた
• システムグレードの見直し（新サービス追加・廃止・重要度変化）を定期的に行う体制がある