Linux log rotation keeps operational evidence usable while preventing logs from consuming unlimited storage. A sound policy defines how files are rotated, when they expire and how the application begins writing to the new destination. Simply renaming yesterday's log is insufficient if the service continues writing into the old file.
Different logging systems need different controls. Traditional text files may use logrotate, while systemd's journal manages its own retention. Container logging may add another layer. This article focuses on designing and verifying the policy rather than providing a configuration copied without regard to the service that owns the logs.
This workflow on getaboutcolumbia explains retention planning, application coordination and the checks that prove rotation worked. It helps retain enough evidence for diagnosis without treating the VPS filesystem as a permanent archive.
Decide which logs you need and for how long
Inventory application logs, web access and error logs, authentication records, system journals and any container output. Identify who uses each stream and which incidents it helps investigate. Keep sensitive data out of logs where possible; a storage policy does not solve excessive collection of credentials, tokens or personal information.
Estimate volume using both ordinary days and noisy incidents. A log producing 100 MB daily under normal conditions can grow much faster when a failed integration repeats an error every second. Retention must account for that possibility, especially on a small root filesystem shared with the database.
The lessons from diagnosing a full VPS disk apply before an emergency occurs: know the mount, owner and growth rate. Give local logs a defined storage budget and decide whether selected events should be forwarded to a separate protected destination. Remote copies also help when the server itself becomes inaccessible.
Treat retention as an operational and organizational decision. There is no universally correct number of days for every business or log type. The chosen period should support expected investigation needs and any applicable requirements, while limiting unnecessary data and cost. Document the owner who can revise that policy.
Match rotation to the service's writing behavior
The logrotate project manual describes time and size conditions, compression, retention and post-rotation actions. Rotation checks happen when the tool runs, so a size condition is not a continuous guarantee that a file can never exceed that size. A fast-growing log may require more frequent evaluation or a different logging design.
Many services need to reopen their log files after rotation. NGINX's control documentation describes its log reopening behavior. Use the service's supported mechanism instead of assuming a generic restart is necessary. A full restart can interrupt work when a narrower action would allow the server to continue operating.
Understand the implications of copying and truncating an active file. The logrotate manual documents a window in which entries can be lost with that approach. Use it only when the application's behavior and the value of the logs justify the tradeoff, rather than selecting it merely because it appears to avoid a service action.
For a hypothetical application, suppose rotation creates a new file with the wrong owner. The rotation job can appear successful while the application silently stops recording events or reports permission errors. Testing must therefore include a newly generated request and confirmation that its record appears in the current log with the intended ownership.
A systemd journal needs a separate policy. The journald configuration manual explains size and free-space controls for journal storage. Check whether logs are persistent across reboots and how the selected settings interact. A text-file rotation rule does not automatically govern journal files or prove that older boot logs will remain available.
Test the entire retention cycle
Start by reading the existing configuration and its scheduling mechanism. A distribution may run logrotate through a timer or another scheduler. Avoid creating a second schedule before checking what already exists, because overlapping jobs complicate diagnosis and can create unexpected behavior.
Use the tool's supported diagnostic mode to inspect how rules would be interpreted before making changes. Then test an actual rotation in a controlled environment or planned window. Confirm the current file, archived file, ownership, permissions, compression and the application's continued output. Record any service action the process requires.
Check retrieval as well as storage. Someone responding to an outage should know where the relevant period lives and how to read compressed archives. The workflow for reading web-server error logs becomes much less effective if rotation has made yesterday's evidence impossible to locate.
Verify expiry with a small test dataset where practical. A policy claiming to retain a certain number of generations should actually remove the intended old generations and preserve the required recent ones. Check naming patterns carefully so unrelated application files cannot be matched accidentally.
Correlate log timestamps with monitoring and deployments. A consistent time convention makes it easier to connect a new release with an error burst. If logs are forwarded remotely, verify delivery delays and local buffering behavior; a healthy-looking destination may still be missing the most recent events during a network interruption.
Mistakes to avoid
Avoid compressing an active file the application still writes to, deleting all logs after an incident or assuming a timer's success proves service output continues. Do not retain sensitive debug output indefinitely. If logs grow rapidly because a service repeatedly fails, investigate the underlying problem using systemd service status and recovery checks; rotation should control storage, not conceal a failure loop.
Two final recommendations
Keep a concise log inventory that names the producer, local path, retention rule and remote destination where applicable. Include a retrieval example so another administrator can find a relevant hour without reverse-engineering the system.
Review log volume after application changes and incidents. New debug settings, integrations and retry behavior can change storage consumption far more quickly than ordinary audience growth.
Conclusion
Linux log rotation is successful when logs keep arriving, older evidence remains retrievable and storage use stays within a deliberate budget. Renaming files alone does not satisfy those goals.
Coordinate rotation with the owning service, manage journals separately and test permissions, reopening, compression and expiry. Watch the actual growth rate rather than relying on a configuration file's existence.
Preserve useful evidence while addressing the errors that generate it. A clear, tested retention policy supports both reliable hosting and faster incident investigation.
