データ復旧計画を崩壊させる10の要因--いざというときに顔面蒼白にならないために

Justin James (TechRepublic) 翻訳校正: 石橋啓一郎

2012-02-15 07:30

 わたしは「失敗は百万に1つの確率」のシナリオでは、ダメージが最大になるときに問題が起きるということを学んだ。データ復旧計画がその好例だ。わたしは、よくできた計画が小さな、あるいは大きな間違いで崩れてしまうのを見ている。この記事では、データ復旧計画を崩壊させる10の問題を挙げ、問題のあるシナリオにどう対処すべきかを示すことにする。

1.バックアップの不良

 システムの運用状況をオンラインに復旧するのが絶望的になったときに、バックアップデータに問題があるのを発見することほど落ち込むことはない。24時間365日の運用が求められる今日では、問題のないバックアップを取るのは難しい場合も多い。多くのアプリケーションは、バックアップソフトウェアとの相性がよくないように見える。時には、バックアップデータそのものの保管が不適切な場合もあり、これはあらゆる種類の問題を引き起こす。そしてもちろん、複雑すぎるバックアップアプリケーションや、想定通りに動かない設定や、ハードウェアが原因で問題が起こる可能性もある。これらの要因が、必要なときに役に立たないバックアップを作り出す。一番必要なときに確実に役に立つようにするには、バックアップシステムを細かくモニタリングし、定期的にテストすることだ。もしうまく動かなければ、最優先でその問題を解決する必要がある。

2.復旧する手段がない

 あらゆるバックアップは、リストアプロセスの開始にライブCDやその他の手段が必要な場合、それが手元になければ価値はない。もちろん、この問題は予行演習で発見されているはずだ。しかし、そのリストアのためのシステムは、常にすぐに使える状態にしておく必要がある。バックアップと一緒にコピーを1つ置いておくのはよいアイデアだろう。

3.復旧後のテスト計画が用意されていない

 システムをリストアしたが、数日後あるいは数週間後に同じ問題が起こっているのに気づいたことはあるだろうか?わたしはある。そしてこれは良くない状況だ。システムやアプリケーションが問題である場合、根本的な原因(例えばウイルス)がバックアップに紛れ込んでいるのかもしれない。リストアを行ったら、大きく分けて2種類のテストを実行する必要がある。一般的なシステムとアプリケーションが、最低限必要とされる正常な状態に戻っているのを検証するテスト、そしてリストアを引き起こした特定の問題が解決しているのを確認するテストだ。前者は必要になるずっと前から用意され、文書化され、公開され、あらかじめ演習が行われていなくてはならない。後者は通常、状況に応じてその場で決定される。

4.復旧を行うハードウェアがない

 復旧の原因となる問題は、ソフトウェア(ウイルス、OSのメルトダウンなど)だと仮定している(あるいは願っている)人もいる。そういう人のハードウェアの調達は、それを反映している。しかし実際には、完全なシステムをリストアできるハードウェアがなければ、完全なリストアプロセスがあるとは言えない。そのハードウェアは、復旧する必要のあるシステムをそのままリストアして動くだけのものでなくてはならない。さもなくば、単にハードウェアは決して故障しないという大きな賭けをしているのと同じだ。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

注目している大規模言語モデル(LLM)を教えてください

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]