Finding the large files eating your hosting disk space: commands and tips

Disk space on a hosting plan is limited and it usually fills up unnoticed. One day the panel shows 90 percent used, even though you don't remember uploading anything big. In practice the space is taken by a few invisible culprits: forgotten backup archives, bloated log files and extracted copies of an old site. Instead of guessing, you can pinpoint them with a handful of commands.

Top-down: searching by folder

Start from your home directory, find the heaviest folder and drill down level by level with du:

cd ~
du -xh -d 1 2>/dev/null | sort -h

-x keeps du on one file system and -d 1 limits depth to one level. The last line is the biggest folder. Step into it and repeat. If www is the largest, check the specific site next:

du -xh -d 1 ~/www/example.uz 2>/dev/null | sort -h | tail -10

On WordPress sites wp-content/uploads and backup plugin folders inside wp-content usually top the list.

Listing the largest files directly

Sometimes it's easier to see the biggest files of the whole account in one list. This finds files over 50 MB and prints the 20 largest in human-readable sizes:

find ~ -xdev -type f -size +50M -printf '%s\t%p\n' 2>/dev/null \
  | sort -n | tail -20 | numfmt --field=1 --to=iec

The junk is usually obvious: backup-2024.zip, old-site.tar.gz or a multi-gigabyte error_log. If numfmt is missing, drop the last part and sizes will be shown in bytes.

The usual suspects

Backup archives and database dumps

find ~ -xdev -type f \( -name '*.zip' -o -name '*.tar.gz' -o -name '*.sql' \
  -o -name '*.sql.gz' -o -name '*.wpress' \) -printf '%s\t%p\n' 2>/dev/null \
  | sort -n | numfmt --field=1 --to=iec

.wpress files come from the All-in-One WP Migration plugin. Download the latest copy you need and delete the rest. A backup stored next to the site disappears with it if something goes wrong on the server, so it is not real protection anyway.

Bloated logs

PHP often writes errors to an error_log file in the script's folder, and a recurring warning can grow it to gigabytes across many folders:

find ~/www -type f -name 'error_log' -size +5M -printf '%s\t%p\n' \
  | sort -n | numfmt --field=1 --to=iec

Read the last lines with tail -50 error_log first, because they often reveal a real bug that will keep the file growing. Truncate with : > error_log rather than deleting.

Hidden folders

Composer, npm and pip keep caches in ~/.cache, ~/.npm or ~/.composer. These are safe to remove; just leave configuration folders such as .ssh alone.

du -sh ~/.[!.]* 2>/dev/null | sort -h

Example: a school website and lesson videos

A private school in Samarkand runs example.uz on WordPress for news and timetables. Within a month the disk was full. du led to wp-content/uploads, where teachers had uploaded multi-gigabyte lesson videos straight into the media library. Large files from the last week were found with:

find ~/www -xdev -type f -size +20M -mtime -7 -printf '%TY-%Tm-%Td %s\t%p\n' \
  | sort

The videos were moved to a video hosting service with only the player embedded on the site, and the originals were deleted. That freed the disk and also sped up page loads.

What is safe to delete

Cache folders, old logs, extracted archives and old site copies are usually safe to remove. Images in wp-content/uploads, database files, mailboxes and configuration files are part of the site. When in doubt, download the file first or rename it and watch the site for a few days. Without SSH you can check folder sizes in the panel's file manager, and questions about SSH access or plan size can go to sayt.uz technical support.