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

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

• 「概要」

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

• 「メッセージストアによるメッセージの削除方法」

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

• 「共有フォルダについて」

• 「共有フォルダに関するタスク」

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

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

• 「自動メッセージ削除 (有効期限および消去) 機能を設定するには」

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

• 「メッセージストアの保守手順を実行する」

• 「メッセージストアのバックアップと復元を行う」

• 「ユーザーアクセスを監視する」

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

• 「新しいシステムへのメールボックスの移行または移動」

概要

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

システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。この追加ディスク容量をシステムに統合するには、2 種類の方法が存在します。もっとも簡単な方法は、別のメッセージストアパーティションを追加することです (「メッセージストアのパーティションを構成する」を参照)。

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

Messaging Server では、メッセージストアの管理のために、Sun Java System Console インタフェースに加えてコマンド行ユーティリティーのセットを提供しています。表 18–1 では、このコマンド行ユーティリティーについて説明しています。これらのユーティリティーの使用に関する詳細については、「メッセージストアの保守手順を実行する」および『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

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

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

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

メッセージストアは、いくつかのメールボックスデータベースとユーザーメールボックスで構成されています。メールボックスデータベースは、ユーザー、メールボックス、パーティション、制限容量、およびその他のメッセージストア関連のデータで構成されています。ユーザーメールボックスには、ユーザーのメッセージとフォルダがあります。メールボックスは「メッセージストアパーティション」に格納されます。メッセージストアパーティションとは、「ディスク」パーティション上の、メッセージストアを格納するための専用エリアです。詳細については、「メッセージストアのパーティションを構成する」を参照してください。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションを使用することをお勧めします。

INBOX などのメールボックスは、store_root にあります。たとえば、ディレクトリパスの例は以下のようになります。

store_root/partition/primary/=user/53/53/=mack1

次の表で、メッセージストアディレクトリについて説明します。

.../userid/nn/
または
.../userid/folder/nn/

メッセージストアによるメッセージの削除方法

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

1. メッセージフラグを「削除」に設定: クライアントがメッセージフラグを「削除」に設定します。この時点では、メッセージには削除のマークが付けられますが、クライアントは削除フラグを外せばメッセージを復元できます。第 2 のクライアントが存在する場合、そのクライアントからは削除されたフラグがただちには認識できない可能性があります。configutil パラメータの local.imap.immediateflagupdate を設定すると、フラグの更新がただちに行われるようになります。

2. メールボックスから削除: メッセージはメールボックスから削除されます。厳密には、メッセージはメッセージストアのインデックスファイルである store.idx から削除されます。メッセージ自体はディスクに残っていますが、メッセージの消去後、クライアントはメッセージを復元できなくなります。

   期限切れは、消去の特殊なケースです。メッセージのサイズや存続期間など、管理者が定義した一連の削除条件に適合するメッセージが消去されます。詳細については、「自動メッセージ削除 (有効期限および消去) 機能を設定するには」を参照してください。

3. ディスクから消去: imexpire ユーティリティーにより、消去されたメッセージをすべてディスクから消去します。デフォルトの場合は、毎日午後 11 時に実行されます。この設定は、メッセージの有効期限スケジュールを制御する local.schedule.expire および消去までの猶予期間 (メッセージが消去されずに保持される期間) を制御する store.cleanupage を使用して変更できます。これは、MTA ログファイルの古いバージョンを消去する imsimta purge コマンドとは異なることに注意してください。

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

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

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

ほかのユーザーもそのストアに対する管理者権限を持っている可能性があります。たとえば、ほかの管理者がこれらの権限を持っている場合があります。

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

• 「管理者エントリを追加するには」

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

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

• 「メールボックスを保護して管理者以外による削除や名前の変更を防止するには」

管理者エントリを追加するには

管理者の追加は、コンソールまたはコマンド行から行うことができます。

手順

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

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

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

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

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

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

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

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

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

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

   configutil -o store.admins -v " adminlist"

   この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。また、管理者は、サービス管理者グループのメンバーである必要があります (LDAP ユーザーエントリ: memberOf: cn=Service Administrators,ou=Groups,o=usergroup)。

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

ここでは、コンソールでメッセージストアの管理者 UID リストにある既存のエントリを変更する方法について説明します。

手順

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

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

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

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

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

   コマンド行

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

   configutil -o store.admins -v "adminlist"

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

管理者の削除は、コンソールまたはコマンド行から行うことができます。

手順

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

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

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

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

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

   configutil -o store.admins -v "adminlist"

メールボックスを保護して管理者以外による削除や名前の変更を防止するには

一部のメールボックスを保護して、管理者以外による削除や名前の変更を防止することもできます。次に、この手順を説明します。管理者以外のユーザーが保護されたメールボックスの削除、変更、または名前の変更を試みると、「mailbox is pinned」というエラーメッセージが表示されます。

local.store.pin configutil 変数を設定します。次の形式を使用してください。

configutil -o local.store.pin -v "mailbox1"%"mailbox2"%"mailbox 3"

ここで、mailbox1、mailbox2、および mailbox 3 は保護するメールボックスで (メールボックス名にはスペースも使用可)、% は各メールボックス間の区切り文字です。

共有フォルダについて

「グループフォルダ」または「共有フォルダ」は、ほかのメールフォルダと同様です。ただし、ほかのユーザーやグループも、与えられている権限に応じて、そのメッセージの読み取り、削除、追加を行うことができます。共有フォルダにメッセージを追加するには、通常のドラッグ＆ドロップを使用する方法、Sieve フィルタを使用する方法、または uid+folder@ domain という形式を使用して直接送信する方法があります。次に例を示します。

carol.fanning+crafts_club@siroe.com

共有フォルダは、ある話題についてのリアルタイムの電子メール会話を開始、共有、アーカイブする場合に便利です。たとえば、ソフトウェア開発者のグループは、mosaic_voices という特定のプロジェクトの進行状況について話し合うための共有フォルダを作成できます。メッセージが共有フォルダ mosaic_voices に送信またはドロップされると、その共有フォルダに対して権限を持っているユーザーは誰でもそのメールボックスを開いてメッセージを読むことができます (権限は個々のアドレスでもグループアドレスでも追加できる)。

ユーザーの共有フォルダは、ユーザーの Shared Folders/Users というメールフォルダに保存されます。ユーザーはこのメールフォルダ内に共有フォルダを作成しアクセスします。「共有フォルダについて」に例を示します。

図 18–2 Ed の共有メールフォルダリストのメールクライアントの例

共有フォルダには 2 種類あります。

• 非公開共有フォルダ - 特定のユーザーが作成し所有する共有フォルダです。共有フォルダの作成をサポートしている Communications Express などのメールクライアントを使用します。詳細については、Communications Express のヘルプ画面を参照してください。

• 公開共有フォルダ - 公開共有フォルダは、メール管理者によって作成されますが、所有者はいません。公開フォルダの電子メールアドレスは次のようになります。

  public+foldername@domain
  

  たとえば、社内の何らかの会についての情報を送信するために public+software_dev@siroe.com などのフォルダを作成します。興味のある従業員に対して、この公開フォルダへのアクセス権を付与します。

通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる特殊な共有フォルダを作成できます。このようなフォルダは、「分散共有フォルダ」と呼ばれます。詳細については、「分散共有フォルダを設定するには」を参照してください。

共有フォルダに関するタスク

この節では、共有フォルダ管理者のタスクについて説明します。

• 「公開フォルダを作成するには」

• 「共有フォルダのアクセス制御の権限を設定または変更するには 」

• 「共有フォルダの一覧表示を有効化または無効化するには」

• 「分散共有フォルダを設定するには」

• 「共有ファイルデータを監視および保守するには」

公開フォルダを作成するには

公開フォルダの場合は、LDAP データベースおよび readership コマンドへのアクセスが必要であるため、システム管理者が作成する必要があります。

手順

1. すべての公開フォルダのコンテナとして機能する public という LDAP ユーザーエントリを追加します (「共有フォルダについて」を参照)。

   次に例を示します。

   dn: cn=public,ou=people,o=sesta.com,o=ISP objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetUser objectClass: ipUser objectClass: inetMailUser objectClass: inetLocalMailRecipient objectClass: nsManagedPerson objectClass: userPresenceProfile cn: public mail: public@sesta.com mailDeliveryOption: mailbox mailHost: manatee.siroe.com uid: public inetUserStatus: active mailUserStatus: active mailQuota: -1 mailMsgQuota: 100

2. mboxutil コマンド行ユーティリティーを使用して、public アカウント内にフォルダを作成します。

   たとえば、gardening という公開フォルダを作成します。

   mboxutil -c user/public/gardening

3. 共有フォルダに対するユーザーのアクセス権を指定します。

   ユーザーとそのアクセス権を指定するには、readership コマンドを使用します。たとえば、次のコマンドは、sesta.com の全員に公開フォルダ gardening の検索、読み取り、および送信のアクセス権を付与します。

   readership -s user/public/gardening anyone@sesta.com lrp

   readership の使用方法の詳細については、「共有フォルダのアクセス制御の権限を設定または変更するには 」を参照してください。

電子メールグループの共有フォルダを追加するには

共有フォルダを作成するには、通常、Communications Express を使用して共有フォルダリストにユーザーを追加するか、前述の方法で公開共有フォルダを作成します。ただし、共有フォルダリストに電子メールグループ (メール配布リスト) を追加して、グループの全員が共有フォルダにアクセスできるようにすることもできます。たとえば、tennis@sesta.com というグループに 25 人のメンバーがいる場合に、このグループアドレス宛のすべての電子メールを保存する共有フォルダを作成できます。

共有フォルダに電子メールグループを追加するには

共有フォルダに電子メールグループを追加するには、システム管理者の権限が必要です。

手順

1. フォルダを作成します。(これをすでに完了している場合、この手順は省略する。)

   通常、グループのいずれかのメンバーがこの作業を行う必要があります。グループメンバーの代わりに、管理者が次のコマンドを使用して作成することもできます。

   mboxutil -c user/gregk/gardening

   gregk は、共有フォルダの所有者の uid です。gardening は、共有フォルダの名前です。

2. グループ共有フォルダへのアクセス権を与える各メンバーについて、そのユーザーエントリに属性と値のペア aclGroupAddr group_name@domain を追加します。

   上の例を使用すると、共有フォルダへのアクセス権を与える各ユーザーエントリに、次の属性と値のペアを追加します。

   aclGroupAddr: tennis@sesta.com

   グループエントリで memberURL 属性を使用して動的に作成されたグループの場合、そのメンバーにはすでにこの属性が設定されています。この属性の URL 値は次のようになります。

   memberURL: ldap:///o=sesta.com??sub?(&(aclGroupAddr=tennis@sesta.com) (objectclass=inetmailuser))

   (この例のエントリ行は印刷上の理由で折り返されているが、実際のエントリは 1 行に記述される。)

