ディザスタリカバリとは

ディザスタリカバリ(Disaster Recovery、DR)とは「災害復旧」を意味します。災害などでシステム障害が発生した際に、迅速に復旧/修復を行うための仕組み、被害を最小限に抑えるための予防措置、そして組織体制を指します。

災害とは、自然災害(地震/津波/風水害など)のみではなく、「火災」「テロ」「不正侵入」「大規模ハッキング」「長期間大規模停電」などの広範囲な事象まで含み、システム全体に対して壊滅的被害をもたらすものを意味します。

システムダウンがもたらす影響

システムダウンは、多くの売上機会損失など、該当企業に対して多大な損害をもたらします。

また、顧客に対してのサービスレベルの低下につながります。サービスを提供する企業は、社会的責任を問われることも考慮に入れなければなりません。

ディザスタリカバリの目的

ミッションクリティカルなサービスを提供する企業にとって、予期せぬシステムダウンタイムに対応できる事業継続体制を構築することは極めて重要な課題です。

ディザスタリカバリは「システムダウンによる利益の損失を可能な限り最小限に抑える」ことを目的とします。

信頼失墜の拡大を防ぐために、「システムダウン予防措置」「確実なデータ保護」「ダウンタイムを最小限にする迅速なサービス復旧」が可能な信頼性の高い事業継続システムが求めらます。

壊滅的システムダウン(想定内障害/想定外障害)は、「もしかしたら起こるかもしれない」ではなく、「必ず起こるもの」と認知し、対策を取る必要があります。

業務継続計画とは

「業務継続計画」とは、システムが壊滅的被害を受けた場合に、迅速にサービスを復旧するために、「バックアップ指針」「災害時復旧手順」などを事前に定めておくものです。

「災害時の指揮本部の確保」「指揮命令系統」「連絡手段整備」などの組織体制面の対策が中心となります。

技術的なディザスタリカバリシステム設計は、「業務継続計画」に従い作成されます。

ディザスタリカバリの想定ケース

経済産業省が公表している「事業継続計画策定ガイドライン」では、ディザスタリカバリの想定ケースとして「大規模なシステム障害」「セキュリティインシデント」「情報漏えい」「データ改竄」などが上げられています。

必要とされる全システムの復旧が必要

システムの一部のみバックアップ対策が行われていたとしても、他のシステムと連動しなければ機能せず、業務が回らない場合が多々あります。

事業継続に必要なすべてのシステムがバックアップされ、迅速に復旧できる「業務継続計画」である必要があります。

「ディザスタリカバリ」は「企業の常識」に

以前は、特に中堅/中小企業において、「情報システムのバックアップ」という領域は、直接的な営業利益を生まない分野として後回しにされがちでした。

しかし、2011年3月の東日本大震災が発生したことを契機に状況が一変しました。システム停止が社会の大混乱を招くことを目の当たりにし、ディザスタリカバリの重要性を考えざるを得なくなりました。

今までディザスタリカバリを意識していなかった企業も含めて、多くの経営者/情報システム担当者は、危機感を持って、災害時事業継続性向上について取り組み始めました。

「ディザスタリカバリ(災害復旧)は企業の生命線」と捉える認識が高まり、多くの企業が、事業継続計画の作成/強化を行っています。

ディザスタリカバリの課題

ディザスタリカバリシステムを構築する場合には、多くの課題が存在します。主な課題を紹介します。

課題1　データバックアップ処理時のネットワーク帯域占拠

災害発生時のデータ損失を最小限に抑えるために、頻繁なデータバックアップは重要なポイントです。

しかし、日常の処理としてリモートバックアップを行う場合、バックアップが拠点間のネットワーク帯域を占拠してしまい、通常業務に支障を生じさせないようなネットワーク設計が必要です。

課題2　増加し続けるデータ量

IT化が進行し、さまざまなコンテンツがデジタルデータとして発生し続けています。そのため、企業のITシステムには、大規模なデータが蓄積されています。

膨大な量のデータをバックアップするためには、長時間を要します。ディザスタリカバリサイト(バックアップサイト)側のストレージ容量も増大します。

データ種類ごとに保護優先度を設定し「どれが守るべきデータなのか」について明確にしておく必要があります。

