cPanel Backup Configuration Tutorial (2026): WHM Incremental Backups to Remote SFTP (Rotation, Encryption, Restore Checks)

A cPanel server can look fine until you need to restore one account, mailbox, or database. This cPanel backup configuration tutorial focuses on one outcome. Your WHM backups must leave the server, rotate predictably, and restore cleanly when you need them.

You’ll use WHM’s built-in backup system with a remote SFTP destination. You’ll also run a few checks that catch the classic “backups exist, restores fail” problems.

This is written for VPS and dedicated operators running cPanel & WHM in 2026.

What you’ll build: a backup plan WHM can actually restore

• Backup type: WHM backups (compressed) with incremental enabled where applicable
• Storage: local staging + offsite SFTP (separate server)
• Retention: simple rotation (daily/weekly/monthly)
• Security: SFTP key auth + restricted backup user + optional at-rest encryption on the target
• Proof: scheduled restore spot-checks for one cPanel account

If you host client sites or resell, plan for cPanel’s I/O-heavy backup jobs. Tight disks and slow storage don’t always fail loudly.

They often fail halfway through the night.

If you want predictable backup windows and fewer “why did this stall?” moments, a managed VPS hosting plan from HostMyCode is a straightforward match for typical cPanel workloads.

Prerequisites (keep these tight)

• A cPanel & WHM server (current stable in 2026) on AlmaLinux / Rocky Linux / similar supported OS
• Root access to WHM
• A separate backup target server with SFTP access (Linux VPS is ideal)
• Enough space for at least 2–3 full backup cycles offsite

Step 1: Prepare a dedicated SFTP backup target

Your offsite target should be a different machine, not “a folder over there.” If the cPanel server is compromised or the disk dies, local-only backups won’t save you.

Bring up a small, minimal Linux box as the target. Keep it boring. Keep it focused on one job.

A low-cost HostMyCode VPS works well because it’s easy to isolate, firewall tightly, and maintain.

Create a restricted backup user (on the target)

On the backup target server:

sudo adduser --disabled-password --gecos "" whmbackup
sudo mkdir -p /srv/whm-backups
sudo chown whmbackup:whmbackup /srv/whm-backups
sudo chmod 750 /srv/whm-backups

Lock SSH down for that user

Edit /etc/ssh/sshd_config on the target. Add a Match block:

Match User whmbackup
  ChrootDirectory /srv
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no
  PasswordAuthentication no

Then build the chroot layout. With chroot, /srv must be owned by root.

sudo chown root:root /srv
sudo chmod 755 /srv
sudo mkdir -p /srv/whm-backups
sudo chown whmbackup:whmbackup /srv/whm-backups

Reload SSH:

sudo systemctl reload sshd

If you want a broader hardening pattern for SFTP-only users, see HostMyCode’s SFTP setup guide and lockdown.

Step 2: Set up SSH keys from the cPanel server to the backup target

WHM supports SFTP destinations, but key-based auth stays stable over time. Generate a dedicated key on the cPanel server.

Don’t reuse someone’s personal key. Don’t rely on passwords.

sudo mkdir -p /root/.ssh
sudo chmod 700 /root/.ssh
sudo ssh-keygen -t ed25519 -a 64 -f /root/.ssh/whm_backup_ed25519 -N "" -C "whm-backup"

Copy the public key to the target:

sudo ssh-copy-id -i /root/.ssh/whm_backup_ed25519.pub whmbackup@BACKUP_TARGET_IP

Test SFTP from the cPanel server:

sftp -i /root/.ssh/whm_backup_ed25519 whmbackup@BACKUP_TARGET_IP

If the connection fails, stop and fix it now.

The usual causes are wrong ownership on /srv, password auth still enabled for that user, or a firewall blocking port 22.

Step 3: Configure WHM backup settings (the part most people rush)

In WHM, go to: Home → Backup → Backup Configuration.

• Backup Status: Enable
• Backup Type: Compressed (recommended for offsite transfer)
• Incremental: Enable if available on your build (reduces daily churn for unchanged data)
• Retain backups in the default backup directory: Keep at least 1 locally (optional, but useful for fast restores)
• Backup Daily: On (low retention)
• Backup Weekly: On (medium retention)
• Backup Monthly: On (long retention)

Pick a sensible schedule

Schedule backups for low-traffic hours. Avoid stacking them on top of other nightly jobs.

