Maintaining log files on a VPS is a fundamental operational task that affects reliability, compliance, and disk utilization. For administrators running instances in Hong Kong or elsewhere — whether a Hong Kong Server, US VPS, or US Server — a well-designed log rotation strategy prevents disks from filling, ensures historical logs are available for troubleshooting, and keeps performance impact minimal. This article dives into the mechanics of log rotation, practical configuration patterns for Linux VPS environments, and guidance on choosing parameters based on workload and regulatory needs.
Why log rotation matters
Logs are append-only by nature and can grow rapidly for busy services (web servers, databases, application stacks). Unmanaged logs lead to full filesystems, degraded performance, and failed services. On VPS instances — particularly small-tier Hong Kong VPS or US VPS — quota limits and smaller disks make rotation especially important. Additionally, retention policies are often required for security audits and incident response, so rotation must account for preservation and secure deletion.
Core concepts and tools
Most Linux distributions use a combination of the following:
- logrotate — generic file-based rotation utility driven by configuration files (usually /etc/logrotate.conf and /etc/logrotate.d/).
- systemd-journald — binary system journal; rotation/size limits are configured in /etc/systemd/journald.conf.
- rsyslog/syslog-ng — syslog daemons that write facility logs to files; they rely on logrotate or internal mechanisms for rotation.
Understanding how these interact is critical. For example, rotating files written by rsyslog requires a postrotate signal to rsyslog (typically SIGHUP) so the daemon reopens log files. With systemd-journald, logs are stored as binary journal files; management uses journald parameters (SystemMaxUse, SystemKeepFree) rather than logrotate.
logrotate fundamentals
Key directives you will commonly use in logrotate configuration:
- daily/weekly/monthly — rotation frequency.
- size — rotate when file exceeds given size (e.g., 100M).
- rotate N — keep N rotated files.
- compress — gzip rotated files to save space; alternatives include xz, bzip2 (slower), or no compression.
- delaycompress — skip compression of the most recent rotated file (useful when services might still read it).
- copytruncate — copy and truncate the original file instead of requiring the process to reopen file handles (useful for apps that cannot handle signal reopen).
- postrotate/endscript — run commands after rotation (e.g., service reload or restart).
Example snippet for an Nginx access log:
</var/log/nginx/access.log> {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
endscript
}
That postrotate uses Nginx’s USR1 to instruct the process to reopen log files, avoiding downtime.
Practical application scenarios
Low-traffic Hong Kong VPS (single-site)
For small Hong Kong VPS instances hosting a single website and few services, disk space can be tight. A conservative configuration:
- Rotate logs daily or when >50M (whichever comes first).
- Keep 7–14 compressed rotations (rotate 7–14).
- Use delaycompress with compress to ensure recent rotated files remain usable by processes briefly.
- Enable mail directive if you want admins alerted when rotation runs fail.
This limits local footprint while keeping a week or two of history for debugging. On such VPSes, consider offloading older archives to an object store or central log server to free disk.
High-throughput US Server or US VPS (API gateway, large traffic)
High-volume logs need different handling:
- Prefer size-based rotation (e.g., size 100M) possibly combined with hourly cron-run logrotate for extreme throughput.
- Use a centralized logging solution (ELK/EFK, Graylog, or syslog over TCP/TLS) to aggregate logs off the VPS in near-real-time.
- Keep minimal local retention (1–3 days compressed) to reduce I/O and disk usage.
- Make sure rotation triggers the service to reopen log files using proper signals, not copytruncate, to avoid losing log entries in high-concurrency logging.
In practice, a hybrid strategy — real-time shipping + short local retention — reduces troubleshooting time while protecting against network outages by keeping a short fallback history locally.
Best practices and hardening
Monitor disk and inode usage
Rotation won’t help if the partition runs out of inodes (many small files) or if temporary spikes exceed reserved free space. Use monitoring (Nagios, Zabbix, Prometheus) to alert on disk usage >70–80% and inode usage >70%. On VPS, set apart a log partition if possible to isolate log growth from root filesystem.
Permissions and secure deletion
Logs often contain sensitive data. Configure create and appropriate umask so rotated logs are accessible only to authorized accounts (e.g., 0640, root:adm). For compliance, implement secure deletion policies for expired logs if required (shred, srm) and document retention.
Compression trade-offs
Compression saves disk space but consumes CPU. On small Hong Kong Server instances CPU might be constrained; gzip is a reasonable default because it balances speed and ratio. For archival transfers to long-term storage, consider recompressing with xz or zstd on a more powerful host.
Handling multi-process writers
Many modern services support log rotation signals (Nginx, Apache, MySQL). Avoid copytruncate if possible because it can cause lost log lines with active appenders. Use the service’s reopen mechanism:
- Nginx: kill -USR1 pid
- Apache: apachectl graceful or kill -USR1
- rsyslog: systemctl reload rsyslog
systemd-journald specifics
If you rely on journald, configure /etc/systemd/journald.conf:
- SystemMaxUse — maximum space the journal may use.
- SystemKeepFree — reserved space to prevent full disks.
- MaxFileSec or MaxRetentionSec — time-based retention.
Binary journals are not handled by logrotate — adjust journald parameters and consider forwarding to syslog or fluentd for aggregation.
Retention, compliance, and archival workflows
Retention policies vary by industry. Typical patterns:
- Operational debugging: keep 7–30 days locally.
- Security/forensics: maintain immutable archives for 90–365 days (or per regulation).
- Long-term audits: archive to offsite cold storage (object storage, S3, Glacier-equivalent).
Automate archival with tools like rclone or aws-cli in a postrotate script or via a scheduled job that picks up compressed archives and uploads them to a secure bucket. Use checksums and lifecycle rules to manage costs.
Performance and cost considerations for VPS providers
On smaller VPS instances, such as entry-level Hong Kong VPS plans, the key concerns are disk space and CPU. Configure more aggressive rotation and smaller compress windows. For larger US VPS or dedicated US Server instances with heavier workloads, decentralize logging and invest in centralized log aggregation to scale horizontally.
Example: sample logrotate entry for MySQL
/var/log/mysql/*.log {
daily
rotate 7
compress
missingok
notifempty
sharedscripts
postrotate
systemctl kill -s SIGHUP mysqld >/dev/null 2>&1 || true
endscript
}
Adjust the postrotate command to the actual service name on your distro. Test rotation with logrotate –debug or –force before deploying widely.
Choosing the right settings: a quick decision guide
- If disk space is constrained (typical on small VPS): rotate more frequently, compress aggressively, and offload older logs.
- If you need exhaustive auditing: keep longer retention but store archives off-VPS to save costs.
- If you have high throughput: prefer signal-based reopen and remote aggregation to minimize local I/O.
- If CPU is a bottleneck: choose faster compression (zstd) if available, or compress off-host.
Summary
Effective log rotation for VPS environments requires understanding the interaction between log writers (rsyslog, journald, application processes) and rotation tools (logrotate), careful selection of rotation frequency and retention, and integration with monitoring and archival workflows. For administrators operating in different geographic markets — whether on a Hong Kong Server, US VPS, or US Server — tailoring rotation settings to the instance size, workload, and compliance requirements will prevent outages and simplify incident response.
For teams running web services on a Hong Kong VPS or evaluating options between regional offerings, consider pairing sensible local rotation policies with centralized logging or object storage for long-term retention. Server.HK provides a range of Hong Kong VPS plans suitable for both small deployments and production workloads; see their Hong Kong VPS options for more details: https://server.hk/cloud.php. For more information about the provider and services, visit Server.HK at https://server.hk/.
