クラウドバックアップ

クラウド導入で時間もコストも節約!DR対策にも効くバックアップの活用ノウハウ

   

: #クラウド , #バックアップ , #DR , #ディザスタリカバリ , #BCP

By blog May 14 2021

share-blog
blog-image


企業の業績向上のためには業務効率の改善が不可欠です。そのために各担当者の方は様々な施策を行っていると思いますが、ITツールを賢く活用することもその一つでしょう。
今やクラウドはどの業種においても必須のツールですが、データバックアップを目的として導入している企業は全体の3割程度にとどまります。時間節約のためだけでなく、災害への備えとしても有効なクラウドバックアップについてご紹介します。

 

ツールは時間節約に効果的

総務省の令和元年度「通信利用動向調査」によると、全体の64.7%の企業がクラウドサービスを利用しているとのことですが、その内容として最も多かったのが「ファイル保管・データ共有」でした。社内で管理するファイルを紙ベース、添付ファイルでやりとりするのに比べて格段に時間を節約できるのがその目的ということが伺えます。
この例からも分かるように、業務効率化や生産性向上のためのツールは山ほどありますが、大切なのはツールを導入する目的をはっきりさせることです。ただ、漠然と「時間節約」のためというのではツール習熟に時間を費やしたにも関わらず、それに見合うだけの効果が得られないことにもなりかねません。

 

BCP(事業継続計画)とDR(災害復旧)

クラウドサービスを導入する別の理由として上げられるのはデータバックアップです。前述の「通信利用動向調査」によると、その目的でクラウドサービスを利用している企業は全体の31.4%ですが、それは人為的なミスだけでなく、大規模な災害へのリスクマネジメントも含まれているようです。それはBCP(事業継続計画)、つまり災害やテロ攻撃によって緊急事態に直面した場合、企業が事業資産の損害を最小限にとどめつつ、中核となる事業の継続あるいは早期復旧を可能にするための計画の一環ともいえます。
BCPと似た概念にDR(ディザスタリカバリ、災害復旧)がありますが、BCPが事業全体の復旧計画を包含しているのに対し、DRは災害やテロなどによって壊滅的になったシステムを復旧・修復すること、またそれに備える企業のシステムや体制を指す点で異なります。

 

ディザスタリカバリ(DR)とは?

ディザスタリカバリとは上記の通り、災害でダメージを受けたデータやシステムを復旧すること、またその対策を指します。

DRにおいて重要な要素はRPO(目標復旧時点)RTO(目標復旧時間)です。

以前のバックアップテストについての記事でも少し触れましたが、RPOとは、災害発生後にシステムを復旧するためにどの時点までさかのぼる必要があるのかを示す指標です。例えば、RPOが0秒であれば災害発生に関わらずデータの消失を回避することができますが、RPOが「前回のバックアップ」であれば災害が発生した時点から直近のバックアップ以降のデータはすべて失われることになります。

これに対してRTOとは災害発生後、オンラインに戻すまで「ダウンを許容できる最大時間」のことを指します。災害復旧のためにはRTOは短ければ短いほど良いのですが、例えばRTOを1時間とした場合、災害発生後1時間以内に復旧を完了させる必要があるということです。


ディザスタリカバリ(DR)とは?

 

なぜDRが必要なのか?

業務効率改善のためにITツールを利用すればするほど企業にとって重要な情報はデータとしてシステム内に保存されることになります。それら膨大なデータが災害によって失われたり、ダウンすることにより長時間アクセス不能になることの影響は計り知れません。
Infrascale社の災害復旧統計情報(2015年)によると、1時間のダウンタイムがもたらすコストは小規模企業で8,000ドル(約875,000円)、中規模企業で74,000ドル(約800万円)、大企業では700,000ドル(約7,660万円)に達する可能性があるとのことです。DR策定が不十分な企業は、ビジネスの中断を余儀なくされるため、顧客や取引先の信用を失い、情報漏洩のリスクにもさらされることになるでしょう。

 

事例【ヨーロッパ】大規模火災に見舞われるも、DR導入でデータを無事復元