3. 共有フォルダに対するグループのアクセス権を指定します。

   これには readership コマンドを使用します。上の例を使用すると、次のコマンドは、tennis@sesta.com のメンバーに公開フォルダ gardening の検索、読み取り、および送信のアクセス権を付与します。

   readership -s user/gregk/tennis tennis@sesta.com lrp

   readership の使用方法の詳細については、「共有フォルダのアクセス制御の権限を設定または変更するには 」を参照してください。

共有フォルダのアクセス制御の権限を設定または変更するには

ユーザーは Communications Express インタフェースを使用して、共有フォルダに対するアクセス制御を設定したり変更したりできます。管理者は readership コマンド行ユーティリティーを使用して、共有フォルダに対するアクセス制御を設定したり変更したりできます。このコマンドの形式は、次のとおりです。

readership -s foldername identifier rights_chars

ここで、foldername は権限を設定する公開フォルダの名前、identifier は権限を割り当てるユーザーまたはグループ、rights_chars は割り当てる権限です。各文字の意味については、表 18–3 を参照してください。

anyone は特別な識別子です。anyone のアクセス権は、すべてのユーザーに適用されます。同様に、anyone@domain のアクセス権は、同一ドメイン内のすべてのユーザーに適用されます。

例

sesta ドメインの全員に公開フォルダ golftournament の検索、読み取り、電子メールのマーク付けができる (ただし、送信は除く) アクセス権を付与する場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament anyone@sesta lwr

メッセージストアの全員に同じアクセス権を割り当てるには、次のコマンドを発行します。

readership -s User/public/golftournament anyone lwr

検索、読み取り、電子メールのマーク付け、および送信する権限をグループに割り当てる場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament group=golf@sesta.com lwrp

このフォルダの管理者権限と送信権限を jdoe という個人に割り当てる場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament jdoe@sesta.com lwrpa

公開フォルダへの個人またはグループのアクセスを拒否するには、ダッシュを userid の前に付けます。たとえば、jsmith の検索、読み取り、書き込み権限を拒否するには、次のようにコマンドを発行します。

readership -s User/public/golftournament -jsmith@sesta.com lwr

個人またはグループのアクセス権を拒否するには、ACL 権限を示す文字の前にダッシュを付けます。たとえば、jsmith の送信権限を拒否するには、次のようにコマンドを発行します。

readership -s User/public/golftournament jsmith@sesta.com -p

uid+folder@domain アドレスを使用して共有フォルダにメッセージを送信するには、readership コマンドに p (送信) アクセス権を使用する必要があります。詳細については、「共有フォルダのアクセス制御の権限を設定または変更するには 」を参照してください。

共有フォルダの一覧表示を有効化または無効化するには

設定オプション local.store.sharedfolders の設定によって、サーバーは LIST コマンドに対する応答として共有フォルダを返す場合と返さない場合があります。このオプションを off に設定すると、オプションは無効になります。デフォルトでは、この設定は有効 (on) になっています。

SELECT および LSUB コマンドは、このオプションの影響を受けません。LSUB コマンドは、すべての購読されているフォルダを返します。これには共有フォルダが含まれます。ユーザーは SELECT を使用して所有するフォルダや購読しているフォルダを選択できます。

分散共有フォルダを設定するには

通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる「分散共有フォルダ」を作成できます。つまり、分散共有フォルダへのアクセス権は、メッセージストアグループ内の任意のユーザーに付与できます。ただし、Web メールクライアント (Messenger Express などの HTTP アクセスクライアント) では、リモートでの共有フォルダアクセスがサポートされていないことに注意してください。ユーザーは共有フォルダを一覧表示および購読できますが、内容を表示したり変更したりすることはできません。

分散共有フォルダでは、次の条件を満たす必要があります。

• メッセージストア userid は、メッセージストアグループ全体で一意である。

• 配備全体で、ディレクトリデータが同一である。

リモートのメッセージストア (つまり、共有フォルダを保持していないメッセージストア) は、表 18–4 に示されている設定変数を使用してプロキシサーバーとして設定されている必要があります。

分散共有フォルダの設定例

図 18–3 に、StoreServer1、StoreServer2、および StoreServer3 という 3 つのメッセージストアサーバーで共有する分散フォルダの例を示します。

図 18–3 分散共有フォルダの例

これらのサーバーは、表 18–4 で示されている変数を設定することによって、ピアプロキシメッセージストアとして互いに接続しています。各サーバーには、golf (Han が所有)、tennis (Kat が所有)、および hurling (Luke が所有) という非公開共有フォルダがあります。さらに、press_releases および Announcements という 2 つの公開共有フォルダもあります。これら 3 つのサーバーのいずれかに存在するユーザーは、これら 3 つの共有フォルダすべてにアクセスできます。図 18–2 に、Ed の共有フォルダリストが示されています。次に、この構成における各サーバーの ACL の例を示します。

$ StoreServer1 :> readership -l
Ed: user/Han/golf 
Ian: user/Han/golf 
anyone: user/public/press_releases

            

$ StoreServer2 :> readership -l
Jan: user/Kat/tennis
Ann: user/Kat/tennis
anyone: user/public+Announcements user/public+press_releases

            

$ StoreServer3 :> readership -l
Tuck: user/Ian/hurling
Ed: user/Ian/hurling 
Jac: user/Ian/hurling 
anyone: user/public/Announcements

            

共有ファイルデータを監視および保守するには

readership コマンド行ユーティリティーを使用すると、folder.db、peruser.db、および lright.db の各ファイルに保存されている共有フォルダデータを監視および保守できます。folder.db には、ACL のコピーが格納された各フォルダの記録があります。peruser.db には、ユーザーおよびメールボックスごとのエントリがあり、このエントリには、各種フラグ設定およびユーザーが任意のフォルダに前回アクセスした日付が示されています。lright.db には、全ユーザーの一覧があり、ユーザーが検索権限を持つ共有フォルダも示されています。

readership コマンド行ユーティリティーでは次のオプションが使用できます。

さまざまなオプションを使用して、次の機能を実行できます。

• 「共有フォルダ使用状況を監視するには」

• 「ユーザーとその共有フォルダを一覧表示するには」

• 「非アクティブなユーザーを削除するには」

• 「アクセス権を設定するには」

共有フォルダ使用状況を監視するには

共有フォルダに積極的にアクセスしているユーザーの数を調べるには、次のコマンドを発行します。

readership -d days

days は、チェック対象とする日数です。このオプションではアクティブなユーザーの数が返されるのであって、アクティブなユーザーの一覧が返されるのではないことに注意してください。

次に例を示します。過去 30 日以内に共有フォルダを選択したユーザーの数を調べるには、次のようにコマンドを発行します。

readership -d 30

ユーザーとその共有フォルダを一覧表示するには

ユーザーおよびユーザーがアクセスした共有フォルダを一覧表示するには、次のコマンドを発行します。

readership -l

出力例:

$ readership -l
group=lee-staff@siroe.com: user/user2/lee-staff
richb: user/golf user/user10/Drafts user/user2/lee-staff user/user10/Trash
han1: user/public+hurling@siroe.com user/golf
gregk: user/public+hurling@siroe.com user/heaving user/tennis

非アクティブなユーザーを削除するには

非アクティブなユーザー (指定の期間内に共有フォルダにアクセスしなかったユーザー) を削除するには、次のコマンドを発行します。

readership -p months

months は、チェックに使用する月数です。

次に例を示します。過去 6 か月間に共有フォルダにアクセスしなかったユーザーを削除します。

readership -p 6

アクセス権を設定するには

新規の公開フォルダにアクセス権を割り当てたり、現在の公開フォルダのアクセス権を変更したりできます。

このコマンドを使用したアクセス権の設定方法の例については、「共有フォルダのアクセス制御の権限を設定または変更するには 」を参照してください。

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

メッセージストアの制限容量は、ユーザーまたはドメインが使用できるディスク容量またはメッセージ数の「制限容量」を設定するしくみです。この節では、次の情報について説明します。

• 「ユーザーの制限容量」

• 「ドメインの制限容量」

• 「Telephony Application Server に関する例外」

詳細については、「制限容量を監視するには」を参照してください。

ユーザーの制限容量

ユーザーの制限容量は、ディスク容量またはメッセージの数によって指定できます。ディスク制限容量は、各ユーザーに割り当てられるディスク容量をバイト単位で指定します。ディスク制限容量は、ユーザーのメールフォルダの数に関係なくユーザーのメッセージの合計サイズに適用されるか、ユーザーメッセージの合計数に適用されます。メッセージ制限容量は、ユーザーのメールボックスに保存されるメッセージの数を制限するものです。

制限容量の情報は、LDAP 属性 (表 18–6) および configutil 変数 (表 18–7) に保存されます。最新の詳細情報については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』を参照してください。Messaging Server では、制限容量を設定する以外にも、次の機能を制御できます。

• 制限容量の通知は、「ディスク制限容量のしきい値」に達したときに、ユーザーに警告メッセージを送信します。

• 制限容量の適用は、制限容量を超過したあとはメッセージストアへのメッセージの配信を停止します。制限容量を超過した場合でもメッセージを配信できるようにすることもできます。

  制限容量を超過したためにメッセージ配信が停止された場合、次のどちらかの状態になるまで、着信メッセージは MTA キューに残ったままとなります。

  • ユーザーのメッセージのサイズまたは数が制限容量を超えない状態になったとき。この時点で MTA によってメッセージが配信されます。

  • 未配信のメッセージの MTA キューに残留している期間が、メッセージが差出人に返されるよう指定された猶予期間を超えてしまったとき。(「猶予期間を設定するには」を参照)。

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

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

ドメインの制限容量

ユーザーの場合と同様、制限容量はドメインに対しても、バイト数またはメッセージ数のどちらかを設定できます。この制限容量は、特定のドメイン内のすべてのユーザーの、累積されたバイトまたはメッセージすべてに対するものです。

Telephony Application Server に関する例外

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

メッセージストアの制限容量の属性およびパラメータ

この節では、メッセージストアの制限容量の属性およびパラメータについて説明します。これらの属性およびパラメータの詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』を参照してください。

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

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

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

• 「個々のユーザー制限容量を指定するには」

• 「ドメイン制限容量を指定するには」

• 「制限容量の通知を配備するには」

• 「制限容量の適用を有効または無効にするには」

• 「猶予期間を設定するには」

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

個別の制限容量が設定されていないユーザーに適用するデフォルトの制限容量を設定するには、コンソールまたはコマンド行を使用します。

手順

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

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

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

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

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

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

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

