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発の記事を朝日インタラクティブが日本向けに編集したものです。