backup-and-disaster-recovery

バックアップと災害復旧

最悪の事態に備えましょう。データベースが消失する、ホストが1週間停止する、デプロイに不正なコードが混入する、ランサムウェアですべてが暗号化される。重要なのは、事前の準備であり、事後の対応ではありません。

---

使用する場面

• 新しいシステムのバックアップを設定するとき
• バックアップアーキテクチャを見直し、検証するとき
• RPO（目標復旧時点）とRTO（目標復旧時間）を定義するとき
• 災害復旧訓練を実施するとき
• インシデント後に不足点を診断するとき
• ランサムウェア、データ破損、内部脅威に備えるとき
• 新しいプラットフォームに移行するとき（災害復旧計画は移行計画に含めます）

使用しない場面

• インシデント対応の最中（incident-responseを使用します）
• 通常のデプロイのロールバック（launch-runbookを使用します）
• コードやコンテンツのバージョン管理（Git、CMSの改訂履歴で対応します）
• 通常のデータベースのスナップショット取得（設定にはこのスキルを使用し、定期的な確認は監視の一環として行います）

---

必要な入力情報

• 対象範囲のシステム（データベース、ファイルストレージ、コード、設定、シークレット）
• ホスティングプラットフォームとプロバイダー
• 既存のバックアップツールと、その対象範囲
• 許容できるデータ損失（時間）
• 許容できるダウンタイム（時間）
• コンプライアンス要件（一部の規制では、特定のバックアップ基準が義務付けられています）

---

フレームワーク：4つの質問

災害復旧計画では、4つの質問すべてに明確に答えます。

質問1：何を復旧可能にする必要がありますか？

状態を保持するすべてのシステムを列挙し、重要度別に分類します。

ティア1：必ず復旧する。 これがなければ事業が停止します。（顧客データベース、トランザクションログ、主要コンテンツストア）

ティア2：復旧すべき。 失うと大きな痛手ですが、致命的ではありません。（分析データ、ログ、二次サービス）

ティア3：復旧できると望ましい。 簡単に再構築できます。（キャッシュ、派生データ、一時的な状態）

このティアによって、RPO、RTO、バックアップ頻度、ストレージ費用が決まります。

質問2：どの程度のデータ損失を許容できますか？（RPO）

RPOとは、許容できるデータ損失の最大期間です。

• RPO＝1時間：1時間ごとのバックアップ、または継続的なレプリケーションが必要です
• RPO＝1日：毎日のバックアップで許容できます
• RPO＝1週間：毎週のバックアップで許容できます

ほとんどの本番データでは、RPOを1時間以下にすることを目標とします。重要な金融システムでは、RPOをほぼゼロにします（継続的なレプリケーション）。

派生データや再構築可能なデータであれば、RPOが1日以上でも問題ありません。

質問3：どの程度のダウンタイムを許容できますか？（RTO）

RTOとは、災害発生後にサービスを復旧するまでの最大時間です。

RTOの目標	必要となる対応
5分未満	自動フェイルオーバー機能を備えたホットスタンバイ
1時間未満	手動フェイルオーバーが可能なウォームスタンバイ、または最新のスナップショットからの高速復元
24時間未満	復元手順を文書化したコールドバックアップ
数日から数週間	可能な範囲で対応し、長期のダウンタイムを許容

RTOによってアーキテクチャの費用が決まります。厳しいRTO（1時間未満）には費用がかかります。緩やかなRTO（数日）であれば低コストです。

質問4：どのような災害を想定しますか？

具体的なシナリオを想定して計画します。それぞれに必要な対策は異なります。

ハードウェア障害。 ディスクが故障します。標準的なバックアップで対処できます。最新のホストの多くは自動的に対応します。

プロバイダーの停止。 リージョンまたはベンダーが停止します。RTOを短くするには、リージョン間またはプロバイダー間の冗長化が必要です。

データ破損。 移行の失敗、バグ、誤削除などです。特定の時点への復元が必要です。最新のバックアップも破損している可能性があるため、過去の履歴が必要です。

ランサムウェアまたは侵害。 攻撃者がデータを暗号化または削除します。バックアップは変更不可にするか、エアギャップで隔離する必要があります。そうでなければ、攻撃者はバックアップも破壊します。

