バックアップを取得することはデータが失われる可能性のある非常事態に備えた基本的な対策だが、いざというときに正しく復旧できなければバックアップの意味はない。正しい復旧のための準備とは。
「正しく復旧できなければバックアップは役に立たない」というのは当たり前のことのようにも感じるだろう。だが正しく復旧できることは、実は当然と言えるほどに簡単なことではない。バックアップから適切に復旧できるようにするには、どのような準備が必要なのか。
バックアップの整合性をテストすることは、事業継続計画(BCP)を計画通りに遂行する上で不可欠だ。データを正常に保管できていることを確認する作業は欠かせない。以下のような事象が発生し得るからだ。
バックアップの整合性をテストする確実な方法は、そのデータを使ってリカバリーを試みることだ。ただしリカバリーの対象がミッションクリティカルな本番システムである場合、現実的にはリカバリーのテストは実施しにくい。そのため代替案を用意しているベンダーもある。例えば仮想的なシステム環境を用意し、その環境をテスト用に使用するといった方法がある。とはいえ、仮想的には複製できないハードウェアへのリカバリーをテストすることも重要だ。
テストにおいて見落とされがちなのが、手順だ。バックアップテストはたいていの場合、
など、技術的な側面に重点を置いている。だがDRが失敗する原因は、技術的なことだとは限らない。特にランサムウェア(身代金要求型マルウェア)攻撃を受けているような状況では、スタッフは重圧を受けていることに加えて、コミュニケーションを取るための正常なネットワークが遮断され、指揮統制を維持することが困難になる。
そのためバックアップとリカバリーの手順では、いつ何を実施するのか、誰が責任を負うのかなどを定め、その通りに動けるようにすることが重要だ。明確な計画と手順は、最悪の事態が発生したときに非常に役立つ。それを用意しておくためには、手順をできるだけ現実的な状況の下でテストする必要がある。そうすれば、手順を実際に実行する際の弱点を特定し、前もって対処できるようになる。テストでは以下の点を確認しよう。
これらの点を確認するための包括的なテストを実施することで、自組織の準備状況と、レジリエンス(障害発生時の回復力)についてさまざまなことが明らかになるはずだ。
テストの目的は、いざというときに本番システムが意図した通りに機能できるようにすることだ。フェールオーバー(予備システムへの切り替え)を計画している場合は、正しく切り替えができるかどうかを確認する必要がある。
RTO(目標復旧時間)とRPO(目標復旧時点)が適切に設定されているかどうかも忘れてはいけないポイントだ。事業は変化するものなので、5年前に設定したRPOとRTOが、現時点では許容できないものに代わってしまっている可能性がある。
理想的なテスト頻度についての簡単な答えは、「できるだけ頻繁に」だ。バックアップとリカバリーの大規模なテストは混乱を招き、コストがかかる可能性があるので、年に1回程度が適切だと言える。より頻繁に実施できるテストもある。例えば重要なアプリケーションのみを対象にした部分的なテストや、アプリケーションの更新の一環として実施できる程度がテストなどがある。
米国TechTargetが運営する英国Computer Weeklyの豊富な記事の中から、海外企業のIT製品導入事例や業種別のIT活用トレンドを厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.
SEOは総合格闘技である――「SEOおたく」が語る普遍のマインド
SEOの最新情報を発信する「SEOおたく」の中の人として知られる著者が、SEO担当者が持つべ...
HubSpot CMSにWebサイトの「定石」を実装 WACUL×100のパッケージ第1弾を提供開始
WACULと100は共同で、Webサイトの「定石」をHubSpotで実装する「Webサイト構築パッケージ...
電通調査で「料理は面倒」が6割超 なぜそうなった?
電通の国内電通グループ横断プロジェクト「電通 食生活ラボ」は、「食生活に関する生活者...