eDirectoryデータベースの復元作業で最も大切なのは、復元が完全に行われたかどうか確認することです。作業に先立ち、「復元作業の前提条件」の説明に従って、必要な準備を行います。必要なバックアップファイルを揃える手順については、「復元に必要なバックアップファイルの収集」を参照してください。
復元するサーバとレプリカを共有しているサーバはすべて、稼動状態で、通信できるようにしておかなければなりません。これは、復元後の検証処理で、同じレプリカリングに属するサーバ間の整合性を確認するために必要です。
必要な次のバックアップファイルをすべて収集してください。
フルバックアップおよびそれ以降のインクリメンタルバックアップのファイルを、復元するサーバの、1つのディレクトリ内に集めます。
最後にバックアップを取って以降のロールフォワードログをすべて、同じサーバ上のもう1つのディレクトリにまとめておきます。
このサーバがレプリカリングに属している場合、最後にバックアップを取った時点以降のロールフォワードログをすべて、ひとつのディレクトリ内に集めておきます。ファイル名はログ生成時と同じにしておかなければなりません。
詳細については、復元に必要なバックアップファイルの収集を参照してください。
メモ:サーバのバックアップファイルがない場合は、Xbrowseを使用して、サーバ情報の回復に役立つ情報をeDirectoryに問い合わせてください。この作業は、サーバオブジェクトやその関連オブジェクトをツリーから削除する前に実行する必要があります。
Xbrowseの詳細については、NetIQサポートのWebサイトを参照してください。
eDirectoryを再インストールし、仮のツリーで稼動させておきます。
障害が起きる前と同じ名前のサーバを作成するので、まずサーバを新しいツリーで稼動させます。復元でサーバーの完全な識別情報を再作成する前に元のツリーに新しくインストールしたサーバを置くことで混乱が生じないようにするためです。データベースの復元処理が完了してから、本来のツリーにサーバを組み入れることになります。
(状況によって実行)このサーバでロールフォワードログ機能を使うためには、復元後に改めて有効に切り替え、障害対策のための書き出し先も設定し直して、ロールフォワードログの環境設定を再作成する必要があります。ロールフォワードログを有効にしてから、改めてフルバックアップも取る必要があります。
復元処理の過程で、ロールフォワードログの機能は無効になり、ログ保存先の設定もデフォルトに戻ってしまいます。
フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
(状況によって実行)IPアドレスを指定してこのサーバにアクセスするアプリケーションやオブジェクトがある場合は、元と同じIPアドレスを設定してください。
復元の過程で、eDirectoryバックアップツールはまず、フルバックアップファイルからの復元を試みます。それが済むと、バックアップツールでインクリメンタルバックアップファイルの名前を入力するよう求められます。その際、次に適用するべきファイルのIDが提示されます。インクリメンタルバックアップファイルからの復元が終わると、今度はロールフォワードログを参照しての復元処理が始まります。バックアップツールによる復元作業の概要も参照してください。
必要なファイルをすべて揃えた後、iManagerやDSBK Clientから復元処理を起動します。DSBKによるバックアップファイルの復元作業またはiManagerによるバックアップファイルの復元作業を参照してください。
ファイルシステムをバックアップしたテープから、eDirectoryフルバックアップファイルを、サーバ上の適当なディレクトリにコピーしてください。
最後に取ったフルバックアップのIDは、バックアップツールのログファイルで確認できます。
同様に、一連のインクリメンタルバックアップファイルを、サーバ上の適当なディレクトリにコピーしてください。
必要なインクリメンタルバックアップファイルは、フルバックアップファイルのヘッダ部で確認できます。「next_inc_file_ID」属性として、次のインクリメンタルバックアップファイルのIDが記述されています。next_inc_file_IDは、インクリメンタルバックアップファイルのヘッダ部にある「incremental_file_number」属性のIDと同じです。ヘッダの説明は、「バックアップファイルのヘッダ書式」を参照してください。
警告:バックアップファイルを開くときは、ヘッダを確認するだけにしてください。ファイルを保存または変更しようとすると、ファイルの一部が切り捨てられる場合があります。ほとんどのアプリケーションがバイナリデータを正しく保存することができません。
インクリメンタルバックアップファイルにはそれぞれ、次のインクリメンタルバックアップファイルのIDが記載されています。
このIDもバックアップツールのログファイルで確認できます。
同じ名前のファイルがいくつもあって、ひとつのディレクトリにまとめるためにファイル名を変更しているような場合、IDはその識別に不可欠です。たとえば無人でのバックアップにいつも同じバッチファイルを使っていて、バックアップファイル名が常に同じであるような場合です。ヘッダ部のIDを見れば、ファイル名が変わっていても適切なファイルを判別できます。
(状況によって実行)ロールフォワードログ機能を有効にしていた場合は、最後のバックアップ以降のロールフォワードログを、生成時のファイル名のまま、サーバ上の適当なディレクトリに集めてください。
このサーバがレプリカリングに属している場合は、ロールフォワードログを使った復元処理が必須です。ロールフォワードログがすべて揃っていない場合、復元検証は失敗してしまいます。リング内の他のレプリカと比較して遷移ベクトルが一致しないからです。デフォルトでは、復元したeDirectoryデータベースが他のレプリカと整合が取れていない場合、そのままではオープンできません。
テキストエディタで最新のバックアップファイルを開き、ヘッダの「current_log」属性を読んで、最初に必要なロールフォワードログを特定します。この作業を繰り返して、続くすべてのロールフォワードログを集めます。
警告:バックアップファイルを開くときは、ヘッダを確認するだけにしてください。ファイルを保存または変更しようとすると、ファイルの一部が切り捨てられる場合があります。ほとんどのアプリケーションがバイナリデータを正しく保存することができません。
必要なロールフォワードログがすべて1ヶ所にまとまっているとは限りません。よく確認して、すべて同じディレクトリに揃えてください。ロールフォワードログは、次の理由から複数の場所に格納されている場合があります。
最後にeDirectoryのフル/インクリメンタルバックアップを実行してから、ロールフォワードログの保存先を変更した場合。
ファイルシステムのバックアップを使用して、ロールフォワードログをテープにバックアップした後で、空きディスク容量を確保するためにそれらのファイルを削除した場合。
テープにバックアップされたロールフォワードログを取得する場合は、データが最新のセットであることを確認してください。テープおよびサーバに複製されたファイルのタイムスタンプを比較する必要があります。ファイルシステムのバックアップ中にデータベースで使用されていたロールフォワードログファイルは、テープでは不完全になります。最新の完全なファイルはサーバに格納されています。
最後にバックアップを実行してからeDirectoryデータベースの名前を変更した(NDSからND1に変更した場合など)。この変更により、ロールフォワードログのパスの最後のディレクトリ名が変更されます。
たとえばログの保存先を「D:\novell\nds\dibfiles\」と指定した場合、eDirectoryデータベース名が「NDS」であれば、実際の保存先ファイルはディレクトリ「D:\novell\nds\dibfiles\nds.rfl\」となります。データベースの名前をNDSからND1に変更した場合、ロールフォワードログのディレクトリはD:\Novell\nds\dibfiles\nd1.rfl\に変更されます。
重要:必要なロールフォワードログがすべてそろっていることを確認してください。バックアップツールでは、ロールフォワードログがすべてそろっているかどうか確認できません。ロールフォワードログは順番に開かれて使用されます。指定したディレクトリ内に次のロールフォワードログが見つからない場合は、復元プロセスが中止されます。必要なロールフォワードログがすべてそろっていなければ復元は完了しません。