In Debian server administration, `/var/log/syslog` is often the most overlooked source of disk space consumption. It is not uncommon for the syslog file on a web server running for several months to exceed a gigabyte in size; without proper rotation and compression strategies, it is only a matter of time before a full disk causes service disruption. Debian's log management is not a "set-and-forget" task—it involves the coordinated operation of three distinct mechanisms: rsyslog, systemd-journald, and logrotate. This article outlines the logging architecture and breaks down compression configurations, performance trade-offs, and verification methods.

Debian Logging Architecture: Understanding Roles and Responsibilities

Debian employs two parallel log management systems; understanding their respective roles is a prerequisite for configuring compression.

rsyslog is responsible for writing kernel and application logs to text files under `/var/log/` (such as `syslog`, `auth.log`, and `kern.log`). These text files are the primary targets for the compression strategies discussed here. Meanwhile, systemd-journald maintains a system of structured binary logs—stored in `/var/log/journal/` or `/run/log/journal/`—which are queried using `journalctl`.

logrotate is a standalone tool for managing text log rotation and compression, typically triggered daily via `/etc/cron.daily/logrotate`. Journald handles its own compression via the `Compress` option, operating through a mechanism entirely separate from logrotate.

The relationship between the two is as follows: journald can optionally forward logs to rsyslog via the `imjournal` module, after which rsyslog writes them to text files. This means the same log data might consume disk space in two places; if disk capacity is a concern, you can disable this redundant writing by setting `ForwardToSyslog=no` in `/etc/systemd/journald.conf`.

logrotate Compression Configuration: From Basics to Fine-Tuning

Debian's default rsyslog rotation configuration is located at `/etc/logrotate.d/rsyslog`, yet compression is often not enabled by default in many installation scenarios. A complete compression configuration looks like this:

/var/log/syslog

{

daily

rotate 7

compress

delaycompress

missingok

notifempty

create 0640 root adm

postrotate

/usr/lib/rsyslog/rsyslog-rotate

endscript

}

It is worth explaining the key parameters individually. `compress` enables gzip compression, which typically saves 50% to 70% of disk space. `delaycompress` postpones compression until the next rotation cycle, keeping only the most recent archive uncompressed—this is crucial for troubleshooting, as the current day's archive can still be viewed directly using `tail` or `grep` without needing to decompress it first. `rotate 7` limits the number of retained archives to seven; combined with the reduced size from compression, this usually keeps syslog disk usage within a few tens of megabytes.

If fine-grained control over the compression level is required, logrotate allows parameters to be passed via `compressoptions`. The default gzip compression level is `-6`, striking a balance between compression ratio and CPU overhead; setting it to `-9` yields smaller file sizes but significantly increases compression time.

compress

compressoptions -9

For logs with extremely high write frequencies (such as high-traffic Nginx access logs), consider increasing the rotation frequency from `daily` to `hourly` and using the `maxsize` parameter to trigger rotation based on file size:

/var/log/nginx/*.log

{

hourly

maxsize 100M

rotate 48

compress

delaycompress

postrotate

/usr/sbin/nginx -s reopen

endscript

}

systemd-journald Compression Mechanism

journald's compression strategy differs significantly from that of logrotate. It enables `Compress=yes` by default, using the XZ algorithm to compress data objects larger than 512 bytes before writing them to disk. This means journald logs are stored in a compressed format from the moment they are created, eliminating the need for additional rotation configurations.

Manual intervention is primarily required for capacity management. Set the following parameters in `/etc/systemd/journald.conf`:

ini

Storage=persistent

SystemMaxUse=1G

SystemKeepFree=1G

MaxRetentionSec=30day

Compress=yes

`SystemMaxUse` limits the maximum disk space consumed by journal logs; once the limit is exceeded, the oldest archived files are automatically deleted. `MaxRetentionSec` sets a time-based retention limit. When both are active, the condition triggered first takes precedence. Apply the changes by running `sudo systemctl restart systemd-journald`.

Performance Trade-offs: Compression Comes at a Cost

Log compression saves disk space but consumes CPU cycles and I/O operations. The compression process involves reading raw logs, executing the compression algorithm, and writing back the compressed file; all three steps generate additional disk I/O and CPU load. For servers where disk I/O is already a bottleneck, frequent log compression may exacerbate system load.

A pragmatic strategy is to apply compression based on log value. For system logs (e.g., `syslog`, `kern.log`), retaining them for 7 days with compression enabled is sufficient. For security audit logs (e.g., `auth.log`), it is recommended to retain them for over 30 days and prioritize remote centralized storage over local compression. For high-throughput service logs (e.g., Nginx or application logs) with massive write volumes, you can reduce the rotation count to 3 or 4, trading a shorter retention period for fewer compression operations. In scenarios with extremely high log volumes, you can replace the `logrotate` compression command from `gzip` to `zstd`; the latter offers faster speeds at similar compression ratios, though you must ensure `zstd` is installed on the system.

Configuration Verification and Troubleshooting

After configuring, verify the results using the following steps. First, force a log rotation to confirm that compressed files are generated correctly:

sudo logrotate -f /etc/logrotate.d/rsyslog

ls -lh /var/log/syslog*

The output should show `syslog` (the current file), `syslog.1` (the previous archive pending delayed compression), and compressed archives such as `syslog.2.gz`. If the compressed file is not generated, check whether the `compress` directive was omitted or verify that the `logrotate` cron job exists.

Another common issue is that `rsyslog` continues writing to the archived file after rotation, corrupting the `.gz` file. To resolve this, a `postrotate` script must be added to the `logrotate` configuration to notify `rsyslog` to reopen its file handles. On Debian, this is typically handled using `/usr/lib/rsyslog/rsyslog-rotate` or `invoke-rc.d rsyslog rotate > /dev/null`.

The core logic of log compression in Debian can be summarized as follows: `logrotate` manages the rotation and compression of text-based logs, while `journald` handles built-in compression for binary logs; each performs its specific role, yet care must be taken to avoid redundant storage. The key to configuration lies not merely in enabling compression, but in setting appropriate retention counts and compression levels based on log types and disk space constraints, thereby striking a balance between compression benefits and CPU overhead.