15.7 復元後の検証処理に失敗した場合の対処方法

復元処理の一環として検証を行います。復元されたeDirectoryデータベースと、レプリカリングに属する他のサーバとの間で、遷移ベクトルを比較するというものです。復元プロセスの詳細については、「バックアップツールによる復元作業の概要」と「遷移ベクトルと復元後の検証処理」を参照してください。

遷移ベクトルが合致しなければ、検証に失敗したことになります。これは一般に、復元処理に使ったファイルのデータが不足していたことを表します。たとえば次のような状況が考えられます。

最後にバックアップを実施した後、ロールフォワードログ機能を有効にしていなかった場合。
ロールフォワードログを取っていたのに、復元の際これを使わなかった場合。
ロールフォワードログが不足していた場合。

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

バックアップファイルやロールフォワードログの指定を単に忘れただけであれば、正しく指定してもう一度復元処理を実行すればよいはずです。次回に復元が成功すれば、検証に成功し、データベースがオープンされるでしょう。

必要なバックアップファイルやロールフォワードログが揃っていない場合は、以下の手順でサーバを復旧してください。検証に失敗したときの復旧手順の概要を説明します。

サーバの識別情報やファイルシステム権利は、バックアップファイルなどが不足していても復旧できるはずです。
バックアップからレプリカを復元できない場合でも、サーバとしては動作します。新しいレプリカが追加されたものとして扱われ、他のサーバにも影響を及ぼしてしまうのです。したがって、レプリカリングからいったんサーバを外し、高度な復元機能やDSRepairツールを使って元の状態に復旧してから、改めてレプリカリングに追加してください。
このサーバにしかデータがない、すなわち他のサーバにレプリカが作られていないパーティションについては、残念ながら復元できません。

検証に失敗した後、このセクションの説明に従ってサーバの識別情報やファイルシステム権利を復旧し、レプリカリングからいったん外し、再び追加します。ｋこの手順でレプリケーションが終了すれば、サーバは元どおりに機能するようになるはずです。ただしレプリカを作っていなかったために復元できなかったパーティションを除きます。

まず、「レプリカリングをクリーンアップする」に従って作業してください。それが終了したらサーバの復旧とレプリカの再追加に進みます。

15.7.1 レプリカリングをクリーンアップする

この手順では、次の方法について説明します。

マスタレプリカの再割り当て。 障害が発生したサーバが、あるパーティションのマスタレプリカを保持していた場合は、DSRepairを使って、レプリカリストに属する他のサーバ上のレプリカを、マスタとして扱うよう指定します。
障害が発生したサーバに対するレプリカリストの参照の削除。 障害が発生したサーバを含むレプリカリングのメンバーである各サーバに対して、障害が発生したサーバが利用できなくなったことを通知する必要があります。

前提条件

eDirectoryそのものは、当該サーバに正常にインストールされているものとします。
復元を試み、検証処理で失敗したことが前提です。
eDirectoryデータベースは稼動しており、(復元処理により作成された)RSTデータベースもマシンに残っているものとします。
どのパーティションのレプリカがこのサーバに保持されていたか、は分かっているものとします。このサーバのレプリカはバックアップファイルのヘッダ部に記録されています。

手順

レプリカリングをクリーンアップするには、次の操作を行います。

DSRepairを起動します。復元対象サーバとレプリカを共有しているサーバのコンソールから、次のオプションを指定して起動してください。
- Windows: -aスイッチを使用します。
- Linux: -Adスイッチを使用します。
-aまたは-Adスイッチを使用した詳細オプションでDSRepairを実行する方法については、「セクション 12.9, DSRepairオプション」を参照してください。

警告:-aまたは-Adを指定してDSRepairを使用する場合は、詳細オプションによってはツリーが破損することがあります。
［レプリカ操作とパーティション操作］を選択します。
編集したいパーティションを選択します。このパーティションが属するレプリカリングから、障害の起こったサーバを外すことになります。
［レプリカリングの表示］を選択して、このパーティションに関するレプリカを持つサーバのリストを表示します。
(状況によって実行)当該サーバにマスタレプリカがあった場合、［このサーバを新しいマスタレプリカに設定］コマンドで、他のサーバにマスタを切り替えます。

この時点で、対象のレプリカリングは新しいマスタレプリカを保持しています。リングを構成するすべてのレプリカに対して、新しいマスタが存在することが通知されます。
そのまましばらく待ちます。上記のレプリカがマスタになったことが他のサーバに認識されるまで、しばらく待ちます。
［レプリカリングの表示］に戻ります。障害が発生したサーバの名前を選択して、［レプリカリングからのサーバの削除］を選択してください。

