VPS disk space cleanup: stop “No space left on device” outages in 2026

A VPS that runs out of disk rarely fails in a clean, obvious way. Databases flip read-only. PHP sessions stop writing. Cron jobs begin to error. Then Nginx returns 500s that look unrelated.

VPS disk space cleanup isn’t about deleting random files. It’s about finding what’s growing, fixing what caused it, and adding guardrails so it doesn’t come back next week.

This is an operator’s view of disk-full incidents on Ubuntu, Debian, AlmaLinux, Rocky Linux, and CentOS Stream. You won’t find a “run these 3 commands and pray” checklist here. That approach is how you delete the wrong thing under pressure.

VPS disk space cleanup starts with a 10-minute triage

Before you remove anything, confirm what’s actually full. It’s easy to free space in /home while /var is the real problem. It’s also easy to wipe logs when you’re really out of inodes.

• Is it blocks or inodes? Blocks are “GB used.” Inodes are “too many small files.”
• Which mount is full? Root (/) is common; /var and /tmp also fill up often.
• Is a deleted file still held open? It won’t show in the directory tree, but it still consumes disk.

Run these checks (safe on production)

df -hT

df -i

sudo du -xhd1 / | sort -h
sudo du -xhd1 /var | sort -h

sudo lsof +L1 | head -n 50

du tells you where the bytes are. lsof +L1 finds “deleted but still open” files. This is common after someone removes a log by hand.

If you see a huge deleted file still open, restart the owning service. That usually releases the space immediately.

If you host customer sites or production WordPress, disk incidents always land at the worst time. Headroom gives you options. A HostMyCode VPS gives you room to resize storage and keep the site online while you clean up properly.

Where the disk goes: the usual suspects on hosting servers

On web hosting stacks, disk growth usually follows a few repeatable patterns:

• Logs growing without rotation (web access logs, PHP-FPM logs, mail logs, application logs)
• Backups piling up locally (daily dumps stored on the same disk as the database)
• Docker/Podman layers and stopped containers (even if you “don’t use Docker much”)
• Package caches (APT, DNF) and old kernels
• Temp directories (session files, uploads, cache directories)
• Runaway databases (binary logs, slow query logs, large temporary tables)

Identify which bucket you’re in, then fix that workflow. Do it once and you can often recover tens of GB. More importantly, you stop the repeat.

Log growth: fix the cause, not just the symptom

Most disk-full outages on hosting VPSs trace back to logs. The response depends on why they’re growing.

Sometimes it’s normal volume from real traffic. Other times it’s noise from bots, errors, or loops.

Fast checks for Nginx/Apache and PHP

# Biggest files in /var/log
sudo find /var/log -type f -printf '%s %p\n' | sort -n | tail -n 30

# Nginx logs
sudo ls -lh /var/log/nginx/

# Apache logs (Debian/Ubuntu)
sudo ls -lh /var/log/apache2/

# Apache logs (RHEL family)
sudo ls -lh /var/log/httpd/

If access logs are massive, sample them before you rotate or truncate. Look for bot storms, hot endpoints, and repeated 404s.

sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

On WordPress, one plugin can turn a minor warning into a log firehose. You’ll see it in php-fpm logs or the web server error log.

Fix the warning and the growth stops. Pruning alone just buys time.

Two guardrails are non-negotiable here: log rotation and a disk usage alert. For a clean, production-ready setup, pair this with Linux VPS log rotation setup: prevent disk full outages with logrotate + systemd. It’s one of the few “set it once” changes that stays valuable for years.

Common pitfall: manual log deletion

Deleting /var/log/nginx/access.log by hand often doesn’t free space. If Nginx still has the file open, the bytes stay allocated.

Rotate properly, or reload the service after truncating:

# Truncate safely (keeps file handle)
sudo truncate -s 0 /var/log/nginx/access.log
sudo truncate -s 0 /var/log/nginx/error.log

# Then reload to be tidy
sudo systemctl reload nginx

Backups on the same disk: the quiet disk killer

Local backups feel reassuring—until they fill the same volume your database needs to write to. The failure mode is predictable.

