これだけでわかるディザスタリカバリガイド

お客様の状況に合わせたサポートが必要な場合や、ご興味をお持ちの場合は、お問い合わせください。または、ディザスタリカバリのヒント、戦略、および計画リソースについてベリタスの事業継続スイートをご確認ください。
 

これだけでわかるディザスタリカバリガイド

 

ディザスタリカバリ (DR) とは、企業を重大な悪影響から保護することを目的とするセキュリティ計画のことです。これにより、企業は、データ障害の発生後、業務を長時間停止したり収益を大きく失うことなく、ミッションクリティカルな業務を維持または迅速に再開できます。

 

災害にはさまざまな形態と規模があります。地震、竜巻、台風などの壊滅的な事象だけでなく、機器の故障、サイバー攻撃などのセキュリティインシデントのことも指し、場合によってはテロも災害に分類されます。

 

企業は、災害に備え、実行すべきプロセスとミッションクリティカルな業務を再開するためのアクションを詳述した DR 計画を作成する必要があります。

 

ディザスタリカバリとは

 

ディザスタリカバリでは、企業の重要なビジネス業務をサポートする IT システムに重点を置きます。多くの場合、事業継続という用語と関連していますが、この 2 つは完全に同じ意味を持つわけではありません。DR は事業継続の一部です。事業のあらゆる側面を災害にかかわらず維持することに、より重点を置いています。

 

IT システムが事業の成功にとって必要不可欠になっているため、ディザスタリカバリは事業継続プロセスにおける主要な柱となっています。

 

ほとんどの経営者は、通常、予期しない危機が発生するまで自然災害の被害を受けるとは考えていません。その結果、多額の運用上および経済上の損失が発生します。これらの事象は予測できない場合があります。経営者として、災害への対応準備計画を策定していないというリスクを冒すことはできません。

 

企業が直面する災害の種類

 

企業が受ける災害には、技術的なもの、自然によるもの、人間によるものがあります。自然災害の例には、洪水、竜巻、台風、地滑り、地震、津波などがあります。一方、人間による災害や技術的な災害には、危険物質の流出、電源またはインフラ障害、化学および生物兵器による脅威、原子力発電所の事故またはメルトダウン、サイバー攻撃、テロ行為、爆発、市民による暴動などがあります。

 

計画の対象となる可能性がある災害は次のとおりです。

  • アプリケーションの障害
  • VM の障害
  • ホストの障害
  • ラックの故障
  • 通信の障害
  • データセンターでの災害
  • 建物またはキャンパスでの災害
  • 市全域、地域、国内、および複数の国での災害

 

DR が必要な理由

 

規模や業種に関係なく、予期しない事象が発生して日常業務が停止すると、企業は迅速に復旧して、顧客や得意先へのサービスの提供を継続する必要があります。

 

ダウンタイムは、企業が直面する最大規模の IT コストになり得ます。Infrascale 社の 2014 年 ~ 2015 年のディザスタリカバリに関する統計情報によると、1 時間のダウンタイムがもたらすコストが小規模企業では 8,000 ドル、中規模企業では 74,000 ドル、大企業では 700,000 ドルに及ぶ可能性があります。

 

中小規模企業 (SMB) の場合、生産性の損失が長引くと、失注、請求の遅延、納期の遅れ、ダウンタイムからの復旧作業に伴う勤務時間増による人件費の増加により、キャッシュフローが減少するおそれがあります。

 

ビジネスの大きな中断を予想して適切に対処できなければ、予期しない災害が発生したときに長期的な悪影響が生じるリスクを負うことになります。

 

DR 計画が導入されていれば、次のような複数のリスクから企業を守ることができます。

  • 評判の失墜
  • 予算外の支出
  • 情報漏えい
  • 得意先や顧客への悪影響

 

企業の高可用性への依存が高まっており、ダウンタイムに対する許容度は低下しています。このため、多くの企業では、DR を導入して災害による悪影響が日常業務に及ばないようにしています。

 

DR の必須要素: リカバリポイント目標とリカバリタイム目標

 