6. デフォルトのメッセージストアの制限容量を使用する場合は、ユーザーエントリで、「M バイト」属性を -1 に設定します。

   コマンド行

   コマンド行でデフォルトのユーザー制限を指定するには、以下の手順に従います。

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

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

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

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

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

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

   デフォルトのメッセージストアの制限容量を使用する場合は、ユーザーエントリで、mailQuota 属性を -2 に設定します。詳細については、表 18–6 を参照してください。

個々のユーザー制限容量を指定するには

各ユーザーには、制限容量を個別に設定できます。ユーザー固有の制限容量を設定するには、ユーザーの LDAP エントリで mailQuota または mailmsgquota 属性を設定します。(表 18–6 を参照。) 制限容量を適用するには、configutil store.quotaenforcement を on に設定します。

ドメイン制限容量を指定するには

ディスク容量の制限容量またはメッセージの制限容量は、特定のドメインに対して設定できます。これらの制限容量は、特定のドメイン内のすべてのユーザーの、累積されたバイトまたはメッセージすべてに対するものです。ドメインの制限容量を設定するには、ユーザーの LDAP エントリで mailDomainDiskQuota または mailDomainMsgQuota 属性を設定し (表 18–6 を参照)、imquotacheck -f を実行します。

制限容量の通知を配備するには

制限容量の通知とは、制限容量に近づいたときにユーザーに警告メッセージを送信する処理のことです。この機能を使用するには、3 つの手順が必要です。

• 「制限容量の通知を有効にするには」

• 「制限容量の警告メッセージを定義するには」

• 「制限容量のしきい値を指定するには」

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

制限容量の通知を有効にするには、コンソールまたはコマンド行を使用します。

手順

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

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

3. 制限容量の警告メッセージを定義します。詳細については、「制限容量の警告メッセージを定義するには」を参照してください。

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

   コマンド行

   コマンド行で制限容量の通知を有効または無効にするには、以下のようにします。

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

   メッセージに何も設定されなかった場合、ユーザーには制限容量の警告メッセージは送信されません。制限容量の警告メッセージの形式については、次の節を参照してください。

制限容量の警告メッセージを定義するには

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

手順

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

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

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

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

   コマンド行

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

   configutil -o store.quotaexceededmsg -v ’message’

   メッセージは RFC 822 形式でなければなりません。メッセージには少なくとも件名行を含むヘッダーがあり、$$、メッセージ本文がそのあとに続いている必要があります。$ は、新しい行を表します。使用しているシェルによっては、$ の前に \ を追加して、$ が持つ特殊な意味をエスケープする必要があることもあります (ほとんどの場合、$ はシェルのエスケープ文字)。次に例を示します。

   configutil -o store.quotaexceededmsg -v ”Subject: WARNING: User quota exceeded$$User quota threshold exceeded - reduce space used.’

   さらに、次の変数がサポートされます。

   [ID] - ユーザー ID

   [DISKUSAGE] - ディスク使用量

   [NUMMSG] - メッセージの数

   [PERCENT] - store.quotawarn パーセンテージ

   [QUOTA] - mailquota 属性

   [MSGQUOTA] - mailmsgquota 属性

   次にこれらの変数の使用例を示します。

   configutil -o store.quotaexceededmsg -v ”Subject: Overquota Warning$$[ID],$$Your mailbox size has exceeded [PERCENT] of its alloted quota.$Disk Usage: [DISKUSAGE]$Number of Messages: [NUMMSG]$Mailquota: [QUOTA]$Message Quota: [MSGQUOTA]$$-Postmaster’

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

   configutil -o store.quotaexceededmsginterval -v number

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

制限容量のしきい値を指定するには

制限容量のしきい値は、クライアントに警告が送信されるときの、制限容量を超えた割合です。ユーザーのディスク使用量が指定したしきい値を超えたら、サーバーからユーザーに警告メッセージが送信されます。

local.store.quotaoverdraft=on の場合、store.quotawarn で設定されたしきい値に関係なく、ユーザーのディスク使用量が制限容量の 100% を超えるまで電子メール通知はトリガされません。

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

手順

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

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

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

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

   コマンド行

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

   configutil -o store.quotawarn -v number

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

制限容量の適用を有効または無効にするには

デフォルトでは、制限容量を超えてもユーザーまたはドメインには何の影響もなく、制限容量超過の通知が設定されている場合に通知を受信するだけです。制限容量を適用すると、ディスク容量が制限容量レベルを下回るまで、それ以上メッセージを受信しないようメールボックスをロックします。

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

制限容量の適用を有効にするには、コンソールまたはコマンド行を使用します。

手順

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

2. 「容量制限実施の有効化」ボックスにチェックマークを付けます。制限容量の適用を無効にする場合はこのボックスのチェックマークを外します。

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

   コマンド行

   制限容量の適用を有効または無効にするには、以下のようにします。

   configutil -o store.quotaenforcement -v [ on | off]

   制限容量を超過すると、メッセージは MTA キューに保存され、メッセージが配信されなかったが、あとで再配信が試行されることを示す通知が差出人へ送信されます。配信の再試行は、猶予期間の期限が切れて、すべてのメッセージが差出人に戻されるまで、またはディスク使用量が制限容量を下回り、メッセージを MTA キューから取り出してメッセージストアに配信できるようになるまで続行されます。制限容量を超えた場合に、メッセージをキューに入れる前にメッセージを返す場合は、次のコマンド行を使用します。

   configutil -o store.overquotastatus -v on

制限容量の適用をドメインレベルで有効にする

特定のドメインの制限容量を適用するには、次のコマンドを使用します。

imquotacheck -f -d domain

すべてのドメインについて有効にするには、-d オプションを除外します。ドメインがその制限容量を超過すると、maildomainstatus 属性が overquota に設定され、このドメインへの全配信が停止します。ドメインが overquota でない場合、値は active に設定されます。

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

ユーザーの制限容量が適用されているようである場合は、制限容量を無効にした場合でも、次のパラメータを確認してください。

次の configutil パラメータは、オフにするか設定しないようにする必要があります。

• store.quotaenforcement

• local.store.overquotastatus

• local.store.quotaoverdraft

store.overquotastatus が on の場合、常に store.quotaoverdraft が on であるとみなし、そうでない場合はユーザーは制限容量を超過して拒否を引き起こすことはありません。また、store.quotaoverdraft が on の場合、ユーザーは制限容量よりも小さいメッセージを 1 つだけ許可されます。すなわち、ユーザーの制限容量よりも大きいメッセージは受け入れません。

これらのパラメータを変更したあとは、必ずメッセージングサービスを再起動してください。

次のメッセージストア属性はアクティブにする必要があります。

• maildomainstatus

• mailuserstatus

メッセージがメールボックスの制限容量よりも大きい場合は、制限容量の適用設定とは無関係にバウンスされます。

猶予期間を設定するには

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

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

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

• メッセージがメッセージキューの最大時間を過ぎてもメッセージキューに残っているとき。これは、notices MTA チャネルキーワードによって制御されます (「通知メッセージの配信間隔を設定するには」を参照)。

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

猶予期間とは、メッセージがメッセージキュー内に保持される期間ではなく、メッセージキュー内に含まれているすべての着信メッセージがバウンスされるまでに、メールボックスが制限容量を超えた状態でいられる期間です。猶予期間は、ユーザーが制限容量のしきい値に達し、警告を受けたときに開始します。「制限容量のしきい値を指定するには」を参照し、注意してください。

メッセージをキューに保持する猶予期間を設定するには

手順

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

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

3. ドロップダウンリストで「日」または「時間」を指定します。

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

   コマンド行

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

   configutil -o store.quotagraceperiod -v number

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

Netscape Messaging Server の制限容量の互換性モード

Netscape Messaging Server のディスク使用量が制限容量を超過すると、サーバーはメッセージの配信を延期またはバウンスし、制限容量超過通知を送信して、猶予期間を開始します。Messaging Server には、この動作を保持するパラメータ local.store.quotaoverdraft があります。

ON に設定すると、メッセージはディスクの使用量が制限容量を超過するまで配信されます。超過時には、メッセージが延期され (メッセージは MTA メッセージキューに保持されるが、メッセージストアに配信されない)、制限容量超過警告メッセージがユーザーに送信されて、猶予期間が開始されます。猶予期間は、制限容量超過メッセージがバウンスされるまで、メールボックスが制限容量超過である期間を決定します。デフォルトでは、メッセージストアがしきい値に達したときに、制限容量の警告メッセージが送信されます。このパラメータのデフォルトは、Off です。

自動メッセージ削除 (有効期限および消去) 機能を設定するには

自動メッセージ削除機能 (有効期限切れおよび消去とも呼ばれる) を使用すると、管理者が定義した一連の条件に基づいて、メッセージストアからメッセージが自動的に削除されます。この機能によって、古いメッセージやサイズの大きいメッセージ、開封済みまたは削除済みメッセージ、特定の Subject: 行を持つメッセージなどを自動的に削除できます。次の削除条件が設定できます。

• フォルダ (メールボックス) 別、ユーザー別、ドメイン別、メッセージストア全体、または特定のパーティション

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

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

• メールボックスでのメッセージの存続期間 (日数)

• メッセージのサイズと猶予期間 (サイズ超過のメッセージを消去する前にメッセージストアに残しておく日数)

• メッセージのフラグが seen か deleted かどうか

• ヘッダー文字列

この機能は、メッセージの消去や消去を行う imexpire ユーティリティーを使用して実行します。メッセージ削除プロセスの詳細については、「メッセージストアによるメッセージの削除方法」を参照してください。

サーバーによってメッセージは警告なしに削除されます。したがって、自動メッセージ削除ポリシーについてユーザーに知らせておくことは重要です。メッセージが突然削除されると、ユーザーや管理者は大変驚くことになるからです。

imexpire の動作方式

imexpire は、コマンド行から呼び出すか、imsched デーモンを使用して自動的に実行されるようにスケジュールします。管理者は、store.expirerule というファイルに一連の有効期限ルールを指定します。このファイルは、メッセージを削除する条件を指定します。ルールの範囲に関連するディレクトリごとに、複数のファイルが存在する場合があります。つまり、メッセージストア全体にグローバルに適用されるルールはあるディレクトリに置かれ、パーティションに適用されるルールは別のディレクトリ、ユーザーに適用されるルールはさらに別のディレクトリに置かれる、というようになります。

グローバル有効期限ルールは、コンソールまたは configutil コマンドを使用して指定することもできますが、store.expirerule を使用する方法をお勧めします。コンソールまたは configutil を使用して多数のルールを作成すると、パフォーマンスの問題が発生することがあります。