Backups run fine for weeks. Then MySQL/MariaDB can’t write, and the site collapses in odd ways.

Start by finding the backup directories:

sudo du -xhd2 / | sort -h | tail -n 20
sudo du -xhd2 /var | sort -h | tail -n 20

Typical locations include /root/backup, /var/backups, /home/USER/backups, and (with control panels) inside account home directories.

If you discover months of full dumps, fix retention and use off-server storage.

A retention rule that holds up in real ops: keep 7 daily, 4 weekly, and 3 monthly backups locally only if you have plenty of disk and a separate data volume. Otherwise, keep a short local window and ship the rest off-server.

For disaster planning and restore testing discipline, the best companion read is Linux VPS Disaster Recovery Plan: Hands-On Backups, Restore Tests, and Failover Prep (2026).

If you’d rather not babysit this, managed VPS hosting from HostMyCode fits the “keep it boring and predictable” crowd: monitored storage, sensible retention, and help when restore day arrives.

Docker and container storage: easy wins without breaking deployments

Even on “traditional” hosting VPSs, Docker shows up. It might be a one-off tool, a CI agent, or a forgotten test deployment.

Container storage grows fast. Cached layers, old images, and leftover artifacts add up.

Check current Docker usage

docker system df

docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Size}}'

Clean up safely (review before you remove)

• Remove unused images (keeps images used by containers): docker image prune
• Remove stopped containers: docker container prune
• Remove unused networks: docker network prune

# Aggressive: removes unused images/containers/networks AND build cache
docker system prune

Avoid deleting volumes unless you’re sure nothing depends on them. Volumes often hold database state.

If you need to inspect volume sizes:

docker volume ls
# Quick and dirty: see which directories are big
sudo du -hd1 /var/lib/docker | sort -h

APT/DNF caches and old kernels: quick recovery, low risk

This won’t usually save you 200 GB. It often buys enough space to stabilize the system while you fix the real leak.

Ubuntu/Debian

sudo apt-get clean
sudo apt-get autoclean
sudo apt-get autoremove --purge

Old kernels take space in /boot. If /boot fills up, updates fail and you end up stuck.

After autoremove, verify:

df -hT /boot || true
uname -r
dpkg --list | grep linux-image | awk '{print $2}'

AlmaLinux/Rocky/CentOS Stream

sudo dnf clean all
sudo dnf autoremove

On RHEL-family systems, old kernel packages can linger too. Review installed kernels and keep a safe minimum (current + one fallback):

rpm -q kernel --last | head

Inodes: “disk is full” but df shows free space

If df -h looks fine but writes fail, check df -i. Inode exhaustion happens when the server creates mountains of small files.

Common sources are cached thumbnails, PHP sessions, mail queues, or logs chopped into tiny chunks.

Find directories with lots of files

# Count files quickly (can take time on huge trees)
sudo find /var -xdev -type f | wc -l

