バックアップやDRを計画する際に意識するべきことをまとめてみた
2025.05.19そのバックアップ、ちゃんと活用できているか不安だな
こんにちは、のんピ(@non____97)です。
皆さんは「そのバックアップ、ちゃんと活用できているか不安だな」と感じたことはありますか? 私はあります。
とりあえずバックアップだけ取っているという環境はよくあると思います。そのようなバックアップはコストだけかかっており、トラブル時に実際に役立つものとは限りません。
それでは非常にもったいないです。
ということで、バックアップやDRを計画する際に意識するべきことをまとめてみます。
自分の中でも普段バックアップやDRを計画する際に意識していることは言語化できていなかったので、整理する意味合いでもまとめました。
計画フェーズ
バックアップやDRをする目的の設定
まずは、バックアップやDRをする目的の設定をしましょう。
この目的を設定することが一番重要です。
一般的にバックアップやDRは、データのロストや業務の継続性向上に対する対応となります。さらに具体的にどのようなリスク、脅威に備えるのかという背景を踏まえて整理すると良いでしょう。
目的がブレると実装もブレてしまい、目的の達成が難しくなってしまいます。
例えば、ランサムウェア対策なのであればWORM機能を導入する必要があるでしょうし、業務継続性向上であればDR先で業務継続できるような環境をスタンバイする必要があるでしょう。
逆にバックアップデータの物理的な破損からのデータの保護が主であるならば、数分レベルの短期間の復旧を目指さないでしょう。また、リージョン障害時に別リージョンでの業務継続を行う必要がないのであれば別リージョンへのバックアップデータの転送のみで済むでしょう。
AWSにおけるDR対策は以下AWS BlogsとAWS公式ドキュメントが分かりやすいです。
目的を定める際には、その理由と背景も明確にしましょう。目的に対して表面的な対応をしていくと、後から「思っていたのと何か違う」となりがちです。目的設定の理由と背景もプロジェクトメンバーに周知しましょう。
繰り返しますが、目的の設定が一番大事です。
障害シナリオごとのRTO/RPO/RLOと前提、優先度の定義
続いて、障害シナリオごとのRTO/RPO/RLOと前提、優先度の定義をします。
RTO/RPO/RLOそれぞれの説明と影響する要素は以下のとおりです。
| 項目 | 説明 | 影響する要素 |
|---|---|---|
| RTO (目標復旧時間) | 障害発生時から何時間以内に正常動作させる必要があるか | - リストアやDR環境へのフェイルオーバー方法 - 意思決定のフロー - 実装およびランニングコスト |
| RPO (目標復旧時点) | 障害発生時から何時間前までの状態に戻す必要があるか | - バックアップ取得間隔 - バックアップの取得方法 - バックアップの転送方法 - 実装およびランニングコスト |
| RLO (目標復旧レベル) | 障害発生時にRTOで定義された時間内にどの程度まで復旧させる必要があるか | - バックアップ取得間隔 - バックアップの取得方法 - バックアップの転送方法 - リストアやDR環境へのフェイルオーバー方法 - 意思決定のフロー - リストアやDR環境へのフェイルオーバーの優先度 - 実装およびランニングコスト |
定義したRTO/RPO/RLOによって取るべき対応は大きく変わってきます。早めに決定しましょう。
決定する際にはいずれも実装/ランニングコストや複雑性とトレードオフになることを意識、周知しましょう。無邪気に「RTO/RPOは0！ RLOは全てのシステムで平常時の100%の処理を捌き切れる状態！」としても現実的には難しいでしょう。各種要素とのバランスを見ながら現実的な落とし所を探っていきましょう。
定義した際の前提も決めておくと安心です。定義したタイミングでのデータ量やファイル数ではRTO/RPO/RLOが遵守できていたのに、利用が進むにつれて規模も大きくなり、RTO/RPO/RLOは遵守できなくなっていたというのはあるあるだと思います。前提を決めておくと、運用の中で前提が崩れている or 崩れつづあることに気づきやすくなります。
複数システムがある場合は復旧の優先度を付けておくことも必要です。全て人力で復旧させる場合にはシビアなRTOを達成させることは非常に困難です。
また、障害の範囲によって取るべき対応や許容できるレベルは異なります。インフラ周りの障害の範囲は例えば、以下のようなものがあります。
- ノード障害
- AZ障害 (データプレーン/コントロールプレーン)
- リージョン障害 (データプレーン/コントロールプレーン)
- グローバルサービス障害
例えば、リージョン全体の障害発生と比べて単一のインスタンス障害の頻度は比較的高いと考えます。そのような比較的高頻度な事象について、毎回復旧時間が長くなってしまうと業務影響的に看過できないでしょう。
一方でリージョン全体障害については、他システムとの優先度の兼ね合いや人的リソースの確保の観点からRTOは長めにせざるを得ないでしょう。発生可能性が低い事象に対してシビアなRTO/RPO/RLOを求めるのはコスト的にアンマッチなケースが多いことがほとんどです。
なお、インフラ周り以外でも以下も障害と言えます。
- データの誤削除
- データ間の整合性の不一致
- パフォーマンスの低下
- ビジネスロジックの不具合
- 不正アクセスによるトラブル
これらはバックアップからのリストアやDR環境へのフェイルオーバーは行わない事象もあるでしょう。処理をリランしたり、旧バージョンへロールバックすることで対応するものもあります。
全部のパターンについて全て整理することは工数的にもスケジュール的にも現実的には難しいと思います。そのため、まずは考えられる障害シナリオを一旦洗い出し、発生可能性が高いものや発生した場合の業務影響が大きいもの、自社や業界のポリシーで定められているものから優先的に整理していくと良いでしょう。
その中で各障害シナリオの一対策としてバックアップやDRを行うことになります。
なお、バックアップやDRをする場合は静的安定性について意識しましょう。
コントロールプレーンの障害によってAWSのAPIの受付が正常に受け付けられないことがあります。そのような状況でEC2インスタンスが破損してしまった時の対応として「日次で取得しているAMIからEC2インスタンスをリストアする」だと、EC2インスタンスを起動するためのAPIを実行できずリストアが出来ないことがあります。
このように障害シナリオによってはバックアップからのリストアやDR環境へのフェイルオーバーといったリアクティブな対応は行えない可能性があります。その障害シナリオに直面した場合に確かに復旧できる or 耐障害性がある対策を検討しましょう。
コントロールプレーンやデータプレーン、静的安定性は以下記事が参考になります。
リストアやDR発動の基準の定義
リストアやDR発動の基準の定義をします。
バックアップやDR環境はお守りではく。リストアやDR環境へフェイルオーバーするためのデータや環境です。リストアやDR環境へフェイルオーバーができて初めて効果を発揮します。
では、リストアやDR環境へフェイルオーバーはいつ行うのでしょうか。そのためには基準が必要です。
1分でもEC2インスタンスに接続できなくなった場合でしょうか? それともAWS Health Dashboardに影響のあるリソースとしてリストアップされている場合でしょうか? はたまた再起動を3回程度繰り返しても、業務復旧できない場合でしょうか。
リストアやDR環境へのフェイルオーバーの作業は大抵大掛かりで、非常に神経を使う作業です。可能な限り行いたくない作業でしょう。
しかし、基準が定義されていなければ、実はすぐ基盤側が復旧し、何もしなくとも復旧できたものに対して大掛かりな作業をしてしまうことになります。一方で、基準が定義されていないことによって、意思決定に非常に時間がかかってしまい、RTOを満たすことができないこともあるでしょう。
意外とリストアやDR環境へフェイルオーバーをする基準が定義されていないケースは多いのではないでしょうか。
網羅的に用意することは非常に難しいですが、発生した事象と、それに対応する一次対応を整理しておき、それでもNGであればリストアやフェイルオーバーをするようなフローにしておくと良いでしょう。
明確な基準が定義されているのであれば、処理の自動化も行えるでしょう。
リストアやDR時の関連システムへの影響整理
リストアやDR時の関連システムへの影響も整理します。
その環境のリストアやDR環境へフェイルオーバーをして終わりではありません。関連システムがあるのであれば、少なからず何かしらの影響があるでしょう。関係性によっては関連システムが異常であると、そもそもリストアやDR環境にフェイルオーバーしても業務継続できないことがあります。
システム間で何のためにどのような処理をしているか、その処理が止まった場合はどのような事象が発生するのか、などと影響範囲や影響度合いを事前に整理しておきます。
場合によってはDR環境にフェイルオーバーする場合は、関連システムとの連携を切って運転を行うこともあります。
リストアやDR時のビジネス上の影響整理
ビジネス上の影響も整理します。
パフォーマンスやコスト影響、RTOが0で復旧できるのことがほとんどないでしょう。
ビジネス側を握っているメンバーにも確認して、ビジネス上の影響度合いと要望を整理しましょう。場合によってはRTO/RPO/RLOの調整が必要になることもあります。
リストアやDR発動の意思決定、連絡フローの定義
リストアやDR環境へのフェルオーバーが必要な場合、現場は慌てているでしょう。
そのような場合に備えて意思決定や状況報告などの連絡フローを定義しておきましょう。RTOがシビアな場合は特に重要です。
なお、天災による広域障害の場合は業務連絡ができないことがあります。場合によっては意思決定者やコアメンバー、実際のDR作業者が特定地域に一箇所に集中していると、そもそも復旧させることができないこともあるでしょう。
そのような場面においてはシステム利用者もシステムを利用できる状況ではないことが多いことから、「早期に復旧させたとしても、ほとんどのシステム利用者はシステムを利用できる状況ではないと判断し、先に決定したRTOを見直す」とすることもあります。使われもしないのに無理に急いで復旧させる必要性は低いという発想です。
このような場合には「体制的にそもそも現実的ではないよね」とマルチリージョンを用いたDRを諦めたりすることもあるので、早めに確認しておきたいです。
仮にそのような場合でも対応が必要な場合では、複数の地域に人員と業務をできる環境を配置しましょう。連絡手段についても障害発生時に備えて、一つだけではなく複数準備しておくと安心です。
DR環境で業務継続するための必要要素の整理
DR環境へフェイルオーバーし、システムを稼働させても実際に利用者が接続できなければ意味がありません。
ネットワーク的な経路の確立や、名前解決や認証が行えることも確認するべきです。
例えば、以下のような東京リージョンをプライマリリージョン、大阪リージョンをDR用のセカンダリリージョンでシステムを稼働させている構成を考えます。
この時、関東広域で大規模な天災があり、東京リージョン全体や東京のDirect Connectロケーションが全滅したとします。こうなると、仮に大阪リージョンへフェイルオーバーしたとしても、ネットワーク的な経路が確立されていないため、大阪リージョンに接続することができません。
また、Direct Connectロケーションの被害は免れたとしても、DNSサーバーおよび認証基盤として使用しているAD DCがSPOFになっているのであれば、大阪リージョンで業務継続することはできません。
DR環境で業務継続するための必要要素の整理し、定めた障害シナリオに対して復旧するために必要な準備を明らかにしましょう。先ほどの例であれば以下のような対応が挙げられます。
- Direct Connectロケーションを複数用意する
- WANを介すなど、Direct Connectロケーションと接続している拠点を複数用意する
- AD DCを各リージョンに配置する
リストアやDR時の粒度の決定
リストアやDR環境へのフェイルオーバーをする際に、どの粒度で行うのか整理しましょう。
粒度によって復旧のさせ方が変わります。
例えば粒度としては以下のようなものが挙げられます。
- ファイルシステムレベル
- ファイル
- ディレクトリ
- ストレージレベル
- ボリューム
- イメージ/スナップショット
- DBレベル
- トランザクション
- テーブル
- スキーマ
- DB
- インフラレベル
- AZ
- リージョン
- システムレベル
- 特定システム
- 全システム
個別ファイル単位でリストアしたいのに都度イメージからリストアするのは手間だったりします。
リストアやDRの粒度によってバックアップやフェイルオーバーのさせ方が大きく変わります。早めに確認しておきたいところです。
DR環境からフェイルバックする場面の定義
DRする場合、いずれフェイルバックするでしょう。
「リストアやDR発動の基準の定義」のように、フェイルバックをするタイミングについても事前に定義しておくと、後々フェイルバックする際に意思決定がスムーズです。
設計・実装フェーズ
フル/差分/増分/合成/永久増分バックアップの実現性確認
バックアップの取得方法はおおよそ以下のように分類できます。
| バックアップタイプ | データ | バックアップ速度 | ストレージ容量 | 復元速度 |
|---|---|---|---|---|
| アクティブフルバックアップ | すべてのデータをコピーします。 | 遅いです。 | 充実しています。 | 速いです。 |
| 増分バックアップ | 前回のバックアップ以降に変更されたデータのみをコピーします。 | 差分バックアップより速いです。 | 差分バックアップよりも小さいです。 | フルバックアップとすべての増分バックアップが必要なため、他方よりも遅いです。 |
| 差分バックアップ | 前回のフルバックアップ以降に変更されたデータをコピーします。 | 増分バックアップよりは遅いが、アクティブフルバックアップよりは速いです。 | 特に後続のバックアップではサイズが大きくなります。 | フルおよび最後の差分だけが必要なため、増分バックアップよりも高速です。 |
| 合成フルバックアップ | 変更されたデータを段階的にコピーしますが、変更を前回のフルバックアップと統合して、合成フルバックアップを作成します。 | 増分変更のみをコピーするので、アクティブフルよりも高速です。 | アクティブフルとほぼ同じストレージです。 | アクティブフルに似ています。 |
| 永久増分バックアップ | フルを 1 つ作成し、続けて (永久的に) 増分を作成します。 | 後続のフルバックアップを作成しないため、合成フルバックアップよりも高速です。 | アクティブフルや合成フルよりも場所を取りません。 | アクティブフルや合成フルよりも早く修復できます。 |
抜粋 : 増分バックアップと差分バックアップ - データバックアップ戦略間の違い - AWS
EBSスナップショットについては合成バックアップや永久増分バックアップに近いかなと思います。
どのバックアップ手法を選択するかで、取得時間やリストア時間、リストア手法、データ転送時間、ストレージコストが変動します。選択しようとしているものを実現する手立てがあるのか整理しましょう。
パイロットライトでバックアップデータをコピーする場合は、そのコピーがフルか増分かも意識しましょう。
EBSスナップショットであれば、転送済みEBSスナップショットとの増分です。
Auroraの場合は常にフルコピーです。
バックアップデータ内の整合性の合意
バックアップデータ内の整合性の取り方についても意識しましょう。
整合性は以下の3種類に大別されます。
| 特性 | クラッシュ整合性 | ファイルシステム整合性 | アプリケーション整合性 |
|---|---|---|---|
| 定義 | システムが突然停止した状態と同等の整合性がある状態 | ファイルシステムのメタデータとデータの整合性が取れた状態 | アプリケーションの観点で完全に一貫性のある状態 メモリ上のキャッシュ、実行中/保留中のトランザクションも正常に完了 |
| 取得方法例 | - ストレージのオンラインスナップショット | ファイルシステムのI/O一時停止 | - VSS - アプリケーションに対応したバックアップソフト |
| メリット | - システムへの影響が小さい - 特別なツールが不要 |
- ファイルシステムレベルの破損がない | - 復元後すぐに使用可能 - データ損失なし |
| デメリット | - 復元後にリカバリ処理が必要な場合がある - データ損失の可能性あり - アプリケーション整合性は保証されない |
- アプリケーションレベルの整合性は保証されない - 一時的なI/O停止が必要 |
- アプリケーション一時停止が必要な場合あり - 専用のソフトが必要 - 実装が複雑 |
例えば、EC2インスタンスのバックアップをするためにAMIを取得することがありますが、再起動を伴わないAMI取得はクラッシュ整合性です。
ファイルシステム整合性を取るためにはIOを停止する = 再起動を行う必要があります。
リストア後に確実に業務継続できる状態にしたいのであれば、ファイルシステム整合性やアプリケーション整合性があるバックアップを取得する必要があります。
整合性は以下記事が参考になります。
バックアップ先やDR先の転送経路の帯域とレイテンシーの調査
ネットワーク上にバックアップデータを流す場合は、転送経路の帯域を圧迫しないか注意しましょう。
使っている回線の太さだけではなく、転送元から転送先のEnd-to-Endで確認をします。可能であれば負荷状況を見ながらiperfなどで計測すると良いでしょう。
転送の規模によっては専用の回線を用意することもあります。
また、ネットワーク越しにレプリケーションする場合、ネットワークレイテンシーが増大するとRTO/RPOにも影響します。併せて確認します。
バックアップの取得、転送にかかる時間の把握
大まかでも良いのでバックアップの取得、転送にかかる時間を把握しておきましょう。
RPOを短くするためにはバックアップデータの取得やDR環境へデータ転送する時間も重要です。
例えば、データ転送に時間がかかりすぎ、RPOを遵守できていないことがあります。データ量が多くない場合であったとしても、Robocopyやrsyncなどファイルを逐次差分チェックをして転送する場合はファイル数に比例して処理時間は長くなります。
事前検証として本番環境と同等のデータ量や複雑性だと、どの程度時間がかかるのか計測しておくと良いでしょう。結果によってはバックアップや転送の方法を見直したり、RTO/RLOの調整や要求の見直しから行うこともあります。
調整や検証には時間ベースのEBSスナップショットコピー機能やAWS Resilience Hubを利用するのも手です。
復旧にかかる時間の把握
RPOと同じくRTOを遵守するために大まかに復旧にかかる時間を事前に検証で確認しましょう。
個人的には検証で計測した時間にプラスαをして、少し悲観的に見ておくぐらいがちょうど良いです。
保持期間/保持世代数と管理方法の合意
保持期間/保持世代数と管理方法について合意しておきましょう。
まずはバックアップデータの保持期間/保持世代数を決めます。
例えば、毎時6世代、日次5世代、週次2世代とバックアップ取得間隔によって保持期間/保持世代数を決めます。
この際は意味のあるリストアかどうか意識しましょう。例えば、DBのスナップショットを1年間保持したとしても1年前のDBスナップショットからリストアして、そのまま運用するケースは非常に稀でしょう。あるとしたら特定データのサルベージでしょうか。
ランニングコストに跳ねる要素であるので、過剰な保持期間/保持世代数になっていないか注意しましょう。
保持期間/保持世代数が決まったら、どのようにして世代を管理するか整理します。
単純な日数や世代数であればバックアップツールやサービスで対応できることもあるでしょう。しかし、他要件との兼ね合いによっては何かツールを自作する必要があります。ツールを自作する場合、ロギングやリトライ処理やエラー通知なども考慮するとなかなか大変です。
実装コストに跳ねる要素でもあるので早めに確認しておくと安心です。
重複排除、圧縮の有無の合意
要件によってはストレージコスト削減のために重複排除、圧縮を求められることがあります。
こちらもバックアップツールやサービスで対応できることもあるでしょうが、自作は大変です。自作するとしてもgzipやzstdで圧縮するぐらいでしょうか。
なお、明確な要件が出てきていない中で「重複排除、圧縮は必要ですか?」とヒアリングすると「必要」と回答されがちです。トレードオフとなる要素についても併せて伝えましょう。
可能であればストレージやバックアップツールやサービスの機能を用いて対応しましょう。
なお、機能を利用する場合はCPUやメモリなどのインフラリソースへの影響やパフォーマンス、コストについても意識しておきましょう。「ストレージコストを抑えるために重複排除と圧縮を行うが、そのためにストレージコスト削減量以上のバックアップソフトの追加ライセンスを払う」となると本末転倒です。
バックアップのWORMの有無の合意
ランサムウェアや誤削除/悪意を持った削除からの防御策としてWORM機能が必要な場合があります。
S3であればオブジェクトロック、AWS Backupであればボールトロック、Amazon FSx for NetApp ONTAPであればSnapLockとTamperproof Snapshotです。
これらの利用を行う必要があるか検討しましょう。
また、そもそもバックアップデータにアクセスできる権限を絞り込むことも検討しましょう。
バックアップの暗号化方式の合意
機微なデータのバックアップは、それもまた機微となります。
バックアップの暗号化をしましょう。
AWS Well-Architected フレームワークにもバックアップの暗号化について言及されています。
暗号化する際は暗号化の方式や、暗号化キーの取り扱いについても合意しておくと良いでしょう。
何の脅威に対しての暗号化なのかで、ストレージ/ミドルウェア/アプリケーション側と暗号化する方式は変わってきます。
DBの話にはなりますが、各暗号化方式が対応する脅威についての説明は以下徳丸先生の動画が分かりやすいです。
バックアップデータの耐久性の確認
そのバックアップ手法におけるバックアップデータの耐久性についても確認しておきましょう。
例えば同一AZのEC2インスタンスのEBSボリュームにバックアップデータを転送し、AMIも取得していないというシチュエーションにおいては、そのバックアップデータの耐久性はEBSボリュームの耐久性となります。
想定している障害シナリオが単一AZのデータ全損であれば、AMIを取得や、そもそもS3バケットに保存するアプローチになるかと思います。
バックアップウィンドウの決定
バックアップウィンドウをステークホルダー間で合意しましょう。
バックアップからリストアする際には、「どのタイミングのバックアップか」が重要です。
場合によってはシステム全体で静止点を取る必要があるため、ワークロードの提供時間を考慮した上でバックアップウィンドウを決定しましょう。
また、オンラインでバックアップ処理をする際にワークロードに負荷がかかることがあります。特にバックアップツールを使う際にはありがちです。アクティブユーザーが多い時間帯や重たいバッチ処理が流れている時間帯は回避しましょう。
DR環境での機能的/パフォーマンス的縮退運転の有無の合意
DR環境では機能的/パフォーマンス的縮退運転をするか合意します。
例えば、リージョンによってはプライマリリージョンで使用していたインスタンスタイプが未サポートだったりします。その場合は旧世代のインスタスタイプを使うことになるでしょう。
また、そもそもフェイルオーバー先のリージョンでは、プライマリリージョンで使用していたサービスが提供されていない場合は、そのサービスを使って動作していてた機能をオミットしてDR環境で稼働させることもあります。どうしてもオミットしたくない場合は、その機能をサポートしている遠方のリージョンを使うことになるかと思いますが、そうなると今度はネットワーク的なレイテンシーによる性能劣化やデータを海外リージョンに持ち出すことが社内ポリシー的にに許可されるのかが気になります。
このようにDR環境として使用するリージョンにて、同一の機能や同等のパフォーマンスを提供できるか整理し、難しければ縮退運転をする方向で合意しましょう。
DR環境のキャパシティ確保の必要性の合意
東京リージョンをプライマリ、大阪リージョンをセカンダリとしてDR構成を組んでいるシステムは多いのではないでしょうか。
つまりは東京リージョンが全損した場合、多くのシステムが大阪リージョンにフェイルオーバーする可能性が高いでしょう。
そのような場合に、大阪リージョンのキャパシティが不足してしまう可能性があります。
DRシナリオがパイロットライトなのであれば、EC2インスタンスやRDS DBインスタンスがキャパシティ不足によって起動できない可能性も考慮しましょう。
それが許容できない場合、常時EC2インスタンスを起動や、キャパシティ予約を行う形になります。
コストに大きく影響があるため注意しましょう。
バックアップソフトライセンスの調達
求める機能によっては商用のバックアップソフトを調達することになります。
商用のバックアップソフトを導入する場合ライセンスの調達が必要になります。併せてライセンスの考え方や保守についても確認しておきましょう。
バックアップやDR環境を用意および運用するために必要なコストの試算
今までの検討内容をもとに、バックアップやDR環境を用意および運用するために必要なコストを整理しましょう。
DR先で商用製品を動作させる場合は、ライセンスを二倍用意する必要があるのかといったことも確認しておきましょう。
コストがかかりすぎているのであれば、各種方式や障害シナリオ、RTO/RPO/RLOの見直しを行うことになります。
手順の整理と検証
手順の整理と検証を行います。
バックアップやDR環境はお守りではく。リストアやフェイルオーバーするためのデータや環境です。リストアやフェイルオーバーができて初めて効果を発揮します。
確実に復旧できるように検証をした上で、手順を整理しておきましょう。
復旧時の体制の構築
意思決定、連絡フローで定めた内容をもとに復旧時の体制の構築します。
運用フェーズ入ってから人を探すのは流石に無理があります。提案や設計のタイミングで運用の体制も考慮しましょう。
バックアップデータの検証と監視の導入
バックアップが破損していないか、正常にバックアップが行われているかの監視の導入をしましょう。
これは使用しているバックアップのツールやサービスに標準で付いているものもあります。
AWS BackupであればNumberOfBackupJobsFailedメトリクスを確認することになるかと思います。
運用フェーズ
リストアとDR訓練の実施
定期的なリストアとDR訓練の実施しましょう。
そのシステム自体の構成のアップデートや関連システムの追加など、状況は計画当初から変わっていることがほとんどです。
計画時に予定していたRTO/RPO/RLOが満たせられるか、訓練を行い、必要に応じて構成や手順の見直しをしましょう。
訓練をする際は本場環境と同等の規模を持ったステージング環境を用意しておくと便利です。
意味のあるバックアップとDR環境を用意しよう
バックアップやDRを計画する際に意識するべきことをまとめてみました。
戻せないバックアップや、いざという時に頼りにならないDR環境はお金だけかかってしまい、非常にもったいないです。
意味のあるバックアップとDR環境を用意できるように、目的からブレークダウンして順次整理、対応していきましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
