DR対策の考え方は2パターン

DR対策であれこれ考える人が多いが、以下の観点で単純に考えてほしい。

まずDRで考える部分を以下の2つに分解したい。
・利用者の接続切替
・システムの受入準備












■利用者の接続切替
　自動か手動かの2パターンになる。
　一例になるが、一般的に自動の場合はロードバランサを入れたりDNSの切替
　手動の場合はDR用のURLに接続したりバッチ等で端末の設定を書換えなどがある。

■システムの受入準備
　こちらも2パターンになる。
　A：災害があってからDR環境を整える
　B：災害がある前からDR環境を整えている

※DR運用時のシステム規模(性能)は通常運用時と同等と思い込みがちであるが
　コストを出した後に、DR運用時のシステム性能は通常時の〇％でと要件がでると
　見積りの手戻りが発生するので予め要件として確認しておくこと。











A：災害があってからDR環境を整える
　・費用を抑えられるDR対策
　・RTO、RPOに余裕のあるシステムで採用される
　・DR環境を整える為に必要なデータ(システムバックアップやファイルなど)を送っておく
　・DR環境の箱(物理マシン、仮想マシンなど)はRTOに応じて準備しておく
　　→箱自体の準備から取り掛かってもRTOを満たせるなら準備しなくてもよい
　　→箱自体を通常時は別の用途で利用したいなら予め準備しておくのもよい

B：災害がある前からDR環境を整えている
　・費用の掛かるDR対策
　・RTO、RPOに余裕の無いシステムで採用される
　・DR環境を整える為に必要なデータ(システムバックアップやファイルなど)を定期的に同期しておく
　　→定期的に同期とは、6時間・1時間・1分・リアルタイムどれも間隔が長いか短いかだけで「定期的」である。
　　→リアルタイムなら専用ソフトウェアを導入しても良いし、それ以外なら作りこみでも対応できることもある。
　・DR環境の箱(物理マシン、仮想マシンなど)は予め準備しておく

ありがちなことだが、ソフトウェア・サービスなどの組合せで色んなパターンを先出してしまい
あれもこれも大して変わらないパターンの提案をするとユーザも提案側も何が最適か迷走する。
上記の「利用者の接続切替」、「システムの受入準備」の組合せから要件や方針を確認して
機能面で実現に必要なソフトウェア・サービスなどは後から考えればよい。

＜補足＞
・RTO(Recovery Time Objective)：いつまでにシステムを復旧させるかの目標値
・RPO(Recovery Point Objective)：いつ時点のデータに復旧させるかの目標値