災害復旧テストとその必要性
今日のハードウェアやソフトウェアがいかに信頼性が高まったとしても、機械は依然として様々な理由で故障する可能性があります。一旦クラッシュすると、システムが停止し、長期間にわたってデータにアクセスできなくなることがあります。また、システムが復旧したとしても、データを復元できない場合があり、取り返しのつかない損失を被ることになります。こうしたリスクを軽減する最も確実な方法は、 包括的な災害復旧(DR)計画.
災害復旧計画とは、定められた時間内にデータやワークロードを復旧させるために実施すべき一連の手順のことです。この詳細なDRチェックリストには、さまざまな災害シナリオに備えて事前に整備しておくべき仕組みが盛り込まれています。
統計によると、世界中の企業の95%が、DRを含む最悪の事態に備えるための計画に多大なリソースを投じています。しかし、実際に その78％が災害復旧テストを実施している 計画が実際に目標を達成しているかを確認するためです。災害復旧テストとは何か、また、いかなるインシデントが発生してもシステムの可用性と事業継続性を確保するために、組織向けのDRテスト戦略をどのように策定すべきかについて、以下で詳しく解説します。
災害復旧テストとは何か？
災害復旧テストとは、災害復旧計画の各手順を検証し、計画が確実に実行され、障害発生後に重要なアプリケーションやデータを復旧できることを確認するものです。 災害復旧計画のテストは、インシデント発生中および発生後に、事業運営と重要なサービスを維持できることを保証することを目的としています。
最も包括的な形の災害復旧テストでは、IT障害やその他の事業中断をシミュレートし、策定済みのDR計画を評価します。災害復旧テストの主な目的は、組織が災害復旧計画で設定された復旧時間目標(RTO)および復旧時点目標(RPO)を達成できるかどうかを確認することです。あなたは RPOとRTOの違いを理解する そして、各アプリケーションやVMごとに設定します。DRテストでは、インフラストラクチャの一部が利用不能になった場合にシステムがどのように動作するかも把握できます。この情報は、実際の障害が発生する前に、組織のDR計画を精緻化し、脆弱な部分を修正するのに役立ちます。
災害復旧テスト計画は、DR計画の技術的な要素だけに限定されるべきではないことに留意してください。 災害復旧に関与する各従業員が自身の役割を理解し、障害発生時に業務を遂行するために必要なリソースにアクセスできるかどうかをテストすることも、同様に重要です。
災害復旧計画のテストは定期的に、できれば年に数回実施すべきです。IT環境は、ソフトウェアの廃止、新しいアプリケーションの導入、ハードウェアの交換などにより常に変化しており、それに伴いDR計画の適切な修正が必要となります。DRテストのプロセスは、メンテナンスのルーチンやスタッフ研修の一環として組み込むことができます。
災害復旧テストが重要な理由
災害復旧計画をテストしない場合、データやシステムへのアクセスを失うリスクがあります。 損失に対して保険をかけることはできますが、インシデントによって失われたデータや、長期間のダウンタイムがビジネスに及ぼす影響を、いかなる保険契約も補うことはできません。稼働時間と可用性を真に確保する唯一の方法は、DR計画を作成し、定期的なテストを実施することです。もし、災害復旧計画のテストが必要であることにまだ確信が持てない場合は、インシデントが発生する前にDRテストがどのような成果をもたらすか、以下のリストをご参照ください:
- DR計画の不備や欠陥を発見する
- 復旧作業中は、手順を正しく実行するようにしてください
- 復旧目標が現実的であり、達成可能であることを確認する
- データの損失を最小限に抑える
- DRチームの対応手順を確認し、各メンバーが自分の役割を確実に理解していることを確認する
- 手遅れになる前に、アップデートや修正を適用しましょう
災害復旧テストプロセスの構成要素
DRテストは、確実に成果を上げ、DR体制の強化に役立つよう計画する必要があります。つまり、災害復旧テストの目的を明確にし、テストの実施頻度、成功基準、結果の評価、および不備やDRの失敗に対処するための手順について、具体的なスケジュールを策定しておく必要があります。これらの要素について、さらに詳しく見ていきましょう。
DRテストの範囲を設定する
DRテストの範囲には、テストプロセスにおいて満たすべき一連の前提条件と期待事項が含まれます。テスト範囲の設定には、以下の事項を含める必要があります:
- DRテストの対象となるシステムと機能を特定する
- どのような災害復旧プロセスをテストするかを定義する:バックアップからのマシン全体の復旧、DRサイトへのフェイルオーバーなど。
- 災害復旧計画の一部が予定通りに実行されない可能性があるため、あらかじめ例外事項や制限事項を定めておく
- DRテストのプロセスに含まれる部門および担当者を特定する
- テスト対象となるシナリオの定義:プライマリサイトの障害、ランサムウェア攻撃、接続切断、サーバー／データベースの障害など。
災害復旧計画の見直し
テストを実施する前に、DR計画を見直す必要があります。DRテストは、組織の方針や慣行に重点を置き、計画的に実施されるべきです。したがって、災害復旧チームは経営陣と協議し、既存のDR計画を見直した上で、現在の事業状況を踏まえて実施すべき変更や更新事項を決定する必要があります。これには、新しいハードウェアやソフトウェア製品の導入、事業拡大、予算削減、人員の入れ替わりなどの要因が含まれます。
DR検査の頻度
現在のIT環境は極めて流動的であるため、災害復旧計画を常に最新の状態に保つには、見直しの頻度を適切に設定することが極めて重要です。年1回、災害復旧計画の見直しと更新を行う組織もあります。しかし、最も効率的な戦略は、組織のミッションクリティカルな構成要素に変更が生じた都度、災害復旧計画を更新(および再テスト)することです。災害復旧テストには時間とコストがかかる場合がありますが、災害復旧プロセスの範囲を考慮しつつ、ビジネス上のニーズとリソースに基づいてテストスケジュールを策定する必要があります。
テストの成功基準
VMの災害復旧テストが成功したかどうかを判断するための基準を設定する必要があります。理想的には、災害復旧計画が有効かつ実行可能であることが実証された時点で、VMの災害復旧テストは合格とみなすことができます。
ただし、災害復旧計画がテストに合格しなかった場合でも、災害復旧テストは成功したとみなすことができます。このシナリオにより、実際の災害が発生する前に災害復旧計画の欠陥を特定し、計画の次期改訂版でそれらに対処することが可能になります。 基本的に、テストの成功基準はあらかじめ定められた期待値に基づいて定義されるものであり、混乱を避けるために、これらを災害復旧テスト計画書に明確に記述する必要があります。
試験結果の評価
VMの災害復旧テストの結果は、社内で現在採用されているDR戦略の全体像を示すものです。復旧チームはテスト結果を評価し、特定された課題に基づいてDR計画の改善策や調整案を策定することができます。
DRテストの結果を評価する際には、以下の指標も考慮する必要があります:
- ミッションクリティカルな業務が復旧するまでにどれくらいの時間がかかったか
- 計画の各段階がどの程度適切に実行されたか(エラーや遅延が発生したかどうか)
- DRテストの実施中に、いくつの操作が正常に完了しましたか
DR計画を改善するために、変更や更新を行い、テストを実施する必要があります。その目的は、より効果的で管理しやすい復旧プロセスを確立することにあります。
DR計画の実施後の検証
災害復旧計画をテストモードで実行した後は、再度その計画を見直すことをお勧めします。災害復旧テストの過程で、強みと弱み、および予期せぬ結果があればそれらを記録し、事業継続性への影響を評価する必要があります。これにより、災害復旧戦略を大幅に改善し、全体的なパフォーマンスを向上させることができます。課題や不具合に対処するための手順を詳細に策定し、次回の災害復旧計画に反映させる必要があります。
災害復旧計画のテストを実施する前に考慮すべき事項
- DRチームのメンバー数: "単一障害点"の問題を回避するため、災害復旧チームには少なくとも2名以上を配置すべきです。チームメンバーが複数いれば、災害発生時に1人が連絡不能になった場合でも、必要な知識を持ち、DRサイトへのアクセス権限を持つ代替要員がいるため、安心できます。
- 災害復旧テストの実施時間帯: 一般的に、DRテストは業務時間外に実施されます。これは、テストに時間がかかる上、業務の妨げになったり、システム全体のパフォーマンスに影響を及ぼしたりする可能性があるためです。しかし、こうしたテスト結果は、実際の業務環境下で災害復旧計画がどのように機能するかを正確に反映していない可能性があります。業務時間中に、VM DR計画の各構成要素を個別にテストすることが、理想的な解決策となるでしょう。これにより、全面的なテストに伴うシステム過負荷のリスクを軽減することができます。
- チームまたはITインフラストラクチャの変更: 災害復旧計画をテストする前に、その計画が不完全なものになったり、時代遅れになったりしかねないさまざまな要因について検討してください。前述の通り、こうした要因には、新しいインフラストラクチャの構成要素や人員の異動などが含まれます。環境における新たな変更については災害復旧チームに随時報告し、最新の更新情報をスタッフに知らせるため、簡潔なメモを送付してください。
災害復旧のテスト手法
このセクションでは、最も一般的な4つの災害復旧テスト手法について解説します。自組織に適した手法はどれか、あるいはこれらの手法を組み合わせて活用できるかどうかを判断する前に、各手法を慎重に検討してください。
チェックリストによるテスト
災害復旧計画のチェックリストによる検証では、満たすべき要件や条件のリストを確認します。この確認作業は、最も基本的な手法であり、現在の計画を検討し、すべての項目を精査して、時代遅れの部分や欠落している部分を見つけ出すため、優れた出発点となります。 具体的には、バックアップサイトの容量が十分であるか、復旧チームに最新の更新情報が通知されているか、データ保護ソリューションが稼働しているかなどを確認することになります。
このDRテスト手法を用いることで、復旧チームはDR計画を迅速に確認し、すべての構成要素が整っていることを確認するとともに、DR戦略において不足している要素を特定することができます。この手順は、最小限の時間と人員で実施可能です。
DRテストの手順
この戦略の目的は、VMの災害復旧計画の各ステップを口頭で確認し、問題点や不備を特定することです。ここでは、復旧チームの全メンバーがDR計画のレビューと議論に参加し、改善策を提案します。
全員が計画を十分に理解し、災害復旧発生時の各自の責任を認識していることを確認することが不可欠です。この方法では、DRプロセスについて口頭で議論するのみです。 ウォークスルーテストでは、DR計画の技術的な側面は実際にテストされたり承認されたりすることはありません。
卓上型／シミュレーション型DR試験
机上テストでは、組織は模擬災害シナリオを検証し、災害復旧計画が適切であるか、また定められた目標を達成できるかを確認します。この災害復旧テスト手法は、ウォークスルーテストの延長線上にあるものと見なすことができます。全チームメンバーに様々な災害シナリオが提示され、その状況下でどのように行動すべきかを議論しながら検討します。これにより、より現実的な環境下でスタッフの対応態勢をテストし、災害復旧計画が予期せぬ問題に対処できるかどうかを確認することができます。
- テーブルトップでのプレイ解説DRチームは、あたかも実際の災害が発生したかのように、計画に沿って段階的に検証を行います。この災害復旧テストの手法により、潜在的な死角や隠れた問題点を特定することができます。
- シナリオシミュレーションこの手法では、本番ワークフローに支障をきたすことなく、テスト環境でDR計画を実行します。シミュレーションは、以下の手順に従って実行されます。 具体的な復旧シナリオ.
- 災害復旧の完全なシミュレーションこのDRテスト手法は、前述のシミュレーションと似ていますが、今回はメインサイトでの業務が完全に停止するというシナリオが含まれています。この手法では、オフサイト拠点での完全な復旧を試みます。
並行テスト
並行テストでは、リカバリシステムの機能を検証し、業務を遂行し、重要なプロセスを確実に保護できるかどうかを確認することができます。主要システムは、本番環境の全ワークロードを処理することが想定されているため、災害復旧テストの対象には含まれません。これは、技術システムを安全かつ業務に支障をきたすことなくテストできる方法です。
完全遮断試験
完全停止型DRテストは、VM DR計画を徹底的に検証するものです。この場合、DRサイトが本番環境の全ワークロードを引き受け、プライマリサイトは停止されます。その目的は、企業の災害復旧計画に基づいて、可能な限り迅速に復旧することです。完全停止型テストの実施は、通常の業務に支障をきたす可能性があり、また多額のコストがかかるため、綿密に計画する必要があります。
復旧プロセスのすべてを文書化する必要があります。 DRテストの実施中に発生したすべての問題や懸念事項を特定し、後で対処できるようにします。復旧チームの行動を綿密に観察し、VM DR計画における潜在的な不備を特定する必要があります。フル・インターラプション・テストは、DRの目標が妥当かつ達成可能かどうかを確認するための適切な災害復旧テスト手法でもあります。
スタッフに事前に通知せずにフル・インターラプション・テストを実施することも検討してください。これにより、災害発生時のチームの準備状況をより正確に評価することができます。
災害復旧テストの役立つヒント
災害復旧(DR)計画のテストは重要な作業ですが、時に負担に感じられることもあります。以下のDRテストのヒントを参考にすれば、時間を節約し、ストレスを軽減できるでしょう:
- 新しいハードウェアやソフトウェアを導入した後は、直ちにテストを行い、その機能性と完全性を確認してください。これにより、製品のRTOを把握し、災害復旧(DR)手順の実施時にどのような動作をするかを確認することもできます。
- 災害復旧(DR)計画を策定する前に、リスク分析(RA)および事業影響度分析(BIA)を実施してください。これらの分析結果を常に確認し、変更があった場合は、それをDR戦略にどのように反映させるべきかを検討してください。
- テストは、DRシナリオに可能な限り近い状況下で実施する必要があります。実際の災害シナリオを想定してシミュレーションを行うことで、DR発生時に従業員がどの程度適切に職務を遂行できるかを確認できます。また、従業員がさまざまなDRシナリオに慣れ、自分に何が求められているかを理解できるようになるため、スタッフのストレス軽減にもつながります。
- DR計画を検証し、テストの過程を監視するために、外部のオブザーバーを招き入れましょう。この方法により、従業員がテストを急いで終わらせるために手抜きをすることを防ぐことができます。さらに、外部のオブザーバーはDR計画の改訂や改善を支援し、組織内部の人々には気づきにくい問題点を指摘してくれることがよくあります。
- インフラストラクチャ内のすべてのアプリケーションの完全なリストを作成してください。このリストには、各アプリケーションの詳細、設定、アプリケーション所有者の連絡先、および契約・ライセンスの詳細を含める必要があります。
- 初期段階では、システムに過度な負荷がかからないよう、DRテストは部分的に、かつ業務時間外に実施すべきです。不備を特定し、それに応じて計画を改善した後、業務時間内に本格的なテストを実施することを検討できます。
災害復旧 NAKIVO Backup & Replication
NAKIVO Backup & Replication は、信頼性の高いバックアップおよび災害復旧ソリューションです。このソリューションにより、バックアップ、レプリケーション、災害復旧のプロセスを自動化できるだけでなく、さまざまなプラットフォーム(物理、仮想、クラウド)にわたってデータの整合性を確保できます。NAKIVOのソリューションには、VMレプリケーション、VMフェイルオーバー、フェイルバック、および サイト復旧 災害復旧のための機能。さらに、災害復旧の手順をテストして、すべてが正しく設定されていることを確認できます。
サイトリカバリのジョブをテストモードで実行する
NAKIVO Backup & Replication テストモードでサイト復旧ジョブを実行することで、災害復旧時にすべてのシステムコンポーネントを容易に復旧でき、定められたDR目標を達成できるかどうかを確認できます。このテストは、本番環境のワークロードに影響を与えません。テストモードのサイト復旧ジョブは、スケジュール設定できるほか、オンデマンドで実行することも可能です。
以下の手順では、テストモードでサイト復旧ジョブを手動で実行する方法について説明します。なお、サイト復旧ジョブは事前に構成しておく必要があります。
- その
Jobsダッシュボードでサイト復旧ジョブを選択し、次にRun Jobボタン。ドロップダウンメニューには2つの選択肢が表示されます。クリックしてくださいTest site recovery仕事。
- 表示されるダイアログボックスで、RTO メトリクスを設定できます。Site Recovery ジョブの完了までに許容される最大時間を指定してください。テストの実行時間が入力した RTO 値を超えた場合、テストは失敗とみなされます。また、このオプションを無効にすることもできます。
- 最後に、[クリック]
Testジョブを実行するには。
試験スケジュールの選択肢
Site Recovery ジョブを設定する際に、テストのスケジュール設定を行うこともできます。これらの設定は、このジョブをテストモードで実行する際に有効になります。
レポートをメールで送信
このオプションを有効にすると、ジョブが完了するたびに、指定した受信者にテストレポートが送信されます。メール通知の設定は、 5. オプション クリックする前にタブキーを押してください Finish.
また、Webブラウザから直接、レポートをPDFまたはCSVファイルとしてダウンロードすることもできます。Site Recoveryジョブを右クリックし、[ Site Recovery Job Report.
