Running websites from a VPS or dedicated server often comes with the responsibility of ensuring that data is protected through routine backups. Like many web administrators, I trusted cPanel’s backup system, assuming it could handle everything without close supervision. That trust was misplaced. One morning, I logged in only to find my server unresponsive, every alert pointing to a single problem: my disk was full. After some digging, I traced the issue back to the very process designed to protect the system—cPanel’s compressed backups.
TLDR
cPanel’s default backup settings use compression, which can rapidly fill up disk space if not carefully monitored. My server failed due to lack of storage caused by compressed backup archives stacking up unnoticed. Switching to an incremental backup strategy using cPanel’s built-in tools and offsite storage not only preserved space but ensured better long-term reliability. This article walks through how I discovered the problem, the failed solutions, and the final setup that worked flawlessly.
The Calm Before the Storm
For months, I was running daily backups on a busy WordPress multisite network. These backups were configured through cPanel, using the default compressed setting. The assumption was simple: compress files, reduce storage usage, and always have a full-site snapshot at hand. At the time, the idea of having daily full backups seemed like a best practice.
What I didn’t understand was that even with compression, full backups can be incredibly large—especially as databases grow, logs accumulate, and old data is never purged. My server had a 250GB SSD, and between active website files, a heavy MySQL database, email storage, and system files, things began to creep toward capacity without setting off performance alerts—until it was too late.
The Day Everything Froze
The crash didn’t begin slowly. One morning, all websites failed to load, and ssh access simply timed out. The only way back in was through my hosting provider’s emergency console, which confirmed the worst: 100% disk utilization. Digging into root directories showed multiple days of compressed backup tarballs, each ranging from 12 to 16 GB.
The issue was twofold:
- Compressed backups do not remove previous versions unless explicitly configured to do so.
- The backup process didn’t consider available disk space before starting, so creating a new backup would consume the last bit of space—triggering the system to crash.
I had unknowingly set a ticking time bomb by turning on compressed full backups, without setting limits or retention rules.
First Attempt at a Fix
The immediate response was to clean up. I manually deleted several backup archives to reclaim space, restarting the server and checking functionality. Once things were up and running, I disabled compressed backups entirely, believing they were too space-hungry.
Instead, I tried creating manual backups weekly and storing them on Amazon S3 using custom cron jobs. This approach still involved using tar.gz files, and although they were no longer stored locally, generation time for these large files would suspend server processes. Load average would spike during compression, impacting web performance. Clearly, this too wasn’t sustainable.
The Shift: Incremental Backups
After repeated frustrations and near-misses with storage and performance, I returned to cPanel’s backup configuration to rethink my strategy. That’s when I considered enabling incremental backups. The feature, while somewhat buried in the interface, was built specifically for my kind of use case. Rather than taking full backups every day, it stores one uncompressed full backup and updates only the files that have changed since the last snapshot.
The Key Advantages of Incremental Backups:
- Minimal Disk Usage – Only new and modified data is stored, not duplicated files.
- Faster Backup Times – Copying changed files is almost instant compared to compressing entire directories.
- Reduced Server Load – No taxing compression steps, lower CPU usage.
The setting can be enabled via WHM:
- Login to WHM as root.
- Navigate to Backup Configuration.
- Set the backup type to Incremental.
- Specify a remote destination, like Amazon S3, Google Drive, or a secondary server via Rsync or FTP.
One critical note: incremental backups cannot be compressed or split into archives, meaning they must be stored on file-level systems where individual file copies are possible. This might seem less secure at a glance, but it drastically improves reliability and performance.
Further Optimization: Remote Destinations
To truly safeguard data and prevent local disk issues, I added a remote backup destination. cPanel allows for easy integration with:
- Amazon S3
- Google Drive
- Another VPS via Rsync over SSH
- FTP or SFTP servers
I chose Rsync over SSH to a second VPS that I use for development. Rsync handles incremental differential syncing efficiently, and files are always accessible and reviewable in real time—unlike compressed archives that require decompression before inspection.
Retention Policies and Monitoring
After moving to incremental backups, I saw a dramatic drop in disk usage. But backups aren’t just “set and forget”—they require policies and monitoring. I did the following:
- Set retention to 7 daily backups, with weekly and monthly backups enabled for critical recovery.
- Used log monitoring via Logwatch and Cron emails to verify backups complete successfully.
- Automated cleanup of outdated log files and temporary files to prevent creeping storage bloat.
Additionally, I set up an alert using Netdata that warns me if disk usage creeps beyond 70%, giving me proactive control over capacity issues long before emergencies.
Lessons Learned
This experience taught me some hard truths about cPanel backups:
- Default is not always safe. The default backup setting is full + compressed, which can quickly cause disk overflows if not managed properly.
- Storage math is not your friend. Your 250GB disk might hold only 2–3 full compressed backups depending on your web content’s size.
- Monitoring and retention are just as important as the backup itself.
- Remote, incremental backups are the safest, lowest-impact method.
Final Setup that Worked
After trial and error, here’s the setup that’s been rock-solid for over a year without failure:
- Backup Type: Incremental
- Backup Directory: Daily backups stored on local /backup volume (mounted separately)
- Remote Destination: Rsync to offsite VPS nightly
- Retention: 7 daily, 4 weekly, 2 monthly
- Monitoring: Netdata + Cron mail + AWS SMS alerts
Conclusion
Embracing incremental backups was more than a technical fix—it was a strategic shift in how I approached data resilience. cPanel offers powerful backup features, but you need to understand and configure them wisely. By ditching compression in favor of incremental syncing and proper retention, I secured my systems without the added burden of disk space micromanagement.
If you ever experience backup-related storage issues, know that you’re not alone—and that there are proven solutions that work, sustainably and efficiently.
