　バックアップの整合性をテストする確実な方法は、そのデータを使ってリカバリーを試みることだ。ただしリカバリーの対象がミッションクリティカルな本番システムである場合、現実的にはリカバリーのテストは実施しにくい。そのため代替案を用意しているベンダーもある。例えば仮想的なシステム環境を用意し、その環境をテスト用に使用するといった方法がある。とはいえ、仮想的には複製できないハードウェアへのリカバリーをテストすることも重要だ。

バックアップと復旧の手順をテストすることの重要性

　テストにおいて見落とされがちなのが、手順だ。バックアップテストはたいていの場合、

バックアップソフトウェアが意図した通りに動作するかどうか
バックアップデータから復旧できるかどうか

など、技術的な側面に重点を置いている。だがDRが失敗する原因は、技術的なことだとは限らない。特にランサムウェア（身代金要求型マルウェア）攻撃を受けているような状況では、スタッフは重圧を受けていることに加えて、コミュニケーションを取るための正常なネットワークが遮断され、指揮統制を維持することが困難になる。

　そのためバックアップとリカバリーの手順では、いつ何を実施するのか、誰が責任を負うのかなどを定め、その通りに動けるようにすることが重要だ。明確な計画と手順は、最悪の事態が発生したときに非常に役立つ。それを用意しておくためには、手順をできるだけ現実的な状況の下でテストする必要がある。そうすれば、手順を実際に実行する際の弱点を特定し、前もって対処できるようになる。テストでは以下の点を確認しよう。

バックアップデータを適切に見つけられること
リカバリー用のシステムをアクティブにできること
正しい順序でシステムのリカバリーができること
リカバリー用のシステムが意図した通りに動作すること
スタッフの誰もが自分の役割を的確に認識していること

　これらの点を確認するための包括的なテストを実施することで、自組織の準備状況と、レジリエンス（障害発生時の回復力）についてさまざまなことが明らかになるはずだ。

　テストの目的は、いざというときに本番システムが意図した通りに機能できるようにすることだ。フェールオーバー（予備システムへの切り替え）を計画している場合は、正しく切り替えができるかどうかを確認する必要がある。

　RTO（目標復旧時間）とRPO（目標復旧時点）が適切に設定されているかどうかも忘れてはいけないポイントだ。事業は変化するものなので、5年前に設定したRPOとRTOが、現時点では許容できないものに代わってしまっている可能性がある。

バックアップからの復旧をテストする頻度

　理想的なテスト頻度についての簡単な答えは、「できるだけ頻繁に」だ。バックアップとリカバリーの大規模なテストは混乱を招き、コストがかかる可能性があるので、年に1回程度が適切だと言える。より頻繁に実施できるテストもある。例えば重要なアプリケーションのみを対象にした部分的なテストや、アプリケーションの更新の一環として実施できる程度がテストなどがある。

Computer Weekly発　世界に学ぶIT導入・活用術

米国TechTargetが運営する英国Computer Weeklyの豊富な記事の中から、海外企業のIT製品導入事例や業種別のIT活用トレンドを厳選してお届けします。

TechTargetジャパントップシステム運用管理