Disk usage: where the gigabytes actually went

When an account feels full, cPanel disk usage usually shows mail, logs, backups, or leftover home files—not a small CMS install. A 2 GB WordPress site can sit inside a much larger home directory because email and error logs grow quietly for years. Open Disk Usage in cPanel first and read the map before you delete anything under uploads.

Read the Disk Usage map in cPanel

Disk Usage breaks down your home directory so you can see which folders hold the weight. Mail directories, log files, old backup archives, staging copies, and public_html are the usual suspects. Trash in File Manager still counts toward the quota until you empty it. Mail left in server-side Trash still counts as well.

JetBackup copies may count depending on how they are stored on the server. Look at the numbers before you prune. Deleting media at random rarely fixes a full disk when mail or logs are the real problem. Keep SQL dumps out of public_html, because a file like backup.sql.gz can be fetched by a scanner quickly.

Confirm the large folders with du

If you have terminal access, confirm what the panel shows with a short summary of your home directory.

du -xh –max-depth=2 ~ | sort -h | tail

That command lists directories from the bottom up after sorting by size. The last lines are the fattest folders under your account. Do not remove ~/mail only because you use an external provider now. An old catch-all is often the real archive, and deleting it without a download can erase years of mail.

If du and the panel disagree by a wide margin, share both numbers with support. The gap is sometimes inode pressure, and sometimes backup storage the panel handles differently from a simple byte total.

Inodes are a different kind of full

Millions of tiny session files or thumbnails can exhaust inodes while byte usage still looks moderate. A disk can feel full at roughly 40 percent of space when inodes are spent. Use df -i when the byte graph does not match the symptoms you see in cPanel.

The Disk Usage view still helps in that case, even when it will not match a simple capacity chart. Imunify quarantines are usually small and are not where the gigabytes went. Restore those files only after you know what they were and why they were flagged.

Clear space in a safe order

Once the large directory is obvious, the fix is straightforward and careful. Empty File Manager trash, rotate or truncate large error_log files, and move backup archives off the server. Then review uploads only if the map still points there after those steps.

Maildirs grow for a long time when nothing expunges old messages, because many IMAP deletes only move mail into Trash. An error_log under public_html can reach gigabytes from a loop nobody noticed. Work from the map, keep dumps out of the web root, and prune mail only after you have a copy you trust.