​

Decide How Long Evidence Survives

SafeSquid deployment evidence must survive troubleshooting and audit review. The default retention is shorter than most compliance regimes require, and a full log volume truncates evidence silently — the gap is discovered during an incident, when the window you need turns out to have rolled off. Set the target before installation. Retention is a storage decision, and storage is a sizing input.

​

Plan what has to be retained

• Local access logs under /var/log/safesquid/access/.
• Reporting Service or SIEM forwarding where required.
• Change records for activation, policy, Root CA rollout, and client routing.
• Time synchronization so log timestamps match incident timelines.
• Disk capacity for access logs, reports, support bundles, and packet captures used during incidents.

​

Set the retention target

Default local retention is 30 days. For compliance regimes that require 90 days or more, forward logs rather than extending local disk alone:

• External syslog — rsyslog, Splunk, ELK.
• Reporting Service.
• Cloud object storage such as S3 or Azure Blob.

Forwarding does not remove the need for local retention. Keep enough local history to diagnose an outage and to recover from a forwarder failure — the forwarder is exactly what breaks during the incident you need the logs for.

Disk and retention planning

Separate high-write log and cache storage where the deployment model allows it. For production nodes, record the retention target for:

• /var/log/safesquid/access/ access logs.
• Configuration backups and exported reports.
• Support bundles and temporary diagnostics.
• OS logs, Monit logs, BIND9 logs, and package-manager logs.

If logs are forwarded to a SIEM, still preserve enough local retention for outage diagnosis and forwarder-failure recovery.

Monitor /var/log/safesquid usage on a schedule and alert before the volume fills. Storage media choice matters here too — see the NVMe write paths in Sizing. Missing: daily log-volume estimates per deployment scale are not stated here. They exist in the legacy source but are undated and unverified against the current build, so the retention target cannot be converted into a disk figure from this documentation alone. Measure during the pilot, or escalate to the CTO before sizing storage from a number.

​

Assign the ownership

Retention fails on ownership more often than on capacity. Record:

• Who owns the retention target and reviews it.
• Who owns the SIEM or syslog destination.
• Who is alerted when the log volume approaches capacity.
• Who confirms, after an incident, that the relevant window was actually retained.

​

Capture retention evidence

Store these artifacts with the deployment record:

• The agreed retention target and the requirement that drove it.
• df -h /var/log/safesquid output against that target.
• The forwarding destination and proof of receipt, where configured.
• The named owner of retention and the review cadence.

​

Troubleshoot retention gaps

​

Next steps

• Logging and Reporting - prove the evidence path works once deployed.
• Sizing - convert the retention target into a storage decision.
• Reporting Service - connect reporting and forwarding.