アカウントの侵害。 攻撃者が管理者の認証情報を入手し、すべてを削除します。対策はランサムウェアの場合と同じです。変更不可のバックアップと、分離されたアクセス制御が必要です。

ベンダーからの締め出し。 アカウントの停止、請求をめぐる紛争、ベンダーの消滅などです。ベンダーの管理下にないバックアップが必要です。

内部脅威。 不満を持つ従業員がデータを削除または持ち出します。監査ログ、職務の分離、変更不可のバックアップが必要です。

ハードウェア障害だけに対処するバックアップ戦略は、戦略とは呼べません。それは最も簡単なケースに対応しているだけです。

---

ワークフロー

ステップ 1：状態を持つシステムを洗い出す

状態を保持するすべてのシステムをリストにします。

システム	データの種類	ティア	現在のバックアップ	テスト済み？

リストにできなければ、保護することもできません。多くの場合、洗い出しをするだけで抜け漏れが見つかります（「あのデータベースのことを忘れていた」という瞬間です）。

ステップ 2：ティアごとに RPO と RTO を設定する

各ティアについて、RPO と RTO に合意します。災害の影響を受ける人々から承認を得てください。

インフラへの投資で裏付けられていない、希望的な目標には異議を唱えましょう。ホットスタンバイのないシステムで RTO を 5 分とするのは現実的ではありません。

ステップ 3：バックアップアーキテクチャを検証または設計する

各システムについて、次の項目を確認します。

• 頻度が RPO に合っていること。
• 保持期間がポイントインタイムリカバリをカバーしていること（本番データでは通常 30 日以上）。
• 保存場所がソースとは別であること。同じディスク、同じアカウント、同じリージョンでは不十分です。
• 少なくとも一部のバックアップコピーに不変性または WORM ストレージを採用すること。ランサムウェアへの対策になります。
• 保存時の暗号化を行うこと。コンプライアンス上の標準です。
• 復元手順をテスト済みであること。テストされていないバックアップは、バックアップとは言えません。

「3-2-1 ルール」は、出発点として役立ちます。データのコピーを 3 つ、異なる種類のストレージを 2 つ、オフサイト（または別のアカウント、別のプラットフォーム）に 1 つ用意します。

ステップ 4：復元ランブックを文書化する

各システムについて、ランブックを作成します。

1. 災害の検知方法（監視の項目を相互参照）
2. 復元を決定する方法（判断基準、承認者）
3. 正確な復元手順（コマンド、スクリーンショット、順序）
4. 復元が正常に機能したことを確認する方法
5. トラフィックを戻す方法
6. コミュニケーション用テンプレート（ステータスページ、顧客への通知）

ランブックが必要になるのは、誰かのキャリアで最悪の夜です。疲れ果てて、パニック状態の自分でも使えるように書いてください。

ステップ 5：訓練を実施する

初めての復元を、本当の災害時に行ってはいけません。

訓練には、次のような方法があります。

• 机上演習： 紙上でランブックの手順を確認します。計画の抜け漏れを見つけるのに役立ちます。
• 部分訓練： 本番以外の環境に復元します。データを確認し、手順を検証します。
• 全面訓練： 災害をシミュレーションします。本番環境へのフェイルオーバー、または全面的な復元を行います。信頼性は最大になりますが、リスクも最大です。

多くのチームでは、四半期ごとに机上演習を行い、年 1 回の部分訓練を実施し、大規模リリースの前やアーキテクチャの大幅な変更後に全面訓練を行います。

ステップ 6：訓練の結果を文書化する

訓練のたびに、次の内容を記録します。

• テストした内容
• うまくいったこと
• 問題が発生したこと
• 実際の RPO と RTO（目標値との比較）
• アクションアイテム

目標が 1 時間だったのに、実際の RTO が 6 時間なら、その目標は絵に描いた餅です。ギャップを解消するか、目標を見直してください。

ステップ 7：次回の訓練を予定する

カレンダーに登録し、担当者を割り当てます。訓練されないバックアップは、徐々に役に立たなくなっていきます。

---

特別なトピック

データベースのポイントインタイムリカバリ

多くのマネージドデータベースは、保持期間内（多くの場合 7～35 日）のポイントインタイムリカバリ（PITR）を提供しています。通常、これにより RPO を数秒から数分にできます。

