バックアップサービスおよび復元サービスについて


eDirectory Backup eMToolについて

Backup eMToolには、個々のサーバ単位で、稼動したままの状態で継続的にeDirectoryデータベースのバックアップを取る機能があります。データベースを停止することなく、処理を始めた時点のバックアップを取ることができます。つまり、バックアップ作業はいつでも可能であり、その間もeDirectoryを使い続けることができます(特に指示しなければこの「ホット」バックアップになりますが、必要であればデータベースを停止して「コールド」バックアップを取ることも可能です)。

また、ロールフォワードログを有効にすれば、最後にバックアップを取った時点以降のトランザクションをすべて記録しておけます。これを使えば、サーバが停止する直前の状態に復元することもできます。さらに、レプリカリングに属するサーバすべてについてロールフォワードログを取る必要があります。これにより、他のサーバとの同期状態も復元できます。バックアップファイルがあっても、ロールフォワードログがなければ復元後の検証処理に失敗し、データベースを開けないことになります。ロールフォワードログの機能は、デフォルトでは無効になっています。詳細については、「ロールフォワードログを使用する」を参照してください。

新しいバックアップツールであるBackup eMToolも、eDirectoryのオブジェクトをすべて一度にバックアップできるわけではありません。各サーバのパーティションが単位となります。この方式は、特定のサーバのみを復元する場合に優れているばかりでなく、TSA for NDS(R)を使う旧式の方法に比べて高速です。ただし、eDirectory 8.6のマニュアルにも記載されているように、TSA for NDSは今でも使用できます。必要に応じてTSA for NDSとBackup eMToolを使い分けられます。動作の違いについては、eDirectory 8.7.3のバックアップ/復元機能で変更された事項を参照してください。

eDirectoryの新しいバックアップツールは、システムバックアップ機能と組み合わせて使用して、eDirectoryバックアップファイルをテープに安全に保存する必要があります。Novellはバックアップ用製品を開発している主要企業と提携しています。一覧については、「NetWare Partner Products: Backup, Restore, & Recovery」を参照してください。

NetWareの場合、このバックアップツールを使うためには、ファイルシステムに対する適切なアクセス権が必要です。詳細については、「NetWareのファイルシステムデータを復元する際のアクセス権の保存」を参照してください。

iManagerからは、コールドバックアップ、無人バックアップ、高度な復元機能を除くバックアップ/復元機能を実行できます。詳しくはNovell iManagerを使ったバックアップ/復元作業を参照してください。一方、eMBox Javaコマンドラインクライアントからは、無人バックアップを含め、どんなバックアップ/復元作業でも実行できます。詳しくはeMBoxクライアントを使ったバックアップ/復元作業を参照してください。

iManagerから実行できるバックアップ/復元オプションについては、オンラインヘルプを参照してください。eMBox Clientから実行できる機能については、バックアップ/復元のコマンドラインオプションを参照してください。

復元の具体的な処理過程については、Backup eMToolによる復元作業の概要を参照してください。

eDirectory Backup eMToolは、eMBoxツールのひとつです。eMBoxは、eDirectoryを構成する一部としてサーバにインストールされるサービスです。

Backup eMToolは次のファイルから成ります。

ファイル名 説明

backupcr

バックアップ/復元機能をすべて含むコアライブラリ。

ユーザインタフェースはなく、backuptlプログラムから動的にロード、リンクされる形で動作します。

backuptl

backupcrライブラリを呼び出すeMToolのインタフェース部分。eMBoxアーキテクチャを介してバックアップ/復元機能を提供するプログラムです。

iManagerプラグイン、eMBox Client、Javaコマンドラインクライアントを介して使用できます。

dsbackup_en.xlf

Backup eMToolで表示されるメッセージの言語ファイルです。

Backup eMToolで作成されるバックアップファイルやログファイルの形式については、バックアップログファイルの書式およびバックアップファイルのヘッダ書式を参照してください。

重要:  復元後の検証処理については、8.5より前のeDirectoryとは互換性がありません。レプリカリングに属するサーバで新しいバックアップ/復元ツールを使う場合は、これに属するサーバすべてをeDirectory 8.5以降にアップグレードする必要があります(復元後の検証についてはeDirectory 8.5以降のみで互換性があるも参照してください)。


eDirectory 8.7.3のバックアップ/復元機能で変更された事項

