編集部からのお知らせ
New! 記事まとめ「ISMAP-LIU」
話題の記事まとめ「通信障害と社会リスク」

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

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

2012-02-15 07:30

8.バックアップに奥行きがない

 青天井の予算がついていて、すべてのバックアップを、個別のスナップショットとして永久に保存できることなどない。このため、なんらかのスケジュールに従って、メディアをローテーションで使う必要がある。そのスケジュールが必要とされる奥行きと冗長性を提供する限り、そのこと自体に問題はない。

 わたしは3日分のバックアップを、「ニアライン」バックアップとしてローテーションで維持している。週に1回、ニアラインバックアップの1つをディスクに転送し、1か月に1度はそれらのディスクの内容を、オフサイトに送って永久保存している。それに加え、Exchangeサーバには独自に1日2回バックアップを実行させており、ニアラインストレージに同じスケジュールで保存している。SQL Serverにも別に1日1回バックアップを実行させており、これもニアラインストレージに保存され、14日間維持される。これによってわたしの組織では、素早く、ただちにオンラインに復旧できる。VM全体を大丈夫だと分かっている場所からリストアし、ExchangeサーバまたはSQLサーバのバックアップを使って、それを最新の状態にするわけだ。

9.オフサイトバックアップの場所が遠すぎる

 これが起こるのは、仮にオフサイトバックアップが必要になる場面があったとしても、どのみちそれを使えるようになるまでには時間がかかるため、簡単にアクセスできなくても問題にはならないと暗に仮定しているためだ。確かに普通はそうだが、必ずそうだというわけではない。時には、どうしてもそのオフサイトバックアップが必要で、それもすぐに使う必要があるという場面もある。オンラインバックアップは、物理メディアをオフサイトに送るのに比べれば便利な代替手段だが、もしいくつかのファイルを抜き出すためだけに、巨大なバックアップ全体をダウンロードする必要があれば、回線は非常に遅く感じるだろうということは考えておくべきだ。オフサイトバックアップを使用する場合は、簡単にアクセスできるようにしておいた方がいい。

10.文書が印刷されていない

 復旧プロセスを文書化しておくことは重要だ。しかし、よく忘れられていることがある。それは、システムが落ちているときには、自分のファイルにアクセスできないかもしれないということだ。例えば、ネットワーク関係の文書をすべてSharePointのサイトに置いていたとしよう。しかし、SQL Serverがやられていたら、どうやってSharePointにたどり着けばいいのだろうか。従って、必要になる可能性がある文書を印刷しておき、できれば物理メディアの近くに(必要なライブCDやその他のリストアのための機材と一緒に)置いておく必要がある。また、印刷した文書は常に最新のものにしておかなくてはならない。わたしがこの資料をSharePointに置くようにしている理由は、文書リストのRSSフィードを登録して、いずれかの資料が変更されたら通知されるようにしておけるからだ。

手痛い経験をしたことは?

 読者は、小さなミスや大きな見逃しのせいで、データ復旧作業に失敗したことがあるだろうか。もしあれば、復旧作業に関わる最悪の悪夢を、コメント欄で他の読者と共有して欲しい。

この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。

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

NEWSLETTERS

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

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

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