あるユーザはStationery Supply社で単一サーバ構成のネットワークを管理しています。サーバは1台しかないので、レプリカ機能で障害に備えるわけにはいきません。その場合、eDirectory 8.7.3に組み込まれた新ツールBackup eMToolを使えば、eDirectoryのバックアップ/復元処理が容易になります。サーバ単位で処理を行う方式であり、しかも高速だからです。
これまでWindows NT ServerでeDirectory 8.6.2を稼動させていましたが、8.7.3にアップグレードした結果、Backup eMToolを起動するバッチファイルを用意し、定期的に無人でバックアップを行えるようになりました。
毎週日曜の夜にフルバックアップを取り、さらに平日は毎晩、インクリメンタルバックアップを取るようにしました。また、eDirectoryの無人バックアップのすぐ後に、ファイルシステムのフル/インクリメンタルバックアップを取るようにします。バックアップテープには、ファイルシステムデータのほか、eDirectoryの最新バックアップも保存されることになります。さらに、データ保存サービス会社と契約して、バックアップテープを社外に保管することにしました。
毎週月曜日の朝、バックアップログを調べて、正常にフルバックアップが取れていることを確認します。また、普段から時々、インクリメンタルバックアップの状況をログで調べています。
ロールフォワードログの機能は無効にしています。それは次のような理由によります。
Stationery Supply社では、人事異動などによりツリー構成を大きく変える場合は、その直前と直後に、手動でバックアップすることにしています。日曜日以外でも、必要に応じて臨時のバックアップを取ろうというわけです。これがロールフォワードログに代わる措置です。
必要になればいつでもバックアップ作業ができるよう、時々テストして確かめています。テスト用にもう1台サーバを購入する予算はないので、市内にあるサービス会社と契約し、必要なときだけサーバを使わせてもらえるようにしました。実機と似た構成のサーバにオペレーティングシステムをインストールし、eDirectoryデータベースの環境もできるだけ同じように構築します。このサーバに、実機から取ったバックアップファイルを使って復元し、想定どおりに復元されていることを確認するのです。
ある水曜日の朝、eDirectoryが格納されたハードディスクの故障が見つかりました。そこで新しいハードディスクを手配したほか、日曜日に取ったフルバックアップファイル、月曜日および火曜日に取ったインクリメンタルバックアップファイルを用意しました。次に、ハードディスクを交換し、eDirectoryをインストールしました。その上に、フル/インクリメンタルバックアップファイルから復元しました。水曜日の朝、故障が起こる前にツリー構成を変更しましたが、これは復元できませんでした。ロールフォワードログを残しておかなかったからです。しかし火曜日夜の状態まで復元できたことで満足しています。ロールフォワードログを取るための管理の手間を考えれば、許容できる範囲だと考えているからです。
あるユーザがOutdoor Recreation社でeDirectoryが稼動する10台のサーバを管理しています。毎週日曜の夜にフルバックアップを取り、さらに平日は毎晩、インクリメンタルバックアップを取っています。eDirectoryのバックアップ後すぐに、ファイルシステムバックアップによりテープに保存しています。
サーバはすべてレプリカリングに属しています。ロールフォワードログ機能は全サーバで有効です。また、その保存先は、eDirectoryとは別の記憶デバイスに割り当てています。ディスクの空き容量やアクセス権は随時監視して、ロールフォワードログであふれてしまわないよう注意しています。使用済みのロールフォワードログは、時々テープにバックアップして削除し、空き容量を増やすようにしています。
もちろんロールフォワードログを有効にすると管理の手間が増えますが、それを上回る利点があると考えています。サーバがレプリカリングに属している場合、いつでも最新の状態をバックアップしておく必要があるからです。こうしておけば、障害が発生しても、他のサーバとの同期状態も含めて元どおりに復元できます。
さらに、テスト環境で定期的にバックアップファイルからの復元を試み、想定どおりに動作することを確認しています。
ある木曜日の午後2時、Inventory_DB1というLinuxサーバの、eDirectoryを格納しているハードディスクが故障しました。
そこでまず、最新のフルバックアップファイルとそれ以降のインクリメンタルバックアップファイルを集め、昨晩午前1時の状態にまでデータベースを復元します。ロールフォワードログは昨夜のバックアップ以降の変更を記録しています。そこで次に、午前1時以降のロールフォワードログを使って、故障が起こる直前の状態に戻さなければなりません。
次のような手順で作業を進めることにしました。
フルバックアップ用のバッチファイルは、ファイル/adminfiles/backup/backupfull.bkにバックアップするようになっています。
ファイルの容量制限を200MBと設定していたので、次の2つのファイルがありました。
インクリメンタルバックアップ用のバッチファイルは、ファイル/adminfiles/backup/backupincr.bkにバックアップするようになっています。
毎日同じバッチファイルを使っているので、ファイル名は常に同じです。しかし、テープからサーバにコピーする時に、ファイル名を変更しなければなりません。復元処理の際は、全ファイルを同じディレクトリに集めておく必要があるからです。
幸いLinuxオペレーティングシステムを格納したハードディスクは故障しなかったので、Linuxの再インストールは必要ありませんでした。
どれも同じbackupincr.bkというファイル名なので、次のように改名します。
注: インクリメンタルバックアップファイルは、必ずしもフルバックアップファイルと同じディレクトリにコピーしなくても構いません。ただし各インクリメンタルバックアップファイルはすべて同じディレクトリに置いておく必要があります。
バックアップファイルの場所として、「/adminfiles/restore」を指定。
復元処理に関するログファイルの出力先として「/adminfiles/restore/restore.log」を指定。
［データベースを復元］チェックボックスをオン。
［ロールフォワードログの復元］チェックボックスをオン。
ロールフォワードログの保存先を入力。
これは普段ロールフォワードログを保存している場所です。eDirectoryとは別のハードディスクなので、今までのロールフォワードログが残っているはずです。
［セキュリティファイルの復元］チェックボックスをオン。
［検証後に復元されたデータベースをアクティブにします］チェックボックスをオン。
［復元の完了後にデータベースを開きます］チェックボックスをオン。
これは、復元後の検証に成功したらeDirectoryをオープンするための指定です。
ロールフォワードログはそのまま残っており、その場所を正しく指定したため、停止直前の状態に復元でき、検証も成功しました。
ロールフォワードログの機能は、復元処理の過程で無効に戻ってしまうため、ここで有効にする必要があります。フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
サーバの稼動状況を調べ、正常に動作していることを確認しました。
ユーザはGK Designs社で15台のサーバを管理しています。毎週土曜の夜にフルバックアップを取り、さらに毎晩、インクリメンタルバックアップを取っています。eDirectoryのバックアップ後すぐに、ファイルシステムバックアップによりテープに保存しています。
サーバはすべてレプリカリングに属しています。ロールフォワードログ機能は全サーバで有効です。
ある日、漏電による火事のため、ある支店のサーバが1台、完全に使えなくなってしまいました。幸い、このサーバのパーティションは、ひとつを除いてすべて、他のサーバにレプリカが作成されていました。ロールフォワードログ機能は有効にしていましたが、それも使えなくなってしまいました。したがって、停止直前の状態にまでeDirectoryデータベースを復元することはできません。
しかしバックアップファイルがあるので、サーバのeDirectory識別情報は再作成できます。ロールフォワードログは使えないので、他のサーバとの同期状態は元に戻せません(遷移ベクトルと復元後の検証処理を参照)。検証処理には失敗するはずです。したがって、復元処理が終わってもeDirectoryデータベースはオープンされません。
そこで、レプリカリングからいったんサーバを外し、DSRepairを使って、他のサーバを参照してレプリカを作る設定に変更しました。その結果、最新のレプリカを保持しているサーバからデータを参照し、最新の状態が作り出されます。具体的な手順は復元後の検証処理に失敗した場合の対処方法を参照してください。
レプリカが作られていなかったパーティションがひとつありました。これは、支店内にあるファックス/プリンタ複合機や大判カラープリンタなど、この支店内のネットワーク印刷オブジェクトを管理しているコンテナです。他のサーバにレプリカがないため、このパーティションは上述の手順では復元できません。このパーティションのオブジェクトは一から作り直さざるをえなかったので、将来に備え、これも他のサーバにレプリカを作っておくことにしました。
そこでロールフォワードログに関する設定をやり直し、改めてフルバックアップを取っておきました。ロールフォワードログの機能は、復元処理の過程で無効に戻ってしまうためです。
ユーザは3ヶ所に分けて設置された20台のサーバを管理しています。その1ヶ所で、水道管破裂による水漏れ事故のため、8台のうち5台が使えなくなってしまいました。
幸い、どのサーバについても、eDirectoryのバックアップを取っていました。しかし全サーバともレプリカリングに属しており、ロールフォワードログはなくなってしまったので、これを使わずに復元作業を進めなければなりません。最初にどのサーバから着手し、レプリカ間の不整合をどのように解消すればよいか、判断できませんでした。状況があまりに込み入っていたため、Novellの技術担当者に相談することにしました。
ユーザとそのチームは、Human Resource Consulting社で1ヶ所に設置された50台のサーバを管理しています。
普段から障害対策のため、ツリーの各パーティションについて3つずつレプリカを作成しています。したがって、サーバが1台停止しても、そのパーティションにあるオブジェクトは他のサーバからアクセスできます。さらに、各サーバに障害があっても復元できるよう、Backup eMToolで定期的にバックアップするほか、ロールフォワードログ機能を有効にし、バックアップテープは別の建物に保管しています。
災害に備えるため、チームでは2台のサーバをDSMASTERとして割り当てています。2台を割り当てているのは、ツリーが大きすぎて、1台では全パーティションのレプリカを保持できないからです。ツリーに属するどのパーティションも、いずれかのDSMASTERサーバにレプリカが作成されています。逆に、同じパーティションのレプリカが2台のDSMASTERサーバに作成されることはないようにして、重複を避けています。これが災害対策として重要な点です。
さらにチームでは、テスト環境で定期的にバックアップファイルからの復元を試み、想定どおりに動作することを確認しています。
ある日、台風で社屋が倒壊し、データセンタにあったサーバもすべて壊れてしまいました。
台風が去った後、チームではまず、パーティションすべてのレプリカを保持する、2台のDSMASTERサーバを復元する作業に取りかかりました。最新のフルバックアップファイルおよびそれ以降のインクリメンタルバックアップファイルを使いましたが、ロールフォワードログは使いませんでした。サーバが壊れたときに、いっしょになくなってしまったからです。DSMASTERサーバを設定する際、この2台が同じレプリカを保持することはないようにしていました。そのため、ロールフォワードログを適用しなくても、復元後の検証処理は問題なく成功したのです。DSMASTERサーバが復元されたことにより、Human Resources Consulting社のツリーに属するオブジェクトはすべてアクセスできるようになりました。
DSMASTERが復元できれば、整合性を損なうことなくツリー全体を再作成できるので、その役割は非常に重要です。
このチームは、ロールフォワードログの機能も有効にしていました。障害が発生する直前の状態にまでサーバを復元でき、レプリカリングに属する他のサーバとの同期状態に不整合が生じないからです。サーバが復旧し、他のサーバと通信できるようになると、停止していた間に行われた更新情報を自動的に受け取り、同期を取ることができます。
しかし今回はそのロールフォワードログを使えません。その場合、レプリカリングに属するサーバのうち、最初に復元処理を実施したものしか正常に復元できないことになります。それ以外のサーバは、他のサーバと同期状態が一致しないということで、復元後の検証処理に失敗してしまうのです(遷移ベクトルと復元後の検証処理を参照)。検証処理に失敗すると、このeDirectoryデータベースはアクティブになりません。
しかしこのチームは、このような状況もきちんと考慮していました。2台のDSMASTERサーバを設定し、重複して保持するパーティションがないようにして、これを復元作業の起点としたのです。重複がないので検証処理に失敗することはありません。これをマスタとして順次他のサーバにコピーしていけば、レプリカリング全体が復元できることになります。
DSMASTERサーバの復元後、他のサーバを復元するために、いくつか必要な作業があります。このチームは次のような手順で、他のサーバを順次復元していきました。
ロールフォワードログがないため、復元後の検証処理に失敗することは分かっています。したがって、データベースは復元されても、まだアクティブになっていません。
この時点で、各サーバの識別情報は元どおりに戻っていますが、レプリカ情報を同期させようとはしません。他のサーバからレプリカのデータを受け取り、改めて構築できる状態になっています。
なお、NetWareサーバの場合、ファイルシステムの復元はeDirectoryの復元後に行う必要があります。
各サーバにどのレプリカが置かれていたか、チームではきちんと把握していました。もっとも、最終バックアップ時点の状況は、バックアップファイルのヘッダを見れば確認できます。
具体的な手順は復元後の検証処理に失敗した場合の対処方法を参照してください。
かなりの作業量でしたが、ツリー自身は比較的早期に使用できるようになり、その時点でサーバ全体を復旧する目処も立っていました。