# Top directories by file count (sampling approach)
for d in /var/*; do echo -n "$d "; sudo find "$d" -xdev -type f 2>/dev/null | wc -l; done | sort -n | tail

Two repeat offenders in hosting:

• PHP sessions: often in /var/lib/php/sessions (path varies by distro).
• WordPress cache directories: under wp-content/cache or plugin-specific paths.

Fix the root cause. Set session GC correctly, configure cache TTL, and enforce rotation/retention.

Databases: binary logs and temp files that quietly grow

MySQL/MariaDB storage issues rarely begin with “the database got bigger.” More often, logs and temp files were enabled, forgotten, and left to grow.

• Binary logs (replication / point-in-time recovery): can grow without expiry.
• General query log: can explode on busy sites; avoid leaving it enabled.
• Slow query log: useful, but needs rotation.
• Temp tables: watch /tmp if you have unusual workloads.

If you’re chasing database slowness while you’re here, don’t guess. Use the slow query log and fix the worst offenders.

This pairs well with Linux VPS MySQL Slow Query Log Tutorial (2026): Enable, Analyze, and Fix Database Bottlenecks.

WordPress disk bloat: backups, media, and cache that never expires

WordPress growth is often healthy: more media, more content, more traffic. The trouble starts when the growth is accidental.

Common causes are backup plugins writing daily ZIPs locally, image tools keeping originals plus multiple variants, and caches that never expire.

What to audit on a WordPress VPS

• Backup plugin directories: confirm where backups are stored and how many are retained.
• Uploads: large video uploads and unoptimized images dominate wp-content/uploads.
• Caches: verify TTL and automatic purge behavior after deploys.
• Staging copies: duplicate site copies tucked inside account directories.

If your business is WordPress-heavy and you’d rather focus on the site than the server, HostMyCode WordPress hosting keeps the stack tuned and the operational chores manageable, while still giving you enough control to run serious sites.

Performance and storage are tied together. Oversized media and uncontrolled caches slow backups and inflate restore time. They also push you toward bigger disks than you actually need.

For the speed side, see WordPress Hosting Performance Optimization in 2026.

Put guardrails in place: alerts, quotas, and predictable cleanup

After you recover space, prevent the repeat. The simplest setup that works: alerts at 80/90%, log rotation, and a basic maintenance cadence.

Monitoring that actually catches disk issues early

• Disk usage by mount (not just root)
• Inode usage
• Disk write latency (spikes can precede failures)
• Growth rate (GB/day): helps you forecast “full in 9 days”

Netdata is a practical fit for most VPS sizes because it highlights what changed without a long setup. For an install that’s operationally sane with a security baseline, use Linux VPS monitoring with Netdata: install, secure, and alert on real server issues.

If you prefer a more standardized metrics+logs pipeline, OpenTelemetry Collector Setup on a Linux VPS is a solid next step.

A small maintenance habit beats emergency cleanup

Disk incidents are usually preceded by weeks of small warnings. A quick monthly check keeps you out of firefighting mode.

For a structured routine, adapt the ideas in VPS maintenance checklist: keep your Linux server fast, secure, and predictable in 2026.

When cleanup isn’t enough: resize, split volumes, or move up a tier

Sometimes you clean things up correctly and still hit the ceiling. That usually means the workload grew. That’s a capacity signal, not an ops failure.

• Resize disk if the workload is stable and you just need more headroom.
• Split data by moving databases or uploads to a separate volume (reduces blast radius).
• Move to a bigger VPS or dedicated server if IOPS and capacity both become constraints.

Planning is easier when you measure first. This dovetails with Linux VPS capacity planning in 2026, especially the sections on disk I/O and realistic safety margins.

Summary: a safer way to handle disk-full incidents

Reliable disk recovery follows a sequence: confirm blocks vs. inodes, identify the hottest directory, inspect before deleting, then enforce retention and alerts.

Follow that order and “No space left on device” becomes a rare annoyance instead of a recurring outage.

If you’re tired of storage surprises—or you need room to grow without re-architecting—start with a right-sized HostMyCode VPS and add managed VPS hosting when you want ongoing monitoring and operational help. HostMyCode’s focus is simple: Affordable & Reliable Hosting that doesn’t create extra work.

FAQ

Is it safe to delete files under /var/log to free space?

It’s safer to truncate or rotate them. If you delete a log file that a running service still has open, disk usage may not drop. Use truncate -s 0 and reload the service, or configure logrotate correctly.

Why did disk space not free up after I deleted a huge file?

A process may still hold the file open. Run sudo lsof +L1 to find deleted-but-open files, then restart the owning service to release the space.

What’s the fastest way to find the biggest directories on a VPS?

sudo du -xhd1 / | sort -h is the quickest starting point. Then drill down into the biggest directory (often /var) with another du -xhd1.

How do I prevent Docker from filling my disk again?

Schedule regular pruning of unused images/build cache, and keep an eye on /var/lib/docker. Use docker system df weekly and avoid deleting volumes unless you’re sure they’re unused.

What disk usage alert thresholds should I use in 2026?

Alert at 80% (warning) and 90% (urgent) per mount, plus inode alerts if your workload generates lots of small files. Add a “growth rate” view so you can predict full-disk dates.