Log files are crucial for keeping your infrastructure observable, tracking application behavior, and diagnosing problems. Unmanaged logs, however, can quickly take up disk space, particularly in VPS environments where storage is frequently constrained. In order to keep your system healthy, Linux distributions come with a potent tool called logrotate that automatically rotates, compresses, and purges logs.

Here we discuss the best practices for using logrotate to manage large log files efficiently on your VPS, ensuring optimal performance and preventing outages caused by full disks.

Why Log Rotation Matters on a VPS

A VPS typically comes with strict storage and I/O budgets. Allowing logs to grow without limits can result in:

• Application crashes caused by full disk partitions
• File system corruption risks
• Inability to write new logs (which makes debugging difficult)
• Performance degradation when log files reach very large sizes
• Higher backup costs due to oversized logs

Logrotate automates cleanup to ensure these problems never occur.

How Logrotate Works

Logrotate runs periodically (usually via cron or system timers) and applies rotation policies defined in:

• /etc/logrotate.conf – global settings
• /etc/logrotate.d/ – per-application configuration files

When a log meets a defined threshold, logrotate creates a new file, renames the old one, compresses it, and optionally deletes older logs.

Best Practices for Managing Large Log Files

Use Size-Based Rotation for High-Volume Logs

Applications such as web servers, load balancers, and mail transfer agents can generate gigabytes of logs daily.

Use the size directive to trigger rotation when the log exceeds a specific threshold:

/var/log/nginx/access.log { size 100M

rotate 10 compress missingok notifempty

}

This avoids situations where time-based rotation (daily/weekly) is not enough.

Always Compress Old Logs

Compression drastically reduces disk usage, especially for text-based logs. Best practice:

compress delaycompress

‘delaycompress’ ensures the previous log stays uncompressed until the next rotation, preventing issues with processes that momentarily hold file handles.

Use copytruncate Only When Necessary

Some applications (e.g., non-daemonized programs) cannot reopen log files on rotation.

copytruncate

copies the log to a rotated file and truncates the original.

However, it has disadvantages:

• Possible loss of log entries during truncation
• Race conditions for highly active logs

Prefer using the application’s native method (e.g., HUP signal) when available:

postrotate

systemctl reload nginx endscript

This allows the service to safely reopen log files.

Keep Only the Needed Number of Rotations

Use the rotate directive to define how many compressed logs to keep.

rotate 7

For large logs, storing too many historical files quickly consumes disk space. Balance operational needs with storage limits.

Exclude Sensitive Logs From Backups

Large logs do not typically need to be backed up.

To reduce backup size and avoid storing unnecessary data:

• Store rotated logs outside key backup paths
• Use .gitignore-style rules if using file-based backups

This is especially useful for VPS environments where backup space is limited or billed.

Monitor Disk Usage and Log Growth

Logrotate is not a “set and forget” tool. It is best practice to periodically review:

• Log file sizes
• Disk usage via ‘df -h’ and ‘du -sh /var/log/*’
• Rotation frequency and retention settings
• Application logging levels (e.g., DEBUG vs. INFO)

If logs spike unexpectedly, it usually indicates an application problem.

1. Use Systemd Journal Rotation for Journal-Based Systems If your system uses journald, configure its rotation separately: Edit /etc/systemd/journald.conf:

SystemMaxUse=200M SystemMaxFileSize=20M

Then restart:

systemctl restart systemd-journald

This prevents journal logs from consuming your entire VPS storage.

Create Application-Specific Logrotate Rules

Custom applications often log to non-standard locations. Create a dedicated rule in /etc/logrotate.d/yourapp:

/opt/myapp/logs/app.log { daily

size 50M rotate 14 compress missingok notifempty postrotate

systemctl reload myapp endscript

}

This ensures your application logs are safely rotated without affecting global settings.

Test Your Logrotate Configuration Before Deploying

Always validate new configurations:

logrotate -d /etc/logrotate.conf

The -d option performs a dry run without making changes.

This helps avoid misconfigurations that could break log rotation.

A sample Logrotate Policy for a VPS: This configuration is suitable for most medium-traffic VPS deployments.

/var/log/myapp/*.log { size 80M

rotate 10 compress delaycompress dateext missingok notifempty sharedscripts postrotate

systemctl reload myapp.service > /dev/null 2>&1 || true endscript

}

Conclusion

Implementing strong logrotate practices is essential for maintaining stability, performance, and observability on your VPS. By defining size-based rotations, compressing old logs, limiting retention, and creating application-specific rules, you minimize the risk of disk saturation and ensure your environment remains reliable.

Long-term operational health is further maintained by routinely testing and monitoring your log rotation policies.