課題3　リカバリ時の復旧手順

災害が発生してシステムダウンとなった場合、サービス復旧(リカバリ)が必要です。

その手順は、シンプルに実行できるようにまとめられている必要があります。

バックアップデータが複数箇所に散在しているなど、煩雑な手順になっている場合には、できるだけシンプルな復旧手順となるように、全体設計を見直す必要があります。

データバックアップの目的

「保護」＋「活用」へ

従来、データバックアップは、IT機器の障害/故障に備えるために、「データを保護する」という目的で行われていました。現在のバックアップは、「データ保護」という要素に加えて、「データ活用」という意味でも必要になってきています。

企業や業界によっては、データの長期保存が義務づけられ、「監査」のために必要なデータをすぐに提出できることが求められています。

「単にバックアップしておけばよいもの」だけではなく、「バックアップデータを活用できる仕組み」も必要になっています。

ウイルス対策

最近では、「ウイルス対策」も目的の1つになっています。

特に、ランサムウェアに感染してしまった場合、データが不正に暗号化されてしまい、復旧できなくなる場合があります。特に、レプリケーション型のバックアップである場合、不正暗号化されたデータをバックアップ上書きしてしまうという状態になりかねません。

確実に復旧できるバックアップ体制が必要とされています。

デジタルフォレンジック

「デジタルフォレンジック(サイバー攻撃を受けた場合に原因を究明するための作業)」や「e-ディスカバリー(米国の電子証拠開示制度：訴訟時デジタルデータ開示)」などにおいても、バックアップの重要性が再認識されてきています。

ディザスタリカバリの指標

ディザスタリカバリに関する主な指標として「RPO」と「RTO」があります。

RPO(Recovery Point Objective)

「RPO」とは「データ保証時間目標」です。

「災害発生時点から、過去に向かってどの時点までのデータ復旧を保証するのか」を示す指標です。

「RPO=1日」である場合、1日1回のリモートバックアップで対応可能です。

「RPO=0(データ損失ゼロ)」を目指す場合は、データ常時即時バックアップ転送(レプリケーション)などの仕組みが必要です。

RTO(Recovery Time Objective)

「RTO」とは「復旧所要時間目標」です。

「災害発生時点から、何時間後(何日後)までにシステムを復旧させるのか」を示す指標です。

「RTO=1カ月以上」とする場合、「リモートバックアップのみを行い、代替機の確保から始める」でも対応可能であるかもしれません。

「RTO=数時間以内」の場合は、バックアップリモートサイトにスタンバイ機を準備しておき、レプリケーションの仕組みが必要です。

ディザスタリカバリ方式選定のポイント

「業務プロセス」と「ビジネスインパクト」の可視化

ITシステムのディザスタリカバリ対策の検討において、ITシステム部門が主導する場合が多くなります。

ITシステム部門は、業務プロセス全体を正確に理解していないことが多く、IT視点からのアプローチに偏ってしまいがちです。システム停止時のインパクトや影響範囲を把握できずに、復旧要件/サービスレベルを定義できないことになります。

ITシステムのディザスタリカバリ対策検討時には、「すべての業務プロセスの可視化」と「各システム停止時のビジネスインパクト」の明確化が重要です。

ビジネスインパクトが最も小さくなるようなディザスタリカバリ設計が必要です。

保護対象データ種類(データ整合性)

RTO/RPOのみに注目するのではなく、保護対象データの種類/重要度の分類が大切です。

それほど正確な整合性を要しないデータ(ファイルサーバなど)は、シンプルなプライマリストレージのバックアップのみで対応可能な場合もあります。

一方、整合性の確保が必要であるデータ(データベースシステムなど)は、不整合が生じないように正確なレプリケーションが必要です。

データ整合性種類ごとに適切なDR方式を選択する必要があります。

DR方式を決定する際の主な要素

保護対象システム規模(データ種類、容量)
復旧要件(RTO：データ保証時間目標、RPO：復旧所要時間目標)
予算

ディザスタリカバリ方式の種類

ディザスタリカバリシステムの主なバックアップ方式として、「遠隔地バックアップのみ」と「遠隔地データレプリケーション＋スタンバイシステム」があります。

遠隔地バックアップ

