Guides

Full VPS disk: find what's taking up space and free it safely

No space left on device: commands to find what's filling the disk, the most common culprits and how to prevent it happening again with logrotate.

UptimeMag editorial team · 13 October 2026 · 5 min read

Disco pieno sul VPS: trovare cosa lo occupa e liberarlo senza fare danni

First step: how full is it and where

If your site is down with "No space left on device" errors in PHP or Nginx logs, don't waste time reading: run this immediately:

df -h

Look at the Use% column: if the filesystem mounted on / (or on /var if it's a separate partition) is at 100% or close to it, that's your problem. On VPS with a single disk, you usually have just one line to check.

Once you've found the full filesystem, you need to know what's taking up the space:

sudo du -x -h --max-depth=1 /var | sort -rh | head -20

The -x flag prevents counting other filesystems mounted under /var (like tmpfs). Repeat, drilling down into the heaviest directory until you find the specific file or folder.

The usual suspects, in order of frequency

1. Logs never rotated

The most common case on manually managed VPS. Check:

sudo du -sh /var/log/* | sort -rh | head -10

On an Ubuntu 24.04 system with Nginx, logs live by default in /var/log/nginx/ (access.log and error.log), according to the access_log directive in the Nginx official documentation. If you find an access.log several gigabytes in size, the cause is almost always logrotate not active or never configured for that file. See below how to fix it.

2. Forgotten backups

Folders like /root/backup, /home/*/backups, SQL dumps left by a script from months ago. You can find them with the same du command above, searching in home directories and custom script folders. You can safely delete these only if the backup is duplicated elsewhere (external storage, another server): never delete your only copy.

3. Package cache

On Ubuntu/Debian, apt cache accumulates in /var/cache/apt/archives. You can safely clean it with:

sudo apt-get clean

On systems with Plesk or cPanel, also check the package manager caches (yum/dnf on CentOS/AlmaLinux: sudo dnf clean all).

4. Resized images and application cache

WordPress with many media plugins, galleries, or runtime-generated thumbnail caches (wp-content/uploads/*-150x150.jpg and variants) can multiply the space used by original images. Check with:

du -sh /var/www/*/wp-content/uploads 2>/dev/null

Be careful here: deleting thumbnails is safe (they get regenerated), deleting the originals isn't.

5. Bloated database tables

If your site uses MySQL/MariaDB, InnoDB files live in /var/lib/mysql. A du -sh /var/lib/mysql/* quickly isolates the heaviest database or table. Application log tables (sessions, audit trails, object cache) that have grown without maintenance are the most common cause here. Fix it with a TRUNCATE on the table or periodic cleanup, not by deleting files by hand.

6. The deceptive case: file deleted but still open

You deleted a huge log with rm, but df -h still shows the disk full. It's not a bug: when a process has a file open and you delete it, Linux doesn't immediately free the disk space. Instead, it removes the entry from the directory, so the file disappears from the filesystem view. The space is only released when the process closes the file or reboots.

To find the process still holding the deleted file open:

sudo lsof +L1

A value of 0 in the NLINK column means the file no longer has an entry in the directory but is still open. The row that matters is the one with (deleted) next to the filename: there you'll find the PID and command of the responsible process.

Two ways to free the space without interrupting the service:

  • restart the process holding it open (e.g. sudo systemctl restart nginx if it's the culprit);
  • truncate the file descriptor directly, without restarting anything:
sudo truncate -s 0 /proc/<PID>/fd/<FD>

replacing <PID> and <FD> with the values from the lsof output. This second way is useful when you can't afford to stop the process (a production database, for example).

How to set up log rotation so it doesn't happen again

On Ubuntu 24.04 logrotate is already installed, and Ubuntu ships it preinstalled and already rotates the logs of system packages such as Nginx, rsyslog and apt. The file that controls Nginx is /etc/logrotate.d/nginx and normally contains this configuration:

/var/log/nginx/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 0640 www-data adm
	sharedscripts
	postrotate
		invoke-rc.d nginx rotate >/dev/null 2>&1
	endscript
}

If the log grows too fast for the daily interval, you can add a size-based rule with the size directive (e.g. size 100M) next to daily: logrotate rotates as soon as the file exceeds that threshold, regardless of the day.

For your own application that writes logs outside /var/log (typical with Laravel, Node, custom scripts), create a dedicated file, for example /etc/logrotate.d/myapp:

/home/deploy/apps/myapp/storage/logs/*.log {
	daily
	rotate 7
	missingok
	notifempty
	compress
	delaycompress
	create 0640 www-data www-data
}

To test the rule before trusting it, use debug mode which simulates rotation without changing anything:

sudo logrotate -d /etc/logrotate.d/myapp

Verify it's fixed

After setting up the rule, check the rotation status with:

sudo cat /var/lib/logrotate/status

and verify that the last rotation date appears for your log. From then on, a weekly df -h (or a monitoring alert on the Use% threshold) will warn you before the disk fills up again.

On cPanel or Plesk

On cPanel, Apache/Nginx logs are already managed by cpanellogd, configurable from WHM; on Plesk, domain log rotation is set from the panel in "Domain Settings > Log Management", without directly touching /etc/logrotate.d. If the full space is due to system or service logs not managed by the panel, the du and lsof commands in this guide still apply.

If the disk is full but you can't find anything large

This happens when your VPS has a small disk (common on entry-level plans with 10-20 GB) and the space is simply exhausted by normal use, not by an anomalous file. In this case the problem is the plan, not the configuration: contact your provider's support for a space upgrade or a volume snapshot/resize, attaching the output of df -h and du -x -h --max-depth=1 / so there's no confusion on their end.

Koapanel is a Prime Software product.

Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).