バックアップと復元のポリシーの設計

データ破壊やデータ損失をともなう障害の状況では、データの最新のバックアップを保有していることが不可欠です。できるだけ、ほかのサーバーからのサーバーの再初期化は避けてください。データのバックアップ方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 9 章「Directory Server のバックアップと復元」を参照してください。

ここでは、バックアップと復元の戦略を計画する上で考慮すべき事項の概要について説明します。

高レベルのバックアップと復旧の原則

バックアップ戦略を設計するときは、次の高レベルの原則を適用します。

• バックアップする必要のあるデータを特定します。

  Directory Server Enterprise Edition の場合、このデータには次のものが含まれます。

  • 共有されているバイナリとプラグイン

  • 証明書データベースのファイル

  • 設定ファイル

  • ログファイルと更新履歴ログデータベース

  • スキーマファイル

  • ユーザーデータ

• バックアップと復元の戦略に、ハードウェア、オペレーティングシステム、およびソフトウェアコンポーネントが含まれている必要があります。

• バイナリバックアップまたは LDIF バックアップを保持するかどうかを決定します。

  一般には、この両方を保持することをお勧めします。詳細については、「バックアップ方法の選択」および 「復元方法の選択」を参照してください。

• バックアップおよび復旧ツール関連の自動化を確立するとともに、自動スクリプトが保守されている必要があります。

  この戦略によって、緊急にバックアップからの復元が必要になった場合の不必要な遅延が回避されます。

• 保持とローテーションの戦略を決定します。

  この戦略には、バックアップを実行する頻度と、バックアップを保持する期間が含まれます。バックアップの保持とローテーションを決定する場合は、パージ遅延と、それによる、レプリケートされるトポロジ内のバックアップへの影響に注意してください。サプライヤで変更が発生すると、それらの変更は更新履歴ログに記録されます。更新履歴ログを空にするための方法がないと、そのサイズは、すべての使用可能なディスク容量が更新履歴ログによって消費されるまで増え続けます。デフォルトでは、これらの変更は 7 日ごとに消去されます。この期間をパージ遅延と呼びます。変更が消去されると、その変更をレプリケートすることはできなくなります。そのため、データベースは、少なくともパージ遅延と同じ頻度でバックアップされる必要があります。

• 単にシステムのバックアップと復旧を実行するのではなく、Directory Server Enterprise Edition で提供されているバックアップおよび復旧ツールを使用します。

バックアップ方法の選択

Directory Server Enterprise Edition では、バイナリバックアップと、LDIF ファイルへのバックアップという 2 つの方法でデータをバックアップできます。どちらの方法にも利点と制限があるため、効果的なバックアップ戦略を計画するには、それぞれの方法について理解することが役立ちます。

バイナリバックアップ

バイナリバックアップは、データベースファイルのコピーを生成するものであり、ファイルシステムレベルで実行されます。バイナリバックアップの出力は、すべてのエントリ、インデックス、更新履歴ログ、トランザクションログを含むバイナリファイルのセットです。バイナリバックアップには、設定データは含まれません。

バイナリバックアップは、次のいずれかのコマンドを使用して実行されます。

• dsadm backup はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf backup は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

バイナリバックアップには、次のような利点があります。

• すべてのサフィックスを一度にバックアップできる。

• LDIF へのバックアップと比較して、バイナリバックアップは格段に高速である。

• レプリケーション更新履歴ログがバックアップされる。

バイナリバックアップには、1 つの制限があります。バイナリバックアップからの復元は、「同一の」設定のサーバーだけでしか実行できません。

この制限は次を意味します。

• 両方のマシンが同じハードウェア、同じオペレーティングシステム (サービスパックやパッチも含まれる) を使用している必要がある。

• 両方のマシンに同じバージョンの Directory Server (32 ビットまたは 64 ビットのバイナリ形式、サービスパック、パッチレベルも含まれる) がインストールされている必要がある。

• 両方のサーバーは、同じサフィックスに分岐する同じディレクトリツリーを持つ必要がある。すべてのサフィックスのデータベースファイルをまとめてコピーする必要があり、サフィックスを個別にコピーすることはできない。

• 両方のサーバーの各サフィックスには同じインデックス (仮想リスト表示 (VLV) インデックスも含まれる) が設定されている必要がある。サフィックスのデータベースファイルの名前は同じである必要がある。

• 各サーバーに、レプリカとして同じサフィックスが設定されている必要があります。部分レプリケーションが設定されている場合、部分レプリケーションはすべてのマスターサーバーで同じように設定されている必要がある。

• どちらのサーバーでも、属性の暗号化は使用できません。

少なくとも、整合性のあるマシンの各セットに対して定期的なバイナリバックアップを実行してください。整合性のあるマシンとは、前述のように同一の設定を持つマシンのことです。

