日常の業務において、ITシステムは必要不可欠になっている。紙での記録に変わり、電子的なデータでのやり取りが増えており、連絡方法としてのメールも一般的になっている。
このような状況の中で、ファイルサーバやメールサーバの障害によるデータの損失は、企業にとって多大なリスクとなり得る。このようなデータ破損に備えるためのディザスタリカバリ（DR）対策として、基本的な手法がバックアップである。
失敗を簡単に把握できるか
規模が比較的小さなシステムの場合、IT管理者が複数の業務を兼任している場合が多い。バックアップのオペレーションに特別な技術習得が必要では困るのだ。また、大切なデータだからこそバックアップが求められるわけで、設定ミスがあってもいけない。
そこで、設定のしやすさがポイントとなる。複雑で高度な機能も重要だが、使いこなせるかどうかもしっかり検討してほしい。もうひとつの大きなポイントは、バックアップの失敗を簡単に把握できるかどうかだ。
バックアップは、業務に影響の少ない夜間にスケジュールを設定し、無人で自動的に実施することが多い。しかし、設定ミスやメディアの不良などのため、バックアップが失敗していても気づかないままの場合もある。何か障害が起きていざリストアしようと思っても、実はバックアップが失敗し続けていたということが起きないよう、どのように失敗を把握できるのかを確認し、失敗のチェックを業務の一環として行うことが肝要だ。
画面1：「Symantec Backup Exec」の例。スケジュールをクリックで設定できる
画面2：バックアップの失敗などのアラートも表示する
RPOとRTO、保持期間でポリシーを策定
バックアップに必要な機器を調達する前に、バックアップポリシーを策定する必要がある。これには以下のような要件を決める必要がある。
- RPO（Recovery Point Objective）：リカバリポイント目標
RPOとは、いつの時点のデータを復旧する必要があるかということで、これはバックアップを実行する頻度となる。バックアップは毎日実行するようスケジュールすることが一般的だ。つまりRPOは24時間となる。 - RTO（Recovery Time Objective）：リカバリ時間目標
RTOは、リカバリに要する時間のことで、障害が起きてから復旧までにシステムのダウンタイムをどの程度許容できるかということである。テープにバックアップを取り、棚にしまってある運用では、障害時には、棚からテープを探してこなくてはいけない。一方、常時接続しているハードディスク（HDD）にバックアップを取っている場合では、すぐにリストア作業が開始できる。また読み込みのスピードも直接RTOに影響する。 - データの保持期間
バックアップデータを何世代保管するかによって、必要なメディアの容量が決まってくる。ハードウェア障害だけを想定するのであれば、最新の状態にだけリストアできれば良く、長期に渡って保管する必要はない。
データを間違って上書きや削除してしまった場合、あるいはソフトウェアの不具合やウイルスによってデータが書き換えられた場合にも対応するのであれば、インシデントの発生からそれに気づくまでに時間が掛かることもあるので、1カ月程度は保管しておいた方がいいかもしれない。また、財務データや顧客との機密情報のやり取りを保全する目的であれば、さらに長い期間の保存期間が必要になる。
これらの要件は、アプリケーションの種類やデータの重要度によって異なることも想定し、ITシステム要件としてルールを定義した上で、組織内で一貫したポリシーを策定し運用することが好ましい。