DR とダウンタイムにおける 2 つの重要な指標は次のとおりです。

  • リカバリポイント目標 (RPO): 災害発生後に、バックアップストレージからリカバリを行い通常の業務を確実に再開するために、過去のどの時点のファイルまで取り戻す必要があるかを示す値 (時間) です。これにより、バックアップの最小頻度が決まります。たとえば、企業の RPO が 4 時間の場合、システムでは 4 時間ごとにバックアップを行う必要があります
  • リカバリタイム目標 (RTO): 災害発生後に企業がファイルをバックアップからリカバリし、通常業務を再開するために必要とする最大時間です。したがって、RTO は、企業が対処できる最大のダウンタイム時間になります。RTO が 2 時間の場合、業務でそれよりも長いダウンタイムは許されません

 

RPO と RTO を特定したら、管理者はこの 2 つの指標を使用して、最適なディザスタリカバリ戦略、手順、およびテクノロジを選択できます。

 

より厳格な RTO の時間内で業務を復旧するには、セカンダリデータを最適な形で配置し、容易かつ迅速にアクセスできるようにする必要があります。データを迅速にリストアする方法の 1 つが即時リカバリです。すべてのバックアップデータファイルをリアルタイムの状態に移行することで、ネットワーク経由で転送する必要がなくなります。これにより、サーバーとストレージのシステム障害に対する保護を提供できます。

 

即時リカバリを使用する前に、以下の 3 つの点を考慮する必要があります。

  • ディスクバックアップアプライアンスのパフォーマンス
  • すべてのデータをバックアップ状態からリアルタイムの状態に移行するのに要する時間
  • フェールバック

 

また、即時リカバリは最大で 15 分かかる可能性があるため、リカバリ時間を短縮したい場合はレプリケーションが必要になる場合があります。レプリケーションとは、定期的にデータベースをコンピュータサーバー A からサーバー B へ電子的に更新 (コピー) することです。これにより、ネットワーク内のすべてのユーザーは常に同じ情報レベルを共有します。

 

ディザスタリカバリ計画 (DRP)

 

Veritas Disaster Recovery Planning Guide (ベリタスディザスタリカバリ計画ガイド)』をご覧ください。

 

ディザスタリカバリ計画は、構造化されたアプローチを文書化したもので、計画外のインシデントに対応するための手順が規定されています。災害の影響を最小限に抑えて、企業がミッションクリティカルな業務を迅速に再開する、あるいは通常どおりの業務を継続するための予防手順で構成されます。

 

通常、DRP では、すべてのビジネスプロセスと継続ニーズを詳細に分析します。さらに、詳細計画を作成する前に、リスク分析 (RA) とビジネスインパクト分析 (BIA) を行う必要があります。RTO と RPO の規定も必要です。

 

1. リカバリ戦略

 

リカバリ戦略はビジネスレベルを起点とする必要があります。これにより、企業の運営にとって最も重要なアプリケーションを判断できます。リカバリ戦略では企業のインシデント対応計画を定義します。一方、DRP では対応方法を詳述します。

 

リカバリ戦略を決定する際、次のような項目について検討する必要があります。

  • 予算
  • 人、物理的な施設などのリソースの可用性
  • リスクに対する経営層の見解
  • テクノロジ
  • データ
  • サプライヤー
  • サードパーティベンダー

 

経営層はすべてのリカバリ戦略を承認する必要があります。リカバリ戦略は企業の目的や目標に沿ったものでなければなりません。リカバリ戦略が策定されて承認されたら、DRP に書き換えることができます。

 

2. ディザスタリカバリ計画の手順

 

ディザスタリカバリ計画 (DRP) のプロセスでは、ドキュメント作成だけにとどまらず、さまざまな作業を行う必要があります。ビジネスインパクト分析 (BIA) とリスク分析 (RA) は、DRP プロセスでリソースを集中させる領域を決定するのに役立ちます。

 

BIA は、破壊的な事象の影響を特定するのに役立ち、DR コンテキスト内でのリスク特定の開始点となります。また、RTO と RPO の決定にも役立ちます。

 

リスク分析により、BIA で浮き彫りになったプロセスとシステムの通常運用を妨げる可能性がある脆弱性と脅威を特定します。また、リスク分析を活用して破壊的な事象の発生確率を評価し、その潜在的な重大性を明らかにすることができます。

 