ローカルバックアップからの復元の方が簡単なため、各サーバーでバイナリバックアップを実行してください。

この章の残りの図では、次の略語を使用します。

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 と M3 でバイナリバックアップが行われます。障害が発生した場合は、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。M1 と M2 を M3 のバイナリバックアップから復元することはできません。M3 と M4 を M1 のバイナリバックアップから復元することはできません。

図 8–2 オフラインのバイナリバックアップ

バイナリバックアップのコマンドの使用方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリバックアップ」を参照してください。

LDIF へのバックアップ

LDIF へのバックアップはサフィックスレベルで行われます。LDIF へのバックアップの出力は、サフィックスに含まれているデータのコピーである、フォーマットされた LDIF ファイルです。このため、このプロセスはバイナリバックアップと比較して時間がかかります。

LDIF へのバックアップは、次のいずれかのコマンドを使用して実行されます。

• dsadm export はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf export は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

これらのコマンドの実行時に -Q オプションを指定しないかぎり、レプリケーション情報はバックアップされます。

LDIF へのバックアップでは、dse.ldif 設定ファイルはバックアップされません。以前の設定を復元できるようにするには、このファイルを手動でバックアップしてください。

LDIF へのバックアップには、次のような利点があります。

• LDIF へのバックアップは、設定に関係なくどのサーバーからも実行できる。

• LDIF バックアップからの復元は、設定に関係なくどのサーバーからも実行できる。

LDIF へのバックアップには、1 つの制限があります。迅速なバックアップと復元が必要な状況では、LDIF へのバックアップでは時間がかかり過ぎる可能性があります。

トポロジの単一マスターで、レプリケートされた各サフィックスを LDIF に定期的にバックアップする必要があります。

次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadm export が実行されています。

図 8–3 LDIF へのオフラインのバックアップ

LDIF へのバックアップのコマンドの使用方法については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF へのバックアップ」を参照してください。

復元方法の選択

Directory Server Enterprise Edition では、バイナリ復元と、LDIF ファイルからの復元という 2 つの方法でデータを復元できます。バックアップ方法と同様に、どちらの方法にも利点と制限があります。

バイナリ復元

バイナリ復元では、データベースレベルでデータがコピーされます。バイナリ復元は、次のいずれかのコマンドを使用して実行されます。

• dsadm restore はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf restore は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

バイナリ復元には、次のような利点があります。

• すべてのサフィックスを一度に復元できる。

• レプリケーション更新履歴ログが復元される。

• LDIF ファイルからの復元と比較して、バイナリ復元は格段に高速である。

バイナリ復元には、次のような制限があります。

• 復元は、同一の設定を持つサーバーでしか実行できない (「バイナリバックアップ」を参照)。バイナリ復元機能を使用したデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「バイナリ復元」を参照してください。

• データベースが破壊されていることに気付かずにバイナリバックアップを実行した場合は、破壊されたデータベースが復元される危険性がある。バイナリバックアップは、データベースの現在の状態をありのままにコピーします。

マシンの設定が同一であり、実行時間を極力減らすことを一番の目的としている場合は、推奨される復元方法はバイナリ復元になります。

次の図は、M1 と M2 が同一の設定を持ち、M3 と M4 が同一の設定を持つことを前提としています。この例では、M1 または M2 を M1 (db1) のバイナリバックアップから復元できます。M3 または M4 を M3 (db2) のバイナリバックアップから復元できます。

図 8–4 オフラインのバイナリ復元

LDIF からの復元

LDIF ファイルからの復元は、サフィックスレベルで実行されます。このため、このプロセスはバイナリ復元と比較して時間がかかります。LDIF からの復元は、次のいずれかのコマンドを使用して実行できます。

• dsadm import はオフラインで、つまり Directory Server インスタンスが停止されているときに実行してください。このコマンドは、Directory Server インスタンスを含むローカルサーバーで実行してください。

• dsconf import は、オンラインで実行でき、さらに Directory Server インスタンスのリモートからも実行できます。

LDIF ファイルからの復元には、次のような利点があります。

• このコマンドは、設定に関係なくどのサーバーからも実行できる。

• レプリケーショントポロジに関係なく、ディレクトリサービス全体の配備に単一の LDIF ファイルを使用できる。予定されているビジネスニーズに合わせてディレクトリサービスをダイナミックに拡張または縮小する場合に、この機能は特に便利である。

LDIF ファイルからの復元には、1 つの制限があります。迅速な復元が必要な状況では、この方法は時間がかかり過ぎる場合があります。LDIF ファイルからのデータの復元の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「LDIF ファイルからのデータのインポート」を参照してください。

次の図では、1 つのマスター (M1) でのみ、レプリケートされた各サフィックスに対して dsadmin import が実行されています。

図 8–5 LDIF からのオフラインの復元