eDirectoryの以前のバージョンでは、バックアップ/復元ツールは、ツリーをオブジェクト単位でバックアップする方式を使用していました。

eDirectory 8.7で組み込まれたBackup eMToolは、方式やアーキテクチャが一新されています。すなわち、ツリーではなくサーバを単位とし、個々のサーバのeDirectoryデータベースをバックアップする、という方式になったのです。この変更により、以前のTSA for NDSよりもバックアップ処理速度が大幅に改善されました。

TSA for NDSは今でも使用できますが、今後は新しいバックアップツールを使うようお勧めします。

サーバ固有の情報もBackup eMToolでバックアップできます。「サーバ固有情報のバックアップに関する変更事項(NetWareのみ)」を参照してください。

新旧バックアップツールの違いを次の表に示します。

項目 TSA for NDSによる以前のバックアップ Backup eMToolによる「ホットバックアップ」

バックアップの対象

ツリー全体をオブジェクト単位でバックアップ。

旧バックアップツール(必要ならば8.7でも利用可能)の詳細については、『Novell eDirectory 8.6 管理ガイド』の「Novell eDirectoryのバックアップと復元」を参照してください。

サーバ単位でeDirectoryデータベースをバックアップ。

ツリー全体の耐障害性は主としてレプリカ作成機能で確保していますが、サーバ単位のバックアップ機能によりさらに強固になります。

災害などで何台ものサーバが停止した場合でもツリーを復元できるようにするためには、DSMASTERサーバを導入し、それに応じたレプリカ作成方針を立てる必要があります。DSMASTERサーバによる災害対策を参照してください。

処理速度

-

大幅に改善されています。新規バックアップツールの開発に当たっては、処理性能を最重視しました。

バックアップファイルの保存先

直接テープに書き出し可。

ファイルシステム上のバックアップファイルとして書き出し。

別途ファイルシステムのバックアップツールを使って、テープに書き出す必要があります。

プラットフォーム間の違い

プラットフォームによって使い方が別々。

どのプラットフォームでも同じ使い方。

個々のサーバ単位での復元

考慮されていません。

サーバ単位での復元処理が可能。ハードディスク障害時のほか、サーバ機を移行する際にも利用できます。

ロールフォワードログを使えば、停止直前の状態に復元することも可能です。これにより、レプリカリングに属する他のサーバと同期状態を揃えることができます。

eDirectoryの関連ファイルもバックアップの対象とすることができます。たとえばNICIファイルのバックアップと復元ができます。独自の関連ファイルリストを作成して、対象ファイルをバックアップに追加することもできます。

NICIファイルのバックアップ/復元

考慮されていません。

NICIファイルのバックアップ/復元も可能です。これにより、復元後、暗号化データにアクセスできます。復元作業の時間を大幅に短縮できるでしょう。

個々のサーバのロールフォワードログ

考慮されていません。

最後にバックアップを取った時点以降のトランザクションを、ロールフォワードログとしてすべて記録しておけます。これを使うと、停止直前の状態にまで復元することができます。複数サーバ環境では、これを使用して他のサーバと同期状態を揃えることができます。ロールフォワードログの機能は、デフォルトでは無効になっています。詳細については、「ロールフォワードログを使用する」を参照してください。


Backup eMToolによる復元作業の概要