imexpire は、起動時にすべての有効期限ルールをロードします。デフォルトでは、imexpire はパーティションごとに 1 つのスレッドを作成します。各スレッドは割り当てられたパーティションの下にあるユーザーフォルダのリストを通過し、その間にローカル有効期限ルールをロードします。この有効期限機能により、各フォルダは有効期限ルールに照らしてチェックされ、メッセージは必要に応じて消去されます。メールボックスディレクトリの内に store.exp ファイルが存在し、store.cleanupage 設定パラメータで指定した期間を過ぎていたために消去されたり期限切れになっていたりするメッセージがある場合は、消去機能によってメッセージハッシュディレクトリ内にあるメッセージファイルが完全に削除され、store.exp ファイルから UID のレコードが削除されます。

msg_svr_base/config/ 内の expire_exclude_list と呼ばれるファイルで、1 行に 1 つずつユーザー ID を追加して、指定したユーザーを有効期限ルールから除外することもできます。

自動メッセージ削除機能を配備するには

メッセージの自動削除には 3 つの手順が必要です。

1. 自動メッセージ削除ポリシーを定義します。どのメッセージを自動的に削除するか、どのユーザー、フォルダ、ドメイン、およびパーティションのメッセージを自動的に削除するか、およびサイズ、メッセージ存続期間、ヘッダーについて特定して削除条件を定義します。削除するメッセージの範囲を定義します。詳細については、「自動メッセージ削除ポリシーを定義するには」を参照してください。

2. imexpire ルールを指定してこのポリシーを実装します。詳細については、「自動メッセージ削除ポリシーを実装するルールを設定するには」を参照してください。

3. imexpire スケジュールを指定します。詳細については、「自動メッセージ削除とログレベルをスケジュールするには」を参照してください。

自動メッセージ削除ポリシーを定義するには

削除条件を指定して独自の自動メッセージ削除ポリシーを定義します。imexpire を使用すると、次の条件を使用する削除が可能になります。

メッセージの存続期間: X 日間より存続期間が長いメッセージを自動的に削除します。属性: messagedays。

メッセージの件数: X 件を超えたフォルダ内のメッセージを自動的に削除します。属性: messagecount。

サイズ超過メッセージの存続期間: X バイトを超えるメッセージを Y 日間の猶予期間後に自動的に削除します。属性: messagesize および messagesizedays。

開封済みおよび削除済みメッセージフラグ: 「開封済み」または「削除済み」フラグが付いているメッセージを自動的に削除します。これらの条件には、「and」または「or」が設定できます。or に設定した場合、メッセージに開封済みまたは削除済みフラグが付いていると、ほかの条件にかかわらず自動削除されます。and に設定した場合、メッセージに付いている開封済みまたは削除済みフラグは、指定したほかの条件すべてを満たした場合に設定されます。属性: seen および deleted。

メッセージのヘッダーフィールド: メッセージを削除する条件としてヘッダーおよび文字列を指定できます。たとえば、「Subject: Work from Home!」というヘッダーがあるメッセージをすべて削除できます。

メッセージのフォルダ: メッセージを削除するフォルダを指定できます。属性: folderpattern

imexpire を使用して、メッセージが開封されてからの期間に基づいてメッセージを削除または保存することはできません。たとえば、200 日経過しても読まれていないメッセージを削除するという指定はできません。

自動メッセージ削除ポリシーの例

例 1: 1,000 件を超えるメッセージが存在するフォルダ内の、存続期間が 365 日のメッセージをすべて削除します。

例 2: ドメイン siroe.com 内の、存続期間が 180 日を超えるメッセージを削除します。

例 3: 「削除済み」のマークが付いているメッセージをすべて削除します。

例 4: sesta.com 内の 1,000 件を超えるメッセージが存在するフォルダから、「開封済み」マークが付いていて、存続期間が 30 日より長く、サイズが 100K バイトより大きく、X-spam というヘッダーが付いたメッセージを削除します。

自動メッセージ削除ポリシーを実装するルールを設定するには

前の節で定義した自動メッセージ削除ポリシーを実装するには、imexpire ルールを設定する必要があります。ルールを設定するには、ルールを store.expirerule ファイルに追加します。2 つの store.expirerule グローバルルールの例を次に示します。

Rule1.regexp: 1
Rule1.folderpattern: user/.*/trash
Rule1.messagedays: 2
Rule2:regexp: 1
Rule2.folderpattern: user/.*
Rule2.messagedays: 14

            

この例では、Rule 1 でごみ箱フォルダ内のすべてのメッセージが 2 日後に削除されることを指定しています。Rule 2 ではメッセージストアのすべてのメッセージが 14 日後に削除されることを指定しています。

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

• 「有効期間ルールのガイドライン」

• 「imexpire ルールをテキストモードで設定する」

• 「imexpire フォルダパターンを設定する」

• 「コンソールを使用して自動メッセージ削除グローバルルールを設定するには」

有効期間ルールのガイドライン

この節では、store.expirerule ファイルルールのガイドラインを示します。

以前のリリースの Messaging Server では、有効期限ルールは、configutil パラメータの store.expirerule.attribute で設定できました (『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「configutil Parameters」を参照)。このリリースでもこれは引き続き可能ですが、ヘッダーの制約を使用した有効期限ルール (特定の件名でメッセージの有効期限が切れるなど) はサポートされません。いずれの場合でも、store.expirerule を使用してすべての有効期限ルールを指定することをお勧めします。

• ルールは、store.expirerule というファイルに指定されます。

• 同一のルールで複数の有効期限条件が指定できます。(上記の例を参照。)

• ルールはメッセージストア全体に適用でき (グローバルルール)、パーティション、ユーザー、フォルダごとにも適用できます。

  • グローバルルールは msg_svr_base/config/store.expirerule に保存されます。

    ---

    注 –

    各グローバルルールがすべてのメールボックスについてチェックされるため、指定するグローバルルールの数によっては、処理のオーバーヘッドが発生することがあります。このため、グローバルルールのファイルには、パーティション、メールボックス、またはユーザーのルールを指定しないでください。一般に、このファイルには必要最小限の有効期限ルールを指定するようにしてください。

    ---

  • パーティションルールは store_root /partition/partition_name/store.expirerule に保存されます。

  • ユーザールールは、store_root/partition/partition_name/userid/store.expirerule にルールを指定するか、folderpattern ルールを user/userid/.* となるように指定して作成できます。

  • フォルダルールは、store_root/partition/partition_name/userid/folder/store.expirerule にルールを指定するか、folderpattern ルールを user/userid/folder となるように指定して作成できます。

  • rule_name を使用するグローバルでない複数のルール (ユーザー、フォルダ、パーティション) は、Messaging Server 6.2p4 リリース以降でのみ実装されたことに注意してください。

• 複数の有効期限ルールが同時に 1 つのメールボックスに適用できます。メールボックスに対する有効期限ポリシーは、グローバルルールとローカルルールで構成されます。ローカルルールは同一ディレクトリのメールボックスおよびそのサブフォルダのすべてに適用されます。

• メールボックスに排他的なルールが指定されていないかぎり、imexpire によって、そのメールボックスに適用されているすべての有効期限ルールが結合されます (表 18–8 を参照)。その結果、ルールセットには、すべての適用可能なルールの中からもっとも制約度の高い有効期限ポリシーが採用されます。たとえば、メッセージの最長存続期間がルール X によって 10 日間、ルール Y によって 5 日間と指定されている場合、結合結果は 5 日間となります。

imexpire ルールをテキストモードで設定する

自動メッセージ削除ルールは、store.expirerule ファイルにルールを指定することによって設定します。store.expirerule ファイルは、1 行につき 1 つの有効期限条件を含みます。グローバルルール設定ファイル (msg_svr_base/data/store/store.expirerule) の有効期限条件は、次の形式になっています。

rule_name.attribute : value

ユーザーまたはメールボックスのルール設定ファイルの有効期限ルールは、次の形式になっています。

attribute: value

例 18–1 に、msg_svr_base /config/store.expirerule の一連のグローバル有効期限ルールを示します。

Rule 1 では、グローバル有効期限ポリシー (すべてのメッセージに適用されるポリシー) を設定しています。設定内容は次のとおりです。

• UNIX 正規表現をルール作成において有効にします。

• 100,000 バイトよりも大きいメッセージを 3 日後に削除します。

• ユーザーによって削除済みとされたメッセージを削除します。

• 「Viagra Now!」または「XXX Porn!」という文字列が Subject: ヘッダーにあるメッセージをすべて削除します。

• すべてのフォルダのメッセージ数を 1,000 件までに制限します。1,000 件を超えた場合、フォルダ内でもっとも古いメッセージを削除して合計件数を 1,000 以内に維持します。

• 存続期間が 365 日よりも長いメッセージをすべて削除します。

Rule 2 では、ホストしているドメインが siroe.com のユーザーに対して自動メッセージ削除ポリシーを設定しています。メールボックスサイズを 1M バイトに制限し、削除済みメッセージを削除し、存続期間が 14 日より長いメッセージを削除します。

Rule 3 では、ユーザー f.dostoevski の inbox フォルダに対して自動メッセージ削除ポリシーを設定しています。「On-line Casino」という件名行のあるメッセージを削除します。

例 18–1 imexpire ルールの例

Rule1.regexp: 1
Rule1.folderpattern: user/.*
Rule1.messagesize: 100000
Rule1.messagesizedays: 3
Rule1.deleted: or
Rule1.Subject: Vigara Now!
Rule1.Subject: XXX Porn!
Rule1.messagecount: 1000
Rule1.messagedays: 365
Rule2.regexp: 1
Rule2.folderpattern: user/.*@siroe.com/.*Rule2.exclusive: 1
Rule2.deleted: or
Rule2.messagedays: 14
Rule2.messagecount: 1000
Rule3.folderpattern: user/f.dostoevski/inboxRule3.Subject: *On-line Casino*
                  

imexpire フォルダパターンを設定する

フォルダパターンは POSIX 正規表現を使用して指定できます。このためには、imexpire 属性の regex を 1 に設定します。この属性を指定しないと、IMAP 表現が使用されます。この形式は user/ で始まり、そのあとにパターンが続きます。表 18–9 に、各種フォルダのフォルダパターンを示します。

コンソールを使用して自動メッセージ削除グローバルルールを設定するには

グローバル有効期限ルールは、コンソールを使用して設定することもできますが、store.expirerule を使用する方法をお勧めします。コンソールまたは configutil を使用して多数のルールを作成すると、パフォーマンスの問題が発生することがあります。

手順

1. 次の操作で自動メッセージ削除の GUI を呼び出します。

   メインコンソール -> サーバーグループ -> Messaging Server (開く) -> Messaging Server コンソール -> 設定タブ -> メッセージストア -> 有効期限/消去 -> 追加

   この GUI の略図を図 18–4 に示します。

   図 18–4 自動メッセージ削除 (有効期限または消去) GUI - 略図

   
   

