ロールフォワードログとは、他のデータベース製品でいう「ジャーナル」に相当する機能です。ロールフォワードログ(RFL)は、データベースの変更をすべて記録したものです。
ロールフォワードログを使用する利点は、最後のフル/インクリメンタルバックアップ以降の変更履歴が得られるため、障害で停止する直前の状態にまでeDirectoryを復元できることです。ロールフォワードログを使用しないと、最後のフル/インクリメンタルバックアップを取った時点までしかeDirectoryを復元できません。
eDirectoryは、トランザクションをデータベースに反映する前に、その操作内容をログファイルに記録するようになっています。デフォルトでは、ログファイルはディスク容量の節約のために次々に重ね書きされるようになっているため、eDirectoryの変更履歴は残りません。
継続的にロールフォワードログを取る設定にすると、変更履歴が連続したロールフォワードログファイルに保存されます。ロールフォワードログ記録はサーバの性能には影響がありません。eDirectoryがすでに作成しているログファイルのエントリを単に保存するだけです。
レプリカリングに属するサーバは、ロールフォワードログ機能を有効にしておく必要があります。バックアップファイルがあっても、ロールフォワードログがなければ復元後の検証処理に失敗し、データベースを開けないことになります。他のサーバとレプリカを共有するデータベースは、停止直前の状態にまで復元しない限りデフォルトではオープンされません。ロールフォワードログがない場合は、「復元後の検証処理に失敗した場合の対処方法」で説明されている別の手順で復旧してください。
ロールフォワードログの機能は、デフォルトでは無効になっています。サーバで必要に応じて有効に切り替えてください。ロールフォワードログは、サーバの復元作業を実行すると再び無効になり、設定がデフォルトに戻ります。このため復元後に再び有効にし、設定を再作成した上で、改めてフルバックアップを取ってください。
メモ:フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
単一サーバ環境ではロールフォワードログがなくても構いません。しかしロールフォワードログがあれば、最後のバックアップ時ではなくシステム停止直前の状態に復元できます。
ロールフォワードログをオンにする場合、ディスクの空き容量は常に監視している必要があります。詳細については、ロールフォワードログのバックアップと削除を参照してください。
この節では、次の項目について説明します。
ロールフォワードログ記録の切り替えや設定には、iManagerまたはDSBKを使います。iManagerによるロールフォワードログの設定またはDSBKによるロールフォワードログの設定を参照してください。
継続的にロールフォワードログ機能を使用する場合、次のような点に注意してください。
バックアップ処理の実行前にロールフォワードログ機能を有効にしておかないと、 データベースの復元に利用することはできません。
障害に備えるため、eDirectoryとは別の記憶デバイスにロールフォワードログを保存するようにしてください。 セキュリティを考慮すれば、ログへのアクセス権も制限する必要があります。詳細については、ロールフォワードログの保存先を参照してください。
ロールフォワードログの保存先を文書に記録しておいてください。 詳細については、ロールフォワードログの保存先を参照してください。
ログの保存先のディスクの空き容量を常に監視している必要があります。 詳細については、ロールフォワードログのバックアップと削除を参照してください。
ロールフォワードログ機能が無効になっていたり、ログファイルを損失した場合は、有効に切り替えた後、改めてフルバックアップを取ってください。 そうしなければ完全に復元できなくなる恐れがあります。次のような状況の場合に必要です。
復元処理の直後。復元処理の過程で、ロールフォワードログ機能は無効になり、設定もデフォルト値に戻ってしまいます。
デバイス障害などにより、ロールフォワードログを保存しているディレクトリを損失した場合。
意図せずにロールフォワードログ機能を無効にしてしまった場合。
ストリームファイルのログ機能を有効にすると、ディスクの空き容量が急速に減少します。 ストリームファイル(ログインスクリプトなど)のログ出力を有効にすると、変更があるたびに、ストリームファイル全体がロールフォワードログに複写されるためです。ストリームファイルのログ出力を無効にし、フル/インクリメンタルバックアップの際にのみストリームファイルをバックアップすると、ログファイルが大きくなるのを遅らせられます。
データベースの復元で最も時間を要するのは、ロールフォワードログを参照する処理です。 ロールフォワードログの容量は、ツリー構造に対して施された更新の回数に応じて増え、ストリームファイル(ログインスクリプトなど)のログ出力を有効にするとさらに増えます。
データベースが頻繁に更新されるようであれば、バックアップの頻度を上げることも検討するとよいでしょう。こうすると、復元処理の過程でロールフォワードログを参照する処理が少なくなります。
ロールフォワードログファイルの名前を変更しないでください。 ログが作成されたときとファイル名が異なる場合、そのログファイルを復元に使用することはできません。
eDirectoryを削除するとロールフォワードログもすべて消えてしまいます。 いったんデータベースを削除した後、ログファイルを使って復元するのであれば、eDirectoryを削除する前に、別の場所にコピーしておいてください。
復元が必要な場合は、復元処理の終了後にそのサーバのロールフォワードログ設定を再作成してください。 この機能を有効にし、ログの保存先を安全な場所に設定します。ロールフォワードログを有効にしてから、改めてフルバックアップも取る必要があります。
この手順が必要となるのは、復元処理の過程で、ロールフォワードログに関する設定はデフォルトに戻るためです。つまり、ロールフォワードログ機能は無効となり、保存先もデフォルトの場所になるからです。フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
ロールフォワードログ機能を有効にした場合、その保存先を、eDirectoryとは別の記憶デバイスに変更します。
保存先を設定する上で、次の点に注意してください。
デフォルトの場所のままにせず、必ずeDirectoryとは別のストレージデバイス上に配置してください。 こうしておけば、デバイス障害のためにeDirectoryが失われても、復元のためにロールフォワードログにアクセスできます。
サーバにストレージデバイスが1つしかない場合、デバイス障害が起こると、ロールフォワードログではeDirectoryの耐障害性は保たれません。この機能はロールフォワードログを使用しないでおく方法もあります。
ロールフォワードログの保存先を変更するには、iManagerのバックアップ環境設定画面、またはDSBKのsetconfigコマンドを使用してください。ロールフォワードログはサーバ上のローカルファイルとして保存する必要があります。
保存先を記録してください。 ロールフォワードログの保存先を記録して、サーバのデータベースの復元が必要なときに見つけられるようにしてください。これはサーバが正常で障害が発生する前に実行することが重要です。
サーバが正常に動作していれば、iManagerのバックアップ環境設定画面、またはDSBKのbackup getconfigオプションで調べることができます。ただし、ハードウェア障害などでeDirectoryが使えない状態になると、この方法でロールフォワードログの場所を調べることはできません。
サーバに障害が発生し、それを復元する場合は、eDirectoryを新たにインストールすると、ロールフォワードログの保存先設定はデフォルトの場所に戻ります。このため、復元作業のためにeDirectoryを再インストールしたとしても、サーバの停止前にロールフォワードログをどこに保存していたか、eDirectoryで調べることはできません。その場合は記録を参照して位置を調べる必要があります。
ロールフォワードログの保存先設定は、_ndsdb.iniファイルにも記録されています。ただし、eDirectoryと同じディスクパーティション/ボリュームにあるため、eDirectoryがあるストレージデバイスに障害が起これば、ログの保存先を調べるために_ndsdb.iniファイルを使用することはできません。
ロールフォワードログの保存先へのアクセス権を制限してください。 これはセキュリティ上の問題です。見ただけで中身がわかるような形式にはなっていませんが、デコードは可能なため、重要なデータが漏洩する恐れがあります。
ディスクの空き容量が充分かどうか、常に監視している必要があります。 詳細については、ロールフォワードログのバックアップと削除を参照してください。
ロールフォワードログ専用のディスクパーティション/ボリュームを用意するのが最善です。 こうしておけば、ディスク容量やアクセス権を監視しやすくなります。
ログの保存先パスのうち、一番深い階層のディレクトリ名はeDirectoryによって作成されます。 この名前は現在のeDirectoryデータベース名に基づいて決まります。
たとえばログの保存先を「d\Novell\NDS\DIBFiles」と指定した場合、eDirectoryデータベース名が「NDS」であれば、実際の保存先ファイルは「d:\Novell\NDS\DIBFiles\nds.rfl」となります。データベースの名前をNDSからND1に変更した場合、ロールフォワードログのディレクトリはd:\Novell\NDS\DIBFiles\nd1.rflに変更されます。
保存先の設定を変えるとその時点で新しいディレクトリができますが、ロールフォワードログはデータベースでトランザクションが発生するまで作成されません。
復元の際は、必要なロールフォワードログをすべて同じディレクトリに集めます。 詳細については、復元処理の準備を参照してください。
放置しておけばロールフォワードログは次々に蓄積され、ディスクパーティション/ボリュームがいっぱいになります。ディスク容量が不足してロールフォワードログを作成できない場合は、eDirectoryはそのサーバに対して応答しなくなります。定期的にログファイルをバックアップし、サーバからは削除するようにして、常に充分なディスク容量を確保するようお勧めします。
削除しても構わないロールフォワードログを判別し、バックアップを取った上で削除するには、次の手順に従います。
「最後に使用済みになった」ロールフォワードログ名を調べてください。
最後の使用済みロールフォワードログの名前は、次のような方法で調べることができます。
iManagerで［eDirectoryの保守］>［バックアップ環境設定］の順にクリックし、表示されるファイル名を調べます。
DSBKでgetconfig backupコマンドを実行します。手順については、DSBKによるロールフォワードログの設定を参照してください。
「最後に使用済みになった」ロールフォワードログとは、トランザクション履歴の記録が終わり、今は書き出しをしていないログファイルのうち、最新のものを表します。データベースはこのファイルに対する書き込みを終えて、今は新しいログファイルで始めているため、オープンしておく必要はもうありません。そのため、「最後に使用済みになった」ロールフォワードログと呼ばれます。一方、データベースがトランザクションを記録している現在のロールフォワードログは「使用中」で、データベースに必要なものです。
ファイルシステムのバックアップ機能を使って、ロールフォワードログをテープに保存してください。
「最後に使用済みになった」ものよりも古いロールフォワードログを削除してください。
警告:ロールフォワードログを削除する際にはより注意を払い、削除しようとするファイルが確実にバックアップされているか、繰り返し確認してください。
「最後に使用済みになった」ロールフォワードログとは、データベースが記録を完了しクローズにしたファイルを指します。サーバからこのファイルを削除しても構わないという意味ではありません。まだテープにバックアップしていないファイルは削除しないようにしてください。
テープに保存してあるロールフォワードログを復元のために使う場合は、次の点に注意してください。
復元に使用する他のロールフォワードログと同様に、ファイルシステムをバックアップしたテープから取得したログファイルは、他のログと合わせてひとつのフォルダに集めてください。このフォルダは、サーバからローカルにアクセスできる必要があります。
テープおよびサーバに複製されたファイルのタイムスタンプを比較する必要があります。タイムスタンプに違いがある場合は、最新のサーバ上のファイルを使います。たとえば、ファイルシステムのバックアップ中にデータベースで使用されていたロールフォワードログファイルは、テープでは不完全になります。最新の完全なファイルはサーバに格納されています。
サーバからeDirectoryを削除すると、ロールフォワードログのディレクトリおよびその中身もすべて削除されます。いったんデータベースを削除した後、ログファイルを使って復元するのであれば、eDirectoryを削除する前に、別の場所にコピーしておいてください。