前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



第 11 章   メッセージストアを管理する


この章では、メッセージストアとメッセージストアの管理インタフェースについて説明します。この章には、以下の節があります。



概要

メッセージストアには、特定の Messaging Server インスタンス用のユーザメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。ストアのサイズを制御するには、メールボックスのサイズ制限 (ディスク制限容量) を指定するか、許可するメッセージ総数を制限指定するか、ストア内のメッセージに関する保存期間決定ポリシーを設定します。

システムにユーザを追加していくに従い、ディスクストレージ要件も増えていきます。サーバがサポートするユーザ数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。この追加ディスク容量をシステムに統合するには、2 種類の方法が存在します。もっとも簡単な方法は、別のパーティションを追加することです。オプションで、特定のメッセージストアを担当する Messaging Server インスタンスを追加することもできます。ただし、この方法は非常に複雑です。

また、複数のホストドメインをサポートしている場合は、1 つのサーバインスタンスを単一の大規模ドメイン専用にした方がよい可能性があります。この構成を行えば、特定のドメインに対するストア管理を指定することができます。また、パーティションをさらに追加することで、メッセージストアを拡張することもできます。

iPlanet Messaging Server では、メッセージストアの管理のために、iPlanet Console インタフェースに加えてコマンドラインユーティリティのセットを提供しています。表 11-1 では、このコマンドラインユーティリティについて説明しています。これらのユーティリティの使用に関する詳細については、「保守および回復手順を実行する」および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


表 11-1    メッセージストアのコマンドラインユーティリティ 

ユーティリティ

説明

configutil  

ストアの設定パラメータの設定および変更を行います。  

deliver  

IMAP または POP メールクライアントがアクセスできるメッセージストアにメールを直接配信します。  

hashdir  

特定のユーザのメッセージストアを格納するディレクトリを識別します。  

iminitquota  

LDAP ディレクトリから制限容量の上限を再初期化し、使用されているディスク容量を再計算します。  

imsasm  

ユーザメールボックスの保存と回復を行います。  

imsbackup  

保存されたメッセージをバックアップします。  

imsexport  

Certificate Management System のメールボックスを UNIX の /var/mail 形式のフォルダ内にエクスポートします。  

imsrestore  

バックアップされたメッセージをリストアします。  

imscripter  

IMAP サーバプロトコルのスクリプティングツール。1 つまたは一連のコマンドを実行します。  

mboxutil  

メールボックスの一覧表示、作成、削除、名前変更、移動を行い、制限容量の使用状況をレポートします。  

mkbackupdir  

メッセージストア内の情報を含むバックアップディレクトリを作成および同期化します。  

MoveUser  

ユーザのアカウントを別の Messaging Server に移動します。  

quotacheck  

メッセージストア内の各ユーザのメールボックスの合計を計算し、そのサイズをそれらに割り当てられている制限容量と比較します。  

readership  

共有の IMAP フォルダ上の読者情報を収集します。  

reconstruct  

破壊または破損したメールボックスを再構築します。  

stored  

バックグラウンドの日常タスクを実行し、ディスクに保存されたメッセージの消去や削除を行います。  



メッセージストアのディレクトリレイアウト


図 11-1 は、サーバインスタンスに対するメッセージストアのディレクトリレイアウトを示しています。メッセージストアはメールボックスの内容に高速でアクセスできるように設計されています。ストアディレクトリについては、表 11-2 で説明しています。

図 11-1    メッセージストアのディレクトリレイアウト

たとえば、ディレクトリパスの例は以下のようになります。

server_root/msg-instance/store/partition/primary/=user/53/53/=mack1


表 11-2    メッセージストアのディレクトリの説明 

場所

内容/説明

server_root/msg-instance/
store/  

メッセージストアのトップレベルのディレクトリ。mboxlist、user、および partition サブディレクトリを格納しています。  

.../store/mboxlist/  

サーバ上のメールボックスに関する情報やメールボックスの制限容量に関する情報が保存されたデータベース (Berkley DB) を格納しています。

ファイル folder.db には、メールボックスが保存されているパーティションの名前、ACL、および store.idx にある情報のいくつかのコピーなど、メールボックスに関する情報が格納されています。folder.db には、メールボックスごとに 1 つのエントリが存在しています。

ファイル quota.db には、制限容量および制限容量の使用状況に関する情報が格納されています。quota.db2 には、ユーザごとに 1 つのエントリが存在しています。

ファイル peruser.db には、ユーザごとのフラグに関する情報が格納されています。このフラグは、特定のユーザがメッセージを確認したかどうか、または削除したかどうかを示しています。

ファイル subscr.db には、ユーザの購読に関する情報が格納されています。  

.../store/user/  

使用されていません。  

.../store/partition/  

デフォルトの primary パーティションが格納されています。このディレクトリには、ほかのサブパーティションを定義して格納することもできます。  

/partition/=user/  

パーティションのサブディレクトリにある全ユーザのメールボックスが格納されています。メールボックスは、高速で検索できるようにハッシュ構造で保存されています。特定のユーザのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティを使用します。  

/=user/hashdir/hashdir/
userid/  

userid という ID を持つユーザ用のトップレベルのメールフォルダ。デフォルトドメインでは、userid は uid です。ホストドメインでは、userid は uid@domain です。メッセージはこのメールフォルダに配信されます。  

/userid/folder  

ユーザ定義のフォルダ。  

/userid/store.idx  

このインデックスは、/userid/ ディレクトリに保存されたメールに関して、 メッセージの数、このメールボックスが使用するディスクの制限容量、メールボックスが最後に追加された時間、メッセージフラグ、各メッセージの可変長情報 (ヘッダーや MIME 構造を含む)、各メッセージのサイズなどのさまざまな情報を提供します。さらにこのインデックスには、各ユーザに関する mboxlist 情報のバックアップコピーや、各ユーザに関する制限容量情報のバックアップコピーも含まれています。  

/userid/store.usr  

フォルダにアクセスしたユーザのリストが格納されています。リストされた各ユーザについて、そのユーザが最後にフォルダにアクセスした時間、ユーザが表示したメッセージのリスト、ユーザが削除したメッセージのリストといった情報が格納されています。  

/userid/store.exp  

消去されたものの、ディスクからは消し去られていないメッセージファイルのリストを格納しています。このファイルは、消去されたメッセージが存在する場合のみ表示されます。  

/userid/store.sub  

ユーザの購読に関する情報が格納されています。  

/userid/nn/  

msgid.msg の形式でメッセージが格納されているハッシュディレクトリです。nn には、00 〜 99 までの数字が入ります。

たとえば、1 〜 99 のメッセージは 00 ディレクトリに保存されており、100 〜 199 のメッセージは 01 ディレクトリに保存されており、9990 〜 9999 のメッセージは 99 ディレクトリに保存されており、10000 〜 10099 のメッセージは 00 ディレクトリに保存されているという具合です。  



ストアによるメッセージの消去方法


メッセージは、次の 3 段階の手順でストアから消去されます。

  1. 削除: クライアントが削除するメッセージをマークします。この時点では、クライアントは「削除済み」マークを外せばメッセージをリストアすることができます。

  2. 消去: クライアント、または指定した存続期間決定ポリシーにより、削除マークの付けられたメッセージがメールボックスから消去されます。メッセージの消去が行われると、クライアントがそれをリストアすることはできなくなります。ただし、メッセージはまだディスク上に存在しています (既存の接続を使用して同じメールボックスにアクセスできる 2 番目のクライアントは、まだメッセージを取り出すことができます)。

  3. クリーンアップ: stored ユーティリティにより、1 時間以上前に消去されたメッセージをすべてディスクから消し去ります

メッセージは、expire オプションを設定して消去することもできます。サーバは configutil によって定義された存続期間決定ポリシーに基づいてメッセージを削除します。メッセージは期限が切れたら消去されますが、クリーンアップが実行されるまで物理的には削除されません (「存続期間決定ポリシーを指定するには」を参照)。



ストアへの管理者によるアクセスを指定する


メッセージストアの管理者は、ユーザのメールボックスを表示してモニタしたり、メッセージストアに対するアクセス制御を指定することができます。ストア管理者は、すべてのサービス (POP、IMAP、HTTP、または SMTP) に対するプロキシ認証権限を持っているので、任意のユーザの権限を使用して任意のサービスを認証することができます。これらの権限により、ストア管理者は特定のユーティリティを実行してストアを管理することができます。たとえば、MoveUser を使用して、ストア管理者はあるシステムから別のシステムへユーザアカウントやメールボックスを移動させることができます。

この節では、Messaging Server のメッセージストアに対してストア権限を付与する方法を説明します。

注

ほかのユーザもそのストアに対する管理者権限を持っている可能性があります。たとえば、自分のサイトで Delegated Administration (DA) 製品を使用している場合、トップレベルの DA 管理者は、デフォルトではメールシステムのすべての Messaging Server に対するストア権限を持っています。デフォルトでは DA ドメイン管理者は、自分のドメインに対するストア権限を持っています。DA 管理者に関する詳細については、『iPlanet Messaging Server プロビジョニングガイド』および DA のマニュアルを参照してください。


次の項で説明するタスクを実行することができます。

管理者によるストアへのアクセスは、configutil コマンドを使用するか、コンソールを使用して指定することができます。

コンソールを使用する場合は、以下の手順に従います。

  1. 構成を行う Messaging Server をコンソールから開きます。

  2. 「構成」タブをクリックして、左のペインの「メッセージストア」を選択します。

  3. 右のペインの「管理者」タブをクリックします。


管理者を追加するには

コンソール: コンソールで管理者エントリを追加するには以下の手順に従います。

  1. 「管理者」タブをクリックします。

    このタブでは、既存の管理者 ID が一覧表示されます。

  2. 「管理者 UID」ウィンドウの横にある「追加」ボタンをクリックします。

  3. 追加する管理者のユーザ ID を「管理者 UID」フィールドに入力します。

    ここで入力するユーザ ID は、iPlanet Directory Server に認識されるものでなければなりません。

  4. 「OK」をクリックすると、「管理者」タブに表示されているリストに管理者 ID が追加されます。

  5. 「管理者」タブで「保存」をクリックして、新たに変更した管理者リストを保存します。

コマンドライン: コマンドラインで管理者のエントリを追加する場合は、以下のようになります。

configutil -o store.admins -v "adminlist"

この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。


管理者エントリを変更するには

コンソール: コンソールでメッセージストアの管理者 UID リストにある既存のエントリを変更するには、以下の手順に従います。

  1. 「管理者」タブをクリックします。

  2. 「管理者 UID」ウィンドウの横にある「編集」ボタンをクリックします。

  3. 「管理者 UID」フィールドに変更を入力します。

  4. 「OK」をクリックして変更を送信し、「管理者の編集」ウィンドウを閉じます。

  5. 「管理者」タブで「保存」をクリックして、変更した管理者リストを送信して保存します。