2. 新しいルールの名前を入力します。

3. メッセージを自動的に削除するフォルダを入力します。

   詳細については、前述の 「imexpire フォルダパターンを設定する」を参照してください。

4. このルールが指定した条件と一致するフォルダに対する排他的なルールである場合は、「排他」ボックスをクリックします。

   このボックスにチェックマークを付けると、このルールが、指定したパターンに一致するほかのすべてのルールに優先します。「排他」チェックボックスの詳細については、表 18–8 を参照してください。

5. フォルダサイズに基づいてルールを作成するには、次を実行します。

   • 「フォルダサイズの制限」チェックボックスにチェックマークを入れます。「メッセージの件数」フィールドには、もっとも古いメッセージが削除されるまでフォルダ内に保持されるメッセージの最大件数を指定します。「フォルダサイズ」フィールドには、もっとも古いメッセージが削除されるまで保持されるフォルダの最大サイズをバイト単位で指定します。

6. メッセージの存続期間に基づいてルールを作成するには、「メッセージ存続期間の制約」チェックボックスにチェックマークを付けます。

   「日数」フィールドで、メッセージがフォルダに保持される期間を日数で指定します。

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

   • 「メッセージサイズの制約」チェックボックスにチェックマークを入れます。「メッセージサイズの制限」フィールドに、フォルダで許可されるメッセージの最大サイズを入力します。「猶予期間」フィールドに、サイズを超過したメッセージがフォルダ内に保持される (削除されるまでの) 期間を入力します。

8. 「開封済み」または「削除済み」メッセージフラグが設定されているかどうかに基づいてルールを作成するには、以下を実行します。

   • 「メッセージフラグの制約」チェックボックスにチェックマークを入れます。

   • 「開封済み:」フィールドでは、「および」を選択すると、メッセージが開封済みであり、かつ、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。「または」を選択すると、メッセージが開封済みであるか、または、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。

   • 「削除済み:」フィールドでは、「および」を選択すると、メッセージが削除済みであり、かつ、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。「または」を選択すると、メッセージが削除済みであるか、または、もう 1 つの条件を満たしている場合にルールを適用することを指定できます。

9. ヘッダーフィールドとその値に基づいてルールを作成するには、以下を実行します。

   • 「ヘッダーの制約」チェックボックスにチェックマークを入れます。

   • ヘッダーと値のリストを次の形式でコンマで区切って入力します。

     header1: value1, header2 : value2

     次に例を示します。Subject: Work at Home!,From: virus@sesta.com

     Expires ヘッダーや Expiry-Date ヘッダーで、日付の値が「メッセージの存続期間の制約」よりも古い場合、メッセージは削除されます。有効期限に関するヘッダーフィールドが複数指定された場合、もっとも古い有効期限が使用されます。(文字列)。

10. 「了解」をクリックすると、新しいルールが自動メッセージ削除リストに追加されます。

自動メッセージ削除とログレベルをスケジュールするには

自動メッセージ削除は、imsched スケジューリングデーモンによってアクティブになります。デフォルトでは、imsched は毎日 23:00 に imexpire を呼び出し、メッセージは消去および消去されます。このスケジュールは、configutil パラメータの local.schedule.expire、local.schedule.purge、および store.cleanupage を設定することによってカスタマイズできます。表 18–10 を参照してください。

有効期限および消去は、大きなメッセージストアでは完了するまでに時間のかかることがあるので、これらのプロセスの実行頻度は実験して決定することをお勧めします。たとえば、有効期限および消去の 1 サイクルに 10 時間かかる場合、有効期限および消去のデフォルトスケジュールを 1 日に 1 回とするわけにはいきません。有効期限と消去をスケジュールするには、local.schedule.purge を使用して消去のスケジュールを個別に指定します。local.schedule.purge が設定されていない場合、imexpire は有効期限を実行したあとに消去を実行します。

コンソールを使用した場合の imexpire スケジュール

次の操作で自動メッセージ削除の GUI を呼び出します。

メインコンソール -> サーバーグループ -> Messaging Server (開く) -> Messaging Server コンソール -> 設定タブ -> メッセージストア -> 有効期限/消去

このコンソールページでは、有効期限ルールが上部に、有効期限および消去スケジュールが下部に一覧表示されます。有効期限および消去をスケジュールするには、「有効期限/消去スケジュール」のプルダウンメニューを使用して、有効期限と消去の両方の月、日、曜日 (0 =日曜日)、時、分を設定します。

日の値は、「日」と「曜日」の両方で設定できます。両方で設定した場合、両方が評価されます。水曜日と 17 日を設定した場合、消去および有効期限は、17 日が水曜日にあたった場合にのみ実行されます。

imexpire ログレベルを設定する

imexpire が完了すると、デフォルトのログファイルに要約が記録されます。有効期限をコマンド行から呼び出す場合は、-v (詳細) および -d (デバッグ) の各オプションを使用して、詳細ステータスまたはデバッグメッセージを stderr に記録するように imexpire に指示できます。imsched を使用して imexpire を呼び出す場合は、configutil パラメータの local.store.expire.loglevel を 1、2、または 3 に設定して各ログレベルを選択できます。Loglevel 1 はデフォルトで、有効期限セッション全体の要約が記録されます。Loglevel 2 では、有効期限切れのメールボックスごとに 1 つのメッセージが記録されます。Loglevel 3 では、有効期限切れのメッセージごとに 1 つのメッセージが記録されます。

メッセージの自動削除から指定されたユーザーを除外する

msg_svr_base /config/ 内の expire_exclude_list ファイルで、1 行に 1 つずつユーザー ID を追加して、指定したユーザーを有効期限ルールから除外できます。

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

メッセージストアパーティションとは、ディスクパーティション上の、メッセージストアを格納するための専用エリアです。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションと 1 つのファイルシステムを使用することをお勧めします。メッセージストアパーティションは、メッセージストアとして特に指定されたディレクトリです。

デフォルトでは、ユーザーメールボックスは store_root/partition/ ディレクトリに保存されています (「メッセージストアのディレクトリレイアウト」を参照)。partition ディレクトリは、単一または複数のパーティションを格納している論理的なディレクトリです。起動時には、partition ディレクトリに primary パーティションと呼ばれるサブパーティションが格納されています。

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

store_root/partition/mkting/
store_root/partition/eng/
store_root/partition/sales/

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

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

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

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

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

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

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

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

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

コンソール

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

メッセージストアパーティションを追加するには

手順

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

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

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

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

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

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

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

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

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

   ---

   注 –

   デフォルトのパーティションとは、ユーザーが作成されたときに、ユーザーエントリに mailMessageStore LDAP 属性が指定されなかった場合に使用されるパーティションのことです。デフォルトのパーティションが必要にならないように、すべてのユーザーエントリに mailMessageStore LDAP 属性を指定してください。

   ---

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

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 属性を設定します。(『Sun Java System Communications Services 6 2005Q4 Schema Reference』の「mailAllowedServiceAccess」を参照。)

   ---

   注 –

   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 属性を変更します。

デフォルトのメッセージストアパーティション定義の変更

デフォルトのパーティションとは、ユーザーが作成されたときに、ユーザーエントリに mailMessageStore LDAP 属性が指定されなかった場合に使用されるパーティションのことです。デフォルトのパーティションが必要にならないように、すべてのユーザーエントリにユーザーのメッセージストアパーティションを指定する mailMessageStore LDAP 属性を指定してください。さらに、デフォルトのパーティションを負荷分散やその他の理由で変更してはなりません。デフォルトのパーティションの定義に依存するユーザーが存在する間に、デフォルトのパーティションを変更するのは無効であり危険です。

デフォルトのパーティションをどうしても変更する必要がある場合は、configutil パラメータの store.defaultpartition でデフォルトの定義を変更する前に、古いデフォルトのパーティションのすべてのユーザー (そのままになっていたユーザー) の mailMessageStore 属性が現在のパーティション (これはデフォルトでなくなる) に設定されているようにしてください。

メッセージストアの保守手順を実行する

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

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

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

• 「制限容量を監視するには」

• 「ディスク容量を監視するには」

• 「stored ユーティリティーを使用する」

• 「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」

メッセージストアへの物理ディスクの追加

Messaging Server メッセージストアには、特定の Messaging Server インスタンス用のユーザーメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。

システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。Messaging Server では、必要に応じてストアを追加できます。ストアを追加するための 1 つの方法は、ストレージ機器を使用することです。Messaging Server で Network Appliance ストレージ機器を設定する方法については、『』を参照してください。

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

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

mboxutil ユーティリティー

メールボックスの一般的な保守タスクを実行する場合は、mboxutil コマンドを使用します。mboxutil で実行できるタスクは次のとおりです。

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

• 孤立メールボックスおよび非アクティブメールボックスの一覧表示と削除

• メールボックスの作成

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

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

• 孤立したメールボックスおよび非アクティブのメールボックスの削除

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

mboxutil プロセスを実行途中で強制終了しないでください。SIGKILL (kill -9) で強制終了すると、各サーバーを再起動し、回復処理を行わなければならないことがあります。

表 18–11 に、mboxutil コマンドの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

mboxutil コマンドで POSIX 正規表現を使用できます。

メールボックスのネーミングルール

メールボックス名は、次のフォーマットで指定します。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

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

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

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

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

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

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

孤立アカウント (対応するエントリが LDAP にないメールボックス) を検索するには、次のコマンドを使用します。

mboxutil -o

コマンド出力が次のように続きます。

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドで作成したファイルは、孤立メールボックスを削除するスクリプトファイルにすることができます。この例では、ファイル名は orphans.cmd です。

mboxutil -o -w orphans.cmd

コマンド出力は次のとおりです。

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドを使用して孤立したファイルを削除します。

mboxutil -d -f orphans.cmd

hashdir ユーティリティー

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

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

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

hashdir crowe

readership ユーティリティー

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

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

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

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

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

readership -d 15

制限容量を監視するには

imqutoacheckユーティリティーを使って、制限容量の使用状況と制限を監視します。このユーティリティーは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。制限容量と使用状況に関する数値は、K バイトでレポートされます。また、このユーティリティーでメールボックスのサイズとユーザーに割り当てられた制限容量を比較することもできます。オプションとして、制限容量に対し一定の割合を超えたユーザーに対し、電子メールによる通知を送信することができます。

imquotacheck のいくつかの機能が変更されました。Messaging Server 6.x では、quotacheck ユーティリティーが imquotacheck に替わりました。Messaging Server 5.x では、ユーザーのリストを取得するために quotacheck ユーティリティーを使用すると、quotacheck はローカル mboxlist データベースを検索しました。この機能は、mboxutil ユーティリティーの検索機能と重複します。

