cPanel Disk Usage Shows More Than Real Files? Fix It

Most Common Cause: Missing Log Files That cPanel Counts But You Can't See

Here's the thing. cPanel doesn't just count your website files. It also counts stuff like Apache logs, error logs, and FTP logs. And these logs can get huge fast. Had a client last month whose cPanel showed 12GB used, but his WordPress site files were barely 2GB. The culprit was a 10GB Apache access log file from a bot hitting his site for months.

cPanel stores these logs in /usr/local/cpanel/logs or /var/log/apache2 for each domain. You won't see them in your file manager or FTP. But cPanel's disk usage calculation counts them. So your usage looks bigger than your actual files.

How to check and fix it

1. SSH into your server as root.
2. Run:

   du -sh /var/log/apache2/* /var/log/maillog /usr/local/cpanel/logs/error_log 2>/dev/null | sort -rh | head -10

3. Find any log file bigger than 100MB. That's your problem.
4. Delete or rotate them:

   truncate -s 0 /var/log/apache2/access.log

5. Then set up log rotation so it doesn't come back. Edit /etc/logrotate.d/apache2 and set size to 50M and rotate daily.

After you truncate, run whmapi1 updatequota from SSH to force cPanel to recalculate. Done.

Second Cause: MySQL Temp Tables and Binary Logs Not Cleaned Up

Another common one. MySQL creates temporary tables when queries run. If a query crashes or times out, those temp files stay behind. They live in /tmp or /var/lib/mysql and can be gigabytes each. I've seen one client whose MySQL tmp directory had a 15GB temp file from a failed WooCommerce import. cPanel counted that as disk usage but the client couldn't see it in their account.

Also, MySQL binary logs (mysql-bin.000001 type files) keep growing if not purged. These record every change to the database. They're important for replication but useless if you don't need point-in-time recovery.

How to fix it

1. Check MySQL temp files:

   ls -lh /tmp | grep -E '^.*#sql.*|^.*ibdata.*'

2. If you see big files, stop MySQL, delete them, restart MySQL.
3. Clear binary logs:

   mysql -u root -p
   PURGE BINARY LOGS BEFORE NOW();
   EXIT;

4. Set automatic purge in MySQL config (/etc/my.cnf):

   [mysqld]
   expire_logs_days = 3

   Then restart MySQL.
5. Run whmapi1 updatequota again.

Skip this if you need binary logs for replication to a slave. Otherwise, purge them. They waste space.

Third Cause: Stale Backups and cPanel Backup Files

cPanel can store its own backups inside your home directory. If you have cPanel backup enabled in WHM, it might be dumping full account backups into /backup or /home/username/backup. These backups include everything — databases, emails, files — so they double-count your disk usage. Had a client who thought he had 20GB of files, but half was his own weekly backups piling up.

Also, cPanel's cpbackup feature creates incremental backups that stay on disk. If the backup rotation isn't set right, they never get cleaned up.

How to fix it

1. Check backup directory:

   du -sh /backup/* /home/*/backup/ 2>/dev/null

2. Look for .tar.gz or .tar files larger than 100MB.
3. Delete old ones:

   find /backup -name '*.tar.gz' -mtime +7 -delete

4. In WHM, go to Backup Configuration and set retention to 7 days max. Also disable storing backups on the same disk if possible.
5. Run whmapi1 updatequota again.

If you use a third-party backup service like JetBackup or R1Soft, check their directories too. Same problem.

Quick-Reference Summary Table

After each fix, run whmapi1 updatequota to make cPanel recalculate. Don't skip that step. cPanel won't update itself right away. Good luck.