DSRepairを起動する際に詳細オプションで-aまたは-Ad(プラットフォームにより選択)を指定していなかった場合、このコマンドは表示されません。

警告:障害の起こったサーバをマスタレプリカに設定したままで、このコマンドを実行しないでください。リング内のサーバリストを見れば確認できます。マスタレプリカであれば、「ステップ 5」を参照して、他のサーバにマスタを切り替えてから、当該サーバをレプリカリングから外します。
管理者としてログインします。
説明メッセージを読み、それに対する同意を入力して処理を続行します。
DSRepairを終了します。

レプリカリングを構成するすべてのサーバに通知が行われます。
障害が発生したサーバを含んでいる各レプリカリングごとに、1つのサーバ上で、この手順を繰り返します。

続いて、障害が生じたサーバ上に、新たにレプリカを構築します。「サーバの復旧とレプリカの再追加」に進んでください。

15.7.2 サーバの復旧とレプリカの再追加

レプリカ設定を「外部参照」側に書き替え、自分自身はレプリカリングに属していないものとして動作するようにします。その上でサーバからレプリカを削除すると、データベースのロックを解除できるようになります。

レプリカを削除すれば、レプリカをサーバに再追加する作業は終わりです。あとは自動的に、他のサーバから各レプリカの最新版を参照し、再追加していきます。各レプリカが再追加されたら、サーバは元と同じように機能するはずです。

DSRepairを使用してレプリカを削除し、レプリケーション機能により再追加する手順を次に示します。

が完了していることを確認します。レプリカリングをクリーンアップする
上書き復元コマンドを、次のように実行します。併せてログファイル名も指定してください。

dsbk restadv -v -l logfilename

この詳細復元オプションにより、RSTデータベース(復元したが検証に失敗したもの)の名前をNDSに変更します。ただしロックは解除しません。
サーバコンソールで、DSRepairの高度な復元機能により、レプリカ設定をすべて外部参照に切り替えます。
- Windows: ［スタート］>［設定］>［コントロールパネル］>［NetIQ eDirectoryサービス］の順にクリックします。［dsrepair.dlm］を選択します。［起動パラメータ］フィールドに、「-XK2 -rd」と入力します。［Start］をクリックします。
- Linux: 次のコマンドを入力します。
```
ndsrepair -R -Ad -xk2
```
-rdまたは-Rスイッチは、ローカルデータベースとレプリカを修復します。

警告:DSRepairによる高度な復元機能は、正しく使用しないとツリーが破損することがあります。
修復が終了したら、ロックを解除してデータベースを開きます。次のように実行してください。
```
dsbk restadv -o -k -l logfilename
```
-oはデータベースのオープン、-kはロック解除を表します。
iManagerを使って、修復されたサーバをレプリカリングに再追加します。
1. NetIQ iManagerで、［役割およびタスク］ボタンをクリックします。
2. ［パーティションとレプリカの管理］>［レプリカビュー］をクリックします。
3. 複製したいパーティションの名前とコンテキストを指定し、［OK］をクリックします。
4. ［レプリカの追加］をクリックします。
5. ［サーバ名］フィールドの横にある［参照］ボタンをクリックし、修復されたサーバを選択します。
6. 必要なレプリカのタイプを選択して、［OK］をクリックしてから、［完了］をクリックします。
7. このサーバが属していた各レプリカリングについて、上記の操作を繰り返します。
レプリケーション処理が終わるまでしばらく待ちます。

レプリカの状態が［新規］から［オン］に変われば、レプリケーション処理は終了です。これはiManagerで確認できます。詳細については、レプリカに関する情報を表示するを参照してください。
NICIセキュリティファイルを復元するには、最初に、NICIファイルだけを復元してから、NDSDサーバを再起動して、DIBを復元します。
(状況によって実行)このサーバでロールフォワードログ機能を使うためには、改めて有効に切り替え、障害対策のための書き出し先も設定し直して、ロールフォワードログの環境設定を再作成する必要があります。ロールフォワードログを有効にしてから、改めてフルバックアップも取る必要があります。

この手順が必要となるのは、復元処理の過程で、ロールフォワードログに関する設定はデフォルトに戻るためです。つまり、ロールフォワードログ機能は無効となり、保存先もデフォルトの場所になるからです。フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。

ロールフォワードログの詳細については、「セクション 15.3, ロールフォワードログを使用する」を参照してください。