Configure Remote Backup Destinations in WHM: S3 & FTP

If your WHM server only backs up to local disk, you don't actually have a backup — you have a copy of your data sitting on the same box that could fail, get compromised, or fill up its disk right along with everything else. WHM's Backup Configuration screen lets you push full and incremental backups straight to Amazon S3, Backblaze B2, or a remote FTP host, but the setup has a few gotchas that trip up even experienced admins. Here's how to do it properly.

Symptom: "We Have Backups" That Won't Actually Save You

This usually surfaces one of two ways. Either a client asks where their offsite backups are and the honest answer is "on the same server," or a restore is needed after a disk failure and the backups went down with the drive. WHM's built-in Backup system defaults to writing to /backup on local storage unless you explicitly configure a remote destination — and a lot of servers get set up once, backups get scheduled, and nobody ever comes back to add offsite storage.

Local-only backups protect you from human error — someone deletes a file, a plugin update corrupts a database. They do nothing for hardware failure, ransomware that encrypts the whole filesystem, or a VPS provider incident that takes the entire node offline.

Cause: Remote Destinations Are a Separate, Optional Step

WHM treats "backups run" and "backups go somewhere safe" as two different settings, and it's easy to configure the first without the second. In WHM > Backup > Backup Configuration, enabling backups and picking a schedule only writes to local disk by default. Remote destinations live in a separate section further down the same page, and if you skip it, WHM won't warn you — it just quietly keeps writing everything to the same disk as your live sites.

Fix: Setting Up S3, Backblaze B2, or FTP as a Backup Destination

1. Get Your Storage Credentials Ready

Before touching WHM, create a dedicated bucket (or FTP account) just for backups — don't reuse one that already holds other data. You'll need:

• Amazon S3: an IAM user with s3:PutObject, s3:GetObject, s3:ListBucket, and s3:DeleteObject permissions scoped to that bucket only — access key and secret key.
• Backblaze B2: an Application Key scoped to a single bucket, plus the bucket's S3-compatible endpoint (Backblaze exposes an S3-compatible API, which is what WHM's "S3 Compatible" destination type expects).
• FTP/FTPS: hostname, port, a dedicated FTP user with write access to a backups-only directory, and the passive/active mode your firewall allows.

Scoping the credentials matters — if the server is ever compromised, you don't want the attacker's first move to be wiping every backup along with the live data. A bucket policy that allows writes but blocks deletes (or a separate read-only key for verification) is worth the extra ten minutes.

2. Add the Destination in WHM

1. Log into WHM as root and go to Backup > Backup Configuration.
2. Scroll to Additional Destinations and click Create New Destination.
3. Pick the destination type: Amazon S3, S3 Compatible (for Backblaze B2, Wasabi, DigitalOcean Spaces, etc.), or FTP.
4. Fill in the bucket name/region (or FTP host/path), then paste in the access key and secret, or FTP credentials.
5. Leave Disable this destination unchecked, but don't check "Retain local backup copies" off yet — you want a local copy while you confirm the remote upload actually works.

3. Validate the Connection Before You Trust It

WHM has a Validate button next to each destination — always click it. It runs a lightweight write/delete test against the bucket or FTP path. If validation fails, it's almost always one of these:

For FTP specifically, check your firewall rules — CSF blocks outbound FTP passive-mode ports by default on a lot of hardened VPS setups, and that shows up as a timeout that has nothing to do with your credentials.

4. Set Retention and Run a Real Test Backup

Under Backup Configuration, set how many daily, weekly, and monthly backups to retain — both locally and on the remote destination. Keeping unlimited history on S3 will quietly grow your storage bill every month, so pick a number you can justify (30 daily, 8 weekly, 6 monthly is a common starting point) and let WHM prune the rest automatically.

Then trigger a manual backup instead of waiting for the nightly cron: WHM > Backup > Backup Configuration > Additional Destinations, or from shell as root:

/usr/local/cpanel/bin/backup --force

Watch /usr/local/cpanel/logs/cpbackup/ (or check the email WHM sends on completion) to confirm the archive actually landed in the bucket, not just on local disk. Log into the S3 console or FTP client separately and look for the file — don't trust the WHM success message alone until you've verified it once by hand.

Prevention: Make Offsite Backups Something You Don't Have to Remember

• Alert on backup failure, not just success. WHM emails on completion, but that email is easy to filter and ignore. Route backup failure notifications to a channel someone actually checks — Slack webhook, PagerDuty, whatever your team uses.
• Test a restore at least once a quarter. A backup that's never been restored is a theory, not a safety net. Spin up a throwaway account or a test VPS and actually pull a backup down and restore it.
• Keep the 3-2-1 rule in mind. Three copies of your data, on two different media, with one offsite. Local WHM backup + S3 bucket in a different region than your VPS covers most of that on its own.
• Rotate credentials periodically and confirm the IAM policy hasn't drifted after any bucket policy changes elsewhere in your AWS account.
• Don't forget email and DNS zone data — full account backups include these, but if you've split backups into pieces (home directory only, for example), double-check mail and DNS zones are actually part of what's shipping offsite.

Frequently Asked Questions

Does WHM support Backblaze B2 directly, or do I need the S3-compatible option?

Use the "S3 Compatible" destination type and point it at Backblaze's S3-compatible endpoint for your bucket's region (found in the B2 bucket details page). There's no dedicated "Backblaze" option in WHM — the S3-compatible type covers it along with Wasabi, DigitalOcean Spaces, and similar providers.

Will remote backups slow down my server during the backup window?

Upload happens after the local archive is created, so it adds time to the overall backup job (bounded by your upload bandwidth) but doesn't add CPU load beyond the normal compression step. On a VPS with a slow or capped uplink, schedule backups for off-peak hours and consider WHM's bandwidth throttling option under Backup Configuration if the upload is competing with live traffic.

Can I keep local backups AND send them offsite, or is it one or the other?

You can do both — that's the recommended setup. Keep a short local retention window for fast restores of recent accidents, and a longer remote retention window on S3/B2 for disaster recovery. Just watch your local disk usage if you keep both for long retention periods.

My validation test passes but the actual backup never shows up in the bucket. What's wrong?

Validation only tests a small write/delete operation, not a full transfer. A full backup failing separately is usually a timeout on large accounts (check /usr/local/cpanel/logs/cpbackup/ for the specific error), an IAM policy that allows small test objects but has a size or prefix restriction, or the destination running out of storage quota mid-upload.

Is it safe to give WHM's backup user delete permissions on the bucket?

Only if you're relying on WHM's automatic retention pruning to remove old backups — in which case it needs s3:DeleteObject to work. If you'd rather backups be immutable from the server's perspective (protecting against ransomware that could otherwise wipe your offsite copies too), skip delete permissions and manage retention with a bucket lifecycle policy on the storage provider's side instead.