A Zimbra server that is running short on disk space can make log cleanup feel urgent, but /opt/zimbra/log/audit.log is not just disposable diagnostic output. Zimbra documents it as the audit trail for authentication events and administrative activity. That means the best cleanup method depends on whether you need immediate space, historical evidence, or a longer-term retention fix.
The safest default is to leave the active audit.log file alone and deal with older rotated copies first. If you are subject to an internal retention policy, legal hold, or compliance requirement, archive those files to another filesystem before deleting anything. If the active file itself has become abnormally large, you can clear it, but that should be treated as an emergency measure because it removes current audit history and can introduce a small race window if the server keeps writing while you copy it.
Zimbra's own logging documentation places audit.log under /opt/zimbra/log and describes Log4j as the component responsible for rotating files such as audit.log and mailbox.log. Other Zimbra logs may instead use the operating system's logrotate configuration, so do not assume every file in the directory follows the same mechanism. See the official Zimbra log-file reference and Zimbra log rotation notes.
| Approach | Disk space recovered | Audit history retained | Operational risk | Best fit |
|---|---|---|---|---|
| Delete old rotated audit logs | High when many generations exist | No, unless backed up first | Low if you verify filenames first | Most routine cleanup jobs |
| Compress old rotated logs | Moderate to high | Yes | Low | Systems that still need local history |
| Move old logs to separate storage | High on the Zimbra filesystem | Yes | Low to moderate | Compliance or long retention |
| Truncate the active audit.log | Immediate, potentially large | No unless copied first | Higher | Emergency space recovery only |
| Change pruning or retention behavior | Prevents recurrence | Depends on policy | Moderate if misconfigured | Recurring growth problems |
First confirm that audit logs are actually responsible for the pressure. Run these as root:
df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*The first command tells you how full the filesystem containing /opt is. The second shows the overall Zimbra log footprint. The third exposes the active audit file and any rotated generations. If the audit files are only a small fraction of the filesystem, clearing them may not solve the real problem; mailbox stores, backups, database files, or another log family may be consuming the space instead.
Also record your installed version before changing behavior:
su - zimbra -c 'zmcontrol -v'これは重要な点です。なぜなら、Zimbraのドキュメントは複数の製品世代にまたがっており、Log4jの構文、生成される設定、およびプルーニングジョブは異なる場合があるからです。古いWikiの例から保持値をコピーして、それが現在のデフォルト値であると決めつけないでください。
削除対象を決定する前に、ファイルシステムの使用状況、Zimbraログの総サイズ、および個々の監査ログの生成状況を確認してください。
Zimbra では、関連する 2 つのメカニズムについて説明しています。1 つは、ファイル ( ) を含むファイル用の Log4j audit.log、もう 1 つは他のいくつかの Zimbra ログ用のオペレーティングシステムの機能logrotateです。また、Zimbra 独自の crontab にログメンテナンス タスクが含まれている場合があることも記載されています。推測するのではなく、ライブ構成を確認してください。
su - zimbra
crontab -l
exit
grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.inこれらのファイルのいずれかに、ご使用のリリースで想定される設定が含まれていない場合は、古い例を無理やり適用するのではなく、周辺のログ設定を確認してください。生成されたファイルは、サービスの再起動後や設定の再生成後に上書きされる場合もあります。Zimbraのログに関する注記では、生成されたプロパティファイルへの一時的な編集と、対応する.inテンプレートで行われた永続的な変更を明確に区別しています。
監査ログの量が予想以上に多いサーバーについては、追加のログ記録が意図的に有効になっていないか確認してください。Zimbra 10.0.6 リリースノートには、zimbra_additional_loggingローカル構成属性に関する説明があり、これを使用すると、認証失敗イベントやその他の有用な認証イベントをログに追加できますaudit.log。容量を節約するためだけに、有用なセキュリティログを無効にしないでください。ログの量が正当な場合は、通常、保持、圧縮、または集中ログストレージの方が適切な解決策です。Zimbra 10.0.6 の公式リリースノートを参照してください。
保持期間やローテーションの動作を変更する前に、サーバーの実際のcrontabとLog4jの設定を確認してください。
ほとんどの管理者にとって、古いローテーション済み監査ログは最初に確認すべき対象です。find削除する前に、レポート専用モードで使用してください。以下の例は、30日以上前のローテーション済み監査ログの一覧です。30日はあくまでも目安であり、Zimbraが規定する保持期間ではありません。
find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -printそれらのファイルが不要になった場合は、レビュー済みのローテーション済みファイルのみを削除してください。それらを保持する必要がある場合は、まず別のファイルシステムにコピーまたはアーカイブしてください。Zimbraパーティションがほぼ満杯の場合は、別のマウントを使用することが重要です。同じ満杯のファイルシステム上に圧縮アーカイブを作成すると、一時的にさらに多くの容量を消費する可能性があるためです。
mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps /opt/zimbra/log/audit.log.OLD_GENERATION /mnt/backup/zimbra-audit-logs/確認したファイル名に対して、この手順を繰り返してください。ソースを削除する前にバックアップを確認してください。 のような広範囲なパターンは避けてください。rm -f /opt/zimbra/log/audit.log*このパターンはアクティブなファイルにも一致します。
古いログをローカルに保持しつつ、ファイルサイズを削減したい場合は、ローテーションされたファイルのみを圧縮してください。
gzip /opt/zimbra/log/audit.log.OLD_GENERATION圧縮が有効かどうかは、現在のログローテーション設定によって異なります。一部のデプロイメントでは、メンテナンスの一環として既に過去のログが圧縮されている場合があります。新たなレイヤーを追加する前に、実際にどのような圧縮が行われているのかを確認してください。
Zimbraの履歴ログに関するガイダンスでは、監査ログには機密データが含まれる可能性があると警告しています。アーカイブは、ライブログと同じアクセス制御で扱ってください。Zimbraの公式ログガイダンスを参照してください。
まず古いローテーション済みファイルを一覧表示し、必要な履歴を別のストレージにコピーしてから、レビュー済みの世代を削除します。
ローテーションされたファイルが問題ではなく、アクティブなファイルaudit.log自体が重要な領域を消費している場合は、切り捨てによってすぐに領域を解放できます。ただし、切り捨ては最も明確なトレードオフを伴うオプションでもあります。つまり、ファイルが切り捨てられると、現在の監査履歴は削除されます。
より安全な緊急時の手順としては、mailboxdを一時的に停止し、アクティブなファイルを別のファイルシステムにコピーし、元のファイルをその場で切り詰めて所有権とアクセス許可を保持し、mailboxdを再度起動することです。
su - zimbra -c 'zmmailboxdctl stop'
cp --preserve=all /opt/zimbra/log/audit.log /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)
truncate -s 0 /opt/zimbra/log/audit.log
su - zimbra -c 'zmmailboxdctl start'この方法はメールボックスサービスのダウンタイムを引き起こすため、すべての環境に適しているわけではありません。mailboxdを停止せずにライブファイルをコピーするとダウンタイムは回避できますが、コピー後かつ切り捨て前に書き込まれたエントリが失われる可能性がある競合状態が発生します。ディスク負荷がそれほど高くない場合は、ローテーションされたファイルをクリーンアップし、保持期間を修正する方が望ましいです。
アクティブログを最初の対応手段として使用しないでくださいrm。ディレクトリエントリが削除された後でも、プロセスは開いているファイルディスクリプタを通して書き込みを続ける可能性があるため、期待されるディスク容量がすぐに解放されない場合があります。緊急のクリアが本当に必要な場合は、既存のinodeを切り詰める方が予測しやすいです。
クリーンアップ後、エラーがないことを前提とするのではなく、結果を確認してください。
df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'良好な結果には、次の3つの兆候があります。目的のファイルシステムの空き容量が増加しているaudit.logこと、新しいイベントが引き続き発生し、関連するZimbraサービスが引き続き実行されていること。空き容量が急激に減少しているdfにもかかわらず、ファイルシステムが満杯であると報告される場合はdu、さらにデータを削除する前に、実行中のプロセスによってまだ開かれたままになっている削除済みファイルがないか確認してください。
クリーンアップ後、回復した容量、最近の監査活動、およびサービスの状態を確認します。
保持または削除プロセスを調整する際は、必要な履歴期間を文書化してからにしてください。既存のZimbra crontabとLog4jの設定を確認し、バージョンに応じた最小限の変更のみを行ってください。元の設定のコピーを保持し、次回のローテーションで期待どおりのファイルが作成されることをテストしてください。
単に削除するよりも、原因を調査する方が迅速です。ログイン試行の繰り返し、クライアントの設定ミス、監視プローブ、または意図的に拡張された認証ログなどは、すべて監査ログの量を増加させる可能性があります。監査ログはaudit.logセキュリティ調査に役立つため、証拠を隠蔽するよりも、根本的なノイズを減らす方が通常は良いでしょう。
ログを保持用に設計されたストレージに移動または送信します。集中ログ、オブジェクトストレージ、または専用のログファイルシステムにより、コンプライアンス履歴がメールプラットフォームに必要な容量から分離されます。Zimbra のログファイルドキュメントでは、集中ログの候補について明示的に説明していますaudit.log。
audit.log*。/etc/logrotate.d/zimbra。Zimbra は Log4j をローテーション メカニズムとして文書化していますaudit.log。古いローテーション済みログが主な消費要因である場合、望ましい結果は単純です。アクティブな監査ログはそのまま維持され、履歴ファイルはポリシーに従ってアーカイブまたは削除され、ファイルシステムは正常に動作するのに十分な空き容量を確保します。すぐに再び空き容量が減り始めた場合は、クリーンアップを解決策とみなすのをやめ、書き込みレート、認証アクティビティ、ローテーション構成、およびその他のログ設定を調査してください。一度限りのクリーンアップか、繰り返し発生する増加かというこの違いこそが、実際に問題が解決したかどうかを判断する基準となります。
Learn how to identify, archive, compress, and remove old Zimbra audit logs, when to avoid truncating audit.log, and how to verify that disk space and logging recover correctly.
Kopano dagentストレージサーバーへの接続障害のトラブルシューティングを行うには、サーバーの状態、server_socket、Unixソケットの権限、リモートリスナー、および制御された配信テストを確認します。
トランザクションロックを特定し、ロックストレージをRedisに移動し、クラスタをチェックし、安全に再テストすることで、ownCloudのファイルロックタイムアウトエラーを修正します。
Troubleshoot Matrix Synapse OOM problems during /sync by checking memory pressure, tuning caches carefully, isolating initial sync, and monitoring workers.
マスターキーモード、APCu、Redis、またはValkeyによるロック、そしてパフォーマンスへの影響を最小限に抑える段階的な導入により、Nextcloudのサーバー側暗号化を安全に有効化します。
MatrixのM_FORBIDDENルーム管理者エラーを修正するには、メンバーシップ、パワーレベル、ターゲットユーザーのランク、およびmake_room_adminなどのSynapseサーバー管理者リカバリオプションを確認してください。
Zimbraウェブメールでサインインはできるものの、空白ページが表示される場合は、ブラウザの問題とメールボックスまたはプロキシの障害を切り分け、適切なログを確認して、安全な復旧を検証してください。
Jitsi Meet サービスが再起動で停止している原因を特定し、致命的なログを読み、パスワードの欠落、マウントエラー、互換性のない設定など、Docker でよく発生する原因を修正します。
Jitsi Meetのアカウント認証がルームパスワードとどのように異なるか、従来のセキュアドメイン方式の設定方法、およびアクセス制御の安全な検証方法について学びましょう。
ownCloudのバックグラウンドジョブが実行されない場合は、Cronモードに切り替えて、systemdタイマーを使用してocc system:cronをスケジュールし、タイマーとログを確認してください。
