データのバックアップ体制、万全ですか目指せ! ネット時代の幸せな管理者(11)(2/2 ページ)

» 2008年10月06日 12時00分 公開
[山崎 佑司,@IT]
前のページへ 1|2       

「RTO」と「RPO」という指標

 前述したように、従来のバックアップ設計と比べて、新たな要件が加わっている昨今のバックアップ設計は、かなり複雑化

 この状況でバックアップを設計する手法の1つとして、バックアップを用いて、いざデータを復旧させることをシミュレーションする、つまりリストア設計からバックアップ設計を行う、という手法を利用します。

 その際の指標となるのが、RTOとRPOです。RTOは、目標復旧時間(Recovery Time Objective)のことで、障害や災害の発生からデータを復旧できるまでの目標時間を表す指標です。RPOは、目標復旧地点(Recovery Point Objective)のことで、障害

や災害が発生した際に、どの時点までのデータを復旧できるか、という目標地点を表す指標です。

 例えばRTOが1時間、RPOが1日、というバックアップ設計を行っている場合には、障害や災害発生時から最大1日前のデータを発生から1時間で復旧できる、という設計になります。

 一般に、RTOとRPOともに短時間に設定にするとコストは高くなり、長時間に設定するとコストは下がることになります。

 これらの数値は、BCPに照らし合わせ、コストとのバランスを考慮しながら決定されるべき数値であり、事前に整理したデータの種別ごと/重要性ごとにランク付けし、実際のバックアップ計画に落とし込んでいく必要があります。

 また、RTOの決定には、その障害の規模に応じた区分を加えて検討する必要がある場合があります。

 サーバのハードディスクドライブ(HDD)の障害が発生した場合と、災害が発生し、オフィスやデータセンタといった単位で障害が発生した場合とでは、障害復旧にかかる時間も異なります。それぞれの場合に対応するため、障害規模に応じて複数のRTOと、バックアップ設計を組み合わせて運用することも検討しましょう。

目標指標とバックアップ手法

 RTO/RPOがともに1〜数日という比較的長時間の設計を行う場合は、従来利用されているテープを用いたバックアップ手法を利用する場合が多いと思います。RPOは実質的にバックアップ間隔と同義となりますので、転送速度が遅いテープバックアップを利用する場合には、現実的にRPOが長くなってしまう、ともいえます。同時に、RTOも転送速度の影響を受け、長くなる傾向にあります。バックアップテープを他所保管する場合には、メディアそのものの輸送時間も影響します。

 一方でテープバックアップは、ほかのバックアップ手法に比べてトータルコストが抑えられることから、これらの時間が許容できる性質のデータのバックアップ設計には、有効な手段として利用されます。

 逆に、RTO/RPOがともに数秒(またはゼロ)という短時間が要求されるバックアップ設計を行う場合には、データバックアップのみならず、サーバやネットワークインフラの高可用性設計も併せて行うことが必要になります。

 RTOが数秒ということは、障害が発生した場合に、即時にサービスが復旧する(もしくは停止しない)ことが必須であり、それを実現するためには冗長化・クラスタリング化されたインフラを用意する必要があります。災害まで考慮する場合には、データセンタ単位での冗長化の検討が必要になるかもしれません。

 また、RPOが数秒ということは、直前のデータまで復旧させる(究極的にはデータ損失ゼロである)ことが求められます。

そのためには、同期レプリケーションされたバックアップデータが必要であり、それに伴うバックアップシステムを構築しなければなりません。そして、これらの実現には高いコスト投下が必要になってきます。

 また、目標指標とコストの両面から、これらの中間として存在する、Disk to Diskでのバックアップは、設計のしやすさや運用負荷のバランスから、よく利用されるバックアップ手法として存在しています。

 こうした例からも分かるように、バックアップ設計とバックアップコストは非常に密接な関係にあります。バックアップ運用は一過性のあるプロジェクトとは異なり、企業が存続していく限り、継続して運用しなければいけない業務です。より効果的かつ効率的にバックアップ運用を行うために、データの性質による整理/優先順位付けをしっかりと行い、適切な指標を策定していきましょう。

リストアシミュレーションの重要性

 これまでお話ししてきたようなポイントを考慮しながら、バックアップ設計を行っていくわけですが、皆さんお分かりのとおり、設計以上に重要な事柄として、運用が待っています。

 社内のデータを洗い出し、分類し、適切なバックアップ設計を行ったとしても、それらがきちんと運用され、データがバックアップされていなければ意味がありません。

 そして、万が一の場合に、バックアップされたデータから、サービスが復旧できなければ元も子もありません。

 そこで、普段の業務をこなしながらではなかなか手を付けるのが難しいかもしれませんが、日程を決めて、バックアップデータから、きちんとデータが復旧できるのかどうかのシミュレーションを行う、いわば非常訓練日を設けてみましょう。

 もちろん本番稼働しているサーバやインフラを停止するわけにはいきませんから、小規模な仮のサーバやインフラを用意し、障害が発生した状況をシミュレーションします。

 その際に、以下のようなポイントに気を付けて、いま行っているバックアップ運用は適切なのかどうかを確認し、不備があれば改善していきます。

  • 保存されたバックアップデータは、適切に入手することができるか
  • 入手したバックアップデータを用いて、サーバ/ネットワーク機器を復旧させることができるか
  • サーバ/ネットワーク機器の復旧により、サービスはきちんと稼働できるか
  • 設計したRPOまで、データが復旧できているか
  • 設計したRTO以内でサービス復旧することができたか

これを機に

 どうでしょうか。設計どおりにデータを取り戻すことができたでしょうか。

 バックアップ設計は定期的な見直しが必要となります。リストアシミュレーションは、そのきっかけになるでしょう。

 日常的に重要度を意識していながらも、後回しになりがちなバックアップ。これを機に「いまのバックアップ体制は十分なのか」と、問いかけてみませんか。

著者紹介

▼著者名 川村 聖一

2001年 日本電気株式会社入社。キャリア営業、法人顧客SEに従事。

2004年 同社ISP部門へ異動。ISPネットワーク設計・構築、新技術導入、ISMS取得に従事。

2006年 NECビッグローブ株式会社へ出向。法人向けアウトソースサービスのコンサルティング・設計・運用を担当。

Internet Weekプログラム委員。

2007年 JANOG運営委員として活動。

▼著者名 仲西 亮子

2000年 三井情報開発株式会社(現:三井情報株式会社)入社。

2000年 外資系ISPの技術部へ出向、IPアドレス管理やドメイン名管理業務に従事の後、同社iDCのバックボーン運用業務従事

2002年 三井情報開発株式会社でiDC事業開始と共に出向解除。同社でASの管理・運用業務に従事。

2005年 同社のiDC事業部がMKIネットワーク・ソリューション株式会社として子会社化。これに伴い、MKIネットワーク・ソ

リューションズ株式会社へ出向、現在に至る。

2007年 JANOG運営委員として活動。

▼著者名 山崎 佑司

1999年 ソニーシステムデザイン株式会社(現:ソニーグローバルソリューションズ株式会社)入社。ソニー本社をはじめと

した、大規模エンタープライズネットワークの設計、構築、運用を担当。

2001年 ソニーグループのショールームや、ソニーグループが主催する各種イベントにおけるネットワークシステムの企画、

設計、構築、運営を手掛ける。

2003年 ソニーグループiDCのネットワーク運用業務に従事。データセンターインフラの設計、構築等の業務を行う。

2006年 テオーリアコミュニケーションズ株式会社入社。システムインテグレーション全般を担当する。

2007年 JANOG運営委員として活動。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