ディザスタリカバリシステムにおいて、ローカルバックアップに加えて、遠隔地(リモート)バックアップが重要です。

ローカルシステム内において、「バックアップ」や「RAIDシステム」を行っていたとしても、災害により建物全体に被害が及んだ場合、データ損失の恐れがあります。

単純に「データを保護する」という目的のみである場合、リモートバックアップのみで対応可能です。システム構成がシンプルであるため、低コストで導入できます。

東日本大震災以降は、日本東西や海外にバックアップデータを分散することも重要視されています。データセンターを利用したリモートバックアップも増えています。

「同期方式」と「非同期方式」

データコピーの方式には「同期方式」と「非同期方式」があります。

同期方式

バックアップサイトへのコピー完了を確認してから、サーバに完了報告を行う方式です。
プライマリサイトとバックアップサイト間でデータの一致が保証されます。

非同期方式

プライマリサイトのストレージへの書き込みが終わった時点で、バックアップサイトのコピー完了を待たずにサーバに完了報告を行う方式です。

非同期方式では、災害発生のタイミングによって、プライマリサイトとバックアップサイトのストレージの内容に差異が発生する可能性があります。

レプリケーション方式

「レプリケーション方式」は、常時、リアルタイムに、プライマリシステムのデータを、バックアップシステムへデータ転送する手法です。

プライマリシステムに障害が発生した場合、データが転送されているバックアップシステム側で、システムを継続できます。

「RPO(Recovery Point Objective）」の観点としては、バックアップ方式よりも、障害直前状態での復旧を行えます。

「コールドスタンバイ」と「ホットスタンバイ」

コールドスタンバイ

待機系のスタンバイシステムを構築しておきます。
システム自体は停止させておきますが、データについては、プライマリシステムからのレプリケーションにより、常時データ同期を行います。

プライマリシステムがダウンした場合には、手動でスタンバイシステムを起動して、サービスの継続を行います。

ホットスタンバイ

スタンバイシステム側でも、システムを起動させた状態にしておき、プライマリシステムがダウンした瞬間に、自動的に、スタンバイシステムをプライマリへ昇格させ、サービスを継続する仕組みです。

システムダウンタイムを短くすることが可能ですが、仕組みが複雑になるため、コストが高くなる傾向があります。

クラウドバックアップ

クラウド利用が一般的になってくるに従い、ディザスタリカバリにクラウドを利用するケースが増えてきています。

主なメリット

ハードウェアなどのIT資産を自社で管理する必要がない
必要量/必要スペックの機器を必要な時に利用できる
オンプレミスでバックアップシステムを構築するのに比べ、低コストで利用可能
ストレージサイズのオートスケール
コールドスタンバイの場合、システムを停止しておけば、利用料金が発生しない
レプリケーションとHAクラスタリングの利用において、インフラとして親和性が高い

コストとのトレードオフ

「RPO」と「RTO」が小さいほど、短いダウンタイムでの復旧が可能となりますが、それに従いコストが増大していきます。

「コスト面」と「各データの資産価値」を考慮し、どのレベルまでの対策が必要なのかについて、最適な方法を模索する必要があります。「自社での実施」と「外部サービス委託」についてのバランスも重要です。

要件を明確にし、ある程度許容しつつ、最小コストでディザスタリカバリシステムを構築することが求められます。

「経営層」と「ディザスタリカバリ」

事業継続計画の策定がディザスタリカバリシステム構築の前提となります。企業システムが非常事態に陥った場合の「組織としての行動」「復旧の優先順位」などのグランドデザインの中にディザスタリカバリを組み込まなければいけません。

そのために重要となってくるのが「経営層のディザスタリカバリに対する重要性の認識」です。ディザスタリカバリは、企業存続に関わる重要な経営判断となるため、現場任せではなく、経営層がディザスタリカバリプロジェクトを推進していくことが求められます。

まとめ

データは企業の重要資産として守らなければいけません。特に、日本は、地震/津波/火山噴火など自然災害の多い国です。

「災害には必ず巻き込まれる」という前提で、最適なディザスタリカバリシステムを構築し、事態に備えることが求められています。

オープンソースでディザスタリカバリを実現する「DRBD」に関するお問い合わせはこちら▼

参照元サイト

ディザスタリカバリとは