復元作業に先立ち、バックアップファイルをすべて揃えておく必要があります。その手順については復元処理の準備を参照してください。iManagerやeMBox ClientからBackup eMToolの復元機能を呼び出すと、Backup eMToolで次のような処理が行われます。

  1. DSエージェントをクローズします。
  2. アクティブなDIB(Data Information Base)セットを、NDSからRSTに切り替えます。

    既存のNDSデータベースはそのままサーバに残り、復元後の検証に失敗した場合は、再びこれがアクティブなDIBセットになります。

  3. 復元処理が始まります。新たにRSTというDIBセットを作り、そこに復元します。
  4. DIBセットをいったん無効にします。

    擬似サーバのログイン無効属性をオンにします。これは、このDIBセットを使ってDSエージェントがオープンされるのを避けるための措置です。

  5. ロールフォワードログに関する設定をデフォルトに戻します。

    したがって、復元後はロールフォワードログを書き出さない設定になります。書き出し先ファイル名の設定もデフォルトに戻ります。

    このサーバでロールフォワードログ機能を使うためには、復元後に改めて有効に切り替え、障害対策のための書き出し先も設定し直して、ロールフォワードログの環境設定を再作成する必要があります。ロールフォワードログを有効にしてから、改めてフルバックアップも取る必要があります。

  6. 復元されたRSTデータベースの検証処理を行います。

    復元されたデータの整合性を確認します。この確認は、レプリカを共有しているすべてのサーバにアクセスし、遷移ベクトルを比較して実行されます。

    検証結果はログファイルに出力されます。

    リモートサーバの遷移ベクトルの方がローカルベクトルより後の時間に作成されたものである場合は、復元されなかったデータがあるということなので、検証処理は失敗します。

    あるレプリカの検証処理に失敗した場合、ログにはたとえば次のように出力されます。遷移ベクトルを比較している様子がわかります。

    Server:\T=LONE_RANGER\O=novell\CN=CHIP 
       Replica:\T=LONE_RANGER\O=novell 
          Status:ERROR = -6034 
             Local TV             Remote TV 
             s3D35F377 r02 e002   s3D35F3C4 r02 e002 
             s3D35F370 r01 e001   s3D35F370 r01 e001 
             s3D35F363 r03 e001   s3D35F363 r03 e001 
             s3D35F31E r04 e004   s3D35F372 r04 e002 
             s3D35F2EE r05 e001   s3D35F2EE r05 e001 
             s3D35F365 r06 e003   s3D35F365 r06 e003

    詳細については、「遷移ベクトルと復元後の検証処理」を参照してください。

  7. 検証に成功した場合は、RSTをNDSと改名し、ログイン無効属性をオフにします。したがってこれがサーバでアクティブなeDirectoryデータベースになります。失敗した場合は改名しないので、元のNDSが再びアクティブなDIBセットになります。

    検証に失敗した場合の復旧方法については、復元後の検証処理に失敗した場合の対処方法を参照してください。「高度な復元オプション」を使えば、強制的にRSTデータベースをアクティブにし、ロックを解除することもできますが、Novellの担当者の指示がない場合はお勧めできません。


バックアップファイルのヘッダ書式

バックアップファイルのヘッダには、次のような重要な情報が記録されています。

各バックアップファイルのヘッダはXML形式で記述されます。ヘッダ部に続き、データベース内のデータを、バイナリ形式で記録します(ファイルの末尾にバイナリデータがあると構文解析でエラーが発生しますが、XMLヘッダはXML標準に適合しています)。バックアップが複数のファイルに分かれる場合、各ファイルに同じヘッダ情報を記録します。

警告:  バックアップファイルを開く場合でもヘッダを確認するだけにとどめ、保存や変更はしないようにしてください。ファイルの一部が切り捨てられてしまうことがあります。ほとんどのアプリケーションではバイナリデータを正確に保存することはできません。

