Log Retention Economics on a Budget VPS: Sizing Storage Before It Forces an Upgrade

Log retention is the cheapest-looking line item on a budget server and one of the most common causes of an unplanned upgrade. The mechanism is predictable: a service logs at a volume nobody measured, retention is left at a default of “keep everything,” and eighteen months later the disk is 80% full and the only available fix is a larger plan. The cost is not the logging itself — it is the storage tier you buy to hold data you will never read. Sizing it properly is a ten-minute exercise with an arithmetic answer. Pick a plan that leaves room for the number you calculate, using the budget VPS comparison table to see which storage sizes are available at each price.

Measure the daily rate first

Retention planning starts with one number: bytes written to log files per day. Everything else is multiplication. Measure it over 24 hours on a normal day, not a quiet one:

• Check the log directory sizes before and after a full day: du -sb /var/log.
• Do the same for application log directories, which often live outside /var/log.
• Repeat during a busy day if your traffic is spiky, because the peak is what fills the disk.

A small web server typically writes 40–150 MB/day with default verbosity. A noisy application with per-request debug logging can write several gigabytes a day, which is the difference between comfortable retention and an emergency.

The retention arithmetic

Required bytes = daily rate × retention days × compression ratio inverse. Text logs compress well; a 6:1 ratio is realistic for typical access and application logs, 10:1 for very repetitive output.

The table exposes the real decision: for most small servers, a month of compressed retention fits in under a gigabyte, which means retention is almost never a reason to buy a bigger plan. The disk-full incidents come from either no rotation at all or debug-level logging left enabled, not from the retention window people thought they needed.

What retention length actually buys

Retention is an insurance policy against two specific events, and both have short investigation windows:

• Incident forensics. Something broke at 02:00 and you need the hours before it. Seven days covers almost every case; thirty covers the case where nobody noticed for a week.
• Abuse or security investigation. A provider asks about traffic from three days ago, or you need to trace an intrusion. Thirty to ninety days is the practical range.
• Compliance. This is the only driver that justifies a year or more, and if it applies to you it is a requirement, not a preference.

Outside compliance, retention beyond 90 days is nearly always storage spent on data that will never be read. The audit-rate of old logs is extremely low, and any investigation that runs longer than a quarter needs a database, not a text file.

The three costs retention hides

Disk space is the obvious one. Two others are less visible and usually more expensive.

• Backup cost. If your backups include /var/log, every retained byte is copied to backup storage, often daily. A 30 GB log directory can triple your backup window and your offsite bill. Exclude logs from backups and keep only what forensics needs.
• Search time. A 20 GB uncompressed log directory makes grep slow enough that people stop looking. That is a real operational cost: the logs exist but are not usable in the one situation they were kept for.

Both are fixed by the same two changes: compress on rotation and exclude from backups.

A configuration that stays cheap

Two settings do most of the work. For systemd-journald, cap the journal by size rather than time:

• SystemMaxUse=500M — a hard ceiling regardless of how noisy a service becomes.
• SystemMaxFileSize=50M — bounds any single file.
• Compression on, which journald does by default.

For file-based logs, use logrotate with rotate, compress, delaycompress and maxsize. Set maxsize as well as a rotation count, because time-based rotation alone can produce a huge single file during a burst before the daily rotation runs. A hard size cap is the setting that actually prevents the disk-full incident.

Reduce the rate rather than the retention

The most effective lever is upstream. Retention multiplies whatever the daily rate is, so cutting the rate by 80% cuts every downstream cost by 80%:

• Turn off debug logging in production. It is the single largest cause of runaway log volume.
• Drop health-check and monitoring probe requests from access logs — on some servers these are the majority of lines.
• Log errors at full detail and successful requests at one line, or not at all.
• Sample high-volume informational output rather than writing every event.

An 80% reduction in daily volume turns a 30 GB retention requirement into 6 GB, which usually fits inside the plan you already have. That is a free upgrade, achieved by configuration rather than purchase.

Shipping logs off the server

If you genuinely need long retention, do not keep it on the same disk as the application. Cold storage — object storage, or a separate cheap archive volume — costs a fraction of block storage on a VPS. Send only what you need to keep, compress before shipping, and keep 7–14 days locally for fast forensics. This splits the two requirements: speed for the recent window, cheap capacity for the long tail. Doing it this way typically costs a few dollars a month instead of a plan upgrade that costs $10–$20 more every month forever.

The review cadence

Log volume drifts. A new service, a traffic increase, or a verbosity change can double it in a month without anyone noticing. Add a single alert on disk usage crossing 75% and a quarterly look at the daily rate against the table above. When the rate changes, revisit retention rather than storage — the plan is almost never the thing that needs to grow.

Sizing storage around a real retention number, rather than a default, is one of the few places where a small amount of measurement converts directly into a lower monthly bill. Check the storage tiers against your calculated figure in the affordable VPS server research and provider notes before you accept an upsell you did not need.