コマンドライン: コマンドラインでメッセージストアの管理者 UID リストにある既存のエントリを変更する場合は、以下のようになります。

configutil -o store.admins -v "adminlist"


管理者エントリを削除するには

コンソール: コンソールを使用してメッセージストアの管理者 UID リストからエントリを削除するには、以下の手順に従います。

  1. 「管理者」タブをクリックします。

  2. 「管理者 UID」リストで項目を選択します。

  3. 「削除」をクリックして項目を削除します。

  4. 「保存」をクリックして、管理者リストに変更を送信して保存します。

コマンドライン: コマンドラインでストア管理者を削除する場合は、以下のように管理者リストを編集することができます。

configutil -o store.admins -v "adminlist"



メッセージストアの制限容量について


この節では、以下の情報について説明します。


ユーザの制限容量

ユーザのメールボックスのサイズ制限を指定することで、メッセージストアのサイズを制限することができます。以下のタイプの制限容量を指定することができます。

  • ディスク制限容量は、各ユーザに割り当てられるディスク容量を制限するものです。ディスク制限容量は、ユーザのメールフォルダの数に関係なくユーザのメッセージの合計サイズに適用されるか、ユーザメッセージの合計数に適用されます。ディスク容量に限りがある場合は、ユーザのディスク制限容量を設定した方がよいでしょう。

  • メッセージ制限容量は、ユーザのメールボックスに保存されるメッセージの数を制限するものです。

制限容量の情報は、LDAP 属性および設定変数として保存されます。制限容量の適用が有効になっている場合、Messaging Server は、メッセージストアにメッセージを挿入する前に制限容量キャッシュと設定ファイルをチェックして、制限容量を超えないようにします。制限容量の通知が有効になっている場合、ユーザがディスク制限容量に到達したら、エラーメッセージが送信されます。また、ユーザが制限容量に近づいたらサーバから警告メッセージを送信することも可能です。

すべてのユーザに対してデフォルトの制限容量を設定することも、個々のユーザに対して制限容量を設定することもできます。ユーザが制限容量を超えているかどうかを判別するために、Messaging Server は、まず個々のユーザに対する制限容量が設定されているかどうかを確認します。個別の制限容量が設定されていない場合、Messaging Server はすべてのユーザに対して設定されているデフォルトの制限容量を確認します。

ユーザのメッセージが制限容量を超えてしまった場合、以下のどちらかの状態になるまで、メッセージは MTA キューに残ったままとなります。

(1) ユーザのメッセージのサイズまたは数が制限容量を超えない状態になったとき。この時点で MTA によってユーザにメッセージが配信されます。(2) 未配信のメッセージが MTA キューに残留している期間が指定された猶予期間を超えてしまったとき。「猶予期間を設定するには」を参照してください。

ディスク容量は、ユーザがメッセージを削除または消去したときや、設定された存続期間決定ポリシーに従ってサーバがメッセージを削除したときに使用可能になります。


ドメインの制限容量とファミリーグループの制限容量

特定のドメインや、ドメイン内のファミリーグループに対して制限容量を設定することもできます。これらの制限容量は強制されるものではありませんが、レポート処理を行う場合に役立ちます。


Telephony Application Server に関する例外

統一されたメッセージング要件をサポートするために、Messaging Server ではメッセージストアによって課された制限容量を無効にする機能を提供しています。これにより、特定のエージェント、つまり Telephony Application Servers (TAS) が受け取ったメッセージが確実に配信されます。TAS によって受け入れられたメッセージは特別な MTA チャネルを通るようにルーティングされ、メッセージは制限容量に関係なくストアに配信されるようになります。TAS チャネルの設定の詳細については、第 8 章「チャネル定義を設定する」を参照してください。



メッセージストアの制限容量を設定する


すべてのユーザについてのデフォルトの制限容量は、iPlanet Console または configutil コマンドを使用して設定することができます。また、個々のユーザ、ファミリーグループ、およびホストドメインについての制限容量も設定することができます。

このマニュアルでは、デフォルトの制限容量の設定方法について説明します。個々のユーザ、ファミリーグループ、およびホストドメインの制限容量の設定に関する詳細については、『Delegated Administrator's User Guide』を参照してください。

この節では、以下のタスクについて説明します。

iPlanet Console を使用する場合は、以下の手順に従います。

  1. iPlanet Console から構成を行う Messaging Server を開きます。

  2. 「構成」タブをクリックして、左のペインの「メッセージストア」を選択します。

  3. 右のペインの「制限容量」タブをクリックします。


デフォルトのユーザ制限容量を指定するには

デフォルトの制限容量は、個別の制限容量がまだ設定されていないユーザに適用されます。個別の制限容量の設定はデフォルトの制限容量よりも優先されます。

コンソール: コンソールでデフォルトの制限容量を指定するには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. デフォルトのユーザディスク制限容量を指定するには、「デフォルトのユーザディスク制限容量」フィールドで次のオプションのどちらかを選択します。

    「無制限」: このオプションは、デフォルトのディスク制限容量を設定しない場合に選択します。

    「Size specification」: このオプションは、デフォルトのユーザディスク制限容量を特定のサイズに制限する場合に選択します。ボタンの横のフィールドに数字を入力し、ドロップダウンリストから「M バイト」または「K バイト」を選択します。

  3. メッセージ数の制限を指定する場合は、「デフォルトのユーザメッセージ制限容量」ボックスに数字を入力します。

  4. 「保存」をクリックします。

コマンドライン: メッセージの合計サイズについてのデフォルトのユーザディスク制限容量を指定する場合は、以下のようになります。

configutil -o store.defaultmailboxquota -v [ -1 | number ]

ここで -1 は制限がないことを示し、number はバイト数を示します。

メッセージの合計数についてのデフォルトのユーザ制限を指定する場合、以下のようになります。

configutil -o store.defaultmessagequota -v [ -1 | number ]

ここで -1 は制限がないことを示し、number はメッセージ数を示します。


制限容量の適用と通知を有効にするには

制限容量の適用と通知は、有効にしたり無効にしたりすることができます。サーバの動作は、表 11-3 に示すように、設定変数の設定方法によって異なります。

表 11-3    制限容量の適用と通知

適用オン

適用オフ

通知オン  

メッセージは指定された猶予期間まで据え置かれます。猶予期間が切れたら拒否されます。メッセージをメールボックスに追加することはできません。

IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドによってエラーメッセージが表示されます。  

メッセージがストアに配信されます。メッセージをメールボックスに追加することができます。

IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドはエラーメッセージを表示しません。  

通知オフ  

メッセージは指定された猶予期間まで据え置かれます。猶予期間が切れたら拒否されます。メッセージをメールボックスに追加することはできません。

IMAP SELECT コマンド、配信コマンド、および SMTP メール送信機能はエラーメッセージを表示しません。

IMAP APPEND コマンドによってエラーメッセージが表示されます。  

メッセージがストアに配信されます。メッセージをメールボックスに追加することができます。

IMAP SELECT、IMAP APPEND、SMTP メール送信機能、および配信コマンドはエラーメッセージを表示しません。  


制限容量の適用を有効にする

コンソール: コンソールで制限容量の適用を有効にするには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. 「容量制限実施の有効化」ボックスにチェックマークを付けます。

    このボックスでオンとオフの切り替えを行います。制限容量の適用を無効にする場合はこのボックスのチェックマークを外します。

  3. 「保存」をクリックします。

コマンドライン: コマンドラインで制限容量の適用を有効にする場合は、以下のようになります。

configutil -o store.quotaenforcement -v [ yes | no]

ここで no を指定したら制限容量は適用されません。


制限容量の通知を有効にする

コンソール: コンソールで制限容量の通知を有効にするには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. 「容量制限有効化の通知」ボックスにチェックマークを付けます。

    このボックスでオンとオフの切り替えを行います。制限容量の適用を無効にする場合はこのボックスのチェックマークを外します。

  3. 制限容量の警告メッセージを定義します。

    「制限容量の警告メッセージの定義」を参照してください。

  4. 「保存」をクリックします。

コマンドライン: コマンドラインで制限容量の通知を有効にする場合は、以下のようになります。

configutil -o store.quotanotification -v [ yes | no ]
configutil -o store.quotaexceededmsg -v message

message に何も設定されなかった場合、ユーザには制限容量の警告メッセージは送信さ れません。


制限容量の警告メッセージの定義

ディスク制限容量を超えたユーザに送信するメッセージは、以下の手順で定義することができます。メッセージはユーザのメールボックスに送られます。

コンソール: コンソールで制限容量の警告メッセージを定義するには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. ドロップダウンリストから使用言語を選択します。

  3. ドロップダウンリストの下にあるメッセージテキストのフィールドに、送信するメッセージ内容を入力します。

  4. 「保存」をクリックします。

コマンドライン: コマンドラインで制限容量の警告メッセージを定義する場合は、以下のようになります。

configutil -o store.quotaexceededmsg -v message

メッセージは RFC 822 形式でなければなりません。

警告メッセージの送信頻度を定義する場合は、以下のようになります。

configutil -o store.quotaexceedmsginterval -v number

この number は日数を示しています。たとえば、3 が入っていれば 3 日ごとにメッセージが送信されます。


制限容量のしきい値の指定

制限容量のしきい値を指定すれば、IMAP ユーザがディスク制限容量に到達する前に、警告メッセージを送ることができます。ユーザのディスク使用量が指定したしきい値を超えたら、サーバからユーザに警告メッセージが送信されます。

クライアントが IMAP ALERT 機能をサポートしている IMAP ユーザの場合は、ユーザがメールボックスを選択するたびに画面にメッセージが表示されます (メッセージは IMAP ログにも書き込まれます)。

コンソール: コンソールで制限容量のしきい値を指定するには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. 「制限容量の警告のしきい値」フィールドに警告しきい値の数字を入力します。

    この数字は許可された制限容量のパーセンテージを表しています。たとえば 90% を選択した場合、ユーザは許可された制限容量の 90% を使用したところで警告を受けることになります。デフォルトは 90% です。この機能をオフにするには 100% と入力します。

  3. 「保存」をクリックします。

コマンドライン: コマンドラインで制限容量のしきい値を指定する場合は、以下のようになります。

configutil -o store.quotawarn -v number

この number は許可された制限容量のパーセンテージを示しています。


猶予期間を設定するには