Messaging Server 6.x では、この重複機能が imquotacheck ユーティリティーから削除されました。imquotacheck でユーザーの検索を実行する場合、検索はローカルの mboxlist データベースではなく、LDAP ディレクトリに対して行われます。ローカル mboxlist データベースからユーザーのリストを取得するには、mboxutil ユーティリティーを使用します。

制限容量がルールファイルの最小しきい値を超えるすべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck

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

imquotacheck -d siroe.com

デフォルトのルールファイルにしたがって、すべてのユーザーに通知を送信するには、次のように入力します。

imquotacheck -n

指定したルールファイル myrulefile と指定したメールテンプレートファイル mytemplate.file にしたがって、すべてのユーザーに通知を送信するには、次のように入力します (詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imquotacheck」を参照)。

imquotacheck -n -r myrulefile -t mytemplate.file

ルールファイルを無視して、すべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck -i

user1 のフォルダ使用状況別に一覧表示するには (ルールファイルを無視)、次のように入力します。

imquotacheck -u user1 -e

ディスク容量を監視するには

システムがディスク容量やパーティションの使用状況を監視する頻度と、システムが警告を送信する環境条件を指定することができます。詳細については、「ディスク容量を監視する」を参照してください。

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

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

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

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

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

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

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

• 必要に応じた警告の生成。

• 必要に応じたデータベース回復 (「メッセージストアの起動と回復」を参照)。

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

表 18–12 に stored オプションの一部を示します。一般的な使用例についてはこの表に従ってください。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

状態を出力するには、次のように入力します。

stored -t -v

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

configutil -o store.expirestart -v 21

場合によっては、stored ユーティリティーを再起動する必要があります (メールボックスリストのデータベースが破損した場合など)。UNIX 上で stored を再起動するには、コマンド行で次のコマンドを使用します。

msg_svr_base/sbin/stop-msg store
msg_svr_base/sbin/start-msg store

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

同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする

1 つのメッセージが複数の受取人に送信されると、そのメッセージは各受取人のメールボックスに格納されます。一部のメッセージングシステムでは、同じメッセージのそれぞれのコピーを各受取人のメールボックスに格納します。それに対して、Sun Java System Messaging Server では、そのメッセージが格納されているメールボックスの数に関係なく、メッセージのコピーを 1 つだけ保持するよう努めます。このために、そのメッセージが含まれているメールボックス内にそのメッセージへのハードリンクを作成します。

ほかのメッセージングシステムが Sun Java Messaging Server に移行されると、移行プロセスによってメッセージの複数のメッセージコピーが作成されることがあります。メッセージストアが大きい場合、大量のメッセージが不必要に重複することになります。また、IMAP append 操作やほかのソースからなど、通常のサーバー操作で同じメッセージの複数のコピーが蓄積される可能性もあります。

Messaging Server には、余分のメッセージコピーを削除し、それらを 1 つのコピーへのハードリンクに置き換える relinker という新しいコマンドが用意されています。

Relinker の動作方式

再リンク機能は、コマンド行モードでもリアルタイムモードでも実行できます。relinker コマンドを実行すると、メッセージストアのパーティション全体がスキャンされ、MD5 メッセージダイジェストリポジトリがハードリンクとして作成または更新され、余分のメッセージファイルが削除されて、必要なハードリンクが作成されます。

ダイジェストリポジトリは、メッセージストアに格納されているメッセージへのハードリンクから構成されます。このリポジトリは、ディレクトリ階層 partition_path/=md5 に格納されます。このディレクトリは、ユーザーメールボックスの階層 partition_path /=user に対応しています (図 18–1 を参照)。ダイジェストリポジトリのメッセージは、その MD5 ダイジェストによって一意に識別されます。たとえば、fredb/00/1.msg のダイジェストが 4F92E5673E091B43415FFFA05D2E47 である場合、 partition/=user/hashdir/hashdir /=fredb/00/1.msg は partition/=md5/ hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg にリンクされます。別のメールボックスに同じメッセージ (partition_path /=user/hashdir/hashdir/gregk/00/17.msg など) があると、そのメッセージもまた partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg にハードリンクされます。図 18–5 はこのことを示しています。

図 18–5 メッセージストアのダイジェストリポジトリ

このメッセージの場合、リンクカウントは 3 になります。両方のメッセージが fredb および gregk というメールボックスから削除されると、リンクカウントは 1 になり、メッセージを消去できます。

relinker プロセスは、リアルタイムモードで実行しても同じように機能します。詳細については、「リアルタイムモードで relinker を使用する」を参照してください。

コマンド行モードで relinker を使用する

relinker は、メッセージストアのパーティション全体をスキャンし、MD5 メッセージリポジトリをハードリンクとして作成または更新して、余分のメッセージファイルを削除します。relinker がストアパーティションをスキャンし終わると、再リンク前後の一意のメッセージ数とパーティションのサイズに関する統計情報が出力されます。すでにハッシュされているストアを迅速に処理するために、relinker は =md5 にまだ存在しないメッセージのダイジェストだけを計算します。また、ダイジェストリポジトリ全体を消去することもできます (ユーザーメールボックスに影響しない場合)。

コマンドの構文は次のとおりです。

relinker [-p partitionname] [-d]

ここで、partitionname は処理されるパーティション (デフォルト: すべてのパーティション) を示し、-d はダイジェストリポジトリが削除されること示します。出力例を次に示します。

# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

relinker は、特にリポジトリにメッセージがまったく存在しない場合の最初の実行は、時間がかかることがあります。これは、すべてのメッセージのダイジェストを計算しなければならないためです (relinker 条件がすべてのメッセージを含めるように設定されている場合)。relinker 条件の設定については、「relinker を設定する」を参照してください。たとえば、100G バイトのメッセージストアを処理するのに 6 時間を要するとします。ただし、実行時再リンクが有効になっている (「リアルタイムモードで relinker を使用する」を参照) 場合は、relinker コマンドを実行する必要はありません。

relinker コマンド行モードが排他的に使用され、実行時オプションが有効でない場合は、ダイジェストリポジトリ (=md5) を消去する必要があります。そうしないと、ストア (=user) 内に消去されたメッセージがダイジェストリポジトリ内にリンクを持ち続ける (孤立する) ため、それらのディスク領域が解放されません。移行後などにストアの最適化を 1 回だけ行なっている場合は、relinker を一度実行してから、relinker -d でリポジトリ全体を削除できます。移行中に消去を何度も行なった場合は、実行するたびに期限切れや孤立したメッセージがリポジトリから消去されるので、relinker コマンドを繰り返し実行するだけで十分です。

異なるパーティションの各処理と並行して、relinker の複数のインスタンスを実行しておくと安全です (-p オプションを使用)。メッセージは同じパーティション内でのみ再リンクされます。

リアルタイムモードで relinker を使用する

リアルタイムモードで relinker 機能を有効にするには、configutil パラメータの local.store.relinker.enabled を yes に設定します。リアルタイムモードで relinker を使用すると、設定された relinker 条件 (「relinker を設定する」を参照) に一致する、配信された (または復元された、IMAP によって追加された、など) すべてメッセージのダイジェストが計算され、そのダイジェストがリポジトリにすでに存在するかどうかが確認されます。ダイジェストが存在する場合は、メッセージの新しいコピーを作成する代わりに、そのダイジェストへのリンクが宛先メールボックスに作成されます。ダイジェストが存在しない場合は、メッセージが作成され、あとでそのメッセージへのリンクがリポジトリに追加されます。

stored は、各パーティションのダイジェストリポジトリをスキャンし、リンクカウントが 1 か、relinker 条件に一致しないメッセージを消去します。スキャンは、設定可能な期間内に一度に 1 つのディレクトリで実行されます。これは、入出力負荷が均等に分散され、ほかのサーバー操作に著しい影響を及ぼさないようにするためです。デフォルトでは、消去サイクルは 24 時間です。これは、メッセージがストアから削除されるか、設定可能な最長保存期間を過ぎたあとも、24 時間までは存在するということを意味します。このタスクは、relinker のリアルタイムモードが有効になっている場合にのみ使用できます。

relinker を設定する

表 18–13 に、relinker 条件を設定するためのパラメータを示します。

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

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

• システムのクラッシュ

• ハードウェア障害

• 過失によるメッセージまたはメールボックスの削除

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

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

• ユーザーの移行

コマンド行ユーティリティーの imsbackup と imsrestore を使用するか、Legato Networker^TM が採用された統合ソリューションを使用してメッセージストアのバックアップと復元を行うことができます。

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

メッセージストアのバックアップと復元は、すべてのメッセージファイルとディレクトリをバックアップする方法でも行うことができます。詳細については、「メッセージストアの災害時のバックアップと復元」を参照してください。

この節では、次の項目に分けて説明しています。

• 「メールボックスバックアップポリシーの作成」

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

• 「Messaging Server のバックアップと復元のユーティリティー」

• 「部分的な復元に関する考察」

• 「部分的な復元に関する考察」

• 「Legato Networker を使用するには」

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

• 「メッセージストアの災害時のバックアップと復元」

• 「バックアップおよび復元の問題のトラブルシューティング」

• 「メッセージストアの災害時のバックアップと復元」

メールボックスバックアップポリシーの作成

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

• 「ビジネス負荷のピーク」

• 「フルバックアップと増分バックアップ」

• 「同時バックアップと順次バックアップ」

ビジネス負荷のピーク

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

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

増分バックアップ (「増分バックアップ」を参照) とは、ストアをスキャンして変更データを見つけ、変更分だけをバックアップする方法です。フルバックアップとは、メッセージストア全体をバックアップすることです。システムが増分バックアップに対してどのくらいの頻度でフルバックアップを実行するのかを決定する必要があります。増分バックアップを毎日の保守手順の中で実行し、フルバックアップを週に 1 度実行することをお勧めします。

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

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

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

バックアップグループは、正規表現で定義されたユーザーメールボックスの任意の集まりです。ユーザーメールボックスをバックアップグループに組織化することで、より柔軟なバックアップ管理を定義することができます。

たとえば、3 つのバックアップグループを作成し、第 1 のグループには A 〜 L で始まるユーザー ID を、第 2 のグループには M 〜 Z で始まるユーザー ID のユーザーを、第 3 のグループには ID が数字で始まるユーザーを含めます。管理者はこれらのバックアップグループを使用してメールボックスを同時にバックアップできます。または、ある日に一部のグループのみバックアップし、別の日にほかのグループをバックアップすることもできます。

バックアップグループについて注意すべき事項がいくつかあります。

