「Syslog 伺服器應保存多久日誌」並沒有一個通用數字。美國國家標準與技術研究院的 NIST SP 800-92（Guide to Computer Security Log Management）採取的方式是政策驅動：機構應先就每一類日誌訂明保留期、保護措施、檢視頻率及負責人，再把政策落實到系統設定，而非先看儲存空間剩多少再決定。
因此正確的提問方式是逐類日誌反推。防火牆的連線紀錄、交換機的埠狀態變化、伺服器的登入紀錄、應用系統的操作紀錄，四者的用途與價值密度完全不同，用同一個保留期處理必然出現一邊過長、一邊過短的情況。政策應允許按類別設定不同期限。
| 日誌類別 | 主要用途 | 保留期考慮 |
|---|---|---|
| 設備運作狀態（介面上下、電源、溫度、風扇） | 故障排查與硬件壽命判斷 | 覆蓋一個維護周期即可，價值隨時間下降較快 |
| 連線與流量紀錄（防火牆、位址轉換） | 追溯來源、處理濫用及事故 | 須覆蓋事件發生至被發現的時間差，通常需要較長 |
| 認證與權限變更（登入、失敗嘗試、設定改動） | 保安調查與責任追溯 | 價值密度最高，一般保留最長，並須防篡改 |
分層的實際好處是控制成本。把三類日誌以同一最長期限保存，儲存量會被低價值的狀態訊息佔去大半；分層後可把預算集中在認證及設定改動紀錄上。
早期的 syslog 實作方式記載於 RFC 3164（The BSD syslog Protocol），屬事後整理的描述性文件，欄位定義寬鬆，不同廠商的訊息格式差異大。RFC 5424（The Syslog Protocol）則正式定義了訊息結構，包括版本號、帶時區的時間戳、主機名及結構化資料欄位，令解析與檢索可靠得多。
傳輸方式同樣影響保留策略。以 UDP 傳送的 syslog 不保證送達，網絡繁忙或設備重啟時可能靜默丟失訊息，因此「日誌完整」這個假設並不成立。RFC 5425（Transport Layer Security Transport Mapping for Syslog）定義了以 TLS 傳送 syslog 的方式，同時提供可靠傳輸與加密。若日誌會用於保安調查，傳輸可靠性應與保留期同等重視——保留一年但中途丟失了關鍵訊息，實際價值仍然有限。
時間戳準確性是第三個前提。多台設備的日誌需要互相對照，若各自走時便無法確定事件次序，NTP（RFC 5905）的同步安排因此屬必要配套，而非可選項目。
第七步最常出現落差：政策寫保留半年，但因容量不足實際只剩三星期。這種落差在事故發生時才發現，代價最高。
日誌只存在設備本機，設備被入侵或重啟後紀錄即失。送往獨立的日誌伺服器是可信度的基本前提。
網絡設備的管理員不應同時具備刪改日誌伺服器紀錄的權限，否則紀錄無法用於責任追溯。
以 TLS 傳送可同時避免中途竊聽與靜默丟失，適用於會用作調查依據的日誌。
NIST SP 800-92 強調日誌需定期分析。只儲存不檢視，異常要等到事故後才被發現。
香港中小企的網絡規模通常是一台防火牆、數台交換機及數個無線接入點，日誌伺服器多以現有網絡儲存裝置或一台虛擬機承擔。這種規模最常見的問題並非保留期太短，而是日誌從未集中：設備各自把紀錄寫在本機記憶體，重啟即清空。因此第一步應是建立集中收集，其後才討論保留多久。
辦公室環境亦影響存放位置的選擇。香港辦公室面積緊張，日誌伺服器常與其他設備同置於一個小型機櫃或機房角落，散熱及供電條件有限。若日誌屬保安調查用途，應考慮把歸檔複本存放於另一位置，避免同一次事故（例如水浸或機櫃電源故障）令紀錄與被調查的系統一併損失。相關的環境考慮可參考本站的機房環境監控。
多分店企業的情況另有考慮。若分店以互聯網連回總部傳送日誌，線路中斷期間的訊息會丟失，因此分店設備應設定在本地暫存並於恢復後補送，或改用可靠傳輸方式。這一點在香港常見的商業寬頻環境下尤其實際，因為住宅式寬頻的穩定性與專線有差距。
不確定如何應用於實際環境？我們的工程師可按現場情況提供建議，免費解答及報價。
WhatsApp 即時查詢若閣下正計劃相關工程或需要選購設備，歡迎瀏覽網絡系統工程服務了解方案詳情，或透過網上快速報價與我們的工程師聯絡。
產品規格以原廠最新文件為準；有需要請聯絡我們工程師。