Many servers already rotate logs, run scans, or ship metrics overnight. For many setups, 02:00–05:00 local time works.

If backups regularly drag, check I/O wait before blaming CPU. Also check runaway logs and temp growth.

HostMyCode’s disk space troubleshooting tutorial walks through the usual suspects under /var.

Choose what to back up (be explicit)

• Files: On
• Databases: On
• Mailbox: On (most “restore worked, but email didn’t” cases start here)
• DNS zones: On (especially if your server is authoritative)

If you run separate nameservers, keep zones synchronized. Also write down the topology.

That way, restores don’t turn into guesswork.

For a clean split-DNS pattern, see cPanel DNS cluster setup.

Step 4: Add remote SFTP destination in WHM

Back in WHM: Home → Backup → Backup Configuration. Scroll to Additional Destinations (the label varies a bit by build).

Add a new destination:

• Destination Type: SFTP
• Host: BACKUP_TARGET_IP (or hostname)
• Port: 22
• Username: whmbackup
• Path: /whm-backups (remember the user is chrooted to /srv)
• Authentication: SSH key
• Private key path: /root/.ssh/whm_backup_ed25519

Sanity-check the remote path

Chroot trips people up because paths look “wrong” if you think in full filesystem terms.

If the user is chrooted to /srv, then /whm-backups maps to /srv/whm-backups on disk.

Test the path with:

sftp -i /root/.ssh/whm_backup_ed25519 whmbackup@BACKUP_TARGET_IP:whm-backups

Step 5: Set retention and rotation (avoid “infinite backups”)

Retention is where backup systems quietly bankrupt your disk. Keep the policy simple and predictable.

You should be able to reason about both space and restore points.

• Daily: 7 copies
• Weekly: 4 copies
• Monthly: 3 copies

If you need longer retention, measure first.

Mail-heavy accounts are often larger than web files. They also grow in ways you won’t notice until the target volume fills.

Optional: add server-side “hard” retention on the target

WHM should prune old sets, but you can add a safety net on the target.

One conservative approach is to keep everything under /srv/whm-backups, then delete archives older than 120 days.

sudo find /srv/whm-backups -type f -mtime +120 -name '*.tar.gz' -delete

Run it weekly via cron or a systemd timer on the target. Keep the scope tight.

Don’t get clever with wildcards.

Step 6: Run a manual backup and watch logs like an operator

In WHM: Home → Backup → Backup Configuration. Trigger a manual run from the UI.

If your runbook prefers it, run the backup script from CLI instead.

While it runs:

• Check load and I/O wait: top, iostat -x 1 (install sysstat if needed)
• Confirm remote transfer: watch files appear on the target

On the target server:

sudo ls -lah /srv/whm-backups

If the job triggers memory pressure and random failures, compression may be getting OOM-killed.

Fix the underlying resource issue before chasing “mystery” backup bugs.

HostMyCode’s swap configuration tutorial covers safe sizing and kernel settings. The principles still apply even if your cPanel OS differs.

Step 7: Verify what got backed up (don’t assume)

You don’t need to audit every file to gain confidence. Verify one representative account end-to-end.

Check web files, database dumps, and mail.

Pick an account with:

• WordPress + uploads
• At least one MySQL database
• Active email usage (IMAP folders, sent items)

Quick integrity checks on the target

List the newest archives:

sudo find /srv/whm-backups -maxdepth 2 -type f -name '*.tar.gz' -printf '%TY-%Tm-%Td %TT %p\n' | sort | tail -n 20

Spot-check an archive without extracting it fully (on a Linux host with tar):

tar -tzf /srv/whm-backups/ACCOUNT_BACKUP.tar.gz | head

If tar can’t list contents, treat the archive as suspect.

It’s often a truncated upload from a network interruption. A full disk on the target can also cause it.

Step 8: Do a restore drill for one cPanel account (the step people skip)

If you haven’t restored from a backup, you don’t have a backup plan.

The goal isn’t a full disaster simulation. It’s a repeatable, low-risk test you can run again.

Option A (recommended): restore to a staging cPanel server

Restore one account to a small staging cPanel VPS. This avoids touching production, while still proving the full chain works.

1. Deploy a fresh cPanel server (matching major versions helps).
2. Download one backup set from SFTP to the staging server.
3. In WHM: Transfers → Restore a Full Backup/cpmove File and select the archive.
4. Validate:
   • Website loads (hosts file override helps before DNS changes)
   • wp-admin login works
   • Mailboxes exist and folders are present
   • Database tables are populated

