Most disk-full outages don’t come from “a big website.” They come from quiet, steady growth. Logs never rotate, backups duplicate, caches stick around, and mail queues never drain.
This server storage cleanup tutorial shows you how to reclaim space safely on a hosting VPS or dedicated server. It also adds guardrails so you’re not back here next month.
These steps assume a Linux hosting box (Ubuntu 24.04 LTS, Debian 12/13, AlmaLinux 9/10, Rocky 9/10). The stack is typical: Nginx/Apache, PHP-FPM, MySQL/MariaDB, Postfix/Exim, and possibly cPanel/WHM.
Run the commands as written. Pause long enough to confirm what you’re deleting and why.
Before you delete: confirm what’s actually full
Do the boring checks first. They keep you from “cleaning” the wrong mount.
This mistake is common on servers with a separate /var or attached storage.
-
Check overall usage:
df -hTLook for filesystems at 85%+ usage. Write down the mount point and filesystem type.
-
Find the biggest directories on the full mount:
sudo du -xhd1 /var | sort -h-xkeeps the scan on the same filesystem. That way you don’t chase numbers from another mount. -
Confirm which files are “hot” right now:
sudo find /var -xdev -type f -size +500M -printf '%s %p\n' | sort -n | tail -n 30This quickly surfaces runaway logs, oversized caches, and forgotten archives.
If the server is already erroring (503s, failed cron, failed writes), make breathing room first. Start with low-risk moves like clearing package caches (see below).
If you need an outage-friendly workflow for “No space left on device,” follow our VPS disk space troubleshooting tutorial. Then come back here for long-term prevention.
Quick relief checklist (safe, reversible, and fast)
These usually free hundreds of MB to several GB. They won’t touch your site content.
-
APT (Ubuntu/Debian):
sudo apt-get clean sudo apt-get autoremove --purge -y -
DNF/YUM (AlmaLinux/Rocky):
sudo dnf clean all sudo dnf autoremove -y -
Journal logs (systemd): keep the last 7 days (adjust as needed):
sudo journalctl --disk-usage sudo journalctl --vacuum-time=7d -
Tmp cleanup (do not delete random app temp dirs):
sudo systemd-tmpfiles --clean
Re-check usage after each step. This tells you what actually helped:
df -h
Find “deleted but still taking space” files (the classic trap)
Linux won’t reclaim space from a deleted file if a process still has it open.
That’s why “I deleted a 5GB log and nothing changed” is so common.
Find deleted-but-open files like this:
sudo lsof +L1 | awk '{print $7, $9, $1, $2}' | sort -n | tail -n 25
If you see a large deleted file (often *.log) held by Nginx, PHP-FPM, or a mail service, restart the service. That releases the disk blocks:
sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm 2>/dev/null || true
sudo systemctl restart apache2 2>/dev/null || true
On cPanel servers you may also use service scripts. On most modern deployments, systemctl is still the right tool.
Log cleanup you can trust: logrotate + sane retention
Logs pay for themselves—until they don’t. The goal isn’t “delete logs.”
The goal is to rotate them, compress them, and cap retention.
Step 1: confirm logrotate is running
Most distros run logrotate daily via a systemd timer or cron.
sudo systemctl status logrotate.timer 2>/dev/null || true
sudo ls -l /etc/cron.daily/logrotate 2>/dev/null || true
Step 2: identify noisy logs
Start where the growth is happening:
sudo du -h --max-depth=1 /var/log | sort -h
Common offenders on hosting nodes:
/var/log/nginx/or/var/log/apache2/(access logs under bot load)/var/log/php*-fpm.log(warnings repeating per request)/var/log/maillog,/var/log/exim_mainlog(bounces, spam bursts)/var/log/mysql/(enabled slow logs with no cap)
Step 3: apply a tight, hosting-friendly rotation policy
Create a custom logrotate rule. Example for Nginx on Ubuntu/Debian:
sudo nano /etc/logrotate.d/nginx-custom
/var/log/nginx/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -s /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
endscript
}
Test it before you rely on it:
sudo logrotate -d /etc/logrotate.d/nginx-custom
sudo logrotate -f /etc/logrotate.d/nginx-custom
If access logs balloon because of crawlers, fix the traffic pattern too. Rotation alone won’t stop the growth.
Add rate limiting or bot-block rules; our Nginx rate limiting tutorial is the next logical step.
Clean caches the right way (OS, PHP, and app layers)
Caches should be disposable. If you can’t throw it away safely, it’s not a cache.
It’s untracked storage.
OS package caches
If you skipped the quick relief section, go back and do it. Package cache cleanup is high-impact and low-risk.
PHP session bloat
On busy PHP servers (WordPress, WooCommerce), session files can pile up. They usually live under /var/lib/php/sessions or a similar path.
sudo du -sh /var/lib/php/sessions 2>/dev/null || true
sudo find /var/lib/php/sessions -type f -mtime +7 -delete 2>/dev/null || true
Adjust +7 to match your application’s session behavior.
If you need long-lived sessions, tune PHP’s session.gc settings instead of deleting in bulk.
WordPress cache plugins and Nginx FastCGI cache
If you run Nginx FastCGI cache, it’s usually under /var/cache/nginx or a custom path.
sudo du -sh /var/cache/nginx 2>/dev/null || true
Avoid wiping caches mid-peak unless you’re ready for a load spike. Prefer your configured purge method, or schedule a controlled cleanup window.
If you want a cache that stays fast without turning into a disk bomb, set strict cache keys and size limits. See our FastCGI cache setup guide for WordPress.
Mail spool and queue cleanup (hosting’s silent disk killer)
Mail problems often show up as disk usage. Deferred messages keep retrying. Spam floods mailboxes.
Bad routing can create a bounce loop that never ends.
Step 1: measure mail storage
-
Postfix (common on VPS mail stacks):
sudo du -sh /var/spool/postfix 2>/dev/null || true sudo postqueue -p | tail -n 50 -
Exim (common on cPanel):
sudo du -sh /var/spool/exim 2>/dev/null || true sudo exim -bp | tail -n 50
Step 2: fix the cause before purging
If you delete the queue without fixing routing/auth, it will come right back.
For common causes and safe cleanup, use our mail queue troubleshooting tutorial.
If the backlog is really a deliverability problem (SPF/DKIM/DMARC or PTR), you’ll get better results by aligning authentication; this guide covers it: email authentication setup guide.
Step 3: controlled queue deletion (only after validation)
Examples (use carefully):
-
Postfix: delete all deferred mail (common during provider outages):
sudo postsuper -d ALL deferred -
Exim: remove all messages older than 3 days:
sudo exiqgrep -o 259200 -i | sudo xargs -r exim -Mrm
If you host mailboxes, also check for oversized IMAP storage (Maildir growth). On cPanel this is usually under /home/*/mail.
cPanel/WHM-specific storage hotspots (backups, logs, and user data)
On reseller and shared-style cPanel servers, usage grows across many accounts.
Backups and service logs can tip you over faster than you expect.
Check what’s large in /home and /backup
sudo du -xhd1 /home | sort -h | tail -n 30
sudo du -xhd1 /backup 2>/dev/null | sort -h || true
Typical culprits:
- Multiple generations of full-account backups stored locally
- Softaculous or app installers caching archives
- Large
error_logfiles inside public_html - Hidden
.trashdirectories from FTP clients
Fix runaway “error_log” files in user directories
Find large error logs under user homes:
sudo find /home -type f -name error_log -size +200M -print
Before you truncate anything, open the log. Look for the repeating error.
Then truncate safely. This keeps the inode and avoids permission surprises:
sudo truncate -s 0 /home/USERNAME/public_html/error_log
If it refills quickly, you’re looking at an application bug or PHP misconfiguration. It’s not “a disk issue.”
Docker and container images (only if you actually run them)
If you run Docker on your VPS, image layers and unused volumes can quietly eat tens of GB.
Measure first:
docker system df 2>/dev/null
Then prune conservatively:
docker image prune -a
docker container prune
Do not run docker system prune --volumes unless you’re sure volumes are disposable. Volumes often hold databases or uploaded content.
Prevent a repeat: add disk alerts and automated guardrails
Cleaning buys you time. Alerts and limits keep you from spending that time later.
Set a simple disk usage alert (quick and effective)
Create a small script that checks disk usage and logs a warning (or emails you via your preferred method).
This example writes to the journal. It also returns a non-zero exit code for monitoring tools:
sudo nano /usr/local/sbin/diskcheck.sh
#!/usr/bin/env bash
set -euo pipefail
THRESHOLD=85
OUT=$(df -P -x tmpfs -x devtmpfs | awk 'NR>1 {print $5" "$6}')
ALERT=0
while read -r pct mount; do
pct=${pct%%%}
if [ "$pct" -ge "$THRESHOLD" ]; then
echo "$(date -Is) WARN disk usage ${pct}% on ${mount}" | systemd-cat -t diskcheck
ALERT=1
fi
done <<< "$OUT"
exit $ALERT
sudo chmod +x /usr/local/sbin/diskcheck.sh
sudo /usr/local/sbin/diskcheck.sh || echo "Disk usage above threshold"
Schedule it daily:
sudo crontab -e
15 2 * * * /usr/local/sbin/diskcheck.sh
If you want a more complete monitoring setup (uptime + CPU/RAM + disk + log checks), follow our server monitoring tutorial.
Cap journald growth permanently
Edit:
sudo nano /etc/systemd/journald.conf
Set reasonable caps (example):
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=7day
sudo systemctl restart systemd-journald
Make logrotate stricter where it matters
For high-traffic sites, rotate access logs daily and keep 7–14 days compressed.
For application error logs, 30 days is usually enough unless compliance requires more.
Storage hygiene checklist for hosting servers (printable)
- Keep root filesystem under 70% in steady state; treat 85% as “fix now.”
- Rotate and compress web + mail logs; cap retention.
- Vacuum journald; set size limits in
journald.conf. - Use truncation for huge live logs instead of deleting open files.
- Audit
/homefor user-level runaway logs (error_log), caches, and trash folders. - Fix mail queue causes before queue deletion (routing/auth/DNS).
- Add alerts for disk usage and inode usage (
df -i) if you host many small files. - Document what “safe to delete” means on your stack, and stick to it.
Where HostMyCode fits (keeping the boring problems boring)
If you’re done firefighting storage and want a steady platform for real workloads, start with a HostMyCode VPS sized for your traffic and retention needs.
If you’d rather not babysit updates, monitoring, and maintenance, managed VPS hosting keeps disk incidents from turning into downtime.
Running multiple sites or reseller-style hosting? HostMyCode gives you room to grow without playing “disk roulette” every month. Pick a HostMyCode VPS for hands-on control, or choose managed VPS hosting if you want the guardrails handled for you.
FAQ
Is it safe to delete log files directly?
Usually not. If a process keeps the file open, deleting it won’t free space until the process restarts. Prefer logrotate or truncate, then restart the service if needed.
Why did free space not increase after I deleted a huge file?
Most often, the file was still open. Run lsof +L1 to find deleted-but-open files and restart the owning service to release the disk blocks.
What’s the safest “emergency cleanup” on a production hosting VPS?
Cleaning package caches and vacuuming journald are generally safe. After that, focus on identifying the biggest log or spool directories rather than deleting random app data.
Should I keep backups on the same disk I’m trying to protect?
No. Local backups help with quick restores, but they don’t protect against disk failure or full-disk incidents. Keep at least one offsite copy and test restores regularly.
How do I stop access logs from growing too fast?
Rotate daily and compress, then reduce noise: rate limit abusive traffic, block known bad bots, and avoid logging excessive request details unless you’re actively debugging.
Summary: reclaim space now, then make it hard to regress
Use df and du to find the real pressure point.
Free quick space with package cache cleanup and journald vacuuming.
Then work through the usual suspects: logs, mail spools, user-home bloat, and deleted-but-open files.
Once the server is stable again, add alerts and stricter rotation so the fix actually sticks.
If you want a hosting platform where capacity planning and routine maintenance don’t turn into a monthly outage drill, run your sites on HostMyCode VPS or hand the operational load to managed VPS hosting.