ページの先頭です。
ここから本文です。

技術情報

【GUARDIAN】 GUARDIANWALL V6.0 または V7.0 におけるメールアーカイブの消失に関する注意事項

GUARDIANWALL V6.0 または V7.0 において、 ある一日分のメールアーカイブの消失する可能性があることに関する注意事項に関して、 以下の内容をご確認いただけますようお願いいたします。
※GUARDIANWALL V7.1 以降のバージョンでは該当いたしません。

1  発生条件

以下(1)、(2)の条件を両方満たす場合に、本問題が発生する可能性があります。

(1) 管理サーバと検査サーバが別々のハードウェアで構成されている
(2) 検査サーバ側でメールアーカイブのローテーションが始まっている
     (既に検査サーバ側の「メール保存ディレクトリ」の使用率が100%になっている)

※上記(1)、(2)を満たしても、必ず発生するわけではありません。 条件を満たした場合に、極めて稀に発生する場合があります (論理上は、 検査サーバでの古いデータ削除が1日1回発生していると仮定すると1日ごとにおおよそ1000万分の1の確率で発生すると予測されます) 。


2  発生事象

GUARDIANWALL のメールアーカイブ保存領域が不足した場合のローテーション仕様を説明いたします。
検査サーバの「メール保存ディレクトリ」のディスク使用率が100%になった場合、 最も古いメールアーカイブファイル(1日分1ファイル)をサイズ 0 バイトに切り詰める処理 (truncate) を行い、その後削除処理 (unlink) を行います。

この truncate から unlink までのごく短時間内に、管理サーバからログ収集処理が実行されると、 削除完了前の 0 バイトのメールアーカイブファイルが管理サーバへ収集されてしまい(※)、 過去に管理サーバに置かれた同名のメールアーカイブファイルが 0 バイトのファイルで上書きされます。

※ログ収集処理は、検査サーバ上のメールアーカイブファイルの最終更新時刻が、 管理サーバ上の同ファイルよりも新しい場合にそのファイルを収集します。 この場合、truncate により最終更新時刻が更新されるため収集対象になります。


3  発生時の影響

0 バイトのメールアーカイブファイルで上書きされた日のメール本文が管理画面から閲覧できません。


4  事象発生の確認方法

本問題がすでに発生しているかどうかは、以下の手順でご確認いただけます。

*メールアーカイブ保存ディレクトリの確認

管理サーバのコンソールにログインし、以下のコマンドを実行します。
「メールアーカイブ保存ディレクトリ」の設定値は、 管理画面の [共通]-[管理サーバー管理]-[基本設定]-[管理サーバーパラメータ] から確認可能です。
# cd <メールアーカイブ保存ディレクトリ>
# ls -al *.mar
※実行結果にサイズ 0 バイトのメールアーカイブ(ファイル名:YYYYMMDD-HOSTID-DEVID.mar)が表示された場合、 本問題がすでに発生しています。

また、テープやディスク(バックアップディレクトリ)にメールアーカイブのバックアップを取得されている場合は、 以下の手順でバックアップ済みのメールアーカイブについても同様の確認が可能です。

*バックアップテープの確認

管理サーバのコンソールにログインし、以下のコマンドを実行します。
Linux版の場合、バックアップデバイスのデフォルト値は /dev/st0 です。 バックアップデバイスを変更されている場合は設定値を管理画面の [共通]-[管理サーバー管理]-[基本設定]-[管理サーバーパラメータ] からご確認ください。
# /opt/Guardian/local/bin/tar tvf <バックアップデバイス> | grep .mar
※実行結果にサイズ 0 バイトのメールアーカイブ(ファイル名:YYYYMMDD-HOSTID-DEVID.mar)が表示された場合、 該当のバックアップデータは消失しています。

*バックアップディレクトリの確認

管理サーバのコンソールにログインし、以下のコマンドを実行します。
「バックアップディレクトリ」の設定値は、管理画面の [共通]-[管理サーバー管理]-[基本設定]-[管理サーバーパラメータ] から確認可能です。
# cd <バックアップディレクトリ>
# find ./ -name wall.tar.gz | xargs -n1 /opt/Guardian/local/bin/tar ztvf | grep .mar
※実行結果にサイズ 0 バイトのメールアーカイブ(ファイル名:YYYYMMDD-HOSTID-DEVID.mar)が表示された場合、 該当のバックアップデータは消失しています。


5  暫定回避策

本不具合を暫定的に回避する方法としまして、 古いメールアーカイブのローテーション削除がまだ一度も実行されていない場合は、 古いメールアーカイブ削除処理が当面行われない程度のディスクを検査サーバに追加する方法がございます。
(管理画面の [共通]-[検査サーバー管理]-[個別設定]-[設定]-[データ保存] から、 検査サーバの「メール保存ディレクトリ」の追加設定も必要です)
ディスクを追加した後は、ローテーション削除が実行されるよりも前に、 GUARDIANWALL のバージョンアップを実施いただきますようお願いいたします。

また、仮に本不具合が発生した場合のデータ復旧方法としまして、 検査サーバ上のメールアーカイブがローテーション削除されるよりも前に、 管理サーバ上の同じメールアーカイブのバックアップを取得されている場合は、 リストアし閲覧することが可能です。
※「メールアーカイブ保存ディレクトリ」にバックアップしたメールアーカイブを戻す方法はございません。


6  恒久対策

GUARDIANWALL V7.1 以降のバージョンでは本問題が発生しないよう仕様が改善されておりますので、 恐れ入りますが、最新版へのバージョンアップをお願いいたします。
※V6.0 または V7.0 をご利用の場合、これまで発生していなくとも今後発生する可能性がありますので、 バージョンアップを実施いただきますようお願いいたします。

製品名カテゴリ

GUARDIANWALL

対象製品

品名: GUARDIANWALL
リビジョン: V6.0, V7.0
対象OS: Linux
Solaris
  • コンテンツID: 3140100294
  • 公開日: 2011年02月24日
  • 最終更新日:2018年10月12日

アンケート

サポート情報充実のためアンケートにご協力をお願いいたします。



コメント欄:
ここからページ共通メニューです。 ページ共通メニューを読み飛ばす。
ページ共通メニューここまで。