{"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-08-23T22:05:02","modified_gmt":"2026-08-23T22:05:02","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":"VPS Disk Space Forensics: The Complete Guide to Finding and Reclaiming Storage on a Small VPS"},"content":{"rendered":"\n

A 20-40 GB VPS disk fills up faster than you expect. One day df -h<\/code> shows 100%, apt<\/code> refuses to run, MySQL stops writing, and your site starts returning random 500s. The fix is rarely “upgrade to a bigger plan” \u2014 it is methodically finding what you forgot about. This guide covers the full forensic routine: from the initial panic to long-term prevention, with tools and techniques for every Linux distribution.<\/p>\n\n\n\n

Phase 1: Diagnose the Problem<\/h2>\n\n\n\n

When disk space vanishes, start with three commands that rule out the most common false leads:<\/p>\n\n\n\n

# Check actual disk usage vs. inode exhaustion\ndf -h \/\ndf -i \/\n\n# Check for deleted files still held open by processes\nsudo lsof +L1 | head -20\n\n# Find the biggest directories (one filesystem only)\nsudo du -xhd1 \/ | sort -hr | head -20<\/code><\/pre>\n\n\n\n
1. Inode Exhaustion<\/h3>\n\n\n\n
If df -i<\/code> shows 100% but df -h<\/code> shows free space, you have run out of inodes. The filesystem cannot create new files even though space exists. This is common on VPS images with small default inode tables. The culprit is usually a directory full of tiny files: mail spools (\/var\/mail<\/code>), PHP session files (\/var\/lib\/php\/sessions<\/code>), or Docker overlay filesystems. Deleting files is the only fix \u2014 ext4 cannot add inodes after creation.<\/p>\n\n\n\n
2. Deleted Files Held Open<\/h3>\n\n\n\n
A process (commonly a logging daemon, database, or web server) may keep a file open after it has been deleted. The kernel does not release the disk blocks until the file descriptor is closed. lsof +L1<\/code> lists these hidden consumers. Restart the owning process to release the space \u2014 do not just kill the PID without understanding what it is.<\/p>\n\n\n\n
3. Rapid Space Survey with ncdu<\/h3>\n\n\n\n
For interactive exploration, ncdu<\/code> is the best tool. It walks the filesystem, shows directory sizes in a sortable interface, and lets you delete with a single keypress. Install it, run it on the root filesystem, and drill into the largest directories:<\/p>\n\n\n\n
sudo apt install ncdu   # Debian\/Ubuntu\nsudo dnf install ncdu   # Fedora\/RHEL\nsudo ncdu -x \/<\/code><\/pre>\n\n\n\n
Phase 2: Attack the Usual Suspects<\/h2>\n\n\n\n
systemd Journal (the #1 Hidden Consumer)<\/h3>\n\n\n\n
On modern Linux distributions, journald<\/code> stores logs in a binary format that is not managed by logrotate. It can easily consume several gigabytes. Check and cap it:<\/p>\n\n\n\n
# See current usage\njournalctl --disk-usage\n\n# Shrink immediately\nsudo journalctl --vacuum-size=200M\n\n# Cap future growth\n# Edit \/etc\/systemd\/journald.conf:\n# SystemMaxUse=200M\n# MaxFileSec=1week\nsudo systemctl restart systemd-journald<\/code><\/pre>\n\n\n\n
Package Cache and Old Kernels<\/h3>\n\n\n\n
APT and DNF keep downloaded package files in a cache. Old kernels accumulate in \/boot<\/code> and are never removed automatically on most distributions:<\/p>\n\n\n\n
# Debian\/Ubuntu\nsudo apt clean\nsudo apt autoremove --purge\n\n# Check installed kernels\ndpkg --list | grep linux-image\n\n# Fedora\/RHEL\nsudo dnf clean all\nsudo dnf autoremove<\/code><\/pre>\n\n\n\n
Docker and Container Overhead<\/h3>\n\n\n\n
Docker images, build cache, and container logs grow without bound unless you enforce limits. Run a prune and configure log rotation:<\/p>\n\n\n\n
# Check usage\ndocker system df\n\n# Prune everything (caution: removes unused images, containers, volumes)\nsudo docker system prune -af --volumes\n\n# Cap container logs in \/etc\/docker\/daemon.json:\n# {\n#   \"log-driver\": \"json-file\",\n#   \"log-opts\": {\n#     \"max-size\": \"10m\",\n#     \"max-file\": \"3\"\n#   }\n# }<\/code><\/pre>\n\n\n\n
Database Binary Logs and WAL Files<\/h3>\n\n\n\n
MySQL\/MariaDB binary logs and PostgreSQL WAL segments accumulate without bound when retention is misconfigured:<\/p>\n\n\n\n
# MySQL: show and purge old binary logs\nmysql -e \"SHOW BINARY LOGS;\"\nmysql -e \"PURGE BINARY LOGS BEFORE NOW() - INTERVAL 2 DAY;\"\n\n# PostgreSQL: check WAL directory size\nsudo du -sh \/var\/lib\/postgresql\/*\/pg_wal\/<\/code><\/pre>\n\n\n\n
Snap Packages (Ubuntu Only)<\/h3>\n\n\n\n
Snap keeps old revisions of every installed package. A handful of snaps can quietly eat several gigabytes:<\/p>\n\n\n\n
# List all revisions\nsnap list --all\n\n# Limit retained revisions\nsudo snap set system refresh.retain=2\n\n# Remove old revisions\nsudo snap remove --revision OLD_REVISION package-name<\/code><\/pre>\n\n\n\n
Application-Specific Caches<\/h3>\n\n\n\n
Common cache directories that grow unbounded: Composer (~\/.cache\/composer<\/code>), npm (~\/.npm\/_cacache<\/code>), pip (~\/.cache\/pip<\/code>), and PHP sessions (\/var\/lib\/php\/sessions<\/code>). Set up a cron job to clear caches older than 30 days, or configure tmpwatch<\/code> \/ tmpreaper<\/code> for automatic cleanup.<\/p>\n\n\n\n
Phase 3: Configure Long-Term Prevention<\/h2>\n\n\n\n
Three guardrails prevent 90% of recurrence:<\/p>\n\n\n\n
    \n
  1. Cap journald<\/strong> at 200 MB as shown above.<\/li>\n
  2. Set up disk usage alerts<\/strong> \u2014 a simple cron check that emails or pushes a notification when disk exceeds 85%:<\/li>\n<\/ol>\n\n\n\n
    #!\/bin\/bash\n# \/usr\/local\/bin\/disk-alert.sh\nTHRESH=85\nUSE=$(df -h \/ | awk 'NR==2 {print $5}' | tr -d '%')\nif [ \"$USE\" -ge \"$THRESH\" ]; then\n  echo \"Disk ${USE}% full on $(hostname)\" | mail -s \"Disk Alert\" you@example.com\nfi\n# Add to crontab: 0 * * * * \/usr\/local\/bin\/disk-alert.sh<\/code><\/pre>\n\n\n\n
      \n
    1. Automate log rotation<\/strong> \u2014 verify that logrotate runs daily, and add custom configs for any service that writes logs outside the standard paths.<\/li>\n<\/ol>\n\n\n\n
      The Last Resort: What to Do When You Cannot Free Enough Space<\/h2>\n\n\n\n
      If you have pruned everything and still sit at 80%+ usage, you have three options:<\/p>\n\n\n\n