私は、古くて一方的な災害復旧計画の更新に関するプロジェクトを主導する任務を負っています。今のところ、DRのIT側を整理することを検討しています。最後にこれを行ったとき、彼らは単一の災害（データセンターがflood濫した）を作り、他のすべての災害タイプを除外してそれを計画することによって彼らの範囲を設定しました。もっと丸みのあるアプローチを取りたいです。これは解決された問題であり、他の組織がDR計画を作成していることは知っています。
私たちの計画は、IT DR計画を進めて、「これはITのDR計画に必要なものです。大学の他の部分と一致していますか？修復されたサービスの優先順位はありますか？変更したいですか？」計画の残りの部分が何であるかについてはかなり良い考えがあり、これがうまくいくと期待しています。
私が探しているのは、DR計画の範囲を決める方法と、考えるべき質問に関するガイダンスです。DR計画の開発に関連するお気に入りのリソース、書籍、トレーニングはありますか？
回答:
優れた情報源は、Disaster Recovery Journal（約）です。
利用可能なコミュニティリソースには、一般に受け入れられているプラクティス（GAP）ドキュメントの現在のドラフトが含まれています。また、さまざまなDR / BCトピックをカバーするいくつかのホワイトペーパーも利用できます。
プロセスは難しいように見えますが、最終的にどこに行きたいかについての適切なアウトラインで体系的に近づくと（DRJ GAP文書のように）、投資時間を最適化し、最終製品の価値を最大化することができます。
私は彼らの四半期ごとの出版物も同様に興味深く、有益であると思います（購読）。
アイデアを追加すれば、誰もが自分のアイデアを追加したら、この投稿から素敵なウィキを作成できます。従うべきことがたくさんあることは理解していますが、回復に関しては、特定の優先順位を持っている人もいます。始めに、ここに私のものがあります：
DRの基本的なことは、RTO（回復時間目標）とRPO（回復ポイント目標）です。これらは、おおよそ「それを取り戻すのにどれだけの時間を受け入れられるか、どれだけのデータを失うことができるか」と解釈されます。理想的な世界では、答えは「なし」です。しかし、DRシナリオは例外的な状況です。これらは本当に顧客によって動かされるべきですが、ITの角度から始めているので、あなたは最善の推測をすることができますが、必要に応じて上下に調整する準備ができています。合理的に得ることができる「なしとなし」に近いものを目指すことは良いことですが、収益が減少するポイントがいつ入るかを認識する必要があります。
これらの2つの要因は、1年の異なる時期に異なる場合があり、異なるシステムでは異なる場合があります。
よりバランスのとれたアプローチが好きです。DRシナリオにつながる可能性のあるイベントをリストするのは魅力的ですが、これらは実際にはリスク分析/緩和演習に属します。DRにより、インシデントは既に発生しており、それが何であったかの詳細はあまり関連性がありません（おそらく、DR施設の可用性に影響するという点を除く）。サーバーを紛失した場合は、落雷や誤ってフォーマットされたものなどに関係なく、サーバーを取り戻す必要があります。災害の規模と広がりに焦点を当てたアプローチは、結果をもたらす可能性が高くなります。
顧客が関与することに消極的であることがわかった場合、顧客に使用する1つのアプローチは、IT以外の角度からDRの質問をすることです。紙のファイルがすべて炎上した場合の計画を尋ねるのは、ここの例です。これにより、より広範なDRに関与することができ、有用な情報を自分の計画に取り入れることができます。
最後に、計画を定期的にテストすることが成功に不可欠です。紙上では素晴らしく見える美しいDR計画を立てることは良くありませんが、それは目標を達成しません。
実際、最初のステップとして、「単一のインシデント」開発モデルは良い考えです。その理由の1つは、計画の実行をより現実的かつ集中的にすることです。洪水の計画を立ててください。次に、別のインシデント（たとえば、長期停電）を想定し、その計画をそれに適用し、何が壊れているかを修正します。数回の反復の後、計画は比較的堅牢になります。
いくつかの考え...-使用できない人々を考慮してください。洪水が発生した場合、すべての関連スタッフが利用可能であると想定することはできません。休暇中、負傷、または家族との付き合いがある可能性があります。
-コミュニケーションの問題と弱点を計画します。複数の番号と複数のモードがあります。
-DR計画には一連のコマンドが必要です。誰が決定を下すかを知ることは重要です。
-計画は、オフサイトおよびオフグリッドを含め、広く配布する必要があります。災害時にアクセスできる必要があります！
私が働いている場所では、過去2年間に大規模なDRテストを実施しています。「現実的な」状況でサービス、人、プロセスをテストすることが有用であることを発見しました。あなたがそれらを役に立つと思うことを期待して、いくつかの教訓（おそらく明らか）を学びました：
私が得ているのは、DR計画プロセスに関するすべてを理論的にしないようにすることです。実際に物事を壊し、したがって組織の準備に関するハードデータを取得する許可を求めます。もちろん、経営陣からの真剣なサポートが必要になりますが、最悪の場合のリハーサルに数日を費やすことは、ビジネスにとって素晴らしい焦点となります。
チアン
British Standards Institute（BSi）には、継続性管理と災害復旧に重点を置いたいくつかの標準があります。
当たり前のように思えるかもしれませんが、上記のオフサイトのドキュメントに沿って、オフサイト（できれば地域外）のバックアップがあることを確認してください。これは、オンラインストレージサービスまたはテープの保管場所である可能性があります。
私は私たちが毎年多くの自然災害を抱えていない地域から来ているので、できれば地域外にいると言いますが、もし私たちが災害を起こした場合は、大規模な破壊（地震、火山）を伴う地域規模です。銀行が液体のホットマグマ（/ Dr。Evil Voice）にさらされるまで、バックアップを銀行のセーフティボックスに保管しておくとよいでしょう。
私が読んだことのあるものは、大きなサイトがヒットしたときのためにホットなサイトを維持するコストを分担する機関です。彼らは、仮想化などを使用して、ホットサイトにとって重要な両社のミッションを復元する計画を制定し、その後、明滅するレベルでスタッフを共有します。ちょっとした考え。
ローラ、
以下に、DRの基本を説明するSQLServerPediaからのリンクを示します。
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/