{"id":916,"date":"2026-08-18T23:40:27","date_gmt":"2026-08-18T23:40:27","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=916"},"modified":"2026-09-27T22:03:50","modified_gmt":"2026-09-27T22:03:50","slug":"small-vps-disk-full-find-and-reclaim-space","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/small-vps-disk-full-find-and-reclaim-space\/","title":{"rendered":"Reclaiming Disk Space on a Full VPS: A Measured Procedure with du, lsof and Journald Limits"},"content":{"rendered":"\n

A full disk on a production VPS rarely announces itself politely. Services fail to write logs, databases refuse connections, and the first symptom is usually a generic 500 with no useful message. This is a methodical reclaim procedure: quantify what is large, decide what is safe to delete, and verify the space actually came back. Every step below is measured, not guessed.<\/p>\n\n\n\n

Step 0: Confirm It Is Really a Space Problem<\/h2>\n\n\n\n

Two different failures look identical from the application side. Run both checks before deleting anything.<\/p>\n\n\n\n

df -hT \/\ndf -i \/\nstat -f -c 'blocks free: %f  files free: %d' \/<\/code><\/pre>\n\n\n\n
If df -h<\/code> shows free space but df -i<\/code> shows 100 percent inode usage, the fix is finding millions of tiny files, not large ones. If both show space, check for deleted-but-open<\/strong> files, a classic cause of 100 percent usage that du<\/code> cannot see.<\/p>\n\n\n\n
lsof -nP +L1 | sort -k7 -n | tail -20<\/code><\/pre>\n\n\n\n
Any process holding megabytes of deleted files will not release them until restarted or reloaded (SIGHUP often works for daemons). Restarting the offending process returns the space instantly with no deletion risk.<\/p>\n\n\n\n
Step 1: Attribute Usage by Directory, Sorted<\/h2>\n\n\n\n
Use du<\/code> with a depth limit so it stays fast, then drill down only into the large branches.<\/p>\n\n\n\n
du -x -d1 -h \/ 2>\/dev\/null | sort -h | tail -15\n# then, for the biggest branch:\ndu -x -d1 -h \/var 2>\/dev\/null | sort -h | tail -15<\/code><\/pre>\n\n\n\n
The -x<\/code> flag keeps the walk on one filesystem, which prevents du<\/code> from wandering into mounted volumes and misattributing their size. In practice four locations account for the vast majority of runaway usage on small VPS instances.<\/p>\n\n\n\n
Location<\/th>Typical culprit<\/th>Safe reclaim method<\/th>Risk<\/th><\/tr><\/thead>
\/var\/log\/journal<\/td>Unbounded systemd journal<\/td>journalctl --vacuum-size=200M<\/code><\/td>None<\/td><\/tr>
\/var\/log<\/td>Rotated but uncompressed logs<\/td>logrotate -f \/etc\/logrotate.conf<\/code><\/td>Low<\/td><\/tr>
\/var\/lib\/docker<\/td>Dangling images, stopped containers<\/td>docker system prune -a<\/code><\/td>Medium<\/td><\/tr>
\/var\/lib\/mysql<\/td>Binary logs \/ relay logs<\/td>PURGE BINARY LOGS BEFORE ...<\/code><\/td>High<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Step 2: Cap Journald So It Cannot Regrow<\/h2>\n\n\n\n
Vacuuming once fixes today. Editing the config fixes every month after that.<\/p>\n\n\n\n
mkdir -p \/etc\/systemd\/journald.conf.d\ncat >\/etc\/systemd\/journald.conf.d\/99-cap.conf <<'EOF'\n[Journal]\nSystemMaxUse=300M\nSystemMaxFileSize=50M\nMaxRetentionSec=2week\nEOF\nsystemctl restart systemd-journald\njournalctl --disk-usage<\/code><\/pre>\n\n\n\n
On a 25 GB VPS, a 300 MB journal cap is generous while still leaving weeks of history for post-incident forensics.<\/p>\n\n\n
Container and Layer Bloat<\/h2>\n\n\n\n
Docker is the single most common silent consumer on a small VPS. Each image pull leaves an intermediate layer set, and stopped containers retain their writable layer. Inspect before you prune, because prune -a<\/code> will remove images you still need.<\/p>\n\n\n\n
docker system df -v | head -40\ndocker image ls --format '{{.Repository}}:{{.Tag}}\\t{{.Size}}' | sort -k2 -h\ndocker container ls -a --size --format '{{.Names}}\\t{{.Size}}'\n# reclaim only dangling layers first\ndocker image prune -f\ndocker builder prune -f --filter until=168h<\/code><\/pre>\n\n\n\n
On a host that builds images, the build cache usually dwarfs the images. Cap it in the daemon config so it cannot grow without bound:<\/p>\n\n\n\n
cat >\/etc\/docker\/daemon.json <<'EOF'\n{\n  \"log-driver\": \"json-file\",\n  \"log-opts\": { \"max-size\": \"10m\", \"max-file\": \"3\" }\n}\nEOF\nsystemctl restart docker<\/code><\/pre>\n\n\n\n
The log-opts<\/code> block matters more than the prune: unbounded container stdout logs are how \/var\/lib\/docker silently doubles in a month on a busy host.<\/p>\n\n\n\n
Finding the Million-File Case<\/h2>\n\n\n\n
When df -i<\/code> is the number that is full, aggregate by directory count rather than size. A PHP session directory, a mail queue, or a web cache with a broken eviction policy can hold millions of 4 KB files.<\/p>\n\n\n\n
find \/ -xdev -type d -printf '%p\\n' 2>\/dev\/null | while read d; do\n  n=$(find \"$d\" -maxdepth 1 -type f 2>\/dev\/null | wc -l)\n  [ \"$n\" -gt 5000 ] && echo \"$n $d\"\ndone | sort -rn | head -20<\/code><\/pre>\n\n\n\n\n
Step 3: Find Duplicate or Stale Large Files<\/h2>\n\n\n\n