猶予期間は、メッセージを差出人にバウンスするまでメールボックスが制限容量 (ディスク容量やメッセージの数) を超えた状態でいられる期間を指定するものです。MTA がメッセージを受け取っても、メッセージは MTA キューに残り、次のいずれかの状況が発生するまでメッセージストアには配信されません。

  • メールボックスが制限容量を超えない状態になったとき。この時点でメールボックスにメッセージが配信されます。

  • ユーザが指定された猶予期間を過ぎても制限容量を上回ったままでいるとき。この時点でサーバが、キュー内に含まれているすべてのメッセージをバウンスします。

  • メッセージがメッセージキューの最長時間より長くキューに残ったままであるとき。

たとえば、猶予期間が 2 日間に設定されているときに 1 日分の制限容量を超えた場合、新しいメッセージは引き続き受信され、キュー内に保持され、配信試行は続行します。2 日目を過ぎると、メッセージはバウンスされます。
注

猶予期間とは、メッセージがキュー内に保持される期間ではなく、キュー内に含まれているすべての受信メッセージがバウンスされるまでに、メールボックスが制限容量を超えた状態でいられる期間です。


コンソール: コンソールで、メッセージがキューに保持される猶予期間を設定するには、以下の手順に従います。

  1. 「制限容量」タブをクリックします。

  2. 「制限容量超過時の猶予期間」フィールドに数字を入力します。

  3. ドロップダウンリストで「Day(s)」または「Hour(s)」を指定します。

  4. 「保存」をクリックします。

コマンドライン: コマンドラインで制限容量の猶予期間を指定する場合は、以下のようになります。

configutil -o store.quotagraceperiod -v number

この number は時間数を示しています。



存続期間決定ポリシーを指定するには


存続期間決定ポリシーは、サーバによるディスク使用を制御するためのもう 1 つの手段です。1 つまたは複数のメールボックスにメッセージが保存される期間を制御することができます。ディスク容量が制限されている場合、存続期間決定ポリシーを設定してストアからメッセージを削除するとよいでしょう。ただし存続期間決定ポリシーを設定する場合には、このポリシーについてユーザを教育する必要があります。サーバがこのポリシーに基づいてストアからメッセージを削除する場合、削除の前に警告メッセージを送信しないからです。

存続期間決定の規則は、以下の条件に基づいて作成できます。

  • メールボックス内のメッセージ件数

  • メールボックスの合計サイズ

  • メールボックス内にメッセージが残っている日数

  • 指定されたサイズを超えるメッセージがメールボックスに残っている日数

1 つのメールボックスに対して複数の規則を指定する場合、有効期限に関する規則はすべて適用されますが、もっとも制約度の高い規則が優先されます。たとえば、2 つの規則が 1 つのメールボックスに適用される場合を考えてみます。一方の規則では 1000 件のメッセージが許可されており、もう一方の規則では 500 件のメッセージが許可されています。有効期限が切れた場合、サーバは 500 件のメッセージが残った状態になるまでメールボックスからメッセージを削除します。別の例では、一方の規則では 3 日間で 100,000 バイトのメッセージが許可されており、もう一方の規則では 12 日間で 1000 バイトのメッセージが許可されています。この場合、規則が結合された結果、3 日間で 100,000 バイトのメッセージサイズが許可されることになります。つまり、サーバは、メールボックスに 4 日以上存在する 100,000 バイトを超えるメッセージを削除するのです。特定のメールボックスまたはメールボックスのセットだけに特別な規則を適用させたい場合は、Exclusive パラメータを使用してください。

コンソール: コンソールを使用して新しい規則を作成するには、以下の手順に従います。

  1. iPlanet Console から構成を行う Messaging Server を開きます。

  2. 「構成」タブをクリックして、左のペインの「メッセージストア」を選択します。

  3. 右のペインの「存続期間」タブをクリックします。

  4. 「追加」をクリックして「ルールの通知」ウィンドウに進みます。

  5. 新しい規則の名前を入力します。

  6. この規則が適用されるターゲットフォルダを指定します。

    パス名、ファイル名、または文字列の一部分が入力できます。以下に示す IMAP ワイルドカードも使用できます。

    * - あらゆる文字列に一致します。
    % - スラッシュ (/) 以外のあらゆる文字列に一致します。

    新しい規則は、指定したパターンに一致するフォルダのみに適用されます。

  7. この規則がターゲットフォルダに適用される唯一の規則である場合、「Exclusive」選択ボックスをクリックします。

  8. フォルダサイズに基づいて規則を作成する場合は、以下を実行します。

    • 「メッセージ件数」フィールドには、もっとも古いメッセージが削除されるまでフォルダ内に保持されるメッセージの最大件数を指定します。

    • 「フォルダサイズ」フィールドには、フォルダサイズを数字で指定します。また、それに続くドロップダウンリストから「M バイト」または「K バイト」を選択します。

    指定したフォルダサイズを超えた場合、このサイズ内に収まるまでサーバはもっとも古いメッセージから順に削除していきます。

  9. メッセージの存続期間に基づいて規則を作成する場合は、「日数」フィールドにメッセージをフォルダに残すべき日数を数字で指定します。

  10. メッセージサイズに基づいて規則を作成する場合は、以下を実行します。

    • 「メッセージサイズの制限」フィールドには、フォルダ内で許可されたメッセージの最大サイズを示す数字を入力します。また、それに続くドロップダウンリストから「M バイト」または「K バイト」を選択します。

    • 「猶予期間」フィールドには、指定されたサイズを超えたメッセージをフォルダに残さなければならない日数を示す数字を入力します。

    猶予期間が過ぎたら、サーバが最大サイズを超えたメッセージを削除します。

  11. 「OK」をクリックして新しい規則を「存続期間ルール」リストに追加し、「追加」ウィンドウを閉じます。

  12. 「保存」をクリックして現在の「存続期間ルール」リストを送信し保存します。

コマンドライン: コマンドラインで新しい規則を作成する場合は、以下の各コマンドを使用します。ここで name は、この規則に付けた名前を表しています。ただし、ここではもっとも頻繁に使用する store.expire* オプションのみを説明しています。完全なリストについては、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

この規則が適用されるターゲットフォルダを指定するには

configutil -o store.expirerule.name.folderpattern -v pattern