DR 計画のチェックリストには以下の手順が含まれます。

  • アクティビティ範囲の確立
  • 関連するネットワークインフラドキュメントの収集
  • 複数の脅威と脆弱性、および企業の重要な資産の特定
  • 過去の予定外のインシデントおよびその対応に関するレビュー
  • 現在の DR 戦略の特定
  • 緊急対応チームの特定
  • 経営層による DRP のレビューと承認
  • 計画をテストする
  • DR 計画の更新
  • DR 計画の監査の実施

 

3. DRP の作成

 

DRP 作成にあたり、必要なすべての重要なアクション手順の要約をまとめ、必要不可欠な連絡先をリストアップします。これにより、重要な情報に容易かつ迅速にアクセスできるようになります。

 

DR 計画では、チームメンバーの役割と責任を定義するとともに、アクション計画の開始条件の概要を示す必要もあります。その後、必ず対応とリカバリアクティビティを詳細に規定します。この他に、DRP テンプレートに入れる必須項目は次のとおりです。

  • 目的に関する声明
  • DR ポリシーに関する声明
  • 計画の目標
  • パスワードなどの認証ツール
  • 地理的なリスクと要因
  • メディア対応のヒント
  • 法的情報と財務情報
  • 計画の履歴

 

4. DRP の範囲と目的

 

DRP の範囲はさまざまです (基本的なものから包括的なものまで)。100 ページを超えるものもあります。

 

DR の予算もさまざまで、時間の経過とともに変動する場合があります。このため、米国連邦緊急事態管理庁のオンライン DR 計画など、無料で入手できるリソースを活用できます。また、オンラインには多数の無料の情報やハウツー記事があります。

 

DRP の目標チェックリストには、以下の項目が含まれます。

  • 重要な IT ネットワークとシステムの特定
  • RTO の優先順位付け
  • システムとネットワークを再起動、再構成、またはリカバリするために必要な手順の概要作成

 

DR 計画では、少なくとも、日常のビジネス業務への悪影響を最小限に抑える必要があります。また、予期しないインシデントが発生した場合に従うべき緊急事態時の対応手順について、従業員が把握している必要があります。

 

DRP プロセスにおいて、距離は重要でありながら見過ごされることが多くあります。利便性、コスト、テスト、帯域幅を考慮したうえで DR サイトとして理想的なのは、プライマリデータセンターに近い場所にあるサイトです。ただし、停止の範囲はさまざまなので、プライマリデータセンターとその DR サイトが近くに配置されていると、地域的な事象によってその両方が破壊される場合があります。

 

5. ディザスタリカバリ計画の種類


特定の環境に合わせて DRP を調整できます。

  • 仮想化された DRP: 仮想化により、効率的で簡単な方法で DR を実装できます。仮想化環境を使用して、新しい仮想マシン (VM) インスタンスをすぐに作成し、高可用性のアプリケーションリカバリを実現できます。さらに、テストが容易になります。DR 計画には、アプリケーションが DR モードでより迅速に動作し、RTO および RPO の範囲内で通常業務に復旧できることを確認するための検証機能が含まれている必要があります
  • ネットワーク DRP: ネットワークをリカバリするための計画の策定は、ネットワークの複雑さが増すにつれて複雑化します。そのため、リカバリ手順をステップごとに詳述し、正しくテストして、最新の状態に維持することが必要不可欠です。ネットワーク DRP の対象になるデータは、ネットワークのパフォーマンスやネットワーク担当者など、ネットワークに固有のものになります
  • クラウド DRP: クラウドベースの DR は、ファイルバックアップから完全なレプリケーションプロセスまで多岐にわたります。クラウド DRP は、時間、スペース、およびコスト効率に優れていますが、維持するにはスキルと適切な管理が必要です。IT 管理者は、物理サーバーと仮想サーバーの両方の場所を把握している必要があります。また、この計画では、クラウドに関連するセキュリティの問題にも対処しなければなりません
  • データセンター DRP: この計画では、データセンター施設とそのインフラに重点を置きます。この DRP の重要な要素の 1 つが、主要な必須コンポーネント (建物の場所、セキュリティ、オフィスのスペース、電源システムおよび保護など) を分析する運用リスク評価です。また、考えられるシナリオについて、より広範に対処する必要があります

 

