cPanel/WHM Remote Backup to FTP or S3 Failing? Here's How to Fix It

SSH into your cPanel server as root and tail the transport log:

tail -200 /usr/local/cpanel/logs/cpbackup_transporter.log

This log records every remote backup transport attempt, the destination name, the error message, and the timestamp. Look for lines containing WARN, ERROR, failed, or stalled.

ls -lth /usr/local/cpanel/logs/cpbackup/

Files are named by date. Open the most recent one to see which accounts succeeded and which failed:

grep -i "error\|fail\|warn" /usr/local/cpanel/logs/cpbackup/$(ls -t /usr/local/cpanel/logs/cpbackup/ | head -1)

If the standard log is not detailed enough, you can run a manual backup transport in debug mode:

/usr/local/cpanel/bin/cpbackup_transporter --all --verbose 2>&1 | tee /tmp/backup_debug.log

Common error strings and what they mean:

• Connection to remote server stalled — timeout; increase the timeout value in WHM
• Couldn't write to remote file: Failure — disk full on remote, or permission denied
• 530 Login incorrect — FTP credentials wrong or expired
• Permission denied (publickey) — SFTP key not accepted (wrong key, wrong user, or authorized_keys mismatch)
• AccessDenied — S3 IAM policy too restrictive
• NoSuchBucket — S3 bucket name incorrect or wrong region
• Connection refused — firewall blocking port 21/22/443 from the cPanel server
• PASV mode failed — remote FTP server not accepting passive connections

Test the FTP connection from the cPanel server command line before trusting WHM's "Validate Destination" button:

ftp -p YOUR_REMOTE_FTP_IP

Login with your backup credentials. If this fails, the issue is credentials or network — not WHM. If it succeeds here but fails in WHM, the issue is in WHM's destination config.

On the remote FTP server, ensure the passive port range is open. For vsftpd, add to /etc/vsftpd.conf:

pasv_enable=YES
pasv_min_port=40000
pasv_max_port=50000

Then open those ports in CSF or iptables:

csf -a YOUR_CPANEL_SERVER_IP
# or
iptables -I INPUT -p tcp --dport 40000:50000 -j ACCEPT

Check SELinux status on the remote server:

getenforce

If it returns Enforcing, either switch to permissive mode or add a SELinux boolean to allow FTP transfers:

setsebool -P ftpd_full_access on

Navigate to WHM > Backup > Backup Configuration > Additional Destinations. Edit your FTP destination, re-enter the password (WHM does not always persist it), click Save and Validate Destination.

SFTP Destination Fixes

WHM uses a dedicated SFTP backup key. Generate or view it:

cat /root/.ssh/cpanel_backup_id_rsa.pub

This public key must exist verbatim in ~/.ssh/authorized_keys on the remote SFTP server for the backup user. A single extra space or trailing newline will cause authentication to fail.

sftp -i /root/.ssh/cpanel_backup_id_rsa BACKUP_USER@REMOTE_IP

If this succeeds, WHM will too. If it asks for a password, the key is not accepted — re-copy the public key to the remote authorized_keys file.

ssh BACKUP_USER@REMOTE_IP "ls -la /backup/directory/"

The user must have write access. If the directory is owned by root, either chown it to the backup user or use ACLs.

nc -zv REMOTE_IP 22

If this times out, the remote firewall is blocking port 22 from the cPanel server's IP. Add a whitelist rule on the remote server's CSF or iptables for the cPanel server's IP.

Your IAM user (or role) needs the following minimum permissions on the target bucket. In the AWS Console, navigate to IAM > Users > your backup user > Permissions > Add inline policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR-BUCKET-NAME",
        "arn:aws:s3:::YOUR-BUCKET-NAME/*"
      ]
    }
  ]
}

S3 bucket names are case-sensitive and region-specific. In WHM > Backup Configuration > Additional Destinations, the Bucket field must exactly match the bucket name in AWS — no trailing slash, no prefix. The Region dropdown must match the AWS region where the bucket was created (e.g., us-east-1, ap-south-1). A region mismatch produces a PermanentRedirect error in the transport log.

Modern S3 buckets have Block Public Access enabled by default — this is correct. However, if someone has also set a bucket ACL that denies the IAM user, backups will fail with AccessDenied even though the IAM policy is correct. In the AWS Console under your bucket > Permissions, verify the bucket policy does not have an explicit Deny that overrides the IAM Allow.

Install the AWS CLI on the cPanel server and test with the same credentials WHM will use:

aws configure --profile cpanel-backup
aws s3 ls s3://YOUR-BUCKET-NAME --profile cpanel-backup
aws s3 cp /tmp/testfile.txt s3://YOUR-BUCKET-NAME/test/ --profile cpanel-backup

If the cp command succeeds here, WHM should work. If it fails, the error output from the CLI is far more descriptive than what the transport log provides.

If you are using a non-AWS S3-compatible target (Linode Object Storage, Backblaze B2, Wasabi, MinIO), you must set a custom endpoint. WHM's built-in "Amazon S3" destination type hard-codes the AWS endpoint. Use the Custom S3-Compatible destination type instead and enter your provider's endpoint URL (e.g., us-east-1.linodeobjects.com for Linode, s3.us-west-001.backblazeb2.com for Backblaze).

Estimate your backup transfer time:

# Check your uplink bandwidth to the remote destination (in Mbps)
speedtest-cli --server REMOTE_IP

# Calculate minimum required timeout in seconds:
# timeout_seconds = (backup_size_GB * 1024 * 8) / (bandwidth_Mbps * 0.7)
# Example: 30 GB backup at 50 Mbps usable = (30 * 1024 * 8) / (50 * 0.7) = 7,021 seconds (~2 hours)

The 0.7 factor accounts for overhead, retries, and network congestion. Always add 20% headroom to your calculated minimum.

Navigate to WHM > Backup > Backup Configuration > Additional Destinations. Edit your destination. Find the Timeout field (labelled "Maximum Destination Timeout"). The value is in seconds; the range is 30–300 for the per-request timeout. For the overall backup timeout, edit /etc/cpbackup.conf directly:

grep -i timeout /etc/cpbackup.conf

Add or update:

BACKUP_DESTINATION_TIMEOUT=14400

This sets a 4-hour overall transfer window. Restart the backup transport after changing:

/scripts/restartsrv_cpbackup

If the backup job saturates the server's uplink and causes timeout failures on other connections, limit the transfer rate via trickle or set WHM's built-in bandwidth throttle. In the Additional Destinations config, the Bandwidth Throttle field (in KB/s) lets you cap transfer speed. A value of 5120 (5 MB/s) is a safe starting point for most servers.

If you have multiple remote backup destinations configured, WHM will attempt all of them simultaneously by default. On a server with 3 destinations and 30 GB of backups, that is 90 GB of concurrent outbound transfer — a guaranteed timeout on most links. Schedule destinations at different hours by adjusting the backup start time in WHM > Backup > Backup Configuration, or disable all but one destination temporarily to isolate the failing one.

If your remote backup jobs consistently time out due to volume, switch from full daily backups to incremental. In WHM > Backup Configuration, set Backup Type to Incremental. Incremental backups only transfer changed files, reducing a 30 GB daily transfer to 1–3 GB on typical shared hosting servers. Note: incremental backups require the remote destination to support directory creation (FTP and SFTP both work; S3 uses key prefixes which also work).

If you are managing multiple cPanel servers or need an independent audit of why your backups are silently failing, the CloudHouse server management service team handles exactly this kind of deep backup infrastructure diagnosis and remediation.