A Safe Log Retention Policy for a Linux VPS

Logs need a storage budget just like databases and uploaded files. Keeping everything forever eventually makes logging compete with the service it is supposed to explain. Deleting everything during an incident removes the evidence you need most. A practical retention policy states which logs matter, how long you keep them, where they live, and who verifies that rotation works.

Inventory the different logging systems

List application files, reverse-proxy logs, the systemd journal, container logs, and any remote destination. These may use different retention mechanisms. A logrotate policy for a text file does not automatically control journal storage or a container runtime's logging driver. Record each producer's average and peak daily volume. Inspect for accidental duplicate delivery, such as the same verbose application output stored locally in several places. Reducing an unnecessary duplicate can recover capacity without shortening the useful investigation window.

Assign retention by purpose

Separate routine diagnostics, access records, security-relevant events, and temporary debug output. Decide the operational need for each without assuming one retention period fits everything. Keep sensitive data out at collection time: passwords, authentication tokens, and complete request bodies rarely belong in ordinary logs. A longer retention period also lengthens exposure if those records are copied or accessed improperly. Restrict access to the destination and document any business or contractual requirements that influence the retention decision.

Budget for a bad day

Suppose your measured normal output is 150 MiB daily, but a recurring error can produce 2 GiB in an hour. A policy based only on the normal rate can fill the disk before tomorrow's cleanup. Set a storage bound and an early alert, then investigate the noisy error itself. Compression may reduce older text logs, but use observed compression behavior rather than assuming an exact ratio. Leave disk room for the active file, rotation activity, and the rest of the application.

Rotate through documented mechanisms

The logrotate manual describes rotation options and the tradeoffs of approaches such as copying and truncating a live file. The journald configuration manual covers journal storage limits. Follow the owning service's instructions for reopening a rotated file. Removing its pathname alone may leave the process writing to an unlinked file that still occupies disk space. Review dry-run output before applying a new policy to production logs.

Verify both retention and usefulness

After a rotation cycle, confirm that the application still writes fresh entries, permissions are correct, and older records remain readable where expected. Check that expiration removes only the intended history. Perform a small investigation exercise: locate a known request or service restart from the previous day and correlate its timestamp across systems. A retention setup that saves bytes but loses timestamps, attribution, or access to archived files does not meet its operational purpose.

Store the policy with your guest administration notes, and review it whenever you add a service or enable debug logging. Consult LayerOne documentation for platform context and our backup guide when deciding which diagnostic records also need independent copies.