{"id":794,"date":"2026-08-03T22:50:03","date_gmt":"2026-08-03T22:50:03","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=794"},"modified":"2026-08-03T22:50:03","modified_gmt":"2026-08-03T22:50:03","slug":"logrotate-disk-space-management-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/logrotate-disk-space-management-vps\/","title":{"rendered":"Logrotate and Disk Space Management on a VPS: Keep Logs Useful Without Filling the Disk"},"content":{"rendered":"\n

A full disk is one of the most common causes of VPS outages \u2014 and it is almost always self-inflicted. Application logs, database binlogs, and package manager caches grow silently until \/<\/code> hits 100%, at which point services start failing with cryptic No space left on device<\/code> errors, SSH logins break, and even rm<\/code> refuses to work for the root user in some configurations. The fix is a two-part routine: find what is consuming space, then rotate and prune logs automatically with logrotate and journald limits. This guide covers both, with configs you can copy straight onto a Debian or Ubuntu VPS.<\/p>\n\n\n\n

The good news is that the tools are built into every Linux distribution \u2014 no extra agents or paid services required. If you are evaluating hosts for a workload that generates heavy logs, our comparison table<\/a> includes plans with larger NVMe allocations, which gives you more headroom before rotation policies matter.<\/p>\n\n\n\n

Step 1: Find What Is Eating the Disk<\/h2>\n\n\n\n

Start with filesystem usage, then drill down:<\/p>\n\n\n\n

df -h                              # which mount is full\ndu -xh --max-depth=1 \/ | sort -h   # largest top-level directories\ndu -xh --max-depth=2 \/var | sort -h | tail -10   # largest subdirs\nfind \/var\/log -type f -size +100M -exec ls -lh {} \\;   # huge log files<\/code><\/pre>\n\n\n\n
On a typical web VPS, \/var\/log<\/code> and \/var\/lib\/docker<\/code> are the usual suspects, followed by MySQL’s ib_logfile*<\/code> and binary logs. The -x<\/code> flag keeps du<\/code> on one filesystem, so a large \/proc<\/code> or mount point does not skew the numbers.<\/p>\n\n\n\n
Step 2: Logrotate \u2014 Rotation, Compression, Retention<\/h2>\n\n\n\n
Logrotate runs daily via cron and processes the configs in \/etc\/logrotate.d\/<\/code> (plus the global defaults in \/etc\/logrotate.conf<\/code>). The core directive set is small but powerful:<\/p>\n\n\n\n
# \/etc\/logrotate.d\/myapp\n\/var\/log\/myapp\/*.log {\n    daily\n    rotate 14          # keep 14 rotated files\n    compress           # gzip old logs\n    delaycompress      # keep yesterday's log uncompressed\n    missingok\n    notifempty\n    create 0640 www-data www-data\n    postrotate\n        systemctl reload myapp\n    endscript\n}<\/code><\/pre>\n\n\n\n
Two details matter in production. First, create<\/code> restores the correct owner and permissions on the fresh log file so the app keeps writing after rotation. Second, the postrotate<\/code> script tells the service to reopen its log handles \u2014 Nginx and Apache need reload<\/code> or USR1<\/code>; systemd services with StandardOutput=append:<\/code> often need a restart instead. For services that reopen files on SIGHUP<\/code>, use copytruncate<\/code> instead: it copies and truncates without touching the file handle, at the cost of a few lost lines.\n\nWhen the log file is owned by a service user (common for PHP-FPM or containerized apps), add su www-data www-data<\/code> to the config so rotation, compression, and create<\/code> run as that user \u2014 otherwise logrotate may run as root and produce files the app cannot write to. If several services share one directory, wrap their postrotate<\/code> scripts in sharedscripts<\/code> so the reload runs once for the whole block rather than once per file. And if a service writes a high-volume log that must never grow beyond a fixed size regardless of time, replace daily<\/code> with size 100M<\/code> \u2014 rotation then triggers on file size instead of the clock.<\/p>\n\n\n\n
Step 3: Cap journald Before It Caps Your Disk<\/h2>\n\n\n\n
systemd-journald writes its own binary journal under \/var\/log\/journal<\/code> and, left alone, can grow without bound. Set explicit size limits in \/etc\/systemd\/journald.conf<\/code>:<\/p>\n\n\n\n
[Journal]\nSystemMaxUse=500M        # cap the journal at 500 MB total\nSystemMaxFileSize=100M   # individual file size before rotation\nMaxRetentionSec=2week    # drop entries older than two weeks\nCompress=yes<\/code><\/pre>\n\n\n\n
Apply with systemctl restart systemd-journald<\/code> (or systemctl kill -s USR1 systemd-journald<\/code> for a less disruptive reload). The journal will compact itself down to the new limit on the next rotation, freeing space without losing recent entries. A 500 MB cap plus two-week retention is a good default for most VPS workloads.<\/p>\n\n\n\n
Step 4: Prune the Other Log Producers<\/h2>\n\n\n\n