ディザスタリカバリ(Disaster Recovery:略称はDR)という言葉をご存じですか。
日本語では「災害復旧」と訳されるこの仕組みは、地震や台風など天災による被害を受け、通常業務を行うのが困難になった場合を想定し、データやシステム自体を迅速に復元・復旧させる取り組みを表します。
DRが普及し始めた当初は天災のみを想定するケースが多かったですが、今では停電時やサイバー攻撃によるシステム障害といった、ITシステムの様々な非常事態に備える施策をDRと呼ぶのが一般的です。
この記事では、ディザスタリカバリの仕組みや構成する3つの指標、さらにディザスタリカバリと併せて紹介されることが多いBCPとの違いについて、わかりやすく解説します。

とある企業のシステム管理者として10年以上勤めています。 自身の経験や知識を活かし、誰にでも分かりやすい記事をお届けしたいです。
ディザスタリカバリとは?
ディザスタリカバリとは、自然災害や人為的災害によって使用不可となったシステムの復旧に備え、被害を最小限に抑えるための予防措置のことです。
重要なデータの保護、システム復旧時に使うバックアップの確保、さらには代替システムの用意など、様々なケースを想定して施策を検討する必要があります。
ここでは、ディザスタリカバリの仕組みに加え、ディザスタリカバリを構成する3つの指標についても解説します。
ディザスタリカバリとは
ディザスタリカバリは、災害によって被害を受けたシステムの早期復旧、もしくは、システム停止を予防するための体制づくり。ITシステムを活用する企業にとっては整備しておくべき施策です。
災害とは地震や台風といった天災だけでなく、火災や大規模停電、外部からのサイバー攻撃といった、システムが利用停止に陥る外的要因すべてが含まれます。
災害による被害を完璧に回避するのは難しく、それよりもいかにビジネスを停滞させないかに着目したプロセスです。
ディザスタリカバリ(DR)とBCPの違い
ディザスタリカバリ(DR)とよくセットで解説されるのが「BCP」です。BCP(Business Continuity Planning)とは、日本語では「事業継続計画」となります。
組織にとってビジネスを継続できないほどの緊急事態が発生した際、被害を最小限に食い止め、ビジネスを継続・早期再開させるためにあらかじめ方法や手段を計画しておくことです。
BCPは組織全体の戦略的な手法
BCPとは組織に起こり得るあらゆるリスクの発生時、いかにビジネスを継続させるかという戦略的な手法です。
BCPはビジネスの中核となる事業全てを対象とした計画なので、計画対象がシステムだけとは限りません。企業で働く誰にとっても無関係なものではないため、経営陣から従業員までBCP計画を共有しておくのが重要です。
災害からの復旧、そして復旧後の事業継続まで視野に入れたBCPを日頃からしっかりと立案・共有している企業は、顧客や市場関係者から高い評価を得られ、企業価値の向上にも繋がります。
また、BCPは一度立案すれば終わりではありません。BCP作成後に時間が経過した結果、計画通りに機能しなかったケースも見受けられるため、定期的に計画内容を見直し、常に現状に則した計画となるように維持を求められます。
DRは復旧対応に特化
BCPが事業全てを対象とした復旧計画に対し、ディザスタリカバリ(DR)はITシステムに特化した復旧計画です。
BCPは復旧後の事業継続まで含まれた計画ですが、DRはITシステムの復旧計画のみに絞っているため、BCPと比べても対象となる範囲が限定的であり、課題点や対策の洗い出しは比較的取り組みやすいと言えるでしょう。
業界ごとにDRの構築事例も多く、DRに特化したソリューションも多数存在します。DRは技術的側面が大きいので、まずはBCPとは異なる視点で策定するのをおすすめします。
3つの指標 RPOとRTO・RLO
ディザスタリカバリを評価する3つの指標として、RPOとRTO、そしてRLOを理解しておきましょう。
災害によって止まってしまった、もしくは水準が落ち込んだITシステムを「どれぐらいの時間で」「どの時点まで」「どの程度」復旧するのかを定めたものです。
それぞれに共通点や違いがあり、ITシステムの規模によっても変わってくるので、DRを策定する上で言葉の意味を理解しておくのが大切です。
ここでは、RPO・RTO・RLOについて詳しく解説します。
RPO(Recovery Point Objective):目標復旧時点
RPO(Recovery Point Objective)とは、日本語に訳すと「目標復旧時点」となります。復旧対象のITシステムにおいて、過去のどの時点までデータを復旧させるかの指標です。
RPOをどの程度に設定するかは、ビジネスの内容によって異なります。
例えばショッピングサイトを運営している場合、RPOは「ゼロ秒」に設定するのが理想的です。システム障害が発生する1分前に商品が購入された可能性があり、そのデータが復旧できないとなると、取引自体が存在しなかったこととなり、損失となってしまうからです。
しかし、ゼロ秒に設定したいのであれば、バックアップもほぼリアルタイムに取れる仕組みが必要となります。
このように、RPOをどの程度に設定するかはバックアップの頻度にも大きく関連するため、システムやデータの性質に応じてRPOを検討しなければなりません。
RTO(Recovery Time Objective):目標復旧時間
RTO(Recovery Time Objective)とは、日本語に訳すと「目標復旧時間」となります。復旧対象のITシステムをいつまでに復旧させるかの「時間」に関連した指標です。
システムが停止した場合、どれぐらいの時間でシステムを復旧できるかが大きなポイントとなります。被害状況にもよりますが、1時間で復旧できるのか、もしくは、数日レベルでかかるのでは大きな違いです。
ただし、RTOは闇雲に短く設定すればいいものではありません。
1日に数百万人が利用するシステムと、1週間に1~2回しか使わないシステムで比べると、復旧にどれだけ時間をかけていいかは明らかに異なります。システムの規模や性質によって、適切なRTOを検討しましょう。
RLO(Recovery Level Objective):目標復旧レベル
RLO(Recovery Level Objective)とは、日本語に訳すと「目標復旧レベル」となります。復旧対象のITシステムをどのレベル(水準)まで復旧させるかの指標。RTOとセットで策定されるのが一般的です。
平常時を100%とした場合、どのレベルまで達すればシステムを再開するかを定めたのがRLO。ビジネスの内容としてどの程度まで損失を許容できるかによって、目標値は変わってきます。
そのため、RLOは高く設定するほどより平常時に近づくので、損失は最小限に抑えられますが、RTOとのバランスも考慮しなくてはなりません。
また、RLOをいくつかの段階に分ける方法もあります。
第1段階として1日で主要な部分のみ復旧させ、第2段階では1週間かけて完全復旧を目指す考え方もありますので、ビジネスの性質に応じて検討してみてください。
ディザスタリカバリが重要な理由
企業にとってディザスタリカバリを準備するのが重要な理由をまとめます。
- システムダウン=サービスの提供停止を意味する
- システムダウン前の状況に戻すためには、多くの時間とコストがかかる
- 企業における危機管理の不備を露呈することで、企業価値は大きく下がる
ディザスタリカバリを準備しておけば、サービスの提供停止による損失を最小限に食い止められ、復旧までにどの程度の時間やコストが必要となるのか推測できます。
また、ディザスタリカバリを整備済みだとアピールできれば、利用者や株主からの信頼へと繋がり、企業価値が向上する効果も期待できるでしょう。
自社にディザスタリカバリの仕組みが無い、もしくは整備が不十分だと感じたら、一度検討し直すのをおすすめします。
ディザスタリカバリの3つの方法は?
引用元:Freepik
日本は自然災害が多く、特にこの十数年は各地で甚大な災害が多数発生してきました。企業においてディザスタリカバリを定めておくのは、自社を守る上で非常に重要であると理解して頂けたでしょうか。
そのディザスタリカバリにおいて、計画を実現するための方法がいくつかあります。
その中でも一般的によく活用される3つの方法について解説します。それぞれにメリット・デメリットが存在し、どの方法が一番適切かは企業の性質によっても異なる点に注意が必要です。
ミラーリング
ミラーリングとは、データバックアップを保管するストレージ装置を現地と遠隔地に2台準備し、サーバーOSの機能を使って遠隔地までデータを保管する方法です。遠隔地へデータを送るため通信回線が必要ですが、高頻度でバックアップを取得できる方法となります。
バックアップデータは全てストレージ装置内へ保管されるので、テープ保管で必要なテープ交換の手間が発生しません。テープ交換忘れなども起きない仕組みのため、バックアップの確実な保全が可能です。
一方、ストレージ装置が2台必要となるのが最大のデメリットとなります。保存領域が大容量なストレージ装置は、1台あたりがかなり高額であり、最低でも2台必要となるミラーリングはコストがネックとなる点に注意が必要です。
テープ保管
テープ保管とは、バックアップデータを磁気テープ内に保存し、そのテープを遠隔地へ運搬して保管する方法です。運搬したテープは耐火金庫内に保管するなど、火災や盗難などに対しても物理的に対策を施します。
磁気テープ自体は消耗品ですが単価が安いため、複数本の予備を持ちやすいのもメリットです。曜日ごとにテープを分けておけば、データ復元の際にどの時点まで戻すのか判断が付きやすくなります。
ただし、磁気テープは年数経過とともに劣化を避けられない媒体です。長期間、耐火金庫内に保管していたテープから復元する際、テープが劣化しデータが正常に戻らない場合も考慮しなければなりません。
また、テープ自体を遠隔地へ輸送しなければならないため、その分の運送コストが発生する点にも注意が必要です。
パブリッククラウド
パブリッククラウドとは、バックアップデータをAWSやGoogleCloudといったクラウドサービス上へ保存する方法です。災害の被害を受けたエリアへサーバー機器を置く必要がないため、同時被災を避けられデータを確実に守れるのがメリットといえます。
また、クラウドサービスは初期費用が安い、もしくは、数カ月は無料といったケースも少なくないため、初期費用を抑えられるのもパブリッククラウドの良い点です。
初期費用が抑えられる一方、パブリッククラウドは従量課金制を採用しているサービスも多く、使えば使う(転送するデータ量が多い)ほど、料金が嵩んでしまうのがデメリットです。
毎月のデータ転送量は予想がつきにくく、支払う料金が変動しやすいともいえます。
ディザスタリカバリ システムの選定ポイントは?
引用元:Freepik
ディザスタリカバリ用としてシステムを導入する場合、どのようなポイントに注意して選定すればいいでしょうか。
新たにシステムを導入するのは、決して安い投資ではありません。費用対効果を考え、ディザスタリカバリの要件を満たしているシステムかどうか慎重に検討しましょう。
ここでは、システムを選定する重要なポイントである「ビジネス要件の明確化」「システム環境に適した技術要件の検討」「予算とリソースのバランス調整」について解説します。
ビジネス上の優先順位を明確にする
ディザスタリカバリのシステムを選定する場合、まずビジネス上の優先順位を明確にする必要があります。
被災してすべてのシステムが停止、さらにサービス提供が不可能な状況へ陥った場合、どの事業を最優先に復旧させるのか決めておかなければなりません。これらの要件を明確にしておけば、RTO(目標復旧時間)やRPO(目標復旧時点)も決定できるでしょう。
優先順位を明確にするためには、平常時から様々な部門や関係者とのコミュニケーションも欠かせません。どの部署がどのような役割を担っているのか理解しておけば、より実状に則した優先順位を定められます。
ディザスタリカバリ システムに組み込む技術要件を選定
ビジネス上の優先順位を明確にできたら、次はシステムの技術要件を慎重に検討しましょう。
ディザスタリカバリ用に最適化されたシステムやIT技術は多数あり、技術要件を決定するためには、重要とするデータの種類や量、ビジネス規模などを考慮する必要があります。
また、データの保護が最優先なのか、システムの復旧・冗長化を最優先とするかによっても、選定するシステムが大きく異なる点に注意が必要です。コスト面にも大きく影響する部分ですので、ここは慎重に検討を行います。
既存の技術だけでなく、将来的な拡張や効率化も見込むのであれば、仮想化やレプリケーションといった新しい技術も候補として検討するのをおすすめします。
予算とリソース
もちろん、ディザスタリカバリに予算やリソースを無制限に注ぎ込めるのであれば、対策として限りなく完璧に近いシステムを構築できるでしょう。
しかし、実際にはそれだけの予算とリソースを割けるものではありません。あくまでも予算の範囲内でシステムを検討せねばならず、決して完璧ではなくとも、理想形に近い形でディザスタリカバリの仕組みを構築する必要があります。
その一方で、コストやリソースを必要以上に削減してしまうと、企業におけるディザスタリカバリとして中途半端なものにしかなりません。
ディザスタリカバリを検討する立場にある方には、ここまでで説明したビジネス上の優先順位・技術要件を検討し、適切な予算とリソースが配分される調整を求められます。
ディザスタリカバリのサイト設計:3つの運用方式
引用元:Freepik
ECサイトなど、被災時であっても極力サービス停止を避けなければならないサイトを運営する場合、サイト設計におけるディザスタリカバリが求められます。
ここでは、システムを停止させない、もしくは、システムの早期復旧が実現可能となる3つの運用方式をご紹介します。
運用方式によって復旧速度やコスト、リスク対応のレベルが変わってくるので、自社のビジネスにとってどの方式が適切なのか、慎重に選ぶ必要があります。
ホットスタンバイ
まず、スタンバイとは「サーバーやストレージといった、システムが稼働する上で必要なハードウェアの予備を準備する方法」を表します。
実際に本番環境として運用しているサーバー類と同じ構成で備えておくことで、何かしらの障害が発生した際もすぐに切り替えが可能という特徴があります。
そして「ホットスタンバイ」とは、予備のサーバー類も常に電源を入れておき、本番環境と同じように稼働させる方式です。ホットスタンバイのメリットとしては、常に本番環境と予備が同じ状であるため、障害が発生しても即座に切り替えできます。
システム障害の影響は最小限に抑えられますが、デメリットとして、運用コストが2倍必要になる点は注意が必要です。
絶対に停止できないサイトや、停止をわずかに抑えなければならないサイトにおすすめの方式といえます。
コールドスタンバイ
ホットスタンバイに対し「コールドスタンバイ」は、サーバー類の予備を準備しておく所までは同じですが、平常時は予備のサーバー類の電源を落として使わない状態にしておく点が異なります。電源を入れないため、運用コストがかからない点が最大のメリットです。
しかし、コールドスタンバイは、システム障害発生時に手動で切り替えなければならない点がデメリットといえます。
バックアップデータとの同期が必要になるなど、切り替えには時間がかかるため、数時間~1日近くシステム障害が発生しても影響の少ないサイトにおすすめの方式です。
ディザスタリカバリに対応できているサイトを構築したいが、コストは抑えたいといった場合にも最適といえます。
ウォームスタンバイ
ウォームスタンバイは、ここまでご紹介したホットスタンバイ・コールドスタンバイ両方の特徴を併せ持つ方式です。
予備のサーバー類も常に電源を入れておく点はホットスタンバイと同じですが、ウォームスタンバイ用として準備するサーバー類は、本番環境よりも少しスケールダウンした構成にする点が異なります。
本番環境が完全復旧するまでのいわば”繋ぎ”としての使い方ができ、常時電源が入っている点でコールドスタンバイよりも早期でシステムを再開させられるのが特徴です。
本番環境と同じだけのリクエスト処理能力はありませんが、コストも抑制できるため、まさに折衷案ともいうべき方式となります。
コストは抑制しつつ、システム停止の影響を小さく抑えたいケースに最適です。
ディザスタリカバリのまとめ
いかがでしたでしょうか。今回は、ディザスタリカバリの仕組みや3つの方法、BCPとの違いなどをご紹介しました。
日本国内では様々な天災が毎年のように起きており、いつどのタイミングで災害が発生するのかは分かりません。予期せぬ災害によってシステムが停止した場合、「どのようにシステムを復旧させるか」が非常に重要であり、企業におけるBCP、そしてディザスタリカバリを平常時に考えておく必要があります。
ディザスタリカバリを構成する3つの指標、そして、主に採用される3つの方法を正しく理解し、自社に合ったディザスタリカバリの内容を検討してみてはいかがでしょうか。
ディザスタリカバリの内容について不明な点がある、もしくは、どのようにシステムを選定すればよいかお悩みの場合、ぜひ株式会社Jiteraへお問い合わせください。
貴社の課題点について伺わせて頂き、最適なディザスタリカバリ案を提案させて頂きます。