XMLヘッダのDTDを次に示します(このDTDは参照のため、バックアップファイルのヘッダの一部として書き込まれます)。

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<!DOCTYPE backup [ 
<!ELEMENT backup (file|replica)*> 
<!ELEMENT file (#PCDATA)> 
<!ELEMENT replica EMPTY> 
<!ATTLIST backup version CDATA #REQUIRED 
    backup_type (full|incremental) #REQUIRED 
    idtag CDATA #REQUIRED 
    time CDATA #REQUIRED 
    srvname CDATA #REQUIRED 
    dsversion CDATA #REQUIRED 
    compression CDATA "none" 
    os CDATA #REQUIRED 
    current_log CDATA #REQUIRED 
    number_of_files CDATA #IMPLIED 
    backup_file CDATA #REQUIRED 
    incremental_file_ID CDATA #IMPLIED 
    next_inc_file_ID CDATA #IMPLIED> 
<!ATTLIST file size CDATA #REQUIRED 
    name CDATA #REQUIRED 
    encoding CDATA "base64" 
    type (user|nici) #REQUIRED> 
<!ATTLIST replica partition_DN CDATA #REQUIRED 
    modification_time CDATA #REQUIRED 
    replica_type (MASTER|SECONDARY|READONLY|SUBREF| 
    SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED 
    replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED| 
    CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA| 
    BEGIN_ADD|MASTER_START|MASTER_DONE| 
    FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1| 
    Unknown) #REQUIRED> 
]>

DTDに含まれる属性について次の表で説明します。

属性 説明

backup version

バックアップツールのバージョン。

backup backup_type

フルバックアップかインクリメンタルバックアップかの別(コールドバックアップはフルバックアップとして扱います)。

backup idtag

バックアップ時刻に基づいて生成されたGUID。バックアップファイル名が変わっていても、これを使えばバックアップを識別できます。

backup time

バックアップ処理の開始日時。

backup srvname

バックアップ対象サーバの識別名。

backup dsversion

サーバ上で稼動しているeDirectoryのバージョン。

backup compression

Backup eMToolがバックアップデータを圧縮したかどうか。対象になるのはバックアップデータ本体だけで、ヘッダは圧縮されません。

backup os

バックアップ処理を実行したオペレーティングシステム。復元はこれと同じオペレーティングシステムのみで行うようお勧めします。

backup current_log

復元に必要な最初のロールフォワードログ。正しく復元するために必要な情報です。

backup number_of_files

分割してバックアップする場合のファイル数。ひとつ目のバックアップファイルにのみ記録されます。

backup backup_file

このバックアップファイル名。

複数のファイルに分けてバックアップする場合、各ファイル名には順序番号がつきますが、それも含むファイル名が記録されます。複数のバックアップファイルのファイル名の例は、-s ファイルサイズを参照してください。

backup incremental_file_ID

インクリメンタルバックアップの場合、そのファイルのID。

backup next_inc_file_ID

これに続くインクリメンタルバックアップに与えるID。正しく復元するために必要な情報です。

file size

このファイルの<file>タグ間にあるデータ長。

file name

バックアップファイル名およびその保存先。

file encoding

ファイルのエンコードに使ったアルゴリズム。

file type

これがNICIファイルか、それ以外にユーザが指定したファイルかの別。

replica partition_DN

パーティションの識別名。

各レプリカをどのサーバに配置しているか記録していない場合に役立ちます。災害で何台ものサーバが停止した場合、バックアップファイルのヘッダに表示されたこの情報を見れば、最初にどのサーバを復元するべきか判断できます。

replica modification_time

バックアップ時点の、このレプリカの遷移ベクトル。

replica replica_type

レプリカの種別。マスタ、読み込み専用など。

replica_state

バックアップ時点でのレプリカの状態。「On」、「New Replica」など。

バックアップファイルのヘッダ例を次に示します。これはWindows NTサーバで作成したもので、NICIセキュリティファイルもバックアップ対象になっています。

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<!DOCTYPE backup [ 
<!ELEMENT backup (file|replica)*> 
<!ELEMENT file (#PCDATA)> 
<!ELEMENT replica EMPTY> 
<!ATTLIST backup version CDATA #REQUIRED 
    backup_type (full|incremental) #REQUIRED 
    idtag CDATA #REQUIRED 
    time CDATA #REQUIRED 
    srvname CDATA #REQUIRED 
    dsversion CDATA #REQUIRED 
    compression CDATA "none" 
    os CDATA #REQUIRED 
    current_log CDATA #REQUIRED 
    number_of_files CDATA #IMPLIED 
    backup_file CDATA #REQUIRED 
    incremental_file_ID CDATA #IMPLIED 
    next_inc_file_ID CDATA #IMPLIED> 
<!ATTLIST file size CDATA #REQUIRED 
    name CDATA #REQUIRED 
    encoding CDATA "base64" 
    type (user|nici) #REQUIRED> 
<!ATTLIST replica partition_DN CDATA #REQUIRED 
    modification_time CDATA #REQUIRED 
    replica_type (MASTER|SECONDARY|READONLY|SUBREF| 
    SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED 
    replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED| 
    CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA| 
    BEGIN_ADD|MASTER_START|MASTER_DONE| 
    FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1| 
    Unknown) #REQUIRED> 
]> 
 
<backup version="2" backup_type="full" idtag="3D611DA2" time="2002-8-19'T10:32:35" srvname="\T=MY_TREE\O=novell\CN=DSUTIL-DELL-NDS" dsversion="1041081" compression="none" os="windows" current_log="00000003.log" next_inc_file_ID="2" number_of_files="0000001" backup_file="c:\backup\header.bak"><replica partition_DN="\T=MY_TREE" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part1" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part2" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part3" modification_time="s3D611D96_r1_e2" replica_type="MASTER" replica_state="ON" /><file size="190" name="C:\WINNT\system32\novell\nici\bhawkins\XARCHIVE.001" encoding="base64" type="nici">the data is included here</file> 
 
<file size="4228" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS2" encoding="base64" type="nici">the data is included here</file> 
 
<file size="168" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS3" encoding="base64" type="nici">the data is included here</file> 
 
<file size="aaac" name="C:\WINNT\system32\novell\nici\nicintacl.exe" encoding="base64" type="nici">the data is included here</file> 
 
<file size="150" name="C:\WINNT\system32\novell\nici\NICISDI.KEY" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="4228" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks2" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="168" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks3" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="1414" name="C:\WINNT\system32\novell\nici\xmgrcfg.wks" encoding="base64" type="nici">the data is included here 
</file> 
 
</backup>

ヘッダ部に続き、データベースのバックアップデータをバイナリ形式で格納します。


バックアップログファイルの書式

eDirectory Backup eMToolは、前回までのバックアップを含め、処理内容を細かく記録したログを残すようになっています。このログファイルにはすべてのバックアップ履歴、バックアップの開始および終了時刻、およびバックアッププロセス中に発生した考えられるエラーについての情報が含まれます。前回までのログに追記する形で記録します。書き出し先を別途指定することもできます。

無人バックアップが正常に実行されているか確認するためにも、このログは重要です。最終行を見ると、成功か失敗かの区別およびエラーコードがわかります。

Backup eMToolのログファイルには、過去のバックアップ処理のIDも記録されています。これは復元に必要なフルバックアップ、インクリメンタルバックアップのファイルを間違いなく揃えるために役立ちます。先頭の4行は、バックアップファイルのヘッダ情報をそのまま複写したものです。

また、同時にバックアップしたファイル名も記録します。NICIファイルや、インクルードファイルでユーザが指定したファイルがこれに当たります。

復元処理の際は、実際に復元されたファイルを記録します。

ログファイルの出力例を次に2つ示します。

|==================DSBackup Log:Backup================| 
Backup type:Full 
Log file name:sys:/backup/backup.log 
Backup started:2002-6-21'T19:53:5GMT 
Backup file name:sys:/backup/backup.bak 
Server name:\T=VIRTUALNW_TREE\O=novell\CN=VIRTUALNW 
Current Roll Forward Log:00000001.log 
DS Version:1041072 
Backup ID:3D138421 
Backing up security file:sys:/system/nici/INITNICI.LOG 
Backing up security file:sys:/system/nici/NICISDI.KEY 
Backing up security file:sys:/system/nici/XARCHIVE.000 
Backing up security file:sys:/system/nici/XARCHIVE.001 
Backing up security file:sys:/system/nici/XMGRCFG.KS2 
Backing up security file:sys:/system/nici/XMGRCFG.KS3 
Backing up security file:sys:/system/nici/XMGRCFG.NIF 
Starting database backup... 
Database backup finished 
Completion time 00:00:03 
Backup completed successfully 
 
|==================DSBackup Log:Restore================| 
Log file name:sys:/save/doc.log 
Restore started:2002-7-19'T19:1:34GMT 
Restore file name:sys:/backup/backup.bak 
Starting database restore... 
Restoring file sys:/backup/backup.bak 
Restoring file sys:/system/nici/INITNICI.LOG 
Restoring file sys:/system/nici/NICISDI.KEY 
Restoring file sys:/system/nici/XARCHIVE.000 
Restoring file sys:/system/nici/XARCHIVE.001 
Restoring file sys:/system/nici/XMGRCFG.KS2 
Restoring file sys:/system/nici/XMGRCFG.KS3 
Restoring file sys:/system/nici/XMGRCFG.NIF 
Database restore finished 
Completion time 00:00:15 
Restore completed successfully


DSMASTERサーバによる災害対策

複数サーバ環境で、サーバがすべて失われてしまうような災害にも備えるためには、ツリーの一部としてDSMASTERサーバを導入することを検討してください。

Backup eMToolは各サーバを個別にバックアップするツールです。すなわち、ツリー全体ではなく、個々のサーバを対象とするよう設計されています。ただしDSMASTERサーバを作成しておけば、Backup eMToolでも、ツリー構造全体をバックアップできるようになります。運用例の概要については、シナリオ:複数サーバ構成のネットワークで、すべてのサーバが使えなくなった場合を参照してください。

災害からの復旧で問題となるのは、同じパーティションのレプリカが複数あって、互いに整合性が取れていない場合の対処方法です。災害によってロールフォワードログも失われている場合、すべてのサーバを同じ時点の状態に復元することはできません。バックアップされたレプリカはサーバごとに異なる時点のものなので、ロールフォワードログを使わずに単純に復元しただけでは、全体をツリーとしてまとめる際に問題が起こるためです。復元後の検証処理は、このような問題を予防するために設計されています。デフォルトでは、他のレプリカとの不整合が見つかれば、eDirectoryデータベースは復元後にはオープンされません。

DSMASTERサーバを導入すればこのような事態に備えることができます。ツリー全体のマスタコピーを作成しておき、これを復元の基準点として使用します。

DSMASTERサーバを導入する手順を次に示します。

以上のようにツリーを設計しておくと、災害が起こっても、迅速にツリー構造を再構築し、稼動させることができます。1台だけのサーバ(あるいは少数のキーサーバ)のみを復元し、これをマスタレプリカとして扱うようにすればよいのです。

このツリーが稼動し始めてから、フル/インクリメンタルバックアップファイルを使用して、DSMASTER以外のサーバも順次復元していきます。ロールフォワードログがないため、他のサーバに対する復元後の検証処理は失敗します。そこで、レプリカリングからいったん外し、DSRepairを使って、すべてのレプリカ情報を外部参照に変更します。その後、DSMASTERサーバ上のコピーからレプリカを作成して、改めてサーバにレプリカを追加します。この手順については、復元後の検証処理に失敗した場合の対処方法に記載されています。

災害により一部のサーバが失われた場合、操作手順はやや複雑になりますので、Novellの担当者に連絡してください。


遷移ベクトルと復元後の検証処理

遷移ベクトルとは、レプリカのタイムスタンプのことです。レプリカ作成時刻を1970年1月1日からの経過秒数で表したものと、レプリカ番号、および現在のイベント番号を組にして表示されます。たとえば次のような形をしています。 

s3D35F377 r02 e002

バックアップ/復元処理に関していえば、復元されたサーバがレプリカリング内で正しく同期しているかどうか確認するために使う、重要なデータです。

同じパーティションのレプリカを保持するサーバは、レプリカの同期を取るため、互いにデータをやり取りしています。サーバはレプリカリング内の他のサーバと通信するたびに、他のサーバの遷移ベクトルを記録しています。遷移ベクトルを使用すると、レプリカリング内の各レプリカが同期を保つためには、どのデータを送ればよいか、サーバが常に把握できます。サーバが停止するとこの通信が止まり、再び通信できるようになるまでの間、遷移ベクトルに更新や変更があっても他のサーバはそれを送信しません。

あるサーバのeDirectoryを復元した後、検証処理として、復元された遷移ベクトルをレプリカリングに属する他のサーバと比較します。これは、復元されたレプリカが他のサーバと同期の取れた状態であるかどうか確認するために実行されます。

リモートサーバの遷移ベクトルの方がローカルベクトルより後の時間に作成されたものである場合は、復元されなかったデータがあるということなので、検証処理は失敗します。これは、フルバックアップまたはインクリメンタルバックアップの前に、ロールフォワードログの機能を有効にしていなかった、ロールフォワードログを使わずに復元しようとした、または必要なロールフォワードログが揃っていなかった、などが原因でデータの損失があることが考えられます。

デフォルトでは、復元したeDirectoryデータベースが他のレプリカと整合が取れていない場合、そのままではオープンできません。

遷移ベクトルに不整合があるログファイルの例については、Backup eMToolによる復元作業の概要を参照してください。

互換性の問題で検証処理に失敗することもあります。これについては、復元後の検証についてはeDirectory 8.5以降のみで互換性があるを参照してください。

検証に失敗した場合の対処方法については、復元後の検証処理に失敗した場合の対処方法を参照してください。


復元後の検証についてはeDirectory 8.5以降のみで互換性がある

復元後の検証処理については、8.5より前のeDirectoryとは互換性がありません。レプリカリング内にeDirectory 8.5より前のバージョンが稼動しているサーバがあれば、復元処理は失敗します。エラーコードは-666、すなわち「DSバージョンの不整合」となります。これは、レプリカが同期していないことを示すのではなく、eDirectoryのバージョンが8.5以前のため、遷移ベクトルの比較ができなかったことを示しているに過ぎません。

デフォルトでは、検証処理に失敗しているため、データベースがオープンされません。ただし、エラーが発生しているのが8.5サーバのみで、他のサーバでは問題なく検証されているのであれば、eMBox Clientで上書き復元を実行することにより、安全にデータベースをオープンすることができます。

あるいは、旧バージョンのサーバをレプリカリングから外し、再度復元を試みる方法もあります。

復元処理と遷移ベクトルの詳細については、Backup eMToolによる復元作業の概要およびBackup eMToolによる復元作業の概要を参照してください。


NetWareのファイルシステムデータを復元する際のアクセス権の保存

NetWareの場合、ファイルシステム権(トラスティの割り当て)は、eDirectoryにあるトラスティオブジェクトによって決まります。そのため、eDirectoryとNetWareのファイルシステムデータを復元する際には、ファイルシステム権について注意する必要があります。

eDirectoryの後でファイルシステムデータを復元するようにすれば、その時点でファイルシステム権も正しく復元されます。ただしこの問題を認識しておくことは必要です。起こりうる問題についてはあらかじめ確認し、必要に応じて予防措置を取ってください。


復元処理によりファイルシステム権に影響が及ぶ理由

eDirectoryの復元作業に先立ち、eDirectoryを新たにインストールし、仮のツリーを作成しておく必要があります。仮のツリーを作成するのは故障した記憶デバイスに代わる新しいデバイス上でも、サーバを移行する場合であれば新しいコンピューター上でもかまいません。

eDirectoryを新規インストールした段階では、トラスティ権が割り当てられたオブジェクトはありません(復元処理の過程で、トラスティオブジェクトも復元されることになります)。

ファイルシステムデータを復元する際、eDirectory内のトラスティオブジェクトが検索されます。しかし、復元前に新規インストールした状態のままでトラスティオブジェクトが見つからない場合、そのオブジェクトに対する権利の割り当てもファイルシステムから削除されることがあります。


この問題への対処方法

復元とファイルシステム権利/トラスティ割り当てに関する問題には、次のように、少しずつ異なるいくつかの対処方法があります。

  • 最も重要なのは、eDirectoryを先に復元し、その後でファイルシステムを復元することです。

    eDirectoryを新たにインストールし、復元する作業に、特別な準備はいりません。これが済んでから、ファイルシステムの復元ツールを使って、ファイルシステム権利やトラスティ割り当てを元に戻すために必要なファイルを復元できます。

  • バックアップの段階で、trustbar.nlmを使用してファイルシステム権利/トラスティ割り当てをバックアップできます。同等の処理ができるサードパーティ製ソフトウェアを使っても構いません。こうしておけば、eDirectoryを復元した後でも、必要に応じてトラスティ割り当てを復元できます。

    ファイルシステム権利/トラスティ割り当てのバックアップは、eDirectoryやファイルシステムと同じスケジュールで実施することもできます。

    注:  ファイルシステム権利のバックアップのスケジュールは、サードパーティ製ソフトウェアのほか、Novell Support Webサイトで提供しているcron.nlmでも可能です。

  • ストレージシステムの構成を検討し直すことにより、eDirectoryやファイルシステムデータを復元しなければならないような障害の可能性を減らすことができます。たとえばRAID構成などにすれば、ディスクが1台故障した場合にデータを損失する可能性は低くなります。sys:ボリュームを冗長構成にしておけば、デバイスに障害があっても、eDirectoryの新規インストールやファイルシステムの復元作業はしないで済むかもしれません。
  • 何らかの理由により、先にファイルシステムデータを復元してしまい、権利が失われてしまったとしても、eDirectoryを復元した後、もう一度ファイルシステムを復元すれば元に戻すことができます。
  • eDirectoryの復元作業が終わるまで、sys:以外のボリュームはマウントしないでおく、という方法もあります。障害を受けたのはsys:ボリュームだけで、ほかは動作している、という場合に有効です。

    確実にボリュームがマウントされないようにするためには、その記憶デバイスとサーバを結ぶケーブルを物理的に外してからNetWareやeDirectoryをインストールし、復元作業の終了後、再び接続し直すようにするとよいでしょう。

    eDirectoryの復元後、必要に応じてsys:ボリュームのファイルシステムを復元して、権利の設定を復旧してください。