如何安全地清除 Zimbra 稽核日誌以釋放磁碟空間

首先確定你真正需要移除哪些東西。

Zimbra 伺服器磁碟空間不足時，清理日誌會顯得迫在眉睫，但日誌/opt/zimbra/log/audit.log並非只是可隨意丟棄的診斷輸出。 Zimbra 將其記錄為身分驗證事件和管理活動的稽核追蹤。這意味著最佳清理方法取決於您需要立即釋放空間、保留歷史證據，還是需要長期保存的解決方案。

最安全的預設做法是保留audit.log目前活動文件，先處理舊的輪替副本。如果您受內部保留策略、法律保留或合規性要求的約束，請在刪除任何內容之前將這些文件歸檔到另一個文件系統。如果活動文件本身變得異常大，您可以將其清除，但這應視為緊急措施，因為它會刪除當前的審計歷史記錄，並且如果伺服器在您複製文件時仍在寫入，則可能會引入一個短暫的競爭視窗。

Zimbra 本身的日誌文件將audit.logLog4j列為負責輪替日誌檔案（例如`.zbra.log` 和 `.zbra.log.log` /opt/zimbra/log）的元件。其他 Zimbra 日誌可能使用作業系統配置，因此不要假設目錄中的每個檔案都遵循相同的機制。請參閱Zimbra 官方日誌檔案參考和Zimbra 日誌輪替說明。audit.logmailbox.loglogrotate

在採取行動之前，請先比較各種清理方案。

方法	已復原的磁碟空間	保留審計歷史記錄	營運風險	最佳匹配
刪除舊的輪調審計日誌	當存在多個世代時，其地位很高。	不，除非先有備份。	如果先驗證檔案名，則價格較低。	大多數日常清理工作
壓縮舊的輪換日誌	中等至高	是的	低的	仍需本地歷史記錄的系統
將舊日誌移至單獨的儲存位置	Zimbra 檔案系統高層	是的	低至中等	合規或長期保留
截斷活動 audit.log	立即產生，潛在影響巨大	除非先複製，否則不行。	更高	僅限緊急空間恢復
改變剪枝或保留行為	防止復發	取決於政策	如果配置錯誤，則影響中等程度。	反覆出現的生長問題

第一步：在刪除任何內容之前，先評估問題。

首先確認審計日誌確實是造成壓力的原因。運行以下命令root：

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

第一條指令會告訴你包含該檔案的檔案系統已用了多少空間/opt。第二條指令會顯示 Zimbra 日誌的整體佔用情況。第三條指令會顯示目前活動的稽核文件以及任何已輪替的日誌版本。如果審計文件只佔檔案系統的一小部分，那麼清除它們可能無法解決根本問題；郵箱儲存、備份、資料庫檔案或其他日誌類型可能才是真正佔用空間的原因。

在變更行為之前，請記錄您安裝的版本：

su - zimbra -c 'zmcontrol -v'

這一點很重要，因為 Zimbra 文件涵蓋多個產品版本，而 Log4j 的具體語法、產生的配置和清理作業可能有所不同。請勿從舊的 wiki 範例中複製保留值並假定它是您目前的預設值。

終端顯示用於測量 Zimbra 日誌和 audit.log 磁碟使用情況的 df、du 和 ls 命令（清理前）。

在決定刪除哪些內容之前，請檢查檔案系統使用情況、Zimbra 日誌總大小以及各個稽核日誌的產生情況。

步驟 2：檢查此伺服器如何輪換和清理日誌

Zimbra 文件中記錄了兩種相關的機制：Log4j 用於處理包括 `<filename>` 在內的文件audit.log，作業系統則logrotate用於處理其他一些 Zimbra 日誌。文件中也指出，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 官方發行說明。

終端機顯示 Zimbra 使用者 crontab 和 Zimbra Log4j 設定檔中 audit.log 引用的審查

在變更保留或輪調行為之前，請檢查伺服器的實際 crontab 和 Log4j 配置。

步驟 3：優先歸檔或刪除輪調日誌。

對於大多數管理員來說，舊的輪換審計日誌是最佳的首要目標。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 官方日誌記錄指南。

終端機顯示了一個查找命令，該命令列出了較早的已輪換的 Zimbra 審計日誌以及刪除前使用的單獨備份目錄。

首先列出舊的輪換文件，將所需的歷史記錄複製到單獨的儲存中，然後再刪除已審核的版本。

何時截斷活動 audit.log 檔案是合理的

如果輪換檔案不是問題所在，而是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 更為可預測。

步驟 4：驗證磁碟復原和日誌記錄是否繼續進行

清理完畢後，要確認結果，而不是只依賴沒有錯誤：

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'

成功的結果有三個跡象：目標檔案系統上的可用空間增加，服務audit.log仍然存在並能接收新事件，以及相關的 Zimbra 服務仍在運作。如果服務數量急劇下降，df但仍會報告檔案系統已滿du，請在刪除更多資料之前，檢查是否有已刪除但仍被正在執行的程序佔用的檔案。

終端機顯示清理後的磁碟使用情況、最近的 Zimbra audit.log 條目以及 Zimbra 服務狀態檢查結果。

清理後，驗證已恢復的空間、最近的審計活動和服務運作狀況。

根據日誌成長的原因選擇長期解決方案。

如果生長正常但滯留時間過長

僅在記錄所需的歷史記錄週期後，才能調整保留或清理流程。檢查現有的 Zimbra crontab 和 Log4j 配置，然後進行最小的版本適配性變更。保留原始配置的副本，並測試下一次輪換是否確實創建了預期的文件。

如果身份驗證雜訊是音量的主要驅動因素

與其僅僅加快刪除速度，不如調查其根源。重複登入嘗試、用戶端設定錯誤、監控探測或有意擴展的身份驗證日誌記錄都可能增加稽核量。由於audit.log審計資料對安全調查很有用，因此減少底層噪音通常比壓制證據更有效。

如果您必須保留數月的審計歷史記錄

將日誌移動或傳送到專為保留而設計的儲存位置。集中式日誌記錄、物件儲存或專用日誌檔案系統可將合規性歷史記錄與郵件平台所需的容量分開。 Zimbra 的日誌檔案文件明確討論了集中式日誌記錄的候選方案，包括audit.log…

不該做什麼

請勿audit.log*使用未經審核的通配符刪除。
不要假設/etc/logrotate.d/zimbra每次發布都會控制活動審計日誌；Zimbra 將 Log4j 作為輪換機制audit.log。
除非確認有足夠的臨時空間，否則不要將檔案壓縮或歸檔到幾乎已滿的檔案系統中。
未經組織、法律或安全要求核實，切勿縮短保存期限。
在不了解 Zimbra 是否會根據範本重新產生 Log4j 檔案之前，請勿永久編輯產生的 Log4j 檔案。

最終檢查

如果舊的輪換日誌是主要資源消耗者，那麼理想的結果很簡單：活動審計日誌保持完整，歷史文件根據策略進行歸檔或刪除，文件系統恢復了足夠的空間以正常運行。如果空間立即再次消失，則不應再將清理視為解決方案，而應調查寫入速率、身份驗證活動、輪換配置以及任何其他日誌記錄設定。這種區別——一次性清理與持續增長——決定了您是否真正解決了問題。