バックアップ戦略とBCP対策

RPO/RTOを数字で決めるところから始める

「バックアップはある」ではBCPになりません。復旧点目標（RPO）と復旧時間目標（RTO）を業務単位で決め、投資と運用負荷のバランスを取ることが出発点です。売上に直結するAPIはRPO 5分/RTO 30分、社内ポータルはRPO 24時間/RTO 翌営業日、のように層別化します。SLAや商取引上のペナルティも併せて棚卸しすると、どこにコストを掛けるべきかが明確になります。

意思決定の目安として、RTO短縮はお金（二重化・ホットスタンバイ）で、RPO短縮は頻度（ジャーナルやログ送信）で買う、という整理が有効です。RTO 15分を求めるなら代替系の常時起動や自動フェイルオーバー、RPO 5分を求めるならデータベースのログシッピングや継続レプリケーションが必要です。逆に「月1回のレポート生成」は週次フル＋日次増分で十分、など線引きを言語化しましょう。

3-2-1-1-0を現場実装する具体

定石の「3-2-1-1-0（3つのコピー、2種類の媒体、1つはオフサイト、1つはイミュータブル/オフライン、検証エラー0）」を、インフラに落とすと次のようになります。

バックアップ種別と頻度

• スナップショット：ブロック/VM単位。主要システムは15分間隔、保持7〜30日。
• アプリケーション一貫性：DBはクエンスフリーズやトランザクションログを活用。フル週1、増分日1、ログ5分。
• イメージ/設定：IaCとOSイメージを別系統で保管。リポジトリもバックアップ対象に。
• SaaSデータ：M365やG Suiteは誤消去に備え外部バックアップを。エクスポート＋別クラウド保管が最低限。

変更不可化と鍵管理

• イミュータブル：オブジェクトストレージのWORM（例：Object Lock）で7〜90日。重要ログは365日。
• オフサイト：異リージョン/別クラウドへ非同期複製。レイテンシと越境規制に注意。
• 暗号化：転送/保存の双方。鍵はKMSでローテーション、DRサイト用にエクスポートしたキーは金庫＋分割管理。
• ネットワーク分離：バックアップ用ネットワークとアカウントを本番から分離。ラテラルムーブメント対策になります。

復旧テストと自動検証

• チェックサム検証：取得直後に全ファイルのハッシュを検証、ジョブが長期化したら異常検知。
• サンドボックス復元：毎月、代表ワークロードを隔離環境へ自動復元しアプリの起動確認まで行う。
• RTO/RPOの計測：復旧所要時間と最終バックアップ時刻を記録、目標未達は原因をチケット化。

運用ドキュメントはテンプレ化して更新を自動化します。手順書の雛形やスクリプトの雛形作成にはChatGPTやClaude、Geminiが下書き支援として便利です。バックアップ・リストアのスクリプト化はGitHub Copilotでの補完も効率化につながりますが、最終的な検証と承認は必ず人が行う前提が安全です。

BCP運用に落とす：訓練・連絡・代替プロセス

BCPは紙では動きません。四半期ごとに「想定インシデント×優先系」のテーブルトップ演習、半年ごとに無停止切替と計画停止復旧の2種類の訓練を回します。訓練のゴールは「誰が・何分で・どの順で」行うかの明文化と、意思決定の短縮です。

連絡網は多経路化します。社内チャット＋SMS＋音声ダイヤルの三段構え、通信断に備え印刷版も用意。意思決定者の代行権限は文書化し、決裁を待たない初動条件（例：監視でランサム挙動を検知後5分以内にスナップショット隔離）を定義します。加えて、重要依存関係（DNS、IdP、メール、決済）の代替手段を列挙し、切替手順をRunbookとして整備します。

身近な企業活用例：EC中小の失敗と改善

NASへ夜間バックアップのみを行っていたEC企業が、ある日、社内端末からのランサム攻撃でNASごと暗号化、受注DBの復旧に48時間を要し機会損失が発生しました。原因は（1）同一ネットワーク上での保管、（2）検証未実施、（3）RPO/RTOの未定義。改善として、RPO 15分/RTO 1時間を設定し、DBログ5分送信、アプリ整合スナップショット15分、WORM 30日を導入。週1でオフサイトに暗号化レプリカ、毎月の自動サンドボックス復元で起動確認まで実行。監視にはバックアップ成功率98％未満でアラート、ジョブ時間が基準±30％を超えたら要調査、という閾値を設定。結果、受注ピーク時の障害でも35分で復旧、欠損は10分未満に収まりました。

監視運用と一体化して継続改善

バックアップ/BCPは監視運用と切り離せません。ジョブの成功率、転送スループット、重複排除率、ストレージ消費、WORMポリシー残日数、鍵の有効期限は監視項目にします。変更検知（ポリシー削除・保持期間短縮）や復元テストの未実施もアラート対象です。障害時はメトリクスから復旧優先度を即時に引き当て、Runbookへ自動リンクさせると初動が早まります。

さらに、監視データを用いたポストモーテムで「どの層がRTO達成を阻害したか」を定量評価し、次回の投資判断へ反映します。例えば、転送帯域がボトルネックなら夜間ウィンドウの再設計や増速、ストレージが律速なら圧縮・重複排除のパラメータ見直し、といった具体策が出ます。ドキュメント更新はAI下書き（ChatGPT/Claude/Gemini）＋人のレビューでタイムリーに回すと、手順の陳腐化を防げます。

こうした「計測→検証→訓練→改善」のサイクルは、日々の死活・リソース・ログ監視と同じ運用リズムで回すのが最も自然です。サーバ監視運用事業の現場では、バックアップの成否や復元テストの結果も一次指標として常時可視化し、障害と同列に扱うことで、BCPの実効性が着実に高まります。