たとえば、パターン user/* は、すべてのフォルダをターゲットにしています。パターン user/%@siroe.com/* は、ドメイン siroe.com に存在する全ユーザの全フォルダがターゲットです。さらに、パターン user/%/Trash では、すべてのユーザのごみ箱 (Trash) フォルダをターゲットにしています。

この規則をターゲットフォルダに適用される唯一の規則に指定するには、次のように入力します。

configutil -o store.expirerule.name.exclusive -v [ yes | no ]

もっとも古いメッセージが削除されるまでフォルダ内に保持されるメッセージの最大件数を指定するには、次のように入力します。

configutil -o store.expirerule.name.messagecount -v number

フォルダサイズを指定するには、次のように入力します。

configutil -o store.expirerule.name.foldersizebytes -v number

この number は、バイト数で表されたサイズです。

メッセージの存続期間を指定するには、次のように入力します。

configutil -o store.expirerule.name.messagedays -v number

この number は日数を示しています。

メッセージサイズを指定するには、次のように入力します。

configutil -o store.expirerule.name.messagesize -v number

この number は、バイト数で表されたサイズです。

指定されたサイズを超えたメッセージをフォルダに残さなければならない期間を示すには、次のように入力します。

configutil -o store.expirerule.name.messagesizedays -v number

この number は日数を示しています。


有効期限の日時を指定するには

有効期限の日時は次のように指定します。

configutil -o store.expirestart -v time (例 : 23 は 11:00PM)
configutil -o local.store.expire.workday -v day (0 〜 6、0 は日曜)

local.store.expire.workday を -1 または 6 より大きい値に設定すると、有効期限とクリーンアップが無効になります。stored は、毎日 store.expirestart で指定した時間にこの設定変数をチェックします。local.store.expire.workday が設定されていない場合、デフォルトで毎日実行されます。この変数を変更したあとで stored を再起動する必要はありません。



メッセージストアのパーティションを構成する


ユーザメールボックスはデフォルトではすべて、msg-instance/store/partition/ ディレクトリに保存されています。partition ディレクトリは、単一または複数のサブパーティションを格納している論理的なディレクトリです。サブパーティションは、単一または複数の物理ドライブにマッピングされます。起動時には、partition ディレクトリに primary パーティションと呼ばれるサブパーティションが格納されています。

必要に応じて partition ディレクトリにパーティションが追加できます。たとえば、ユーザを体系化するために 1 つのディスクを分割する場合、以下のようになります。

msg-instance/store/partition/mkting/
msg-instance/store/partition/eng/
msg-instance/store/partition/sales/

ディスクストレージに対する要求が高まるに従い、これらのパーティションを異なる物理ディスクドライブにマッピングする必要が生じてくると考えられます。

どのディスクでもメールボックスの数を制限しなければなりません。メールボックスを複数のディスクに分散させることにより、メッセージ配信時間を短縮することができます (ただし、必ずしも SMTP の受け入れ率が変更されるわけではありません)。ディスクごとに割り当てるメールボックスの数は、ディスク容量や各ユーザに割り当てられたディスク容量によって異なります。たとえば、ユーザごとのディスク容量の割り当て量が少ない場合は、ディスクごとに割り当てるメールボックスの数を多くできます。

メッセージストアに複数のディスクを必要とする場合、RAID (Redundant Array of Inexpensive Disks) 技術を使用すれば複数ディスクの管理を容易に行うことができます。RAID 技術によってデータを一連のディスクに分散させることができます。このときディスクは単一の論理ボリュームとして表示されるので、ディスク管理が簡単になります。また、冗長性を得るために RAID 技術を使用することもできます。つまり、障害復旧用にストアを複製する目的で使用することができるわけです。

注

ディスクアクセスを向上させるには、メッセージストアとメッセージキューを別のディスクに配置しておく必要があります。



パーティションを追加するには

パーティションを追加する場合、ディスク上でパーティションが保存されている場所の絶対的な物理パスと、パーティションニックネームと呼ばれる論理名を指定します。

パーティションニックネームにより、物理パスに関係なくユーザを論理的なパーティション名にマッピングさせることができます。ユーザアカウントの設定時やユーザのメッセージストアを指定するときに、パーティションニックネームを使用できます。名前の入力に使用するのは英数字で、アルファベットは小文字を使用してください。

パーティションを作成および管理するには、サーバの実行に使用するユーザ ID が、物理パスで指定した場所への書き込み権限を持っていなければなりません。

注

パーティションを追加したら、構成情報を更新するためにサーバをいったん停止してから再起動する必要があります。


コンソール: コンソールを使用してストアにパーティションを追加するには、以下の手順に従います。

  1. iPlanet Console から構成を行う Messaging Server を開きます。

  2. 「構成」タブをクリックして、左のペインの「メッセージストア」を選択します。

  3. 右のペインの「パーティション」タブをクリックします。

  4. 「追加」ボタンをクリックします。

  5. パーティションニックネームを入力します。

    これは指定したパーティションの論理名です。

  6. パーティションのパスを入力します。

    これは指定したパーティションの絶対パス名です。

  7. これをデフォルトのパーティションに指定するには、「デフォルトのパーティションにする」というラベルの付いた選択ボックスをクリックします。

  8. 「OK」をクリックしてこのパーティション構成エントリを送信し、ウィンドウを閉じます。

  9. 「保存」をクリックして現在のパーティションリストを送信し保存します。

コマンドライン: コマンドラインでストアにパーティションを追加する場合は、以下のようになります。

configutil -o store.partition.nickname.path -v path

ここで、nickname はパーティションの論理名、path はパーティションが保存されている場所の絶対パス名を示しています。

デフォルトのプライマリパーティションのパスは次のように指定します。

configutil -o store.partition.primary.path -v path


メールボックスを別のディスクパーティションに移動するには

特に設定を変更しないかぎり、メールボックスは primary パーティション内に作成されます。このパーティションの容量が一杯になると、メッセージを保存することができなくなります。この問題には、次のような対応策があります。

  • ユーザのメールボックスのサイズを小さくする

  • 容量管理ソフトウェアを使用している場合、別のディスクを追加する

  • 別のパーティションを作成し (「パーティションを追加するには」)、メールボックスを新しいパーティションに移動する

可能なかぎり、容量管理ソフトを使用して、システムにディスク容量を追加する方法をお勧めします。これは、この方法がユーザにとってもっとも透過性が高いからです。ただし、次の手順に従って、メールボックスを別のパーティションに移動することもできます。

  1. 移行プロセス中は、ユーザがメールボックスに接続していない状態にしてください。このためには、ユーザに通知を出して、メールボックスの移動作業を行う前にログオフし、作業期間中にログオンしないように指示します。または、ユーザがログオフしたあと、POP、IMAP、および HTTP のサービスを使用できないように mailAllowedServiceAccess 属性を設定します 『iPlanet Messaging Server プロビジョニングガイド』のユーザのプロビジョニングの章を参照してください。
    注

    POP、IMAP、HTTP へのアクセスを許可しないように mailAllowedServiceAccess を設定しても、ユーザがすでにメールボックスに接続している場合に、その接続が切断されることはありません。このため、メールボックスを移動する前に、すべての接続が切断されていることを確認してください。


  2. ユーザのメールボックスを移動するには、次のコマンドを使用します。

    mboxutil -r user/<userid>/INBOX user/<userid>/INBOX <partition_name>

    例 :

    mboxutil -r user/ofanning/INBOX user/ofanning/INBOX secondary

  3. 移動したユーザの LDAP エントリで mailMessageStore 属性を新しいパーティションの名前に設定します。

    例 : mailMessageStore: secondary

  4. ユーザにメッセージストアへの接続が再開されたことを通知します。必要に応じて、POP、IMAP、および HTTP サービスを使用できるように mailAllowedServiceAccess 属性を変更します。



保守および回復手順を実行する

この節では、メッセージストアの保守タスクと回復タスクを実行するのに使用するユーティリティについて説明します。サーバから送信される警告のためのポストマスターメールを常に読む必要があります。また、サーバの実行状況に関する情報を記録したログファイルをモニタする必要もあります。ログファイルに関しては、第 13 章「ログ記録とログ解析」を参照してください。

この節では以下の内容について説明します。


メールボックスを管理するには

この節では、メールボックスの管理およびモニタを行う次のユーティリティについて説明します。mboxutil、hashdir、readership。


mboxutil ユーティリティ

mboxutil コマンドを使用して、メールボックスの一般的な保守タスクを実行します。タスクには以下のものが含まれます。

  • メールボックスの一覧表示

  • メールボックスの作成

  • メールボックスの削除

  • メールボックスの名前変更

  • パーティション間のメールボックスの移動

また、mboxutil コマンドを使用して制限容量に関する情報を表示することもできます。詳細は、「制限容量をモニタするには」を参照してください。

表 11-4 は mboxutil コマンドの一覧です。シンタックスや使用要件の詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


表 11-4    mboxutil のオプション 

オプション

説明

-a  

すべてのユーザの制限容量に関する情報を表示します。  

-c mailbox  

指定したメールボックスを作成します。  

-d mailbox  

指定したメールボックスを削除します。  

-f file  

指定したデータファイルに一覧表示されているメールボックスを作成、削除、またはロックします。  

-g group  

指定したグループの制限容量に関する情報を表示します。  

-k mailbox cmd  

指定したメールボックスをフォルダレベルでロックし、指定したコマンドを実行し、コマンドが完了したらメールボックスのロックを解除します。  

-l  

サーバのすべてのメールボックスを一覧表示します。  

-p pattern  

-l オプションとともに使用した場合、名前がpattern と一致するメールボックスのみが一覧表示されます。IMAP ワイルドカードを使用できます。  

-q domain  

指定したドメインの制限容量に関する情報を一覧表示します。  

-r oldname newname
[partition]  

メールボックスの名前を oldname から newname に変更します。フォルダを別のパーティションに移動するには、partition オプションに新しいパーティションを指定します。

このオプションを使用してユーザ名を変更することができます。たとえば、mboxutil -r user/user1/INBOX user/user2/INBOX では、user1 のすべてのメールとメールボックスが user2 に移動し、新しいメッセージは新しい INBOX に表示されます (user2 がすでに存在している場合、この操作は失敗します)。  

-u user  

メールストアの現在のサイズ、制限容量 (設定されている場合)、現在使用されている制限容量の割合など、ユーザのメールストアのサイズに関する情報を一覧表示します。  

-x  

-l オプションとともに使用すると、メールボックスのパスとアクセス制御が表示されます。  


メールボックスの命名規則
メールボックス名は、次のフォーマットで指定します。user/userid/mailbox。ここで、userid はメールボックスを所有するユーザ、mailbox はメールボックスの名前を表します。ホストドメインでは、userid は uid@domain です。

たとえば次のコマンドでは、ユーザ ID が crowe であるユーザの、INBOX という名前のメールボックスが作成されます。INBOX は、ユーザ crowe に配信されたメール用のデフォルトのメールボックスとなります。

mboxutil -c user/crowe/INBOX

重要 : INBOX という名前は、各ユーザのデフォルトのメールボックス用に確保してある名前です。INBOX は、大文字と小文字が区別されない唯一のフォルダです。ほかのフォルダ名はすべて大文字と小文字が区別されます。


例
全ユーザの全メールボックスを一覧表示するには、次のように入力します。

mboxutil -l

すべてのメールボックスを、パスと ACL の情報とともに一覧表示するには、次のように入力します。

mboxutil -l -x

ユーザ daphne に対し、INBOX というデフォルトのメールボックスを作成するには、次のように入力します。

mboxutil -c user/daphne/INBOX

ユーザ delilah に対し、projx という名前のメールフォルダを削除するには、次のように入力します。

mboxutil -d user/delilah/projx

ユーザ druscilla について、INBOX というデフォルトのメールボックスとすべてのメールフォルダを削除するには

mboxutil -d user/druscilla/INBOX

ユーザ desdemona の memos というメールフォルダの名前を、memos-april という名前に変更するには、次のように入力します。

mboxutil -r user/desdemona/memos user/desdemona/memos-april

ユーザ dulcinea の legal という名前のメールフォルダをロックするには、次のように入力します。

mboxutil -k user/dulcinea/legal cmd

この場合の cmd は、フォルダがロックされている間に実行するコマンドです。

ユーザ dimitria のメールアカウントを新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

この場合、partition には新しいパーティションの名前を指定します。

ユーザ dimitria のメールフォルダ personal を新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/personal user/dimitria/personal partition


hashdir ユーティリティ

メッセージストア内のメールボックスは、高速で検索できるようにハッシュ構造で保存されています。従って、特定のユーザのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティを使用します。

このユーティリティは、特定のアカウントのメッセージストアを含むディレクトリを識別します。また、メッセージストアへの相対パスをレポートします。これは d1/a7/ のようになります。このパスは、ユーザ ID に基づくディレクトリの 1 つ上のディレクトリレベルを基準にしたものです。このユーティリティによってパス情報が標準出力に送られます。

たとえば、ユーザ crowe のメールボックスへの相対パスを検索する場合は次のようになります。

hashdir crowe


readership ユーティリティ

readership ユーティリティは、メールボックスの所有者以外に、何人のユーザが共有 IMAP フォルダ内のメッセージを読んだかを報告するユーティリティです。

IMAP フォルダの所有者は、フォルダ内のメールを読む権限をほかのユーザに与えることができます。ほかのユーザにアクセス権が与えられたフォルダは、共有フォルダと呼ばれます。管理者は readership ユーティリティを使用して、所有者以外に何人のユーザが共有フォルダにアクセスしたかを表示することができます。

このユーティリティは、すべてのメールボックスをスキャンして、各共有フォルダにつき 1 行ずつ、アクセスしたユーザ数とメールボックスの名前を表示させます。ユーザ数とメールボックスの名前の間にはスペースが挿入されます。

アクセスしたユーザとは、過去の指定した日数内に共有フォルダを選択した、個別の認証を受けたユーザのことです。自分の個人用メールボックスを読んだユーザは、数には含められません。個人用メールボックスは、フォルダの所有者以外に購読者がいない場合は、レポートされません。

たとえば次のコマンドでは、最近の 15 日以内に共有の IMAP フォルダを選択したユーザをすべてカウントします。

readership -d 15


制限容量をモニタするには

mboxutil ユーティリティを使用して、制限容量の使用状況やその限界をモニタすることができます。mboxutil ユーティリティは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。制限容量と使用状況に関する数値は、キロバイト (KB) でレポートされます。

たとえば次のコマンドでは、全ユーザの制限容量に関する情報を一覧表示します。

mboxutil -a

次の例では、ユーザ crowe の制限容量に関する情報を一覧表示します。

mboxutil -u crowe

次の例では、ドメイン siroe.com の制限容量に関する情報を一覧表示します。

mboxutil -q siroe.com


ディスク容量をモニタするには

システムがディスク容量をモニタする頻度と、システムが警告を送信する環境条件を指定することができます。ディスク容量のモニタと通知について設定するには、configutil コマンドを使用してディスク容量の警告属性を設定します。表 11-5 を参照してください。


表 11-5    ディスク容量の警告属性

ディスク容量の属性

デフォルト値

alarm.diskavail.msgalarmstatinterval  

3600 秒  

alarm.diskavail.msgalarmthreshold  

10%  

alarm.diskavail.msgalarmwarninginterval  

24 時間  

たとえば、システムがディスク容量を 600 秒毎にモニタするようにするには、次のコマンドを指定します。

configutil -o alarm.diskavail.msgalarmstatinterval -v 600

使用可能なディスク容量が 20% を下回ったら常に警告を受け取るようにするには、次のコマンドを指定します。

configutil -o alarm.diskavail.msgalarmthreshold -v 20

警告属性の設定の詳細については、『iPlanet Messaging Server リファレンスマニュアル』および 「ディスク容量をモニタする」を参照してください。


stored ユーティリティを使用する

stored ユーティリティは、以下の監視タスクと保守タスクをサーバに対して実行します。

  • バックグラウンドと日常のメッセージ処理タスク

  • デッドロックの検出とデッドロックしたデータベーストランザクションのロールバック

  • 起動時の一時ファイルのクリーンアップ

  • 存続期間決定ポリシーの実装

  • サーバの状態、ディスク容量、サービスへの応答時間などの定期的モニタ (「stored」 を参照)

  • 必要に応じて警告を生成

stored ユーティリティは毎日午後 11 時に自動的にクリーンアップと (有効期限による) 失効の操作を行います。また、これ以外の時間にもクリーンアップと失効の操作を行うように選択することもできます。

表 11-6 では stored オプションを一覧表示しています。一般的な使用例についてはこの表に従ってください。シンタックスや使用要件の詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


表 11-6    stored オプション 

オプション

説明

-c  

削除されたメッセージを消去するためにクリーンアップを 1 回実行します。1 回だけ実行し、終了します。-c オプションは 1 回のみの処理で、-1 オプションを指定する必要はありません。  

-d  

デーモンとして実行します。システムチェックを実行し、警告、デッドロック検出、およびデータベース修復をアクティブにします。  

-1  

1 回だけ実行し、終了します。  

-n  

トライアルモードでのみ実行します。メッセージを実際に期限切れにしたり、クリーンアップすることはありません。1 回だけ実行し、終了します。  

-v  

詳細モード出力を行います。  

-v -v  

その他の詳細モード出力を行います。  

有効期限ポリシーをテストするには、次のように入力します。

stored -n

保存期間の終了とクリーンアップを 1 回実行するには、次のように入力します。

stored -l -v

自動的なクリーンアップと失効の操作の時間を変更する場合は、以下のように configutil ユーティリティを使用します。

configutil -o store.expirestart -v 21

場合によっては、stored ユーティリティを再起動する必要があるかもしれません。たとえば、メールボックスリストのデータベースが破損した場合などです。UNIX 上でstored を再起動するには、コマンドラインで以下のコマンドを使用します。

server-root/msg-instance/stop-msg store
server-root/msg-instance/start-msg store

サーバのいずれかのデーモンがクラッシュした場合は、すべてのデーモンを停止させ、stored を含むすべてのデーモンを再起動しなくてはなりません。


メールボックスとメールボックスデータベースの修復

1 つまたは複数のメールボックスが破損した場合、reconstruct ユーティリティを使用してメールボックスまたはメールボックスデータベースを再構築し、すべての矛盾を修復することができます。

reconstruct ユーティリティは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。トランザクションの完了や、完了しなかったトランザクションのロールバックなど、低レベルのデータベースの修復には stored -d を使用します。

表 11-7 では、reconstruct オプションを一覧表示しています。シンタックスや使用要件の詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


表 11-7    reconstruct オプション 

オプション

説明

-f  

reconstruct を強制的に実行して、メールボックスを修復します。  

-m  

メールボックデータベースを修復し、整合性チェックを行います。このオプションにより、スプール領域にあるすべてのメールボックスがチェックされ、必要に応じてメールボックスデータベースのエントリの追加または削除が行われます。このユーティリティは、データベースでエントリの追加または削除が行われると、メッセージが標準出力ファイルに出力されます。  

-n  

メールボックスを修復をせずに、メッセージストアだけをチェックします。メールボックス名が指定されていない場合は、-nオプションを単独で使用することはできません。メールボックス名が指定されていないときは、-n オプションを -r オプションとともに使用する必要があります。-r オプションは -p オプションと組み合わせて使用することもできます。たとえば、以下のコマンドはすべて有効です。

reconstruct -n user/dulcinea/INBOX

reconstruct -n -r

reconstruct -n -r -p primary

reconstruct -n -r user/dulcinea/  

-o  

孤立したアカウントをチェックします。このオプションは、現在の Messaging Server ホスト内で、対応するエントリが LDAP にない INBOX を検索します。たとえば、-o オプションは、所有者が LDAP から削除された、または別のサーバホストに移動された INBOX を検索します。見つかった孤立アカウントのそれぞれに対し、reconstruct ユーティリティは標準出力に次のコマンドを書き込みます。

mboxutil-d user/userid/INBOX  

-o -d filename  

-o オプションで -d filename が指定されている場合、reconstruct は指定したファイルを開き、そのファイルに mboxutil -d コマンドを書き込みます。このファイルをスクリプトファイルにして、孤立したアカウントを削除することができます。  

-p partition  

パーティション名を指定します。フルパス名は使用しないでください。このオプションが指定されていない場合、reconstruct はすべてのパーティションにデフォルト設定されています。  

-q  

制限容量サブシステムの矛盾 (メールボックスの制限容量ルートが正しくない、または制限容量ルートで誤った容量の使用状況がレポートされるなど) を修正します。-q オプションは、ほかのサーバプロセスの実行中に実行できます。  

-r [mailbox]  

指定したメールボックスのパーティション領域を修復し、整合性チェックを実行します。また、-r オプションは、指定したメールボックス内のすべてのサブメールボックスも修復します。-r を指定してメールボックス引数を入力しなかった場合、ユーティリティがユーザパーティションディレクトリ内にあるすべてのメールボックスのスプール領域を修復します。  


メールボックスを再構築するには

メールボックスを再構築するには -r オプションを使用します。このオプションは以下の場合に使用します。

  • メールボックスにアクセスしたら次のどちらかのエラーが返された : 「システム I/O エラー」または「メールボックスのフォーマットが不正です」

  • メールボックスにアクセスしたらサーバがクラッシュした

  • ファイルがスプールディレクトリに追加されたか、スプールディレクトリから削除された

5.0 リリースでは、reconstruct -r は、最初に整合性チェックを実行します。問題が検出されたときのみ整合性および再構築についてレポートされます。従って、このリリースでは reconstruct ユーティリティのパフォーマンスが向上しています。

reconstruct は、次の例で説明するように使用することができます。

ユーザ daphne に属するメールボックスのスプール領域を再構築するには、次のコマンドを使用します。

reconstruct -r user/daphne

メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築するには、次のように入力します。

reconstruct -r

ただし、このオプションは注意して使用してください。メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築する場合、メッセージストアが大規模なため非常に長い時間を要する可能性があるからです (「reconstruct のパフォーマンス」を参照)。これよりも優れた障害復旧に対する手段は、ストア用に複数のディスクを使用することでしょう。ディスクが 1 つダウンしてもストア全体がダウンすることはないからです。ディスクが破損した場合、次のように -p オプションを使用してストアの一部分を再構築するだけですみます。

reconstruct -r -p subpartition

コマンドラインの引数にリストされたメールボックスが primary パーティションに存在する場合のみそれらを再構築するには、次のように入力します。

reconstruct -p primary mbox1 mbox2 mbox3

primary パーティションに存在するすべてのメールボックスを再構築する必要がある場合は、以下のようになります。

reconstruct -r -p primary

整合性チェックを実行せずにフォルダを再構築する場合は、-f オプションを使用します。たとえば、次のコマンドはユーザフォルダ daphne の再構築を実行します。

reconstruct -f -r user/daphne

すべてのメールボックスを修正せずにチェックする場合は、以下のように -n オプションを使用します。

reconstruct -r -n


メールボックスのチェックと修復

高レベルの整合性チェックを行い、メールボックスデータベースを修復するには次のようになります。

reconstruct -m

-m オプションは以下の場合に使用します。

  • 1 つまたは複数のディレクトリがストアスプール領域から削除されたため、メールボックスデータベースのエントリも削除する必要が生じた場合。

  • 1 つまたは複数のディレクトリがストアスプール領域にリストアされたため、メールボックスデータベースのエントリも追加する必要が生じた場合。

  • stored -d オプションによってデータベースの整合性を保つことができない場合。

    stored -d オプションによってデータベースの整合性を保つことができない場合、以下の手順を順番に実行します。

    • すべてのサーバを停止します。

    • server-root/msg-instance/store/mboxlist 内のすべてのファイルを削除します。

    • サーバプロセスを再起動します。

    • reconstruct -m を実行して、スプール領域の内容から新しいメールボックスデータベースを構築します。


孤立したアカウントを削除するには

孤立したアカウント (孤立アカウントとは、対応するエントリが LDAP にないメールボックスのことです) を検索するには、以下のようになります。

reconstruct -o

コマンド出力が以下のように続きます。
  reconstruct: Start checking for orphaned mailboxes
  mboxutil -d user/test/annie/INBOX
  mboxutil -d user/test/oliver/INBOX
  reconstruct: Found 2 orphaned mailbox(es)
  reconstruct: Done checking for orphaned mailboxes

孤立したメールボックスをリストしたファイル (このファイルはスクリプトファイルにして、孤立したアカウントを削除することができます) を作成するには、以下のようになります。ここで、このファイルは orphans.cmd という名前になります。

reconstruct -o -d orphans.cmd

コマンド出力が以下のように続きます。
  reconstruct: Start checking for orphaned mailboxes
  reconstruct: Found 2 orphaned mailbox(es)
  reconstruct: Done checking for orphaned mailboxes


reconstruct のパフォーマンス

reconstruct によって操作を実行するのにかかる時間は、以下に挙げるようないくつかの要素によって異なってきます。

  • 実行される処理と選択したオプションの種類

  • ディスクパフォーマンス

  • reconstruct -m 実行時のフォルダの数

  • reconstruct -r 実行時のメッセージの数

  • メッセージストアの全体サイズ

  • システムが実行するほかの処理とシステムのビジー状態

  • 実行中の POP、IMAP、HTTP、または SMTP アクティビティが存在するかどうか

reconstruct -r オプションにより、最初の整合性チェックが実行されます。このチェックでは、再構築の必要なフォルダの数に応じて reconstruct のパフォーマンスが向上します。

ユーザ数が約 2400、メッセージストアが 85G バイトで、POP、IMAP、または SMTP アクティビティが同時にサーバで実行されている場合を例として考えてみます。

  • reconstruct -m に要した時間は約 1 時間でした。

  • reconstruct -r -f に要した時間は約 18 時間でした。
    注

    reconstruct の操作にかかる時間は、サーバで POP、IMAP、HTTP、または SMTP アクティビティが実行されていない場合、大幅に減少します。




メッセージストアのバックアップとリストアを行う

バックアップとリストアは、もっとも一般的で重要な管理タスクです。メッセージストアにバックアップとリストアのポリシーを実装して、以下のような問題が発生した場合でも、データが失われないようにしておかなければなりません。

  • サーバ間でメールボックスを移動

  • システムのクラッシュ

  • ハードウェア障害

  • メッセージまたはメールボックスを誤って削除した

  • システムの再インストール時またはアップグレード時の問題

  • 天災 (地震、火事、台風など)

また、ユーザを移行する場合にもデータのバックアップが必要です。

Messaging Server では、メッセージストアのバックアップとリストアを行うためのコマンドラインユーティリティを提供しています。また、Messaging Server では Legato Networkerｨ との統合ソリューションも提供しています。

Messaging Server は、単一コピーによるバックアップ手順を提供しています。特定のメッセージを格納するユーザフォルダがいくつあるかにかかわらず、バックアップ時には、メッセージファイルは最初に見つかったメッセージファイルを使用して 1 度バックアップされるだけです。2 番目のメッセージコピーは、最初のメッセージファイル名へのリンクとしてバックアップされます。さらに以下同様に続きます。backup ユーティリティは、メッセージファイルのデバイスや inode をインデックスとして使用して、すべてのメッセージのハッシュテーブルを管理します。ただし、この方法を採用する場合はデータのリストア時に注意が必要です。詳細は、「部分リストアに関する考察」を参照してください。

この節には、以下の項があります。


バックアップポリシーの作成

バックアップポリシーは以下のようないくつかの要素に依存しています。


ビジネス負荷のピーク

システムのバックアップのスケジュールを設定する場合は、ビジネス負荷のピークを考慮に入れる必要があります。たとえば、バックアップは 2:00 a.m など早朝 (深夜) の時間帯にスケジュール設定するのが最善であると考えられます。


フルバックアップと増分バックアップ

増分バックアップとは、ストアをスキャンして変更データを見つけ、変更分だけをバックアップする方法です。フルバックアップとは、メッセージストア全体をバックアップすることです。システムが増分バックアップに対してどのくらいの頻度でフルバックアップを実行するのかを決定する必要があります。増分バックアップは、日常の保守手順の中で実行する必要があるはずです。フルバックアップは、データを移動または移行する必要のある場合に適しています。


同時バックアップと順次バックアップ

ユーザのデータが複数のディスクに保存されている場合、必要に応じて複数のユーザグループを同時にバックアップすることができます。システムリソースによっては、同時バックアップによってバックアップ手順全体の処理速度を向上させることができます。ただし、たとえばサーバのパフォーマンスに影響を与えたくないような場合、順次バックアップを実行することもあります。同時バックアップを行うか順次バックアップを行うかは、システム負荷、ハードウェア構成、使用可能なテープドライブの数など、多くの要素によって決まります。


バックアップグループを作成するには

ユーザをグループ化することで、バックアップ管理を効率的に行うことができます。たとえば、各グループに別々のバックアップセッションを指定することができます。また、複数のグループを同時にバックアップすることもできます。

ユーザメッセージがユーザの名前順に保存されている場合は、A で始まる名前のユーザが 1 つのバックアップグループとなり、B で始まる名前のユーザは別のバックアップグループになります。

メッセージストアの論理ビューは以下のようになります。



ユーザをグループにカタログ化することで、バックアップ管理を効率的に行うことができます。たとえば、各グループに別々のバックアップセッションを指定することができます。また、複数のグループを同時にバックアップすることもできます。バックアップグループの作成の詳細については、「バックアップグループを作成するには」を参照してください。

バックアップグループを作成する場合、グループの定義を保存する設定ファイルを作成する必要があります。このファイルは backup-groups.conf という名前が付けられ、次のディレクトリに保存する必要があります。

server_root/msg-instance/config/backup-groups.conf

このファイルのフォーマットは次のとおりです。
groups=definitions
groups=definitions
.
.
.

たとえば、ユーザ ID の最初の文字でユーザをグループ化する場合、以下の定義を使用します。
groupA=a*
groupB=b*
groupC=c*

バックアップオブジェクトは、以下のようにメッセージストアの論理構造を使用して命名されます。

/server/group/user/mailbox

この server はメッセージストアのインスタンス名で、 たとえば、以下のようになります。

siroe

Messaging Server には backup-groups 設定ファイルを作成しなくても使用することができる、事前定義のバックアップグループが含まれています。これは ALL という名前のグループで、ここにはすべてのユーザが含まれています。


Messaging Server のバックアップとリストアのユーティリティ

データのバックアップとリストアのために、Messaging Server では imsbackup および imsrestore ユーティリティが提供されています。

imsbackup および imsrestore ユーティリティは総合的なバックアップ機能を提供するものではないので注意してください。これらのユーティリティは、Legato Networker のような汎用目的ツールに見られる高度な機能は備えていません。たとえば、このユーティリティでは、テープのオートチェンジャーに対して非常に限定されたサポートが行われているだけです。複数の同時実行デバイスに単一のストアを書き込むことはできないのです。総合的なバックアップは、Legato Networker などの一般化ツールのプラグインを使用して達成することができます。Legato Networker の使用に関する詳細は、「Legato Networker を使用するには」を参照してください。


imsbackup ユーティリティ

imsbackup ユーティリティを使用すると、選択したメッセージストアの内容を、シリアルデバイス (磁気テープ、UNIX パイプ、通常のファイルなど) に書き込むことができます。バックアップの全体または一部は、あとから imsrestore ユーティリティを使って回復できます。imsbackup の出力は、imsrestore に受け渡すことができます。

バックアップを実行するには、以下の例に示すように imsbackup コマンドを発行します。このコマンドは、user1 を backupfile にバックアップします。

imsbackup -f backupfile /mystore/ALL/user1

このコマンドはデフォルトのブロック係数である 20 を使用します。imsbackup コマンドの完全なシンタックスに関する説明は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


imsrestore ユーティリティ

バックアップデバイスからメッセージをリストアするには、imsrestore コマンドを使用してください。たとえば、次のコマンドは backupfile から user1 のメッセージをリストアします。

imsrestore -f backupfile /mystore/ALL/user1

imsbackup コマンドの完全なシンタックスに関する説明は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


部分リストアに関する考察

この単一コピーによるバックアップ手順では、メッセージのリストアの際に以下の点に注意する必要があります。

  • フルリストア: フルリストアでは、リンクの付いたメッセージは、依然としてリンク先のメッセージファイルと同じ inode をポイントしています。

  • 部分バックアップ/リストア: 部分バックアップおよび部分リストアでは、メッセージストアの単一コピーの特性は保持されないことがあります。

以下のように、3 人のユーザ A、B、C に属する 3 つのメッセージが存在すると仮定してみてください。

A/INBOX/1
B/INBOX/1
C/INBOX/1

例 1 : 最初の例では、システムは部分バックアップとフルリストアを以下のように実行します。

  1. ユーザ B および C をバックアップします。

  2. ユーザ B および C を削除します。

  3. 手順 1 のバックアップデータをリストアします。

この例では、B/INBOX/1 および C/INBOX/1 には新しい inode 番号が割り当てられ、メッセージデータはディスク上の新しい場所に書き込まれます。メッセージは 1 件だけリストアされます。2 件目のメッセージは最初のメッセージへのハードリンクです。

例 2 : この例では、システムはフルバックアップと部分リストアを以下のように実行します。

  1. フルバックアップを実行します。

  2. ユーザ A を削除します。

  3. ユーザ A をリストアします。

A/INBOX/1 には新しい inode 番号が割り当てられます。

例 3 : この例では、複数回の部分リストアが必要となる可能性があります。

  1. フルバックアップを実行します。

    B/INBOX/1 と C/INBOX/1 は A/INBOX/1 へのリンクとしてバックアップされます。

  2. ユーザ A と B を削除します。

  3. ユーザ B をリストアします。

    リストアユーティリティが、最初に A/INBOX をリストアするよう管理者に要求します。

  4. ユーザ A と B をリストアします。

  5. ユーザ A を削除します (省略可能)。
    注

    すべてのメッセージを部分リストアでリストアできるようにするためには、-i オプションを付けて imsbackup コマンドを実行します。-i オプションは必要に応じて各メッセージを複数回バックアップします。このオプションは POP 環境においてもっとも有効です。



Legato Networker を使用するには

Messaging Server は、Legato Networker のようなサードパーティ製のバックアップツールへのインタフェースを提供する、バックアップ API を装備しています。物理的なメッセージストア構造とデータ形式は、バックアップ API の中にカプセル化されています。バックアップ API はメッセージストアと直接対話します。さらに、バックアップサービスに対してメッセージストアの論理ビューを提示します。バックアップサービスは、メッセージストアの概念表現を使用して、バックアップオブジェクトの保存や検索を行います。

Messaging Server は Application Specific Module (ASM) を提供しています。これは、Legato Networker の save および recover コマンドによって呼び出され、メッセージストアのデータのバックアップとリストアを行います。さらに ASM は、Messaging Server の imsbackup および imsrestore ユーティリティを呼び出します。

注

この節では、Messaging Server のメッセージストアで Legato Networker を使用する方法についての情報を提供します。Legato Networker インタフェースについて理解するには、Legato のマニュアルを参照してください。



Legato Networker を使用したデータのバックアップ

Legato Networker を使用して Messaging Server メッセージストアのバックアップを行うには、Legato インタフェースを呼び出す前に以下の準備手順を実行する必要があります。

  1. /usr/lib/nsr/imsasm から server_root/msg-instance/bin/imsasm へのシンボリックリンクを作成します。

  2. Sun または Legato から nsrfile バイナリのコピーを取得して、それを以下のディレクトリにコピーします。

    /usr/lib/nsr/nsrfile

  3. ユーザをグループ別にバックアップする必要がある場合は、以下の手順を実行します。

    1. 「バックアップグループを作成するには」 の説明に従って、バックアップグループファイルを作成します。

    2. 設定を確認するために、mkbackupdir.sh. を実行します。

      server_root/backup 内のディレクトリ構造を確認します。このディレクトリ構造は図 11-2 に示されているようなものでなければなりません。

    backup-groups.conf ファイルを指定していないと、バックアッププロセスはすべてのユーザに対して、デフォルトのバックアップグループ ALL を使用します。

  4. ディレクトリ /nsr/res/ で、保存グループ用に res ファイルを作成して、バックアップの前に mkbackupdir.sh スクリプトを呼び出します。図 11-3 に示した例を参照してください。
    注

    Legato Networker では、保存設定の名前には最高 64 文字まで使用できます。デフォルトでは、mkbackupdir.sh は server_root/backup ディレクトリにストアイメージを作成します。このディレクトリ名とメールボックスの論理名を合わせたもの (たとえば siroe/groupA/fred) が 64 文字を超えた場合、mkbackupdir.sh -p を実行する必要があります。このため、mkbackupdir.sh の -p オプションの短いパス名を使用する必要があります。たとえば、次のコマンドでは /backup ディレクトリの下にバックアップイメージが作成されます。

    mkbackupdir.sh -p /backup

    重要 : バックアップディレクトリは、メッセージストアの所有者による書き込みが可能でなければなりません (例 : mailsrv)。


図 11-2 には、バックアップグループのディレクトリ構造のサンプルが示されています。

図 11-2    バックアップグループのディレクトリ構造
siroe-groupA-a1
            -a2
     -groupB-b1
            -b2
     -groupC-c1
            -c2

図 11-3 に、res ファイルのサンプルとして、/nsr/res ディレクトリにある IMS.res という名前のファイルを示します。

図 11-3    サンプルの res ファイル
type: savepnpc
precmd: "echo mkbackupdir started",
   "/usr/siroe/server5/msg-siroe/bin/mkbackupdir.sh -p /backup"
pstcmd: "echo imsbackup Completed";
timeout: "12:00 pm";

ここまでの準備が完了したら、以下の手順に従って Legato Networker インタフェースを実行します。

  1. 必要に応じて Messaging Server 保存グループを作成します。

    1. nwadmin を実行します。

    2. Customize | Group | Create の順に選択します。

  2. バックアップコマンドとして savepnpc を使用して、バックアップクライアントを作成します。

    1. mkbackupdir によって作成されるディレクトリに対して保存設定を行います。

      単一セッションのバックアップには、server_root/backup を使用します。

      同時バックアップには、server_root/backup/server/group を使用します。

      「バックアップグループを作成するには」の定義に従って group があらかじめ作成されていることを確認します。

      また、同時実行するバックアップセッションの数も設定する必要があります。

      「例 : Networker でバックアップクライアントを作成する」を参照してください。

  3. Group Control | Start の順に選択して、バックアップ設定のテストを行います。

例 : Networker でバックアップクライアントを作成する:  : Networker でバックアップクライアントを作成するには、 nwadmin から、Client | Client Setup | Create の順に選択します。
Name: siroe
Group: IMS
Savesets:/backup/siroe/groupA
   /backup/siroe/groupB
   /backup/gotmail/groupC
         .
         .
Backup Command: savepnpc
Parallelism: 4


Legato Networker を使用したデータのリストア

データの回復は、Legato Networker の nwrecover インタフェースまたは recover コマンドラインユーティリティを使用して実行できます。以下の例では、ユーザ a1 の INBOX を回復しています。

recover -a -f -s siroe /backup/siroe/groupA/a1/INBOX

次の例では、メッセージストア全体を回復しています。

recover -a -f -s siroe /backup/siroe


サードパーティのバックアップソフトウェア (Legato 以外) を使用するには

iPlanet Messaging Server では、コマンドライン imsbackup と Solstice Backup (Legato Networker) の 2 つのメッセージストアバックアップソリューションを提供しています。メッセージストア全体をバックアップするために imbackup を単体で実行する大規模なメッセージストアの場合、非常に長い時間がかかってしまう可能性があります。Legato ソリューションでは、複数のバックアップデバイスでのバックアップセッションの同時実行をサポートしています。バックアップを同時実行することにより、バックアップ時間を大幅に短縮できます (毎時 25G バイトのデータバックアップが達成できます)。

その他のサードパーティのバックアップソフトウェア (Netbackup など) を使用する場合は、以下の方法によってバックアップソフトウェアを iPlanet Messaging Server に統合します。

  1. ユーザをグループに分割し (「バックアップグループを作成するには」 を参照)、server_root/msg-<instance>/config/ ディレクトリの下に backup-groups.conf ファイルを作成します。

    たとえば、ユーザを UID によってグループ化するには、/usr/iplanet/server5/msg-siroe/config/backup-groups.conf で次の定義を使用します。

    groupA=a*
    groupB=b*
    groupC=c*
    . . .
    注

    このバックアップソリューションは追加のディスク容量を必要とします。すべてのグループを同時にバックアップするには、メッセージストアの 2 倍のサイズのディスク容量が必要になります。ディスク容量に余裕のない場合は、ユーザを小規模なグループに分け、グループセット単位でバックアップしていきます たとえば、group1 〜 group5、group6 〜 group10 というようになります。バックアップ後、グループデータファイルを削除します。


  2. imsbackup を実行して、準備領域にあるファイルに各グループをバックアップします。

    このためのコマンドは、imsbackup -f <device> /<instance>/<group> です。

    複数の imsbackup プロセスを同時に実行することができます。たとえば、以下のようになります。

    # imsbackup -f- /siroe/groupA > /bkdata/groupA &
    # imsbackup -f- /siroe/groupB > /bkdata/groupB &

    . . .

    imsbackup は大きなサイズのファイルをサポートしていないため、バックアップデータが 2G バイトを超える場合は -f- オプションを使用して、データを stdout に書き込み、ファイルへ出力を受け渡します。

  3. サードパーティ製のバックアップソフトウェアを使用して、準備領域 (上の例では /bkdata) のグループデータファイルをバックアップします。

  4. ユーザをリストアするには、ユーザのグループファイル名を確認し、そのファイルをテープからリストアし、imsrestore を使用してデータファイルからユーザをリストアします。

    imsrestore は大きなサイズのファイルをサポートしていません。データファイルが 2G バイトを超える場合は、 次のコマンドを使用します。

    # cat /bkdata/groupA | imsrestore -f- /siroe/groupA/andy



メッセージストアをトラブルシューティングする

この節では、障害に備えてメッセージストアを保守する際のガイドラインについて説明します。また、メッセージストアが壊れたり、予期せずシャットダウンされた場合に使用する、その他のメッセージストアの回復手順についても説明します。メッセージストア回復の追加手順に関する節は、「メールボックスとメールボックスデータベースの修復」の続きになります。

この節を読む前に、この章と、『iPlanet Messaging Server リファレンスマニュアル』のコマンドラインユーティリティおよび configutil の章を再度お読みになることを強くお勧めします。この節では、以下の項目について説明します。


標準的なメッセージストアのモニタ手順

ここでは、メッセージストアのモニタの標準的な手順の概要を説明します。ここで説明する手順は、全般的な状況のチェック、テスト、および標準的な保守を行う場合に役立つものです。

その他の情報については、「メッセージストアをモニタする」を参照してください。


ハードウェアの容量のチェック

メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。

ディスク容量の不足は、メールサーバの問題と障害を発生させる、もっとも一般的な原因です。メッセージストアに書き込む領域がないと、メールサーバでエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。

ディスク容量のモニタの詳細は、「ディスク容量をモニタするには」および 「メッセージストアをモニタする」を参照してください。


ログファイルのチェック

ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。 ログファイルは、Console を使って確認するか、server-root/msg-instance/log/ ディレクトリ内で確認します。ログファイルは定期的にモニタする必要があります。

ログ記録はサーバパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバのバックアップポリシーなどを考慮する必要があります。サーバのログポリシーの定義の詳細は、第 13 章「ログ記録とログ解析」を参照してください。


stored プロセスのチェック

stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。

  • stored プロセスが実行中かどうかをチェックします。pid ファイルは、stored (server-root/msg-instance/config/store.pid) によって作成および更新されます。

  • stored プロセスによって以下の機能のいずれかが試行されたとき、常に以下のファイル (server-root/msg-instance/config/ ディレクトリ内) のタイムスタンプが更新されることを確認します。

    表 11-8    stored 操作

    stored 操作

    機能

    stored.ckp  

    データベースのチェックポイントが開始されたときに押される。約 1 分ごとにスタンプが付けられる  

    stored.lcu  

    データベースログのクリーンアップごとに押される。約 5 分ごとにタイムスタンプが付けられる  

    stored.per  

    ユーザ単位のデータベース書き込み時に押される。タイムスタンプは 1 時間ごとに付けられる  

  • server-root/msg-instance/store/mailboxlist 内に作成されたログファイルをチェックします。

  • デフォルトのログファイル server-root/msg-instance/log/default/default 内の stored メッセージをチェックします。

stored プロセスの詳細は、「stored ユーティリティを使用する」および、『iPlanet Messaging Server リファレンスマニュアル』の Messaging Server コマンドラインユーティリティの章の stored ユーティリティを参照してください。

stored 機能のモニタの詳細は、「メッセージストアをモニタする」を参照してください。


データベースログファイルをチェックする

データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (server-root/msg-instance/store/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。


ユーザフォルダのチェック

ユーザフォルダをチェックする場合は、以下のコマンドを実行します。reconstruct -r -n (recursive nofix)。これにより、ユーザフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細は、「メールボックスとメールボックスデータベースの修復」を参照してください。


コアファイルのチェック

コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。


一般的な問題と解決策

この節では、以下のようなメッセージストアの一般的な問題と解決策の一覧を示します。


ユーザメールボックスディレクトリに関する問題

ユーザメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザに限られていて、システム全体に対する損傷がないときです。ユーザメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、以下のガイドラインを参考にしてください。

  1. ログファイル、エラーメッセージ、またはユーザが見た異常な動作を確認します。

  2. デバッグ情報と履歴を保存しておくには、server-root/msg-instance/store/mboxlist/ ユーザディレクトリ全体を、メッセージストアの外側の別の場所にコピーします。

  3. 問題が発生している可能性のあるユーザフォルダを見つけるには、reconstruct -r -n コマンドを実行する必要があります。reconstruct を使用しても問題のあるフォルダが見つからない場合は、該当のフォルダが folder.db 内にない可能性があります。

    reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細は、「hashdir ユーティリティ」および、『iPlanet Messaging Server リファレンスマニュアル』の Messaging Server コマンドラインユーティリティの章の hashdir ユーティリティを参照してください。

  4. ファイルが見つかったら、ファイルを調べ、権限をチェックし、適切なファイルのサイズを確認します。

  5. reconstruct -r (-n オプションは付けない) を使用して、メールボックスを再構築します。

  6. reconstruct で問題が検出されない場合は、reconstruct -r -f コマンドを使用して、メールフォルダを強制的に再構築することができます。

  7. フォルダが mboxlist ディレクトリ (server-root/msg-instance/store/mboxlist) 内にはなく、partition ディレクトリ (server-root/msg-instance/store/partition) にある場合は、全体的な矛盾がある可能性があります。この場合は、reconstruct -m コマンドを実行する必要があります。

  8. 上記の手順が機能しない場合は、store.idx ファイルを削除してから、再度 reconstruct コマンドを実行してください。

    警告

    問題のあるファイルが reconstruct では見つからないファイルであることがわかっている場合は、store.idx ファイルだけを削除してください。


  9. 原因が問題を起こすメッセージに限られている場合は、メッセージファイルをメッセージストアの外側の別の場所にコピーしてから、mailbox/ ディレクトリ上で reconstruct -r コマンドを実行する必要があります。

  10. フォルダがディスク (server-root/msg-instance/store/mboxlist/partition/ ディレクトリ) 上にあっても、明らかにデータベース (server-root/msg-instance/store/mboxlist/ ディレクトリ) 内にはないことがわかった場合は、reconstruct -m コマンドを実行してメッセージストアの整合性をチェックします。

reconstruct コマンドの詳細は、「メールボックスとメールボックスデータベースの修復」を参照してください。


ストアの全体に関する問題

メッセージストアの障害がすべてのユーザに影響する問題やシステムの全体的な損傷の結果によるものであるとわかった場合は、以下のガイドラインに従ってシステムを回復することができます。

  1. メッセージストアプロセスを停止します。

    1. メッセージストアプロセスが停止したことを確認したら、メッセージストアプロセスを再起動します。

    2. stored プロセスを実行してデータベースを回復します。

    たいていの場合、データベースの障害は自動的に回復されます。この処理は、stored が起動すると、それによって、キャッシュファイルとデータベースファイルに対してデータベースのログファイルを解析するデータベース回復が開始されるために発生します。データベース回復は、データベースを整合性のある状態に置こうとします。

  2. stored プロセスコマンドでメッセージストアを起動しようとしているときに、msg-start コマンドが突然終了した場合は、stored が失敗したか、ストアを回復しようとしているかのいずれかです。

    stored がメッセージストアを起動しようとしているときにこのプロセスが異常終了した場合は、データベースをリストアするために stored プロセスが大きなログファイルを確認している可能性があります。

    1. server-root/msg-instance/log/default/ ディレクトリをチェックして、stored が解析していた情報を確認します。

    2. また、設定ファイルと pidfile.store ファイルを確認することもできます。

      pidfile.store ファイルは、pid とともに stored プロセスの状態を示します。pidfile は、回復中は init 状態を示し、stored プロセスがデータベースの修復を終えたときは ready 状態を示します。

  3. pidfile が ready 状態を示すと、データベースはすでに回復済みで、メッセージストアの残りの部分を再起動することができます。

    1. store プロセスを起動し、reconstruct -m コマンドを実行します。reconstruct の詳細は、「メールボックスとメールボックスデータベースの修復」を参照してください。

    2. テストアカウントをモニタし、ログファイルを確認して、ユーザメールボックスディレクトリが有効かどうかを確認します。

      個々のユーザメールボックスが損傷している場合は、reconstruct -r コマンドを実行します。

    3. メッセージストアの損傷の度合いが大きい場合は、停止しているメッセージストアプロセスを使って修復する必要があるかもしれません。「メッセージストアの回復手順」を参照してください。

  4. pidfile が ready 状態に変わらない場合、stored プロセスは、mboxlist ログファイルを確認中であるか、データベースを回復できないかのいずれかです。

    1. server-root/msg-instance/store/mboxlist ディレクトリ内に多数のデータベースログファイルがある場合は、stored プロセスが init 状態を終了できない可能性があります。さらに、データベースの回復に時間がかかっている可能性があります。ログファイルが 20 〜 30 個あると、大半のマシンでは処理に非常に時間がかかります。このような場合は、stored プロセスを停止し、server-root/msg-instance/store/mboxlist ディレクトリ内のファイルを削除してから、スナップショットまたは高速回復プロセスを開始する必要があります。

    2. stored プロセスでメッセージストアを回復できない場合は、ほぼ間違いなくデータベースが壊れています。その場合は、データベースのスナップショットコピーをリストアするか、高速回復を実行する必要があります。詳細は、「メッセージストアの回復手順」を参照してください。

      警告

      プロセスがデータベースにアクセスしているときは、絶対にプロセスを終了しないでください。init 状態のときに stored プロセスを終了すると、データベースを既存の mboxlist データから回復することができなくなります。その結果、データは削除されてしまいます。データベースにアクセスしている別のプロセスを終了すると、データベースは矛盾のある状態のままになり、メッセージストア全体をシャットダウンしてから再起動することが必要になります。



メッセージストアの回復手順

この節では、メッセージストアを再構築または修復するための回復手順について説明します。


高速回復を実行するには

データベースに矛盾があるときは、標準の回復時に reconstruct ユーティリティを使用します (「メールボックスとメールボックスデータベースの修復」を参照)。

データベースが標準的な方法では修復できないほど壊れている場合は、以下の手順に従って、高速回復のために reconstruct ユーティリティを使用することができます。

  1. メッセージストアプロセスを停止します。

  2. すべてのストアプロセスが停止していることを確認します。

  3. server-root/msg-instance/store/mboxlist/* ファイルを、あとで確認するために安全な場所にコピーします。

  4. server-root/msg-instance/store/mboxlist/ ディレクトリ内のすべてのファイルを削除します。

  5. stored、imapd、popd、mshttpd のようなメッセージストアプロセスを起動します。

  6. reconstruct -m ユーティリティを実行して、folder.db を再構築します。


データベーススナップショットのバックアップを作成するには

メールボックスデータベースとログファイルのバックアップ (スナップショットともいう) を作成することによって、メッセージストアの破損に備えることができます。データベースが破損してしまった場合は、スナップショットを使用してデータベースを置き換えれば、データベースを再構築しなくて済みます。スナップショット機能は、データベースの整合性のあるコピーを作成し、それによってデータベースを回復することができます。これらのバックアップを保存しておくための十分なディスク容量があることを確認してください。

注

特に指定されていないかぎり、iPlanet Messaging Server 5.2 で使われるデータベーススナップショットパラメータは 表 11-9 に示されているものだけです。


表 11-9 に、データベーススナップショットの作成に使われる 3 つの configutil パラメータを示します。これらのデータベーススナップショットは、回復時に stored プロセスによって呼び出されます。

表 11-9    configutil のデータベーススナップショットパラメータ 

データベーススナップショットパラメータ

説明

local.store.snapshotpath  

mboxlist ディレクトリのコピー先のパスを指定します。メッセージストア所有者に権限が設定されます。スナップショットはサブディレクトリに置かれます。  

local.store.snapshotinterval  

スナップショットの時間の間隔。時間は分単位。この手順は少なくとも 1 日 1 回実行することをお勧めします。  

local.store.snapshotdirs  

ディスク上に保存する個々のスナップショットの数。最低は 2 個で、デフォルトは 3。現在のもので修復できないことが判明する前に、データベースの良好なバックアップを作成しておくことをお勧めします。  

データベースのバックアップを作成するには、configutil コマンドを使用して次のパラメータの値を指定します。

configutil -o local.store.snapshotinterval -v number

ここで、number には stored がデータベースをバックアップする頻度を指定します。この number は、分間隔を示しています。

configutil -o local.store.snapshotpath -v path

この path は、バックアップコピーの置かれる場所を示しています。

警告

初期のリリースの Messaging Server のデータベーススナップショットユーティリティは、現在のユーティリティと同じ方法では機能しません。このため、旧バージョンの Messaging Server のスナップショットユーティリティを Messaging Server 5.2 で使用することはお勧めできません。



データベーススナップショットを使用してメッセージストアを回復するには

データベーススナップショットを使用してデータベースを回復するためには、メッセージストアのレイアウトを熟知していることが必須です。詳細は、「メッセージストアのディレクトリレイアウト」を参照してください。

データベーススナップショットが作成されると (「データベーススナップショットのバックアップを作成するには」 を参照)、それらは src サブディレクトリに保存されます。これらのファイルは、最終的には、回復済みのデータベースが保存されている dst server-root/msg-instance/store/mboxlist/ ディレクトリに移されます。スナップショットファイルに加え、スナップショットの作成中に作成される制御ファイルがあります。表 11-10 に、データベーススナップショットの制御ファイルを示します。これらのファイルはメッセージストア所有者が所有することに注意してください。

表 11-10    データベーススナップショット制御ファイル 

制御ファイル

説明

dst/.nosnap  

設定データが再読み込みされない場合でも、データベーススナップショットプロセスを無効にします。  

dst/.snaprst  

以前のすべてのスナップショットを無効としてマークします。このファイルは最初の新しいスナップショットのあとで削除されます。  

dst/.catrecov  

stored プロセスをトリガして重大な回復処理を開始し、スナップショットを使用可能な形式にリストアします。  

src/.snaptime  

有効なスナップショットがディレクトリ内にあることを示します。このファイルのタイムスタンプは、スナップショットが完了した時間を示します。  

以下の手順で、データベーススナップショット、制御ファイル、src/、および dst/ ディレクトリを使用して手動回復を実行する方法を説明します。

  1. 回復を実行する前に、自分がメッセージストアの所有者であることを確認します。

  2. メッセージストアプロセスを停止し、すべてのプロセスが停止していることを確認します。

  3. server-root/msg-instance/store/mboxlist/ ディレクトリ内のファイルを、あとで確認するために安全な場所にコピーします。

  4. スナップショットがある場合は、メッセージストアと置き換えることができるかどうかを確認します。詳細は、「データベーススナップショットのバックアップを作成するには」を参照してください。

    1. *.snaptime ファイルを使用して、バックアップの有効性と時間を確認します。スナップショットにある該当のログファイルが多すぎる場合は、別のスナップショットを確認します。

    2. データベースに関する問題が取り込まれていない最新の有効なスナップショットを選びます。

      利用できるスナップショットがない場合は、高速回復手順に従ってください。詳細は、「高速回復を実行するには」を参照してください。

  5. server-root/msg-instance/store/mboxlist/ ディレクトリ内のファイルは壊れているため、これらのファイルをすべて削除します。

  6. 該当のスナップショットファイルを、選択したスナップショットから server-root/msg-instance/store/mboxlist/ ディレクトリにコピーします。ただし、*.snaptime ファイルはコピーしないでください。

  7. touch コマンドを使用して、server-root/msg-instance/store/mboxlist/ ディレクトリに .catrecov ファイルを作成します。

    .catrecov ファイルは、重大な回復処理を実行する必要があるメッセージストアを示すものです。

  8. メッセージストアプロセスを起動します。

  9. stored プロセスをモニタします。stored プロセスが回復を行います。

  10. stored プロセスが回復を行ったあとで server-root/msg-instance/store/mboxlist/.catrecov ファイルが削除されていることを確認します。削除されていないと、メッセージストアは、起動したとき常に重大な回復処理が必要であるとみなしてしまいます。

  11. reconstruct -m を実行して、snaptime ファイルと破損したデータベースの間の相違点を修復します。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日