Send WHM Backups to a Remote SFTP Destination

WHM can send scheduled backups to an additional remote destination. Use an encrypted destination such as SFTP rather than ordinary FTP, because full backups can contain databases, email and credentials. Remote storage improves separation from the source server, but it does not remove the need for local backup and restore space.

Plan storage before configuring delivery

This is a WHM administrator task, not an ordinary cPanel-account setting. Confirm which accounts and components are selected for backup, the backup format and schedule, local free space, remote capacity and retention. Keep the available-disk-space check enabled and allow room for a slow or failed transfer.

Backup creation and transport use separate queues. Archives can accumulate locally if creation outpaces delivery. Do not rely on the old assumption that each account always finishes uploading before the next account is backed up. Incremental WHM backups support Rsync additional destinations, not this SFTP workflow.

Add an SFTP destination

1. Open WHM > Backup > Backup Configuration and review the enabled backup settings and selected users.
2. Open Additional Destinations, select SFTP and create a destination with a recognizable name.
3. Enter the remote hostname, SSH/SFTP port, remote username and the backup directory relative to that user’s home directory. The documented default port is 22; use the actual configured port.
4. Use a dedicated backup account with access only to its private backup directory. Choose key authentication where supported, install the corresponding public key on the intended destination, and protect the private key and passphrase on the source. Confirm the server identity through your approved SSH setup process.
5. Decide whether system backups belong on this destination and ensure it is not configured for log files only. Save and validate the destination, then save the overall configuration.

Validate more than the connection

Destination validation checks connectivity/configuration; it is not a restore test. During an agreed low-load window, monitor a scheduled backup and its transport results. A forced backup can impose significant CPU, disk and network load, so this guide does not ask readers to force a production run simply to try the destination.

Inspect failures in the relevant backup and transport logs. Confirm that expected account archives actually arrive, dates and retention match the policy, and incomplete uploads are not treated as successful backups. Check that remote files are not exposed through a website or anonymous sharing.

Prove recovery before relying on the destination

Retrieve a representative archive through an authenticated encrypted route and restore it into a separate authorized test environment. Verify the required website, databases and mail rather than only checking archive size. Plan local staging capacity for a remote restore.

Retaining local copies is a separate decision from remote retention. Do not disable the last working recovery path merely to reclaim disk space. A remote account with the same delete-capable credentials is not automatically immutable or protected against compromise of the source server.

Reference: WHM Backup Configuration documentation. Reviewed October 14, 2026. The old FTP-oriented URL is retained for existing links, but the recommended delivery workflow is now SFTP. No customer backup transport or restore was executed.