1. バックアップグループはメールユーザーの任意の「仮想」グループです。これらは見かけとは異なり、メッセージストアディレクトリに正確にはマッピングされません (図 18–1)。

2. バックアップグループは、UNIX 正規表現を使用して管理者によって定義されます。

3. 正規表現は、設定ファイル msg_svr_base/config/backup-groups.conf で定義されています。

4. バックアップグループが imsbackup および imsrestore で参照された場合、次のパス形式が使用されます。/partition_name/backup_group

backup-groups.conf の形式は次のとおりです。

group_name=definition
group_name=definition
.
.
.

上記の例を使用して、次の 3 つの定義によるバックアップグループを作成するとします。

groupA=[a-l].*
groupB=[m,-z].*
groupC=[0-9].*

これで imsbackup および imsrestore をいくつかのレベルでスコープすることができます。次のバックアップコマンドを使用してメッセージストア全体をバックアップおよび復元することができます。

imsbackup -f device /

groupA の全ユーザー全メールボックスをバックアップするには、次のコマンドを使用します。

imsbackup -f device /partition/groupA

デフォルトのパーティションは primary です。

事前定義のバックアップグループ

Messaging Server には backup-groups 設定ファイルを作成しなくても使用することができる、事前定義のバックアップグループが含まれています。これは user という名前のグループで、ここにはすべてのユーザーが含まれています。たとえば、次のコマンドで primary パーティションのすべてのユーザーがバックアップされます。

imsbackup -f backupfile /primary/user

Messaging Server のバックアップと復元のユーティリティー

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

imsbackup ユーティリティー

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

次の例では、メッセージストア全体を /dev/rmt/0 にバックアップします。

imsbackup -f /dev/rmt/0 /

次の例では、ユーザー ID joe のメールボックスが/dev/rmt/0 にバックアップされます。

imsbackup -f /dev/rmt/0 /primary/user/joe
            

次の例では、バックアップグループ groupA に定義された全ユーザーの全メールボックスが backupfile にバックアップされます (「バックアップグループを作成するには」を参照)。

imsbackup -f- /primary/groupA > backupfile
            

増分バックアップ

次の例は、2004 年 5 月 1 日の午後 1 時 10 分から現在までに保存されたメッセージをバックアップします。デフォルトでは、日付に無関係にすべてのメッセージをバックアップします。

imsbackup -d 20040501:13100
               

このコマンドはデフォルトのブロック係数である 20 を使用します。imsbackup コマンドの完全な構文に関する説明は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

imsrestore ユーティリティー

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

imsrestore -f backupfile /primary/user1

imsbackup コマンドの完全な構文に関する説明は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

バックアップ実行時の多数宛メールの除外

バックアップ操作の実行時には、バックアップから除外するメールボックスを指定できます。重要でないメッセージが多数発生する多数宛またはごみのメールボックスを除外して、バックアップセッションを合理化し、操作完了までの時間を短縮し、バックアップデータの格納に必要なディスク容量を最小限にできます。

メールボックスを除外するには、configutil パラメータの local.store.backup.exclude の値を指定します。

1 つのメールボックス、または「%」文字で区切ったメールボックスのリストを指定できます。「%」文字は、メールボックス名には使用できません。たとえば、次の値を指定できます。

Trash

Trash%Bulk Mail%Third Class Mail

最初の例では、フォルダ Trash が除外されます。2 番目の例では、フォルダ Trash、Bulk Mail、および Third Class Mail が除外されます。

バックアップユーティリティーは、local.store.backup.exclude パラメータに指定されたフォルダ以外のユーザーメールボックスのすべてのフォルダをバックアップします。

この機能は、Messaging Server バックアップユーティリティー、Legato Networker、およびサードパーティー製のバックアップソフトウェアと使用できます。

local.store.backup.exclude の設定を無効にし、バックアップ操作時に完全な論理名を指定して除外したメールボックスをバックアップできます。ごみ箱フォルダが除外されたとします。たとえば、次のように指定することにより、引き続きごみ箱をバックアップできます。

/primary/user/user1/trash

ただし、次のように指定すると、ごみ箱フォルダは除外されます。

/primary/user/user1

the Trash folder is excluded.

部分的な復元に関する考察

部分的な復元は、メッセージストアの一部を復元するときにのみ行われます。完全な復元は、メッセージストア全体を復元するときに行われます。メッセージストアでは単一コピーによるメッセージシステムが使用されています。つまり、メッセージの 1 つのコピーのみが 1 つのファイルとしてストアに保存されます。コピーされたメッセージのほかのインスタンス (メッセージが複数のメールボックスに送信される場合など) は、コピーへのリンクとして保存されます。このため、メッセージを復元する場合には注意が必要です。次に例を示します。

• 完全な復元: 完全な復元では、リンクの付いたメッセージは、依然としてリンク先のメッセージファイルと同じ 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 オプションは必要に応じて各メッセージを複数回バックアップします。

   ドライブやテープなど、バックアップデバイスが検索可能である場合、imsrestore は A/INBOX/1 が格納されている位置を検索し、B/INBOX/1 として復元します。UNIX パイプなど、バックアップデバイスが検索不能である場合、imsrestore はオブジェクト ID とリンクされているオブジェクトの ID をファイルに記録します。管理者は -r オプションを使用して imsrestore を再び呼び出し、欠落しているメッセージ参照を復元する必要があります。

   ---

増分バックアップされたメールボックスからのメッセージを復元するには

増分バックアップされたメールボックスからメッセージを復元する際に、そのメールボックスがメッセージを復元するサーバーに存在する場合は、imesrestore を実行するだけでメッセージを復元できます。ただし、増分バックアップされたメールボックスからメッセージを復元する際に、そのメールボックスがすでに存在しない場合は、別の復元手順に従う必要があります。

メッセージストアサーバーに存在しないメールボックスを復元するには、次の手順のいずれかを使用します。

• 復元操作時に、ユーザーへのメッセージの配信を停止します。このためには、LDAP 属性の mailDeliveryOption に hold を設定します。

• mboxutil -c コマンドでメールボックスを作成してから、imesrestore を使用します。

増分バックアップを復元するためにこれらの手順に従う必要がある理由は、次のとおりです。メールボックスが削除または移行された場合、imsrestore ユーティリティーはバックアップアーカイブに保存されたメールボックスの一意の ID 有効期間およびメッセージの一意の ID (UID) を使用してメールボックスを再作成します。

以前は、imsrestore は削除または移行されたメールボックスを再作成するときに、新しい UID 有効期間をメールボックスに、新しい UID をメッセージに割り当てました。その場合、キャッシュにメッセージが入っているクライアントはメールボックスの UID 有効期間およびメッセージの UID の同期をとりなおす必要がありました。クライアントは、新しいデータを再びダウンロードする必要があり、その結果、サーバーの作業負荷が増大しました。

新しい imsrestore の処理では、クライアントのキャッシュの同期は維持され、復元処理は透過的に実行され、パフォーマンスに悪影響を及ぼすことはありません。

メールボックスが存在する場合、imsrestore は新しい UID を復元されたメッセージに割り当てるので、新しい UID は既存のメッセージにすでに割り当てられている UID と矛盾しません。UID の一貫性を保証するために、復元操作時に imsrestore でメールボックスをロックします。ただし、imsrestore は、新しい UID 値を割り当てる代わりに、バックアップアーカイブからのメールボックスの UID 有効期間とメッセージ UID を使用するようになったため、増分バックアップおよび復元を実行すると UID の一貫性が保てなくなる場合があります。

imsbackup ユーティリティーの -d 日付オプションを使用して増分バックアップを実行する場合、復元操作を完了するために imsrestore を複数回呼び出す必要がある場合があります。増分バックアップを実行する場合、最後のフルバックアップとその後のすべての増分バックアップを復元する必要があります。

復元操作間に新しいメッセージをメールボックスに配信できますが、この場合、メッセージの UID に矛盾が生じることがあります。UID の矛盾が生じないようにするには、前述の手順のいずれかを実行する必要があります。

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 を使用してデータをバックアップするには

手順

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

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

   /usr/bin/nsr

   これは、古いバージョンの Networker (5.x) を使用している場合にのみ必須です。Networker 6.0 以上では、nsrfile は自動的に /usr/bin/nsr の下にインストールされます。

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

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

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

      mkbackupdir.sh によって作成されたディレクトリ構造を確認してください。その構造は、表 18–4 に示されているようになっている必要があります。

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

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

   ---

   注 –

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

   mkbackupdir.sh -p /backup

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

   ---

   表 18–6 には、バックアップグループのディレクトリ構造の例が示されています。

   /backup/primary/groupA/amy /bob /carly /groupB/mary /nancy /zelda /groupC/123go /1bill /354hut

   次の例に、res ファイルのサンプルとして、/nsr/res ディレクトリにある IMS.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 インタフェースを実行します。

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

   1. nwadmin を実行します。

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

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

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

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

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

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

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

      詳細については、「Legato Networker を使用してデータをバックアップするには」を参照してください。

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

   例: Networker でバックアップクライアントを作成する

   Networker でバックアップクライアントを作成するには、nwadmin から、Client | Client Setup | Create の順に選択します。

   Name: siroe Group: IMS Savesets:/backup/primary/groupA /backup/secondary/groupB /backup/tertiary/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 以外) を使用するには

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

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

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

手順

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

   ---

   注 –

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

   ---

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

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

   複数の imsbackup プロセスを同時に実行することができます。次に例を示します。

   # imsbackup -f- /primary/groupA > /bkdata/groupA & # imsbackup -f- /primary/groupB > /bkdata/groupB & . . .

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

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

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

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

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

バックアップおよび復元の問題のトラブルシューティング

この節では、一般的なバックアップと復元の問題、およびその問題の解決策について説明します。

• 問題: imsrestore または imsasm を使用してフォルダまたは INBOX を復元すると、そのフォルダ内のすべてのメッセージが現在のフォルダに追加されます。その結果、そのフォルダにメッセージの複数のコピーが作成されます。

  解決策: imsasm スクリプトで、imsrestore の -i フラグが設定されていないことを確認してください。

• 問題: メールフォルダに追加された新しいメッセージのみの増分バックアップを行おうとしたが、フォルダ全体がバックアップされてしまいます。新しいメッセージのみをバックアップする方法はありますか。

  解決策: imsbackup の -d datetime フラグを設定します。このようにすると、指定された日時から現在までに保存されたメッセージがバックアップされます。デフォルトでは、日付に無関係にすべてのメッセージがバックアップされます。

メッセージストアの災害時のバックアップと復元

災害とは、メッセージストア全体に壊滅的な障害の発生を意味します。つまり、メッセージストアサーバー上のすべてのデータが失われた状態のことです。メッセージストアの災害時の完全な復元では、失われた次のデータが復元されます。