If you want a safe DNS workflow for staging tests and rollbacks, the process in DNS cutover tutorial fits restore drills well.

Option B: restore a single account on the same server (only if you must)

Restoring on the same host can overwrite live data.

Only do this if you understand cPanel’s restore behavior and you have a real rollback plan.

• Prefer restoring to a new username where possible
• Document what will be overwritten (files, DBs, mail)
• Schedule a maintenance window

Step 9: Encrypt at rest on the backup target (practical options)

SFTP protects data in transit. It does not protect backups sitting on disk on the target.

If the target is offsite, multi-tenant, or shared among admins, encryption at rest is usually worth the extra step.

Option 1: Disk encryption on the target

Encrypting the target volume (LUKS) is the cleanest model. It’s usually easiest to do at provisioning time.

If you can’t rebuild, use Option 2.

Option 2: Encrypted storage bucket or encrypted filesystem directory

If you already have an encrypted mount or object storage with encryption controls, land backups there.

For a broader discussion of offsite encryption patterns beyond WHM destinations, see HostMyCode’s VPS backup strategy tutorial.

Step 10: Add alerting for failed backups (simple, effective)

Backups tend to fail overnight. Many people only notice a week later, during a restore.

Set up alerts so you learn about failures the same day.

• In WHM, confirm backup failure notifications are enabled for root/admin.
• On the target, alert on low disk space (start warning at 20%).

If you don’t already have daily reporting, add a lightweight summary tool.

Then actually read it.

A straightforward option is Logwatch (or your preferred equivalent) on both servers.

Troubleshooting: common WHM backup failures and quick fixes

“Transport endpoint is not connected” or partial archives

• Check target disk space: df -h
• Check network stability: packet loss, MTU issues
• Confirm WHM isn’t timing out transfers during peak backup load

Backups succeed locally but fail offsite

• Validate SFTP key permissions on the cPanel server (chmod 600 on private key)
• Confirm chroot paths (use /whm-backups not /srv/whm-backups in WHM if chrooted)
• Check firewall rules on the target (allow port 22 from the cPanel server IP only)

Restores complete but email is missing

• Confirm “Mail” was enabled in backup content selection
• Validate the backup set actually includes mail directories in the archive listing
• On restore target, confirm IMAP service status and mailbox path permissions

Operational checklist (printable)

• [ ] Offsite backup target exists and is separate from production
• [ ] SFTP user is restricted (chroot + key-only auth)
• [ ] WHM backups enabled (files + DB + mail + DNS as needed)
• [ ] Daily/weekly/monthly retention set and validated against disk capacity
• [ ] One manual backup run completed and verified on the target
• [ ] One restore drill completed on a staging server
• [ ] Alerts configured for backup failure and low disk
• [ ] Quarterly restore drill scheduled (put it on the calendar)

Summary: keep backups boring, tested, and offsite

WHM backups are dependable when you treat them like an operational system. Use restricted access, offsite storage, and retention that matches real disk capacity.

Run routine restore checks. After one clean restore drill, monitoring becomes simpler.

You know what “good” looks like.

If you’d rather run this on infrastructure sized and monitored for hosting workloads, start with a HostMyCode VPS. You can also move to managed VPS hosting so backup jobs, storage planning, and restore testing don’t compete with day-to-day support fires.

FAQ

Should I keep local WHM backups if I already push to SFTP?

Usually yes—keep 1 local copy for fast restores, but rely on offsite for real recovery. Don’t keep long retention locally unless you have the disk headroom.

How often should I run a restore test?

At least quarterly for a stable server, and immediately after major changes (cPanel upgrades, storage changes, or migration). If you host clients, monthly spot checks are safer.

What’s a realistic retention setup for small hosting resellers?

7 daily / 4 weekly / 3 monthly is a common baseline. Adjust after measuring the real backup footprint of your largest 3 accounts (web + DB + mail).

Is SFTP enough, or do I need encryption at rest?

SFTP protects data in transit. Encryption at rest depends on your risk model. If the target is offsite or shared among admins, encryption at rest is a sensible upgrade.

Can I back up multiple cPanel servers to the same target?

Yes, but separate them by directory (or separate SFTP users) and budget disk for concurrent weekly/monthly peaks. Also lock SSH to allow only the production IPs.