あるユーザはStationery Supply社で単一サーバ構成のネットワークを管理しています。サーバは1台しかないので、耐障害性を得るためにレプリケーションに頼ることはできません。その場合は、バックアップツール機能を使えば、eDirectoryのバックアップ/復元処理が容易になります。この機能は、サーバに特化されているため、高速です。
eDirectory 8.7.3以降のバージョンで、バックアップツールを実行するためのバッチファイルを使用してサーバの無人バックアップをセットアップしました。
毎週日曜の夜にフルバックアップを取り、さらに平日は毎晩、インクリメンタルバックアップを取るようにしました。また、eDirectoryの無人バックアップのすぐ後に、ファイルシステムのフル/インクリメンタルバックアップを取るようにします。バックアップテープには、ファイルシステムデータのほか、eDirectoryの最新バックアップも保存されることになります。さらに、データ保存サービス会社と契約して、バックアップテープを社外に保管することにしました。
毎週月曜日の朝、バックアップログを調べて、正常にフルバックアップが取れていることを確認します。また、普段から時々、インクリメンタルバックアップの状況をログで調べています。
ロールフォワードログの機能は無効にしています。それは次のような理由によります。
サーバには独立した記憶デバイスがついていないので、ロールフォワードログを有効にしてもバックアップとしては役に立ちません。記憶デバイスが故障すれば、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の再インストールは必要ありませんでした。
バックアップテープを使って、障害を受けたディスクパーティションを復元しました。
次にeDirectoryを再インストールし、仮のツリーを作りました。復元処理では、いったんこのツリー上にデータを復元してから実動ツリーに切り替えることになります。
サーバ上に、バックアップファイルを集めておくためのディレクトリ/adminfiles/restoreを作りました。
フルバックアップファイル(2つに分割されているもの)を、このディレクトリにコピーしました。
さらに、月曜、火曜、水曜のインクリメンタルバックアップファイルもコピーしました。
どれも同じbackupincr.bkというファイル名なので、次のように名前を変更します。
メモ:インクリメンタルバックアップファイルは、必ずしもフルバックアップファイルと同じディレクトリにコピーしなくても構いません。ただし各インクリメンタルバックアップファイルはすべて同じディレクトリに置いておく必要があります。
次にiManagerを使ってeDirectoryを復元することにしました。
iManagerを起動し、［eDirectoryの保守］>［復元］の順にクリックします。
サーバにログインしました。コンテキストとしては、仮に作っておいたツリーを使います。
［復元ウィザード – ファイルの環境設定］画面で次のように操作しました。
バックアップファイルの場所として、「/adminfiles/restore」を指定。
復元処理に関するログファイルの出力先として「/adminfiles/restore/restore.log」を指定。
［復元ウィザード - オプション］画面で次のように操作しました。
［データベースを復元］チェックボックスをオン。
［ロールフォワードログの復元］チェックボックスをオン。
ロールフォワードログの保存先を入力。
これは普段ロールフォワードログを保存している場所です。eDirectoryとは別のハードディスクなので、今までのロールフォワードログが残っているはずです。
［セキュリティファイルの復元］チェックボックスをオン。
［復元されたデータベースを検証後にアクティブにします］チェックボックスをオン。
［復元の完了後にデータベースを開く］チェックボックスをオン。
これは、復元後の検証に成功したらeDirectoryをオープンするための指定です。
復元処理を起動し、インクリメンタルバックアップファイル名を問い合わせるメッセージが表示されたので入力しました。
復元後の検証処理にも成功し、自動的にデータベースがオープンされ、従来どおりのツリーで動作するようになりました。
ロールフォワードログはそのまま残っており、その場所を正しく指定したため、停止直前の状態に復元でき、検証も成功しました。
復元後、ロールフォワードログに関する設定をやり直し、改めてフルバックアップを取っておきました。
ロールフォワードログの機能は、復元処理の過程で無効に戻ってしまうため、ここで有効にする必要があります。フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
サーバの稼動状況を調べ、正常に動作していることを確認しました。
ユーザはGK Designs社で15台のサーバを管理しています。毎週土曜の夜にフルバックアップを取り、さらに毎晩、インクリメンタルバックアップを取っています。eDirectoryのバックアップ後すぐに、ファイルシステムバックアップによりテープに保存しています。
すべてのサーバがレプリカリングに参加しています。ロールフォワードログ機能は全サーバで有効です。
ある日、漏電による火事のため、ある支店のサーバが1台、完全に使えなくなってしまいました。幸い、このサーバのパーティションは、ひとつを除いてすべて、他のサーバにレプリカが作成されていました。ロールフォワードログ機能は有効にしていましたが、それも使えなくなってしまいました。したがって、停止直前の状態にまでeDirectoryデータベースを復元することはできません。
しかしバックアップファイルがあるので、サーバのeDirectory識別情報は再作成できます。復元にロールフォワードログは使えないので、他のサーバが想定している同期状態と合致しません(「遷移ベクトルと復元後の検証処理」を参照)。そのため復元の検証処理が失敗します。つまり、デフォルトで、復元処理が終わってもeDirectoryデータベースが開きません。
そこで、レプリカリングからいったんこのサーバを外し、DSRepairを使って、サーバの古くなったレプリカ情報をすべて外部参照に変え、それから最新のレプリカを保持しているサーバから複製することによって、このサーバに各パーティションの新しいコピーを追加しなおしました。具体的な手順は「復元後の検証処理に失敗した場合の対処方法」を参照してください。
レプリカが作られていなかったパーティションがひとつありました。これは、支店内にあるファックス/プリンタ複合機や大判カラープリンタなど、この支店内のネットワーク印刷オブジェクトを管理しているコンテナです。他のサーバにレプリカがないため、このパーティションは上述の手順では復元できません。このパーティションのオブジェクトは一から作り直さざるをえなかったので、将来に備え、これも他のサーバにレプリカを作っておくことにしました。
そこでロールフォワードログに関する設定をやり直し、改めてフルバックアップを取っておきました。ロールフォワードログの機能は、復元処理の過程で無効に戻ってしまうためです。
ユーザは3ヶ所に分けて設置された20台のサーバを管理しています。その1ヶ所で、水道管破裂による水漏れ事故のため、8台のうち5台が使えなくなってしまいました。
幸い、どのサーバについても、eDirectoryのバックアップを取っていました。しかし、すべてのサーバがレプリカリングに属しており、ロールフォワードログはなくなってしまったので、これを使わずにすべてをツリーに戻さなければなりません。最初にどのサーバから着手し、レプリカ間の不整合をどのように解消すればよいか、判断できませんでした。状況が複雑であるため、復元方法を決めるのにNetIQのサポート部門に相談することにしました。
ユーザとそのチームは、Human Resource Consulting社で1ヶ所に設置された50台のサーバを管理しています。
普段から障害対策のため、ツリーの各パーティションについて3つずつレプリカを作成しています。したがって、サーバが1台停止しても、そのパーティションにあるオブジェクトは他のサーバからアクセスできます。さらに、サーバを個別に復元できるよう、バックアップツールで定期的にすべてのサーバをバックアップし、ロールフォワードログ記録を有効にし、そしてバックアップテープは別の建物に保管するように計画しました。
災害に備えるため、チームでは2台のサーバをDSMASTERとして割り当てています。2台を割り当てているのは、ツリーが大きすぎて、1台では全パーティションのレプリカを保持できないからです。ツリーに属するどのパーティションも、いずれかのDSMASTERサーバにレプリカが作成されています。逆に、同じパーティションのレプリカが2台のDSMASTERサーバに作成されることはないようにして、重複を避けています。これが災害対策として重要な点です。
さらにチームでは、テスト環境で定期的にバックアップファイルからの復元を試み、想定どおりに動作することを確認しています。
ある日、台風で社屋が倒壊し、データセンタにあったサーバもすべて壊れてしまいました。
台風が去った後、チームではまず、パーティションすべてのレプリカを保持する、2台のDSMASTERサーバを復元する作業に取りかかりました。最新のフルバックアップファイルおよびそれ以降のインクリメンタルバックアップファイルを使いましたが、ロールフォワードログは使いませんでした。サーバが壊れたときに、一緒になくなってしまったからです。DSMASTERサーバを設定する際、この2台が同じレプリカを共有することはないようにしていました。そのため、ロールフォワードログを適用しなくても、復元後の検証処理は問題なく成功したのです。DSMASTERサーバが復元されたことにより、Human Resources Consulting社のツリーに属するオブジェクトはすべてアクセスできるようになりました。
DSMASTERが復元できれば、整合性を損なうことなくツリー全体を再作成できるので、その役割は非常に重要です。
このチームは、ロールフォワードログの機能も有効にしていました。障害が発生する直前の状態にまでサーバを復元でき、レプリカリングに属する他のサーバとの同期状態に不整合が生じないからです。サーバが復旧し、他のサーバと通信できるようになると、停止していた間に行われた更新情報を自動的に受け取り、同期を取ることができます。
しかし今回はそのロールフォワードログを使えません。その場合、レプリカリングに属するサーバのうち、最初に復元処理を実施したものしか正常に復元できないことになります。それ以外のサーバは、他のサーバと同期状態が一致しないということで、復元後の検証処理に失敗してしまうのです(「遷移ベクトルと復元後の検証処理」を参照)。検証処理に失敗すると、このeDirectoryデータベースはアクティブになりません。
しかしこのチームは、このような状況もきちんと考慮していました。2台のDSMASTERサーバを設定し、重複して保持するパーティションがないようにして、これを復元作業の起点としたのです。重複がないので検証処理に失敗することはありません。これをマスタとして順次他のサーバにコピーしていけば、レプリカリング全体が復元できることになります。
DSMASTERサーバの復元後、他のサーバを復元するために、いくつか必要な作業があります。このチームは次のような手順で、他のサーバを順次復元していきました。
DSMASTERサーバ上のレプリカを、マスタレプリカとして割り当てます。
DSMASTER以外のサーバをレプリカリングから外します。
フル/インクリメンタルバックアップファイルを使って、DSMASTER以外のサーバを復元します。
ロールフォワードログがないため、復元後の検証処理に失敗することは分かっています。したがって、データベースは復元されても、まだアクティブになっていません。
高度な復元機能を使って、データベースをアクティブにしました。ロックはまだ解除しません。
DSRepairを使って、他のサーバを参照してレプリカを作る設定に変更しました。
データベースのロックを解除しました。
この時点で、各サーバの識別情報は元どおりに戻っていますが、レプリカ情報を同期させようとはしません。他のサーバからレプリカのデータを受け取り、改めて構築できる状態になっています。
各サーバはDSMASTERサーバからデータを受け取り、自動的にレプリカを復元してレプリカリングに復帰します。
各サーバにどのレプリカが置かれていたか、チームではきちんと把握していました。もっとも、最終バックアップ時点の状況は、バックアップファイルのヘッダを見れば確認できます。
ロールフォワードログに関する設定をやり直し、改めてフルバックアップを取っておきました。ロールフォワードログの機能は、復元処理の過程で無効に戻ってしまうので、ここで有効にしたのです。改めてフルバックアップを取る必要があるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
具体的な手順は「復元後の検証処理に失敗した場合の対処方法」を参照してください。
かなりの作業量でしたが、ツリー自身は比較的早期に使用できるようになり、その時点でサーバ全体を復旧する目処も立っていました。