WHM Backup Configuration Tutorial (2026): Schedule, Store, and Test cPanel Server Backups Correctly

Most WHM backup disasters have nothing to do with missing backups. They happen because nobody tested the ones that existed.

An admin sets up the default schedule once, then walks away. Six months later, the remote destination has quietly stopped accepting uploads. By then, the local copies have rotated out too.

This tutorial covers WHM backup configuration the way it should actually work: what to back up, where to store it, and how to schedule it without hammering disk I/O. It also covers how to confirm a restore works before you're forced to rely on one. If you run a shared hosting box, a reseller account, or your own VPS hosting with WHM, this applies to you directly.

Where WHM Backup Configuration Lives

Log into WHM as root and go to Backup > Backup Configuration. This is the master switch for the whole system. Destinations, retention, per-account overrides — it all branches off from here.

Enable backups at the top of the page, then pick a backup type. WHM gives you two options:

• Compressed — smaller files, slower to generate, easier to move offsite
• Uncompressed — faster to create, larger footprint, better if you're backing up to fast local storage

On a typical shared hosting node running 100+ accounts, compressed is almost always the right call. The CPU overhead is manageable on modern hardware. And the bandwidth savings on remote uploads add up fast — often 60-70% smaller than uncompressed archives.

Setting Retention and Schedule Without Killing Disk I/O

Retention settings control how many daily, weekly, and monthly backups WHM keeps. A reasonable starting point for a reseller or shared box:

• Daily: keep 4-5 copies
• Weekly: keep 2-3 copies
• Monthly: keep 1 copy

Don't set daily retention higher than your disk can actually support. If each backup cycle runs 40GB and you're keeping 7 daily copies plus weeklies, that's 300-400GB of dedicated backup headroom on top of live account data. Run df -h /backup before committing to numbers.

For scheduling, WHM lets you pick a backup window. Run full-account backups overnight, ideally 2-4 hours after your busiest traffic period ends. On a dedicated server hosting 200+ cPanel accounts, start the process a bit earlier. It can take 3-5 hours depending on total data volume.

Choosing Backup Destinations

Never rely solely on local disk. If the server's storage fails, your backups fail right along with it. WHM supports several remote transport types under Additional Destinations:

• Amazon S3 (or S3-compatible storage like Backblaze B2, Wasabi)
• SFTP/FTP to a separate server
• WebDAV
• Google Cloud Storage

SFTP to a secondary VPS is the most common setup for small-to-mid hosting operations. Create a dedicated backup user with a locked-down shell. Generate an SSH key pair, then configure WHM to authenticate with the key instead of a password.

In WHM, go to Backup > Additional Destinations, select SFTP, paste in the private key, and run the test transfer WHM offers before saving.

If you're pushing backups to another region for disaster recovery, a low-cost VPS in Amsterdam or a similarly separate location works well as a dedicated backup target. Keep it isolated: no public-facing services, SSH key auth only, and firewall rules limiting access to your production server's IP.

Per-Account Backup Overrides

Not every account needs the same treatment. A client running a 2GB brochure site doesn't need daily full backups. A WooCommerce store with constant order activity does.

Under Backup > Backup User Selection, you can exclude accounts from the global schedule. In newer WHM versions, you can also set account-level backup frequency through user manager.

For high-value accounts, pair WHM's native backups with application-level backups. A WordPress plugin doing database exports every 6 hours gives you a tighter recovery point than a nightly full backup alone.

For email-heavy accounts, remember mail data gets included in full backups by default. It's often the single largest component. Check account sizes with:

du -sh /home/*/mail/* | sort -rh | head -20

This shows you which accounts are bloating your backup windows with mailbox data. A 15GB mailbox archive nobody reads still gets copied in full, every single cycle.

Verifying the Backup Actually Restores

This is the step almost everyone skips, and it's the one that matters most. A backup file sitting on disk tells you nothing about whether it will restore cleanly.

Pick one account a month and run a real restore test on a spare VPS or sandbox WHM environment:

1. Spin up a test server with WHM installed (a low-cost VPS works fine for this)
2. Transfer the backup archive to /home/cpmove-username.tar.gz
3. Run /scripts/restorepkg username
4. Confirm the domain resolves, the database loads, and email accounts are intact
5. Check file ownership and permissions didn't shift during restore

Log the test date and result somewhere your team can see it. You want a failed restore to surface during a controlled test, not during an actual outage at 2am.

For a deeper walkthrough of this exact process inside WHM, see our cPanel backup verification tutorial. It covers running restore tests without touching the live account, which matters if you're verifying production data.

Common Pitfalls in WHM Backup Configuration

• Ignoring failed transfer notifications — WHM emails you when a remote destination fails, but if that alert lands in an inbox nobody checks, you won't notice until it's too late.
• Backing up to the same physical disk — a local backup directory on the same RAID array as live data protects against accidental deletion but not hardware failure.
• No monitoring on backup job duration — if backups that used to take 2 hours start taking 8, something's wrong, usually disk I/O contention or a bloated account.
• Skipping the actual disaster scenario — restoring a single account is a different problem than rebuilding a full server from scratch. Test both, periodically.

It also helps to pair this with broader server monitoring, so backup job failures surface alongside resource alerts. Our server monitoring tutorial covers alerting for stalled cron jobs, which applies directly to backup scripts that quietly stop running.

If you're managing this from a reseller account rather than a full WHM/root server, your options are more limited. You're largely dependent on what your provider configures at the package level. Our WHM account package setup guide covers building reseller plans with backup allowances baked in from the start.

FAQ: WHM Backup Configuration

How often should WHM backups run on a shared hosting server?

Daily incremental or full backups for active accounts is standard. If disk I/O is a concern, run full backups nightly and add database-only backups more frequently for high-transaction sites like WooCommerce stores.

Can I back up directly to Amazon S3 from WHM?

Yes. WHM has native S3 support under Additional Destinations. Use an IAM user with write-only access scoped to a specific bucket — don't use root AWS credentials.

Why do my WHM backups keep failing partway through?

Usual suspects: running out of disk space mid-backup, a remote destination timing out on large transfers, or a corrupted account (often a database with orphaned tables). Check /var/cpanel/logs/cpbackup for the specific error.

Should I use JetBackup instead of native WHM backups?

JetBackup adds a nicer UI, incremental backups, and faster restores, but it's a paid add-on. For smaller operations, native WHM backup configuration is usually enough if it's set up correctly and tested regularly.

How do I know if a backup will actually restore?

Run a test restore on a separate VPS using /scripts/restorepkg. That's the only way to confirm a backup is usable — file size or timestamp tells you nothing about integrity.