You've already cleared the cPanel trash, emptied the access logs, and deleted old backups. But your disk is still groaning at 92%.
When the basic cleanup scripts fail, you need surgical tools. These eight advanced moves target the hidden space hogs on a cPanel server—the ones that don't show up in WHM's disk usage report but quietly fill inodes and eat gigabytes. I've pulled these from real tickets where df -h said 40G used but du -sh /home showed only 20G. Something was always leaking.
1. Find the Real Disk Hogs with ncdu
df -h lies by omission. It shows filesystem totals, not directory-level truth. Before you delete anything, run ncdu (install it if missing: yum install ncdu or apt install ncdu).
ncdu / --exclude /proc --exclude /sys
This gives an interactive, sortable view. Watch for three usual suspects:
/var/lib/mysql— binary logs can chew 5-20 GB if never rotated./home/<user>/mail— accumulated spam and attachments./root/cpmove-*— leftover migration files that cPanel never removed.
Start here. Don't guess.
2. Purge Old MySQL Binary Logs
MySQL binary logs replicate and point-in-time recover. If you don't use either, they're just disk sponges. Even on replicas, you rarely need more than two days of logs.
First check what's there:
mysql -e "SHOW BINARY LOGS;"
Then set an expiration in my.cnf (typically /etc/my.cnf):
expire_logs_days = 2
Restart MySQL or run FLUSH LOGS;. To purge manually without restart:
mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 2 DAY;"
Sometimes the logs are already expired but not removed due to crash recovery state. Run RESET MASTER only if you're absolutely sure no replication depends on them. On a standalone server, it's safe.
3. Reclaim Space from Systemd Journal Logs
Journal logs persist forever by default on most distros. A busy server can accumulate GBs of historical service noise.
Check current usage:
journalctl --disk-usage
Vacuum down to, say, 200 MB:
journalctl --vacuum-size=200M
Set this in /etc/systemd/journald.conf to prevent future bloat:
SystemMaxUse=200M
MaxFileSec=2week
Then restart the journal service:
systemctl restart systemd-journald
Don't skip the restart—it releases the freed space back to the filesystem.
4. Clear Bloated Maildirs and Spam
Email is the #1 cause of mysterious disk usage on shared cPanel accounts. Users hoard newsletters and spam filters keep quarantined copies.
For each user, run:
sudo -u <user> du -sh /home/<user>/mail/
If a Maildir is over 2 GB, it's probably junk. Move the entire directory aside rather than deleting blindly:
mv /home/<user>/mail /home/<user>/mail_old
Then let the user recreate their mail structure. After a week with no complaints, delete the backup.
To purge spam queue (Exim):
exim -bp | awk '/^ / {print $3}' | xargs exim -Mrm
This removes all messages in the frozen queue. Use with caution—some messages are valid retries.
5. Remove Orphaned cPanel Backups
cPanel backup scripts can leave partial files behind, especially after failed transfers. Check these directories:
/backup— full cPanel backups (often GBs)./home/cpmove-*— leftover migration tarballs./root/cpbackup/— daily incremental backups if you use the built-in backup tool.
Find and delete files older than 30 days:
find /backup -type f -mtime +30 -delete
find /home -maxdepth 1 -name 'cpmove-*' -mtime +30 -delete
Better: configure backup retention in WHM >> Backup Configuration >> Retention. Set it to 7 days max for daily backups.
6. Tame Apache Logs
Apache logs rotate via logrotate, but many servers retain 52 weekly logs by default. That's overkill.
Check /etc/logrotate.d/httpd (or apache2). Change:
rotate 4
compress
missingok
notifempty
Then force a rotation:
logrotate -f /etc/logrotate.d/httpd
Consider reducing LogLevel from warn to error in httpd.conf for production:
LogLevel error
Fewer logs written = less disk churn.
7. Free Up Inodes (Too Many Small Files)
A disk might show 30% used but still hit 100% inode usage. This breaks everything: email delivery, cron, even SSH logins.
Find the worst offenders:
find / -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -n
Common culprits:
- PHP sessions in
/tmpor/var/lib/php/session— clear old ones:
find /var/lib/php/session -type f -mtime +2 -delete
- Maildir
cur/directories with thousands of tiny messages. - SpamAssassin Bayes databases (look for large
.bayesfiles under/home/*/.spamassassin). - Custom logs inside user home directories.
For Maildirs, move old messages into a single archive mbox file per user:
# inside a user's home
formail -s < mail/cur/* > old_mail.mbox
rm -rf mail/cur/*
That collapses thousands of files into one.
8. Tune PHP Sessions and Opcache
PHP stores session files per visitor. Busy sites can accumulate millions of stale sessions if the garbage collector sleeps.
Set session.gc_probability = 1 and session.gc_divisor = 100 in php.ini (both already default, but check they aren't overridden). For cPanel, edit /opt/cpanel/ea-php*/.../php.ini.
Also flush Opcache regularly to free memory (not disk space, but inode-stressed servers benefit from fewer cached files):
php -r 'opcache_reset();'
Or via a cron job:
0 3 * * * /usr/bin/php -r 'opcache_reset();'
FAQ
How do I check disk usage per cPanel user from the command line?
repquota -a
If quotas are enabled. Otherwise use:
du -sh /home/* --exclude=/home/cpmove-* 2>/dev/null | sort -rh | head
Is it safe to delete MySQL binary logs on a production server?
Only if you don't need point-in-time recovery or replication. If you do replication, set expire_logs_days = 2 and purging is safe. Without replication, you can safely remove all but the most recent log after a clean restart. Run PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY; to keep one day.
What if my disk space is fine but inodes are full?
That's almost always a Maildir or PHP session issue. Check /home/*/mail for millions of tiny files. Delete old sessions after 1-2 days. For email, consider moving users to IMAP with quotas set low.
What to check first each month
Disk space doesn't disappear overnight. Set up a monthly cron:
0 6 1 * * /usr/sbin/df -h / | mail -s "Disk Usage $(hostname)" [email protected]
0 7 1 * * /usr/bin/journalctl --vacuum-size=200M > /dev/null 2>&1
0 8 1 * * /usr/bin/find /home -maxdepth 1 -name 'cpmove-*' -mtime +30 -delete
Monitor the three leaky buckets: binary logs, journal logs, and Maildirs. Catch them early and you'll never panic over a full disk again.