• すべてのメッセージストアデータ。このデータは、「メッセージストアのバックアップと復元を行う」に説明されている手順を使ってバックアップできます。ファイルシステムバックアップ方法を使用する場合は、次のデータを必ずバックアップするようにします。

  • すべてのメッセージストアパーティション

  • msg_svr_base/data/store/mboxlist にあるメッセージストアデータベースファイル

  msg_svr_base/data/store/dbdata/snapshots にあるメッセージストアデータベースのスナップショット。メッセージストアデータベースのスナップショットファイルの場所はパラメータ local.store.snapshotpath で設定できます。ファイルシステムバックアップを使用する場合は、これらのデータが復元されたあとで reconstruct -m を実行します。

• すべての設定データ。次のデータがあります。

  • msg_svr_base/data/config にあるローカル設定ファイル

  • LDAP Directory Server にある Messaging Server の設定データ

ユーザーアクセスを監視する

Messaging Server では、imsconnutil コマンドが提供されます。このコマンドを使用して、ユーザーの IMAP、POP、および HTTP を介したメッセージストアアクセスを監視できます。また、ユーザーの最新のログインおよびログアウトを確認できます。このコマンドは、メッセージストア単位で機能するものであり、メッセージストア全体に対しては機能しません。

適用される法律または条例に違反する使用、または顧客自身のポリシーまたは契約に違反する使用の場合、この機能またはその他の Messaging Server の機能を使ってユーザーのメールを監視、読み取り、もしくはアクセスすると、不利益を引き起こす可能性があります。

このコマンドを使用するにはシステムユーザー (デフォルト: inetuser) によるルートアクセスが必要です。また、設定変数の local.imap.enableuserlist、local.http.enableuserlist、local.enablelastaccess を 1 に設定する必要があります。

IMAP または Web メールクライアントを介して現在ログインしているユーザーを一覧表示するには、次のコマンドを使用します。

# imsconnutil -c

メッセージストアのユーザーごとの最新の IMAP、POP、または Messenger Express によるアクセス (ログインおよびログアウト) を一覧表示するには、次のコマンドを使用します。

# imsconnutil -a

次のコマンドは 2 つの処理を実行します。1) 指定したユーザーが現在 IMAP、Messenger Express、または mshttp を介して接続しているクライアントからログインしているかどうか判別する (一般に、POP ユーザーの場合は常時接続でない場合があるので、この処理は POP には機能しないことに注意)。2) ユーザーが最後にログインおよびログアウトした時刻を一覧表示する。

# imsconnutil -c -a -u user_ID

ユーザーの一覧は、次のコマンドを使用して 1 行につき 1 ユーザーずつファイルで入力できます。

# imsconnutil -c -a -f filename

-s フラグを使用して、特定のサービス (imap または http) を指定することもできます。たとえば、特定のユーザー ID が IMAP にログインしたかどうかを一覧表示するには、次のコマンドを使用します。

# imsconnutil -c -s imap -u user_ID

imsconnutil の構文の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsconnutil」を参照してください。

次に出力例を示します。

$ ./imsconnutil -a -u soroork

UID     IMAP last access    HTTP last access    POP last access
=========================================================================
ed   08/Jul/2003:10:49:05   10/Jul/2003:14:55:52  ---NOT-RECORDED---

$ ./imsconnutil -c

IMAP
UID    TIME                AUTH            TO                 FROM
===========================================================================
ed   17/Jun/2003:11:24:03  plain     172.58.73.45:193   129.157.12.73:2631
bil  17/Jun/2003:04:28:43  plain     172.58.73.45:193   129.158.16.34:2340
mia  17/Jun/2003:09:36:54  plain     172.58.73.45:193   192.18.184.103:3744
jay  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.159.18.123:3687
pau  17/Jun/2003:12:23:28  plaintext 172.58.73.45:193   192.18.194.83:2943
ton  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.152.18.123:3688
ani  17/Jun/2003:12:26:40  plaintext 172.58.73.45:193   192.18.164.17:1767
ani  17/Jun/2003:12:25:17  plaintext 172.58.73.45:193   129.150.17.34:3117
jac  17/Jun/2003:12:26:32  plaintext 172.58.73.45:193   129.150.17.34:3119
ton  17/Jun/2003:12:25:32  plaintext 172.58.73.45:193   192.18.148.17:1764
===========================================================================
10 users were logged in to imap.
Feature is not enabled for http.
---------------------------------------------------------------------------

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

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

この節を読む前に、この章のこれまでの部分と、『Sun Java System Messaging Server Administration Reference』のコマンド行ユーティリティーおよび configutil に関する章を再度読まれますよう、強くお勧めします。この節では、以下の項目について説明します。

• 「標準的なメッセージストアの監視手順」

• 「一般的な問題と解決策」

• 「メッセージストアの起動と回復」

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

標準的なメッセージストアの監視手順

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

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

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

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

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

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

ログファイルのチェック

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

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

テレメトリを使用してユーザーの IMAP/POP セッションをチェックする

Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP、POP、または Web メールのセッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。

セッションの記録をとるには、次のディレクトリを作成します。

msg_svr_base/data/telemetry/ pop_or_imap/userid

Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

stored プロセスのチェック

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

• stored プロセスが実行中かどうかをチェックします。stored -t -v を実行します。

• store_root/mboxlist 内に作成されたログファイルをチェックします。

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

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

stored プロセスの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の 「stored ユーティリティーを使用する」の章を参照してください。

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

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

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

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

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

コアファイルのチェック

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

メッセージストアの起動と回復

メッセージストアのデータはメッセージ、インデックスデータ、およびメッセージストアデータベースで構成されています。このデータは堅固ですが、ごくまれにメッセージストアのデータに関する問題がシステムに存在することがあります。このような問題はデフォルトのログファイルに示され、ほとんどの場合は透過的に修正されます。ただし、reconstruct ユーティリティーを実行する必要があることを示すエラーメッセージがログファイルに表示される場合がまれにあります。また、最終手段として、メッセージは 「メッセージストアのバックアップと復元を行う」で説明されているバックアップと復元のプロセスによって保護されます。この節では、stored の自動起動および回復プロセスについて説明します。

メッセージストアでは、以前は管理者の職責であった多くの回復処理が自動化されています。これらの処理はメッセージストアデーモンの stored によって起動時に実行され、必要に応じてデータベーススナップショットおよび自動高速復元が含まれます。stored によってメッセージストアのデータベースが徹底的にチェックされ、問題が検出された場合は自動的に修復されます。

また、stored は、デフォルトのログにステータスメッセージを出力することで、データベースのステータスの総合的な分析を提供し、メッセージストアに行われた修復およびメッセージストアを回復するために行われた自動試行について報告します。

自動起動と自動回復 - 動作方式

stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。

データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。

メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。

データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細については、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。

以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。

ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログを監視することは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。

ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。

reconstruct -m が必要であることを示すエラーメッセージ

ここでは、reconstruct -m の実行が必要なエラーメッセージのタイプについて説明します。

エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。次に例を示します。

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。次に例を示します。

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

データベーススナップショット

スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。

メッセージストアのデータベーススナップショット - 動作方式

データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース / 削除済みコピーが 1 つです。データベース / 削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。

現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。

データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。

メッセージストアのデータベーススナップショットの間隔と場所を指定するには

データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。

stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 18–15 に、これらの configutil パラメータを示します。

スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。

スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。

stored はデータベースの監視を実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。

つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。

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

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

reconstruct ユーティリティーは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティーを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。詳細については、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。

表 18–16 に、reconstruct オプションの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「reconstruct」を参照してください。

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

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

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

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

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

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

整合性チェックを行い、プライマリパーティションを修復するには次のように入力します。

reconstruct -p primary -m

-p および -m フラグを指定して reconstruct を実行しても、lright.db は修復されません。これは lright.db を修復すると、メッセージストア内のすべてのユーザーに対して ACL のスキャンを実行する必要があるためです。これをすべてのパーティションに対して実行するのは効率的でありません。lright.db を修復するには、reconstruct -l を実行します。

整合性チェックを行い、john という名前のユーザーのメールボックスを修復するには次のように入力します。

reconstruct -p primary -u john -m

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

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

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

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

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

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

  • store_root/mboxlist 内のすべてのファイルを削除します。

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

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

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 アクティビティーが実行されていない場合、大幅に減少します。

一般的な問題と解決策

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

• 「Messenger Express または Communications Express がメールページを読み込まない」

• 「ワイルドカードパターンを使用したコマンドが機能しない」

• 「不明または無効なパーティション」

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

Messenger Express または Communications Express がメールページを読み込まない

ユーザーが Messenger Express ページまたは Communications Express メールページを読み込めない場合は、圧縮後にデータが破損している可能性があります。これは、古いプロキシサーバーがシステムに配備されている場合に発生することがあります。この問題を解決するには、local.service.http.gzip.static および local.service.http.gzip.dynamic を 0 に設定して、データ圧縮を無効にしてください。これで問題が解決したら、プロキシサーバーを更新することができます。

ワイルドカードパターンを使用したコマンドが機能しない

UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。

次に例を示します。

mboxutil -l -p user/usr44*

これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。

mboxutil -l -p "user/usr44*"

ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。

不明または無効なパーティション

ユーザーのメールボックスが作成したばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、Messenger Express で「パーティションが不明または無効です」というメッセージが表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。

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

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

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

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

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

   reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細については、「hashdir ユーティリティー」および、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の Messaging Server コマンド行ユーティリティーの章の hashdir ユーティリティーを参照してください。

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

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

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

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

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

   ---

   注意 –

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

   ---

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

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

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

store デーモンが起動しない

stored が起動せずに次のエラーメッセージが表示される場合があります。

# msg_svr_base/sbin/start-msg

msg_svr_base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

上記のメッセージは、local.servergid に設定された UNIX グループが見つからないことを示しています。Stored などは、gid をグループに設定する必要があります。local.servergid によって定義されたグループが誤って削除されることがあります。この場合は、削除されたグループを作成し、inetuser をグループに追加し、instance_root の所有権とそのファイルを inetuser とグループに変更します。

新しいシステムへのメールボックスの移行または移動

あるメッセージングサーバーシステムから別のメッセージングサーバーシステムに、既存のメールボックスを移動しなければならない場合があります。これは通常、次のような状況で発生します。

• Sun 以外のメッセージングサーバーから Sun Java System Messaging Server に移行する

• ある物理サーバーから別の物理サーバーにメールボックスを移動する

Messaging Server では、別のシステムにメールボックスを移動するための方法がいくつか用意されています。各方法には、利点と欠点があります。これらの方法については、「ユーザーメールボックスの移行」を参照してください。