地震や台風などの自然災害、またはサイバー攻撃のインシデントに対して、事業を迅速に復旧させる対策を行うことが、ディザスタリカバリ(DR)です。本記事では、災害対策の概要および復旧のための指標とクラウドストレージによるデータ復旧の概要をまとめました。

ディザスタリカバリ(DR)の範囲と目的

ディザスタリカバリ(Disaster Recovery、以下DR)は「災害復旧」を意味する言葉です。頭文字からDRと省略して使われます。最初に対応すべき災害、BCPとの関係、そしてDRの目的について整理します。

DRではどのような災害を想定するか

日本では、2011年3月11日に発生した東日本大震災をきっかけにDRが重視されるようになりました。津波によってPCやサーバなどの機器が浸水して復旧に時間がかかったほか、金融機関のシステムダウンも問題でした。DRでは、地震を含めて以下のような災害への対策を想定します。

  • 自然災害(地震、台風、洪水、津波など)
  • 停電のほかデータセンターなどインフラの障害
  • 火災、爆発、建築物の崩壊
  • テロによる攻撃、暴動、戦争、兵器の使用
  • サイバー攻撃

DRとBCPの関係と位置づけ

DRと似た用語にBCP(Business Continuity Planning、事業継続計画)があります。BCPは事業の継続を目的として、あらゆる災害や事故などに備えてリスク回避や予防対策を行い、早期復旧を図ることです。一方、DRは災害が起きた後の復旧がポイントになります。したがって、長期的な事業継続が目的のBCPの一部として、災害時の復旧をめざすDRが位置付けられます。

DRの目的は、ダウンタイムを最小限に抑えること

災害からの復旧をめざすDRでは、ダウンタイムを最小限に抑えることが重要になります。もし復旧が遅れると、次のような問題が生じます。

  • 業務やサービスの停止
  • 生産性の低下、売上の減少
  • データの消失や情報漏洩など二次被害の発生
  • 企業やブランドの信頼性の低下

DRでは、過去の定められた状態まで、どれぐらいの時間で、どのレベルまで復旧ができるかという目標を定めます。

DRでめざす3つの指標

DRには復旧に関する3つの指標があります。それぞれ簡単に整理します。

目標復旧時点(RPO)

目標復旧時点(RPO、Recovery Point Objective)は、過去のどの時点まで復旧させるかという指標です。頻繁にデータが更新されるシステムでは、最近のポイントを指定する必要があります。一方、更新頻度が少ない場合は、復旧時点を長く指定します。RPOの設定にしたがって、バックアップの頻度が決まります。たとえばRPOを1時間に設定した場合には、1時間ごとにデータの保存が必要です。

目標復旧時間(RTO)

目標復旧時間(RTO、Recovery Time Objective)は、復旧までに必要な時間です。なるべく迅速に復旧させることが望ましいのですが、災害の種類や被害状況によっても異なります。したがって許容範囲を考慮した上で設定します。たとえば復旧時間を短く設定すると、復旧のための準備や人件費がかかることがあります。費用と重要性などを総合的に検討した上で判断します。

目標復旧レベル(RLO)

目標復旧レベル(RLO、Recovery Level Objective)は、災害から復旧させるレベルです。通常のレベルを100パーセントとして定めます。災害によっては、完全に元通りに復旧させることは困難であることから、許容できる範囲で設定します。RTOと組み合わせることにより「いつまでに、どの程度まで復旧させるか」という目標が明確になります。たとえば「業務システムを1日後に全体の7割のユーザーが利用できるまで復旧させる」場合は、RTO:1日、RLO:70%になります。

DR対策の運用方法

DRの指標を踏まえて、クラウドストレージを含めたITシステムのDR対策には4つの運用方法があります。それぞれ整理します。

バックアップ、リストア、レプリケーション

バックアップ、リストア、レプリケーションは低コストで運用可能であり、DRの基本ともいえます。主に次のような方法があります。

  • ローカルディスクや磁気テープなどへのバックアップ
  • クラウドストレージの活用
  • 複数インスタンスへのレプリケーション

ローカルディスクやメディアへのバックアップは、従来から行われてきました。しかし同じ施設内に保管されていると、バックアップが破壊されて復旧できない可能性があります。クラウドストレージへのバックアップは、同一施設にない安全性を確保するとともに、コストや運用負荷を軽減できます。レプリケーションはデータの複製を指しますが、基本的にリアルタイムで行われます。

コールド・スタンバイ

ここからはシステム全体に関わる対策です。コールド・スタンバイは、最小限の構成による予備サーバを用意し、予備サーバは稼働させずに停止状態にしておきます。稼働システムがダウンしたときは、サーバの起動やバックアップの復元などの作業が必要です。復旧の時間はかかりますが、コストを下げることができます。

ウォーム・スタンバイ

ホット・スタンバイとコールド・スタンバイの中間であり、コールド・スタンバイと異なる点としては、最小限の構成による予備サーバを稼働状態にしておきます。ホット・スタンバイよりコストを抑えられる一方、起動時に予備の環境をメインと同等にスケールアップやスケールアウトさせる作業が必要になります。

ホット・スタンバイ

稼働しているサーバと同じ構成の予備サーバを稼働および同期させ、問題があった場合、瞬時に予備サーバに切り替えられる状態にしておきます。OSやアプリケーションのすべてを切り替えて利用できるため、サーバダウンが許されない状況のシステムで使われます。ただし、これまでの方法の中で最もコストが高くなります。

クラウドストレージを活用したDRのポイント

金融機関のシステムのように停止が許されない環境では、ホット・スタンバイのDR対策が求められます。しかし現実的なDR対策の第一歩は、バックアップとリストアの整備ではないでしょうか。オンプレミスの環境では、設備のメンテナンスが必要になります。クラウドストレージを利用することで、初期費用と運用費用を抑えることができます。

クラウドストレージを活用したDRの進め方

最後にクラウドストレージを使ったDRの進め方をまとめます。

  1. BCPおよびDR全体構想のプランニング
  2. 組織体制の決定
  3. バックアップ・リストアの範囲と指標(RPO、RTO、RLO)の策定
  4. クラウドストレージサービスの選定
  5. サービスの決定、テストと検証
  6. 運用と見直し

重要なポイントは、復旧の範囲を明確にすることです。また、たとえバックアップが万全であっても、災害が生じたときにリストアできなかった場合は致命的になります。定期的な点検が必要です。

まとめ

異常気象に加えて社会情勢が大きく変動する現在、さまざまなリスクを回避するためにDR対策が欠かせません。DR対策には、許容範囲の判断のもとにコストを最適化する観点が必要です。Fleekdriveはバックアップの自動化など、DR対策に役立つ機能を備えています。BCPの一貫としてDR対策を検討中であれば、お気軽にご相談ください。