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

バックアップツールには、個々のサーバ単位で、稼動したままの状態で継続的にeDirectoryデータベースのバックアップを取る機能があります。データベースを停止することなく、処理を始めた時点のバックアップを取ることができます。つまり、バックアップ作業はいつでも可能であり、その間もeDirectoryを使い続けることができます

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

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

eDirectoryバックアップツールは、ファイルシステムバックアップ機能と組み合わせて使用して、eDirectoryバックアップファイルをテープに安全に保存する必要があります。NetIQはバックアップ用製品を開発している主要企業と提携しています。詳細については、NetIQ eDirectory Partner Productsを参照してください。

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

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

eDirectory 8.7で組み込まれたバックアップツールは、方式やアーキテクチャが一新されています。ツリーではなくサーバを基準とし、個々のサーバのeDirectoryデータベースをバックアップします。この変更により、以前のTSA for NDSバックアップよりも大幅に速くなりました。

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

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

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

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

各バックアップファイルのヘッダは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に含まれる属性について次の表で説明します。

バックアップファイルのヘッダ例を次に示します。これはWindowsサーバで作成したもので、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:\WINDOWS\system32\novell\nici\bhawkins\XARCHIVE.001" encoding="base64" type="nici">the data is included here</file>

<file size="4228" name="C:\WINDOWS\system32\novell\nici\bhawkins\XMGRCFG.KS2" encoding="base64" type="nici">the data is included here</file>

<file size="168" name="C:\WINDOWS\system32\novell\nici\bhawkins\XMGRCFG.KS3" encoding="base64" type="nici">the data is included here</file>

<file size="aaac" name="C:\WINDOWS\system32\novell\nici\nicintacl.exe" encoding="base64" type="nici">the data is included here</file>

<file size="150" name="C:\WINDOWS\system32\novell\nici\NICISDI.KEY" encoding="base64" type="nici">the data is included here
</file>

<file size="4228" name="C:\WINDOWS\system32\novell\nici\system\Xmgrcfg.ks2" encoding="base64" type="nici">the data is included here
</file>

<file size="168" name="C:\WINDOWS\system32\novell\nici\system\Xmgrcfg.ks3" encoding="base64" type="nici">the data is included here
</file>

<file size="1414" name="C:\WINDOWS\system32\novell\nici\xmgrcfg.wks" encoding="base64" type="nici">the data is included here
</file>

</backup>

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

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

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

バックアップツールのログファイルには、過去のバックアップ処理の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サーバを作成しておけば、バックアップツールでも、ツリー構造全体をバックアップできるようになります。運用例の概要については、「シナリオ: 複数サーバ構成のネットワークで、すべてのサーバが使えなくなった場合」を参照してください。

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

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

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

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

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

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

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

s3D35F377 r02 e002

バックアップと復元のコンテキストでは、復元されたサーバが参加しているレプリカリング内で正しく同期していることを確認するために遷移ベクトルが使用されます。

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

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

リモートサーバの遷移ベクトルの方がローカルベクトルより後の時間に作成されたものである場合は、復元されなかったデータがあるということなので、検証処理は失敗します。これは、前回のフルバックアップまたはインクリメンタルバックアップの前に継続的なロールフォワードログ記録を有効にしていなかった、ロールフォワードログを復元に含めなかった、または復元で指定したロールフォワードログがすべて揃っていなかった、などの理由でデータが不足していることが考えられます。

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

遷移ベクトルに不整合があるログファイルエントリの例については、「バックアップツールによる復元作業の概要」を参照してください。

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