平常時にDR策定が重要であることを示す事例をご紹介しましょう。2021年3月10日、ヨーロッパ大手のクラウドサービス「OVHcloud」の大規模なデータセンターで火災が発生しました。同社の顧客は世界中の企業150万社以上ということですから、管理していたデータがどれほど膨大だったのかは想像に難くありません。
こうした緊急時に巻き込まれたものの、火災直後に同社は復旧計画を発表、ライン川沿いにあるフランスのストラスブールのデータセンター4棟のうち、一棟は全焼しましたが10日後にはサーバーの再稼働が開始しました。この火災によりいくらかのデータは失われてしまったようですが、平常時からDR策定していたゆえに被害を最小限にとどめることができたことを示す例といえるでしょう。

 

DR対策に使えるシステムの選び方

では、企業はどのようにDR対策を講じることができるのでしょうか?DRの有効性とコストの面から大きく分けて2つのシステムが考えられます。
 

1.テープメディア(コスト:高、RTO:非常に長い)

文字通り「テープ」媒体にバックアップをとる方法です。物理的な媒体に保存するためデータの移動がしやすい点はメリットですが、メディアを保管するための環境条件の確保、運用コストがかかるなどの点は考慮が必要です。

たとえば・・・

・室温や湿度を厳格に管理する必要がある(オフィス以外に環境条件の良い保管場所が必要)

・データの読み出しに時間がかかる

・実は仕組みが複雑なため、他のバックアップ方法以上に専門的知識や特別な設備が必要になり、結果的に保守コストが高くついてしまう

「テープに保存していたデータを復元しようとしたら、保管条件が悪くてデータが欠損していた」「何度も使い回しをしているとテープが絡まってしまう」
「読み出しが遅い…」など、テープメディアの扱いで四苦八苦したユーザーの声も多いようです。

このようなことから、昨今ではテープに代わる新しい手段として外部ディスクやクラウドへのバックアップが主流となりつつあります。


テープメディア

 

2. ネットワークを通じてのリモートバックアップ(コスト:高、RTO:短い)

2つ目はネットワークを経由して、別拠点にバックアップを取る方法です。本データと別の場所にバックアップデータを置くために、DRとしては効果的です。また、復旧作業にはリストアが必要ですが、テープメディアに比べてRTOは短時間に抑えることが可能です。
ただ、自社用にバックアップロケーションを別途用意するため、コストは高くなるのが一般的です。


ネットワークを通じてのリモートバックアップ

 

データレプリケーションの重要性

「レプリケーション」という名前が示す通り、本データから予備系システムを作成し、障害発生持に即時切り替えを可能とします。システムの「二重化」ともいえるでしょう。この予備システムは常時稼働し続けることで、RPOの観点からするとDRとしては大変有効であるといえます。ただし、このレプリケーションも自社で構築を行うと大変なコストがかかります。

ただ、本システムを構築するのと同じだけのコストがかかる点、本データがウイルスに感染した場合、そのまま予備系に複製されてしまうなどのデメリットもあります。

 

「使えるCloudBackup+」の機能とメリット(コスト:低、RTO:短い)

使えるねっと提供の「使えるクラウドバックアップ+」はお客様の設定どおりに自動的にシステム全体をバックアップいたします。クラウド型バックアップなので、アプライアンス機器は不要、初期費用や運用コストを低く抑えられますし、オフィスと別のデータセンターに保管するためDRとしても最適です。

DRとして重要なデータレプリケーションを構築するためには導入コストが大幅に上がるのが一般的ですが、「使えるクラウドバックアップ+」ではコストを最小限に抑えつつシステムのレプリケーションによる二重化を実現、RTOも圧倒的短時間に抑えることが可能です。

 

「使えるCloudBackup+」なら低コストで労力を削減

必要な容量に応じて1日30円/1GB0.98円という低コストでデータを保護します。また、クラウドバックアップのため、専門的なITやセキュリティの知識、複雑な設定や構築作業も不要です。さらにシステムイメージ全体を一気にバックアップするため、通常のファイルバックアップに比べて、かなりの時間短縮も可能です。
30日間の無料トライアルで「使えるCloudBackup+」をお試しいただくこともできます。DR対策でお悩みの方は是非ご検討ください。

使えるクラウドバックアップ+(プラス)の詳細はこちら>>


お問い合わせ


無料通話:0120-961-166
(営業時間:10:00-17:00)

<< ブログHOMEへ
お問い合わせ
資料請求

Fatal error: Uncaught Error: Call to undefined function getAnchorDetails() in /var/www/vhosts/tsukaeru.net/httpdocs/blog-detail.php:342 Stack trace: #0 {main} thrown in /var/www/vhosts/tsukaeru.net/httpdocs/blog-detail.php on line 342