| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
Directory Serverで管理されるデータは多くの場合、まとめてインポートされます。Directory Server Enterprise Editionでは、接尾辞全体をインポートおよびエクスポートするためのツールが用意されています。一度にすべての接尾辞のバックアップを作成するためのツール、およびバックアップからすべてのデータをリストアするためのツールも用意されています。
バックアップまたはリストア操作を始める前に、状況に合ったバックアップおよびリストアの計画を立てるようにしてください。各種バックアップ・オプション、考慮事項およびバックアップおよびリストア戦略の計画のためのガイドラインの詳細は、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』のバックアップおよびリストア・ポリシーの設計に関する項を参照してください。
この章の内容は、次のとおりです。
この項では、ディレクトリ・データのバイナリ・バックアップの実行方法について説明します。この項のバックアップ手順に加えてバイナリ・コピーを作成して、これをレプリケーション・トポロジの接尾辞の初期化に使用します。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。
バイナリ・データ・バックアップにより、ディレクトリ・データのコピーを保存することで、後でデータベース・ファイルが破損、またはそれを削除してしまった場合にそのコピーを使用できます。この操作では、データベースのバックアップのみを取り、構成データや証明書など他のデータのバックアップは行いません。障害時リカバリ用にDirectory Server全体のバックアップが必要な場合は、「障害時リカバリ」を参照してください。
|
注意: バックアップの間隔の最長期間が dsconf get-suffix-prop -h host -p port suffix-DN repl-purge-delay repl-cl-max-age バックアップの実行頻度がパージ遅延を下回る場合、バックアップされる前に変更ログがクリアされることがあります。したがって、バックアップからデータをリストアしようとしても、バックアップ前にクリアされた更新記録は失われています。 コンシューマ・サーバーはレプリケートされた接尾辞の内容に対する更新の内部情報、およびこの情報の保持期間を指定するパージ遅延パラメータ |
この項で説明するバックアップ手順ではすべて、デフォルトで同じホストにサーバー・ファイルのコピーを格納します。セキュリティを強化するには、別のマシンまたはファイル・システムにバックアップをコピーおよび格納する必要があります。
Directory Serverを停止して、dsadm backupコマンドを実行する必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ディレクトリ・データをバックアップします。
$ dsadm backup [ -f FLAG ] ... INSTANCE_PATH ARCHIVE_DIR
次に例を示します。
$ dsadm backup /local/dsInst /local/tmp/20091005
|
注意: デフォルトでは、バイナリ・バックアップ・コマンドはバックアップ・データベース上でデータベース・リカバリを実行します。この動作を無効にするには、dsadmを参照してください。 サーバー稼働中は、コマンド バックアップ操作中は、サーバーを停止しないでください。 |
dsadm backup、dsconf backupコマンドおよびバックアップ・フラグの詳細は、dsadmについての説明およびdsconfについての説明のマニュアル・ページを参照してください。
dse.ldifファイルをバックアップするにはサーバーをリストアする場合、証明書、スキーマ、プラグインなどのすべての構成データには、サーバーをバックアップしたときと同じ構成情報が含まれる必要があります。次のタスクでは、dse.ldifファイルをバックアップする方法を示しますが、残りの構成情報も同じ方法でバックアップできます。
$ cp instance-path/config/dse.ldif archive-dir
次の操作を実行すると、Directory Serverは自動的にdse.ldif構成ファイルのバックアップをディレクトリinstance-path/configに作成します。
Directory Serverを起動すると、dse.ldifファイルのバックアップがdse.ldif.startOKというファイルに作成されます。
cn=configブランチを変更した場合、サーバーで変更がdse.ldifファイルに書き込まれる前に、このファイルはまずconfigディレクトリのdse.ldif.bakというファイルにバックアップされます。
dscconfまたはdsadmを使用して、ファイル・システムをバックアップできます。たとえば、簡単にスクリプト記述および導入ができる通常のバックアップを行う際に、dsconfコマンドが役立つでしょう。バックアップを頻繁には行わない場合、またはスクリプト記述に適していないバックアップを行う際に、dsadmコマンドが役立つでしょう。また、Directory Serverが常にリクエストを処理していることが必要かどうか、プロキシ・サーバーおよびロード・バランサが設置されているかどうかなどの他の条件も考慮する必要があります。最終的には、ユーザー固有のニーズに合致するようなデプロイメントで動作する方法を選択します。
dsconfコマンドを使用してファイル・システムをバックアップする際に、凍結モード機能が利用可能です。凍結モードにより、ディスクのデータベース更新は停止するので、ファイル・システムのスナップショットを安全に取得できます。凍結モードは堅牢なバックアップを保証するための追加手法として使用できます。
サーバー・インスタンスが停止している場合、凍結モードは適用できません。
ファイル・システムのバックアップの進行中は、サーバーでディスク上のユーザー・データを書き込まないでください。特定の時間内に更新が行われないことが確実な場合は、この時間内にバックアップを行います。更新が行われないことを保証できない場合は、バックアップを行う前にサーバーを凍結モードにします。
凍結モードのサーバーでは、アクセス・ログとエラー・ログへの書込みが継続されます。単一サーバーのトポロジでは、凍結モード時に操作を受信すると、LDAPエラーが返されます。ログ記録されるエラー・メッセージはオフラインのデータベースに対する標準的なエラーです。レプリケートされたトポロジでは、リフェラルが返されます。凍結モードを適切に機能させるには、データベース上で他のタスクを実行しないようにしてください。
凍結モードにあるサーバーのデータベースは読取り専用モードのデータベースよりも安定しています。凍結モードとは異なり、読取り専用モードではタスクの作成と構成エントリの変更が認められます。凍結モードがオンの場合、構成されたデータベースはすべてオフラインとなります。進行中の内部操作には、オフラインになるデータベースが通知されます。進行中のLDAP操作が完了すると、データベース環境はフラッシュされます。ユーザー・データ検索などの後続の操作がある場合、凍結モードがオフ設定になるまで拒否されます。ただし、凍結モードがオンでも、構成パラメータの検索はできます。
凍結モードはサーバー稼働中のみアクティブにできます。サーバー・インスタンスを再起動すると、凍結モードはオフにリセットされます。
dsconfを使用してファイル・システムをバックアップするにはご使用のサーバーを凍結モードにします。
$ dsconf set-server-prop -h host -p port read-write-mode:frozen
ファイル・システム・タイプに適したツールを使用して、ファイル・システムをバックアップします。
サーバーが凍結モードの場合、再度サーバーを読書き可能にします。
$ dsconf set-server-prop -h host -p port read-write-mode:read-write
サーバーがレプリケーションの更新を別のサーバーから受け取った場合は、凍結モードがオフになるとすぐにレプリケーションの更新が始まります。
dsadmを使用してファイル・システムをバックアップするにはDirectory Serverインスタンスを停止します。
$ dsadm stop instance-path
バックアップするDirectory Serverインスタンスを含む、すべてのディレクトリをリスト表示します。
$ dsadm list-instance-dirs instance-path
このコマンドからの出力を、次の手順で使用するアーカイブ・ユーティリティへの入力として使用できます。
ファイル・システム・タイプに適したツールを使用して、ファイル・システムをバックアップします。
Directory Serverインスタンスを起動します。
$ dsadm start instance-path
LDIFへのバックアップにより、ディレクトリ・データをフォーマットされたLDIFファイルにバックアップできます。
LDIFフォーマットで接尾辞の内容をエクスポートすることにより、ディレクトリ・データをバックアップできます。データのエクスポートは、次のような場合に便利です。
サーバー上のデータのバックアップ
他のディレクトリ・サーバーへのデータのコピー
他のアプリケーションへのデータのエクスポート
ディレクトリ・トポロジ変更後の接尾辞の再移入
構成情報はエクスポートできません。
接尾辞データは大量のディスク領域を占有する可能性があり、特にLDIFフォーマットのファイルではそれが顕著です。圧縮ファイルのエクスポートにより、転送時間とディスク領域を最適化できます。接尾辞データをエクスポートする際に、エクスポート・ファイルのファイル名末尾が.gzであれば、ODSEEでは自動的にファイルが圧縮されます。デフォルトの圧縮レベルは3になります。圧縮レベルを上げると、CPU使用率は大幅に増加しますが、ファイル・サイズではそれほど大幅な収縮は見られません。
レベルの範囲は1から9までの数値となります。その他の値はデフォルトのレベル3に戻されます。出力LDIFファイルの末尾が.gzでない場合、圧縮レベルは無視されます。
|
注意: エクスポート操作の進行中は、サーバーを停止しないでください。 |
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のコマンドのいずれかを使用して、接尾辞をLDIFファイルにエクスポートします。
サーバーがローカルかつ停止中の場合、次を入力します。
$ dsadm export instance-path suffix-DN LDIF-file
dsadm exportはオフライン・バックアップのみとなります。
(ローカルでもリモートでも)サーバーが実行中の場合は、次のように入力します。
$ dsconf export -h host -p portsuffix-DN LDIF-file
dsconf exportはオンライン・バックアップのみとなります。
次の例ではdsconf exportを使用して、2つの接尾辞を単一のLDIFファイルにエクスポートしています。
$ dsconf export -h host1 -p 1389 ou=people,dc=example,dc=com \ ou=contractors,dc=example,dc=com /local/dsInst/ldif/export123.ldif
ldifファイルはサーバー・インスタンスを実行中のマシンで作成されます。dsconfコマンドを実行しているマシンでは作成されません。
dsadm exportおよびdsconf exportコマンドに--no-replオプションを付けて、レプリケーション情報がエクスポートされないように指定することもできます。デフォルトでは、レプリケートされた接尾辞がレプリケーション情報を伴い、LDIFファイルにエクスポートされます。結果として作成されるLDIFファイルには、レプリケーション・メカニズムで使用される属性サブタイプが含まれています。後でこのLDIFファイルをコンシューマ・サーバーにインポートして、「レプリカの初期化」での説明のとおり、コンシューマ・レプリカを初期化できます。
これらのコマンドの詳細は、dsadmについての説明およびdsconfについての説明のマニュアル・ページを参照してください。
次の手順では、ディレクトリの接尾辞をリストアする方法を説明します。サーバーは、「ディレクトリ・データのみのバックアップ」で説明している手順を使用して、バックアップを済ませる必要があります。レプリケーション承諾に関係する接尾辞をリストアする前に、「レプリケートされた接尾辞のリストア」をお読みください。
|
注意: リストア操作中は、サーバーを停止しないでください。サーバーをリストアすると既存のデータベース・ファイルが上書きされるため、バックアップの後に行った変更は失われます。 |
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のコマンドのいずれかを使用して、サーバーをリストアします。
サーバーがローカルかつ停止中の場合、次を入力します。
$ dsadm restore instance-path archive-dir
たとえば、バックアップ・ディレクトリからバックアップをリストアするには、次を入力します。
$ dsadm restore /local/dsInst/ local/ds/bak/2006_07_01_11_34_00
サーバーが稼働中の場合、次を入力します。
$ dsconf restore -h host -p port archive-dir
たとえば、バックアップ・ディレクトリからバックアップをリストアするには、次を入力します。
$ dsconf restore -h host1 -p 1389 /local/dsInst/bak/2006_07_01_11_34_00
リストア操作中は、サーバーを停止しないでください。
|
注意: バックアップ・コピーは、 リストア後、元のサーバーの内容に戻すことはできません。 |
|
注意: ディスク領域を節約するため、ファイルのコピーではなく、移動によってサーバーをリストアできます。この操作を実行するには、 この操作を正常に行うには、バックアップとインスタンス・ファイルを同じファイルシステムに置く必要があります。コピーレス・リストアの実行を選択する場合、サーバー・データはバックアップ・コピーのデータで上書きされ、さらにバックアップ・コピーは破棄されます。 |
これらのコマンドの詳細は、dsadmについての説明およびdsconfについての説明のマニュアル・ページを参照してください。
サプライヤ・サーバーとコンシューマ・サーバー間でレプリケートされた接尾辞では、リストアする前に特別な考慮が必要です。可能な場合、バックアップからのリストアではなく、レプリケーション・メカニズムにより接尾辞を更新するようにしてください。
サプライヤまたはハブ・インスタンスをリストアする際は、サーバーの構成をバックアップを実行したときと同じにする必要があります。これを確実に行うには、Directory Serverデータのリストア前にdse.ldifファイルをリストアします。サーバーの起動中に、--safeオプションを使用します。詳細は、「Directory Serverを起動、停止および再起動するには:」を参照してください。
この項では、レプリカをリストアする場合とその方法、およびその操作後に他のレプリカとの同期を確保する方法について説明します。レプリカを初期化するには「レプリカの初期化」を参照してください。
レプリケートされた大規模な接尾辞に多くのエントリを追加して、レプリケーションの更新が正常に追加されるようにするには、「大規模なレプリケートされた接尾辞への多数のエントリの増分追加」を参照してください。
この項の内容は、次のとおりです。
シングルマスター・サプライヤである接尾辞には、レプリケーション・トポロジ全体に対して信頼できるデータが含まれます。したがって、接尾辞のリストアはトポロジ全体のデータすべてを初期化すしなおすことに相当します。シングルマスターをリストアするのは、リストアするバックアップの内容で全データを初期化しなおす場合のみとします。
エラーによりシングルマスター・データのリカバリが不可能な場合、コンシューマにはバックアップよりも新しい更新を含まれていることがあるので、いずれかのコンシューマのデータを使用することを検討してください。この場合、データをコンシューマ・レプリカからLDIFファイルにエクスポートしてから、そのLDIFファイルよりマスターを初期化しなおす必要があります。
バックアップのリストアでも、マスター・レプリカでのLDIFファイルのインポートでも、後でこのレプリカから更新を受信するすべてのハブおよびコンシューマ・レプリカを初期化しなおす必要があります。サプライヤ・サーバーのログ・ファイルには、コンシューマの再初期化が必要であることを示すメッセージが記録されます。
マルチマスターのレプリケーションでは、他の各マスターにはレプリケートされたデータの信頼できるコピーが含まれています。古いバックアップでは、最新のレプリカの内容より古い場合があるので、リストアできません。可能であれば、レプリケーション・メカニズムにより、他のマスターの内容を使用してマスターを最新にするようにしてください。
それが不可能な場合、次のいずれかの方法でマルチマスターをリストアします。
最も簡単な方法は、バックアップをリストアせずに、他のマスターのいずれかより目的のマスターを初期化しなおすことです。これにより、最新データが目的のマスターへ送られ、データのレプリケーション準備が整います。「LDIFからのレプリカの初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、他のマスターにある最新バックアップのいずれかをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。
他のどのマスターに対しても変更ログ・コンテンツ最大経過時間を超えていないマスターのバックアップがあれば、そのバックアップをこのマスターのリストアに使用できます。変更ログ経過時間の詳細は、「マスター・レプリカの変更ログ設定を変更するには:」を参照してください。古いバックアップをリストアする場合、他のマスターはそれぞれの変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このマスターを更新します。
リストアまたは再初期化の方法にかかわらず、マスター・レプリカでは初期化後も読取り専用モードが維持されます。この動作により、レプリカの他のマスターとの同期が可能になり、これ以後は、「マルチマスター・シナリオでのマスターのリストア」の説明どおりに、書込み操作を行うこともできます。
リストアまたは再初期化したマスターでの書込み操作を許可する前に、すべてのレプリカを収束させることの利点は、ハブまたはコンシューマ・サーバーを初期化しなおす必要がなくなることです。
この項は、レプリケーション・メカニズムでハブ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりハブ・レプリカをリストアまたは初期化しなおす必要があります。
最も簡単な方法は、バックアップをリストアせずに、マスター・レプリカのいずれかよりハブを初期化しなおすことです。これにより、最新データがそのハブへ送られ、データのレプリケーション準備が整います。「接尾辞の初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、別のハブのレプリケートされた接尾辞からの最新のバックアップをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。コピーするハブのレプリカが他にない場合、前項での説明のようにハブを初期化しなおすか、次項での説明のようにハブをリストアします(可能な場合)。
どのサプライヤ(ハブまたはマスター・レプリカ)に対しても変更ログ・コンテンツ最大経過時間も超えていないハブのバックアップがあれば、そのバックアップをこのハブのリストアに使用できます。ハブをリストアする場合、そのサプライヤは各自の変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このハブを更新します。
|
注意: ハブ・レプリカのリストアまたは初期化の方法にかかわらず、他のあらゆるレベルのハブを含め、このハブのコンシューマをすべて初期化しなおす必要があります。 |
この項は、レプリケーション・メカニズムで専用コンシューマ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりコンシューマをリストアまたは初期化しなおす必要があります。
最も簡単な方法は、バックアップをリストアせずに、サプライヤ(マスターまたはハブ・レプリカ)のいずれかよりコンシューマを初期化しなおすことです。これにより、最新データがそのコンシューマへ送られ、データのレプリケーション準備が整います。「LDIFからのレプリカの初期化」を参照してください。
非常に多くのエントリを持つレプリカの場合、バイナリ・コピーを作成して、別のコンシューマのレプリケートされた接尾辞からの最新のバックアップをリストアすれば、高速化できます。「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」を参照してください。コピーするコンシューマのレプリカが他にない場合、前項での説明のようにレプリカを初期化しなおすか、次項での説明のようにレプリカをリストアします(可能な場合)。
どのサプライヤ(ハブまたはマスター・レプリカ)に対しても変更ログ・コンテンツ最大経過時間も超えていないコンシューマのバックアップがあれば、そのバックアップをこのコンシューマのリストアに使用できます。コンシューマをリストアする場合、そのサプライヤは各自の変更ログを使用して、そのバックアップの保存以降に処理されたすべての変更により、このコンシューマを更新します。
マルチマスターのレプリケーションの場合、あるマスターのリストア中に、他のマスターが変更を処理することもあります。したがって、リストア完了時に、新しいマスターは、リストア・データには含まれていなかった新しい更新を受け取る必要があります。マスターのリストアには莫大に時間がかかる場合があるので、保留中の更新数もまた莫大になることがあります。
それらの保留中の更新を収束させるために、新たにリストアされたマスターはリストア後、クライアント操作に対して自動的に読取り専用モードに設定されます。これは、コマンドラインでLDIFファイルからデータをインポートするか、バックアップを使用してバイナリ・コピーを実行することでマスターをリストアする場合にのみ当てはまります。
したがってリストア後は、マルチマスター構成のマスターは、レプリケーション更新を処理して読取り操作を許可しますが、クライアントからの書込み操作すべてに対してはリフェラルを返します。
更新が許可される前に、新しいマスターが他のマスターと完全に同期していることを確認するには、初期化されたマスターで手動により更新を有効にします。
|
注意: この新しい動作によってリフェラルを送信するマスター・レプリカでは、書込み操作を実行するクライアントは構成されたホップ制限に達する場合があります。この場合、クライアントのホップ制限の構成を増やして、クライアントが使用可能なマスターへアクセスできるようにする必要があります。すべてのマスター・レプリカが初期化または再初期化されている場合、クライアント更新を受け付けるレプリカがないので、書込み操作はすべて失敗します。 いずれにしても、初期化されたマスターを注意して監視し、リフェラル属性を適切に設定してサーバーのレスポンスを最大にしてください。 |
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のコマンドをマルチマスター・レプリカの初期化プロセスを自動化するスクリプトで使用できます。
insyncツールを使用して、レプリカが他のすべてのマスターと一致したことを確認します。
全サーバーにおける変更の遅延がゼロの場合、またはレプリカにレプリケートする変更がない場合(-1の遅延)、レプリカは同期状態にあります。詳細は、insyncに関する説明のマニュアル・ページを参照してください。
更新の受付けを開始します。
$ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on
このコマンドにより、読み書きモードが自動的に設定されます。
障害時リカバリの目的でDirectory Serverをバックアップまたはリストアする場合、次の手順を使用してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
コマンドdsadm backupまたはdsconf backupを使用して、データベース・ファイルのバックアップを作成します。
「バイナリ・バックアップ」の手順を使用して、安全な場所にバックアップ・ファイルを格納します。
構成ディレクトリinstance-path/configを安全な場所へコピーします。
スキーマ・ディレクトリinstance-path/config/schemaを安全な場所へコピーします。
別名ディレクトリinstance-path/aliasを安全な場所へコピーします。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
同じハードウェア構成でシステムをリカバリしてください。たとえば、Solaris SPARCでDirectory Serverをリストアするには、Solaris SPARCのリカバリ・メカニズムを使用する必要があります。
すでにホストにあるものと同じバージョンのDirectory Serverをインストールします。
dsadm createコマンドを使用して、サーバー・インスタンスを作成します。
instance-pathは、元のインスタンスと同じである必要があります。「接尾辞の作成」を参照してください。
構成ディレクトリinstance-path /configをリストアします。
スキーマ・ディレクトリinstance-path/config/schemaをリストアします。
別名ディレクトリinstance-path/aliasをリストアします。
リストアしたサーバーの構成が正しいことを確認します。
たとえば、ディレクトリ構造とプラグイン構成はバックアップされたサーバーと同じにする必要があります。
コマンドdsconf restoreを使用して、データベース・ファイルをリストアします。
「バイナリ・リストア」の手順を使用します。
