もしもに備えるバックアップ、リストア（1）：OpenLDAPによるディレクトリサーバ運用（1）（2/2 ページ）

ファイル単位でバックアップする方法

　このバックアップ方法は基本的に、OpenLDAPサーバを停止するなどして、バックアップを行っている最中にバックアップ対象のファイルに変更が行われないことが保証できる状態で実行する方法です。OpenLDAPサーバの構築中やテスト期間中などにおいてサービス停止が可能な期間であれば、最もシンプルな方法であるため、OpenLDAPの操作に十分慣れていない管理者であっても抵抗なく利用することができるでしょう。

　基本的にオフラインで利用しなければならないというデメリットがありますが、リストア時には、ファイルのパーミッションにさえ注意さえすればファイルを元のディレクトリへ戻すだけのシンプルなオペレーションで迅速にサービスを復旧させることができます。

　実際のバックアップオペレーションは、次のようになるでしょう。

　このほか、OpenLDAPの設定ファイルであるslapd.confや、slapd.confからインクルードされるスキーマファイルを変更していればそれらもバックアップしておく必要があります。また、このバックアップで取得したファイルセットを利用したリカバリ処理でトランザクションログを利用しない場合、バックアップを取得する間隔が長くなればリストア時に失われる更新データを受け入れている期間も長くなることに注意する必要があります。

OpenLDAPが提供するツールコマンドを利用する方法

　この方法は、OpenLDAPのディレクトリデータをLDIFファイルとして論理的に抽出するslapcatコマンド、および、LDIFファイルをディレクトリデータベースへロードするslapaddコマンドを利用する方法です。

　LDIFファイルをディレクトリデータベースへロードするslapaddコマンドを実行する際は、OpenLDAPサーバが停止状態である必要があります。しかし、ディレクトリデータを抽出するslapcatコマンドは、OpenLDAPサーバの起動中でも実行できるため、ディレクトリサービス運用中にバックアップデータを取得することができます。

　実際のバックアップオペレーションは、次のようなコマンドを実行することになります。

　上記のslapcatコマンドはディレクトリデータを抽出するだけですので、Berkeley DBの設定ファイルであるDB_CONFIGファイルや、OpenLDAPの設定ファイルであるslapd.conf、さらにslapd.confからインクルードされるスキーマファイルを変更していれば、それらもバックアップ対象となることに注意してください。

　リストア時には、DB_CONIFGファイルやslapd.confファイル、スキーマファイルを所定のディレクトリへ戻した後、OpenLDAPサーバが停止している状態でslapaddコマンドを実行します。

　また、このバックアップ、リストア方法はトランザクションログを利用しないため、バックアップを取得する間隔が長くなれば、リストア時に失われる更新データが発生する期間も長くなってしまうことに注意してください。

slapcatコマンドのメリット、デメリット

　オンライン処理が可能なメリットを持つslapcatコマンドですが、さらにもう1つのメリットがあります。それは、slapcatコマンドはLDIFファイルにディレクトリデータを論理的に出力するため、Berkeley DBのバージョン固有の物理的なファイルフォーマットに依存しないことです。このため、slapcatコマンドを利用して抽出したデータはバージョンの異なるBerkeley DB間やバージョンの異なるOpenLDAP間でのデータ移行に用いることができます（注4）。

　オンラインでバックアップが取得でき、かつ、データ移行に利用可能なメリットを持つslapcat、slapaddコマンドを利用したバックアップ、リストアですが、残念なことに、大規模かつ更新頻度の高いOpenLDAPサーバのバックアップには向かない側面があります。

　slapcatコマンドによるディレクトリデータの抽出は、単純にエントリの先頭から順々に行われます。このため、エントリの最初の読み出しから終了までの間にOpenLDAPサーバに変更、追加、削除といったリクエストがあった場合、それを考慮した一貫性のあるバックアップデータが取得できないことです（図2）。

図2　slapcatコマンドの問題

　slapcatコマンドは、単純にバックエンドデータベースのディレクトリエントリを移動しながら、読み出し位置にあるエントリデータを抽出するため（1〜5）、読み出し位置を過ぎた後に変更されたエントリデータ（3）はバックアップデータには反映されず（6）、反対に読み出し位置に到達するよりも早く変更されたデータ（4）はバックアップデータに反映されます（6）。

　この問題により、エントリ数が多く更新頻度の高い大規模なディレクトリデータベースに対し、更新リクエストがないことを保証できる時間帯以外にslapcatコマンドを利用したバックアップを行う場合、リストア時に、時間的に先に行われた変更が失われているにもかかわらず、後に行われた変更が含まれるといった、一貫性のないデータが復元される可能性を否定できなくなってしまいます。たとえ更新頻度の少ないディレクトリデータベースであっても、slapcatによるバックアップは、できる限り更新のない時間帯を選んで行うよう設計するとよいでしょう。

　オンラインでバックアップを取得する必要があり、かつ、バックエンドデータベースのレベルで一貫性のあるバックアップを取得する必要がある場合は、バックエンドデータベースが提供するコマンドを利用してバックアップを取得し、トランザクションを意識したリカバリ処理が有効になります。第2回は、Berkeley DBが提供するバックアップ、リカバリコマンドを中心に説明していきます。