ディザスタリカバリテスト

 

テストではすべての DRP を実証します。これにより、計画の不備を特定し、災害発生前に問題を修正する機会を得ることができます。また、テストを行うことで計画の有効性を証明し、RPO を特定できます。

 

IT テクノロジおよびシステムは絶えず変化しています。このため、DRP が最新状態であることをテストによって保証します。

 

DRP をテストしない理由としては、予算の制限、経営層の承認の欠如、リソースの制約などが挙げられます。また、DR テストには、時間、計画、リソースが必要です。リアルタイムのデータの使用が伴う場合は、インシデントリスクとなる可能性もあります。しかし、テストは決して無視すべきでない DR 計画の必須要素です。

 

DR テストは、以下のようにシンプルなものから複雑なものまで多種多様です。

  • 計画のレビュー: DRP について詳細にディスカッションし、欠落している要素や矛盾点を探します
  • 机上テスト: 参加者が DR 計画のアクティビティの手順を通しで行います。DR チームメンバーが緊急事態発生時の責務を把握しているかどうかを明確にします
  • シミュレーションテスト: 実際のフェールオーバーは行わずにバックアップシステム、リカバリサイトなどのリソースを使用する全面的なテストです
  • ディザスタモードを一定期間実行: システムテストのもう 1 つの方法です。たとえば、リカバリサイトにフェールオーバーし、そこから 1 週間システムを稼動させてからフェールバックするというテストを実施します

 

DR ポリシーでのテストをスケジュールする必要がありますが、業務の妨げとならないよう注意してください。テストの頻度が高すぎると生産性が低下し、担当者の負担が増えるためです。一方、テストの頻度が低すぎてもリスクがあります。また、大きなシステム変更を加えた後は必ず DR 計画をテストしてください。

 

テストの効果を最大限に高めるには、以下を実現する必要があります。

  • 経営層の承認を得て予算を確保する
  • 詳細なテスト情報をすべての関係者に提供する
  • テストチームがテスト日に対応できるようにする
  • テストを適切にスケジュールして、他のアクティビティやテストと競合しないようにする
  • テストスクリプトが正しいことを確認する
  • テスト環境が準備できていることを確認する
  • ドライランを最初にスケジュールする
  • 必要に応じてテストを中止する準備をする
  • 書記担当者にメモを取らせる
  • 成功した内容と失敗した内容を詳述する事後レポートを作成する
  • 収集した結果を使用して DR 計画を更新する

 

Disaster Recovery-as-a-Service (DRaaS)

 

Disaster recovery-as-a-service は、ここ何年か注目を集めているクラウドベースの DR 手法です。DRaaS のメリットとしては、低コストで導入が容易になるうえ、定期テストが可能になる点です。

 

クラウドテストは共有インフラで実行されるため、企業のコストを削減できます。また、柔軟性が高く、必要なサービスのみを契約できるのに加え、一時インスタンスを起動するだけで DR テストを完了できます。

 

DRaaS に関する期待と要件は文書化され、サービスレベル契約 (SLA) に含まれます。サードパーティベンダーは、従量課金制または契約を通じて、クラウドコンピューティング環境へのフェールオーバーを提供します。

 

ただし、DR サイトには全ユーザーのアプリケーションを実行するための十分な領域が確保されていない可能性があるため、大規模災害の発生後にクラウドベースの DR を利用できない場合があります。また、クラウド DR によって帯域幅のニーズが増加するため、複雑なシステムを追加するとネットワーク全体のパフォーマンスが低下する可能性があります。

 

クラウド DR の最大の欠点は、プロセスをほとんど制御できないことだと考えられます。このため、定義されたリカバリポイント目標とリカバリタイム目標を達成しながらインシデント発生時に DRP を実施するには、サービスプロバイダを信頼する必要があります。

 

コストはベンダーごとにさまざまで、ストレージの使用量またはネットワーク帯域幅に基づいてベンダーによる課金が発生する場合は、コストがすぐに増加する可能性があります。したがって、プロバイダを選ぶ前に、綿密な内部評価を実施して DR ニーズを判断する必要があります。

 

