Cutting disk churn on a 20 GB VPS: journald + logrotate tuning that actually held up

Jalarihala

I run a small 20 GB VPS, and for a while it kept slowly filling up until I started getting disk-space warnings. It was not my data or backups — it was logs.

The problem

Running journalctl --disk-usage showed the journal alone taking up several GB, and a few runaway app logs in /var/log were growing faster than I expected. On a 20 GB disk, that does not leave much room for error, and just deleting logs by hand felt like a temporary fix that would come back in a few weeks.

What I changed

For journald, I set:

SystemMaxUse=200M
MaxFileSec=14day
Storage=persistent

That kept the journal bounded and persistent across reboots, without turning logging off entirely.

For logrotate, I moved to weekly rotation with rotate 4, compress, delaycompress, and missingok, and added size caps on the noisiest app logs so one chatty service could not eat the disk on its own. I also made a point of checking that the rotated logs were actually being compressed and removed, rather than just assuming the config worked.

The result

Log disk usage dropped from several GB to a few hundred MB, and it stayed stable over the following weeks. I now check with du -sh /var/log/* and journalctl --disk-usage every so often, and the numbers no longer creep up the way they used to. It is not a dramatic setup, but it removed a recurring headache.

Two open questions

1. On very small disks, do you prefer SystemMaxUse or SystemKeepFree? I went with a hard cap, but I can see the argument for keeping a free-space reserve instead.
2. How do you handle logs for containers that bypass logrotate? That is the one case where my current setup still feels incomplete, and I would be interested in what has worked for others.

tenji

maybe offload your compressed log file(s) to other server ? also maybe if applicable split them to their importance levels with the least one were gone to binary heavens.