cPanel Backup Destinations: Auto-Send Backups to S3/FTP

Your server dies, gets compromised, or the disk fills up — and you go to grab a backup only to realize it was sitting in the same home directory the whole time. cPanel's default backup destination is "right here on this server," which is exactly the one place a backup shouldn't live if you actually need it during an outage. Here's how to configure a real offsite destination so that stops happening.

Symptom: your only backup copy lives on the server that just failed

This usually surfaces at the worst possible time:

• A VPS goes down hard (disk failure, provider issue, a botched kernel update) and the backup archives on that same disk are gone with it.
• You run Backup Wizard → Download a Full Website Backup, and it saves quietly to the home directory — nobody ever moves it off.
• JetBackup or cPanel's built-in scheduler has been running for months, but every backup point is local, so a full account compromise wipes the site and its history in one shot.
• Support asks for a restore point and the honest answer is "we don't have one that isn't also broken."

None of this is a cPanel bug. It's a configuration gap — nobody ever pointed backups at a second location.

Cause: cPanel doesn't send backups offsite unless you tell it to

By default, both the stock cPanel backup tool and most JetBackup installs write to local storage: the account's home directory, or a separate partition on the same physical server. That's fine for quick "undo my last mistake" restores, but it does nothing for disaster recovery — if the box is gone, so is the backup.

WHM has a dedicated feature for this exact problem, tucked under Backup Configuration → Additional Destinations. It lets you push completed backups to an external location automatically: Amazon S3, an FTP/SFTP server, WebDAV, Google Cloud Storage, or a second server entirely. JetBackup has the equivalent under Destinations in its own settings panel. Either way, the concept is the same — a backup only counts as safe once it exists somewhere other than the server it protects.

Fix: set up an S3 (or FTP) backup destination

Option 1 — Amazon S3 (or any S3-compatible bucket)

This is the most common setup because S3 storage is cheap, durable, and doesn't depend on your hosting provider staying online.

1. In AWS, create a dedicated S3 bucket just for backups — don't reuse one that's already serving other traffic. Enable versioning if you want extra protection against a bad backup silently overwriting a good one.
2. Create an IAM user with programmatic access only (no console login) and attach a policy scoped to that single bucket — s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject. Don't hand it your root AWS credentials; if the server is ever compromised, you want the blast radius limited to the backup bucket.
3. In WHM, go to Backup → Backup Configuration → Additional Destinations → Create New Destination.
4. Set Destination Type to Amazon S3, give it a name, and enter the bucket name, region, Access Key, and Secret Key from the IAM user.
5. Click Validate Destination before saving. WHM performs a test upload/delete against the bucket — if this fails, fix it now rather than finding out after your next scheduled run.
6. Back on the main Backup Configuration screen, make sure the destination is enabled and, if you want to keep local copies too, leave "Retain local backups" checked.

Option 2 — FTP or SFTP to a second server

If you'd rather not deal with cloud storage billing, pushing backups to a second VPS or a NAS over SFTP works just as well.

1. Backup → Backup Configuration → Additional Destinations → Create New Destination, then choose FTP or SFTP as the type.
2. Point it at the remote host, port, and a dedicated backup-only account (not your main SSH user) with write access limited to a single backup directory.
3. For SFTP, use key-based auth if the destination supports it — one less password sitting in a config file.
4. Validate the destination, then check Backup Configuration to confirm the scheduled backup job actually includes this destination and not just the local one.

JetBackup users

The steps are nearly identical, just under a different name: JetBackup → Settings → Destinations → Create Destination, then attach it to your existing backup jobs under Backup Jobs → Edit → Destinations. JetBackup will show per-destination status on each completed job, which makes it easy to spot a destination that's silently failing.

Common destination errors

Prevention: make offsite backups something you don't have to remember

• Automate the schedule. Manual "I'll back it up before this update" habits break the first time you're in a hurry. Set a daily or weekly job and let it run.
• Set retention on the remote end too. Cloud storage costs scale with what you keep — decide how many restore points you actually need (7 daily, 4 weekly is a reasonable start) and let old ones expire automatically.
• Test a restore from the offsite copy at least once. A destination that validates fine during setup can still produce an archive you can't actually restore from months later — you want to find that out on a quiet Tuesday, not during an incident.
• Watch for silent failures. Turn on email notifications for failed backup jobs in WHM or JetBackup so a broken destination doesn't go unnoticed for weeks.
• Keep the offsite credentials out of the backup archive itself. If your IAM keys or FTP password end up inside a config file that's part of the backup, a leaked archive leaks the destination too.

None of this is complicated once it's set up — the whole point is that it then runs quietly in the background, and the day you actually need it, the backup is already somewhere the failing server can't take down with it.