より長期間保持するには、不変ストレージへの定期的なエクスポートをスケジュールします。

PITR だけでは不十分です。データベースサービス自体が侵害された場合、PITR も使えなくなります。必ず、ソースサービスの外部に少なくとも 1 つのバックアップを用意してください。

ファイルストレージのバックアップ

オブジェクトストア（S3、GCS、Azure Blob）では、通常、次の機能を利用できます。

• バージョニング（上書きされたオブジェクトを復元）
• レプリケーション（クロスリージョン）
• オブジェクトロックまたは不変性（削除への対策）

本番環境に不可欠なバケットでは、この 3 つすべてを設定してください。ストレージプロバイダーのデフォルトの保持期間に頼ってはいけません。

コードと設定のバックアップ

コードは Git に保存されています。Git ホスト（GitHub、GitLab など）がバックアップになりますが、ホストが 1 つだけなら、単一障害点も 1 つだけです。

重要度の高いコードについては、次の対応を行います。

• 2 つ目のホスト、または自社サーバーにミラーリングする
• オフラインエクスポートを定期的に行う

設定とシークレットには、別途対応が必要です。

• Infrastructure-as-code：Git に保存し、ミラーリングする
• ランタイム設定：システムと併せてバックアップする
• シークレット：独自のバックアップ方法を備えたシークレットマネージャーに保存する

バックアップのバックアップ

バックアップシステム自体が故障する可能性があります。バックアップのメタデータ、バックアップ認証情報、暗号化キーは、すべてバックアップする必要があります。

紛失したキーでバックアップが暗号化されている場合、そのバックアップは役に立ちません。

コンプライアンス対応のバックアップ

規制によっては、特定の保持期間が求められます（例：財務データは7年間）。適用される基準のうち、最も厳しいものに準拠してください。

コンプライアンス上の保持と運用上のバックアップを混同しないでください。コンプライアンス対応では、復元にかなり時間がかかっても許容されることがよくあります（最終的にデータを提出できれば十分です）。

---

障害パターン

テストされていないバックアップ。 最もよくある失敗です。バックアップは正常に動作しているように見えても、復元に失敗します。テストしてください。

ソースと同じアカウントまたはリージョンにあるバックアップ。 アカウントの侵害やリージョンの停止により、両方が失われます。

イミュータビリティがない。 ランサムウェアによってバックアップも暗号化されます。オブジェクトロックまたはエアギャップストレージを使用してください。

測定されていないRTOとRPO。 目標は「1時間」でも、実際のRTOを誰も検証していません。実証されるまでは、実際の所要時間は目標より長いと想定してください。

復元手順書が誰かの頭の中にしかない。 その人が退職したり、対応できなくなったりすると、手順書は失われます。文書化してください。

バックアップはあってもDR計画がない。 「バックアップがある」だけでは計画とは言えません。計画とは、手順書、アーキテクチャ、そして訓練を組み合わせたものです。

楽観バイアス。 「自分たちには起きない」と考えることです。実際に起きます。起きることを前提に計画してください。

バックアップが古すぎる、または新しすぎる。 破損がすぐに発見されない場合に備え、特定の時点に戻れる履歴が必要です。30日以上保持する日次スナップショットを使用してください。または、継続的レプリケーションと、履歴用の定期的な別スナップショットを併用してください。

「忙しいから」と訓練を先延ばしにすること。 災害時には、さらに忙しくなります。

コミュニケーション計画がない。 データの復元は作業の半分です。顧客、関係者、社内チームに状況を伝えることが、もう半分です。

---

出力形式

DR計画書には、次の内容を含めます。

• インベントリ： 状態を保持するすべてのシステム
• 階層化： システムごとの重要度
• 目標： 階層ごとのRPOとRTO
• アーキテクチャ： バックアップツール、頻度、ストレージ、イミュータビリティ
• 手順書： システムごとの復元手順
• 訓練スケジュール： テストする内容と時期
• 訓練記録： 過去の訓練結果
• コミュニケーションテンプレート： 実際のDR事象発生時に伝える内容

---

参考ファイル

• references/restore-runbook-template.md：検知、承認、手順、検証、ロールバックを網羅した、復元手順書用の記入式テンプレート