候補となるプロバイダには次のような項目を確認します。

  • DRaaS は既存のインフラに基づいて動作するのか
  • 既存の DR およびバックアッププラットフォームとどのように統合できるのか
  • ユーザーは内部アプリケーションにどのようにアクセスするのか
  • 必要な DR サービスを提供できない場合はどうなるのか
  • 災害発生後にデータセンターで稼動できるようになるまでどのぐらいかかるのか
  • フェールバック手順はどうなっているのか
  • テストプロセスはどうなっているのか
  • 拡張できるのか
  • DR サービスの使用料はどのように請求されるのか

 

ディザスタリカバリサイト

 

DR サイトにより、プライマリデータセンターが利用できない場合に、テクノロジインフラおよび運用をリカバリおよびリストアできます。内部サイトか外部サイトかは問いません。

 

企業には、内部 DR サイトを設置して維持する責任があります。このようなサイトは、より短い RTO と大規模な情報要件を抱える企業で必要になります。内部のリカバリサイトを構築する際の考慮事項には、ハードウェア構成、電源保守、サポート機器、レイアウト設計、冷暖房、場所、スタッフなどがあります。

 

外部サイトと比較するとはるかに高額ですが、内部 DR サイトでは DR プロセスのすべての側面を管理できます。

 

外部サイトは、サードパーティベンダーが所有して運用し、以下のいずれかに分類されます。

  • ホット: ハードウェアとソフトウェア、24 時間体制のスタッフ、従業員および顧客データを含むフル機能を備えたデータセンターです
  • ウォーム: データセンターの設備はありますが、顧客データは含まれません。クライアントは追加の機器をインストールしたり、顧客データを導入したりすることができます
  • コールド: データと IT システムをサポートするためのインフラが用意されています。ただし、クライアント企業が DR 計画を始動させ、機器を設置するまでテクノロジは搭載されません。長期にわたる災害の際に、ウォームサイトやホットサイトを補完することがあります

 

ディザスタリカバリのティア

 

1980 年代に、SHARE Technical Steering Committee と International Business Machines (IBM) の 2 つの組織がDR サービスレベルを記述するためのティアシステムを考案しました。このシステムでは、最小限の能力を表すティア 0 から最大限の能力を表すティア 6 までを使用して、オフサイトでのリカバリ能力を示しています。

 

第 7 ティアは、DR 自動化を盛り込むために後になって追加されました。現在、DR シナリオでの最高レベルの可用性を表しています。一般に、各ティアでのリカバリ能力が向上すると、コストも削減されます。

 

結論

 

災害への備えは容易ではありません。ソフトウェア、ハードウェア、ネットワーク機器、接続、電力、テストを網羅した包括的なアプローチをとり、ディザスタリカバリを RPO 目標と RTO 目標の範囲内で達成できるようにする必要があります。綿密で実用的な DR 計画の実施は容易な作業ではありませんが、多くの利点が期待できます。

 

導入されたディザスタリカバリ計画を企業内の全員が認識する必要があり、その計画を実施するときには効果的なコミュニケーションが重要になります。DR 計画を策定するだけでなく、テスト、担当者のトレーニングに加え、すべてを適切に文書化して、定期的に改善することが必要不可欠です。最後に、サードパーティベンダーのサービスの導入は慎重に行うようにしてください。

 

エンタープライズレベルのディザスタリカバリ計画が必要な場合は、ベリタスがお手伝いします。今すぐお問い合わせください。担当者からご連絡を差し上げます。

 

ベリタスのポートフォリオでは、耐障害性を備えた企業となるために必要なすべてのツールを提供します。日常の微細な災害から「ブラックスワン」イベントまで広範囲にわたって対応します。Veritas Resiliency Platform に関する詳細を確認し、今すぐ無料体験版をダウンロードしてください。

 

 

 

その他の推奨リソース

 

4 ステップのデータ保護計画

段階的なアプローチですべてのワークロードを効率的に保護できます。

バックアップ計画はすでに策定済みでしょうか。

データの安全性を保つためのバックアップ戦略をご確認ください


デジタル時代の企業のための IT 分析のベストプラクティス

Global 2000 企業が、エンドツーエンドの IT 分析をどのように利用してビジネスを効率化しているのかについてご紹介します。

お問い合わせ

エンタープライズレベルのデータ保護計画が必要な場合は、ベリタスがお手伝いします。