cPanel Backup Configuration Tutorial (2026): WHM Backup Setup, Remote Storage, and Restore Drills That Actually Work

A backup you’ve never restored is a hope, not a plan. On a VPS, cPanel/WHM gives you several backup options. But the defaults often fail in real incidents: full disks, broken incrementals, missing DNS zones, or restores that run long enough for customers to notice.

This cPanel backup configuration tutorial walks through a production-ready WHM backup setup for 2026. You’ll build schedules that fit your traffic, retention you can afford, remote storage that doesn’t quietly fail, and restore drills you can repeat. The goal is simple: recover one file, one account, or the whole server without guesswork.

What you’ll build (and what you should decide first)

Before you change any WHM setting, define what “good” means for your operation. These decisions control storage cost, restore time, and the size of a failure domain.

• RPO (Recovery Point Objective): how much data you can lose. Many small hosts target 24 hours; busy WooCommerce stores often need 6–12 hours.
• RTO (Recovery Time Objective): how long you can be down. Account restores can be quick; full-server recovery is slower and needs more prep.
• Scope: single cPanel account restore, reseller restore, or a full WHM server rebuild.

A sensible baseline for many WHM VPS deployments is daily compressed account backups + weekly full backup, kept for 14–30 days, with at least one copy stored off-server.

Prerequisites and safe starting checks

You’ll need root access in WHM and SSH access to the server. The examples assume a standard cPanel install on AlmaLinux/Rocky Linux (common in 2026 for WHM fleets). WHM screens are similar across supported platforms.

1. Confirm you have disk headroom on the local server (even if you use remote storage). WHM still needs working space to build archives.

df -h /
df -h /home

If you’re already tight on disk, fix that first. A full filesystem is one of the most reliable ways to break backups and upgrades.

If you want a methodical cleanup flow, use this internal guide: disk space troubleshooting on a Linux VPS.

2. Confirm your server hostname and rDNS are correct if you rely on emailed backup alerts. Hostname issues also tend to surface later as SSL and mail problems.

hostnamectl
hostname -f

For deliverability hygiene, review: Reverse DNS setup tutorial.

Pick the right hosting plan for backup-heavy WHM workloads

Backups hit CPU and disk I/O hard. Cheap VPS plans can look fine until nightly backups overlap with real traffic. Then you feel it as slow admin panels, delayed PHP work, and long backup windows.

For predictable backup performance, prioritize NVMe storage, enough RAM to avoid swap thrashing, and CPU headroom for compression. If you’d rather offload the operational burden, managed VPS hosting is the straightforward option.

If you’re building and tuning it yourself, start with a HostMyCode VPS sized for your account count and retention goals.

cPanel backup configuration tutorial: configure WHM backup settings (the important screens)

In WHM, open Home → Backup → Backup Configuration. Labels vary slightly by theme, but this is the main screen for the backup engine.

1) Enable backups and choose a backup type

Set Backup Status to enabled. Then choose a backup type. In 2026, most operators land on one of these:

• Compressed: saves space, costs CPU during backup and restore. Common default.
• Uncompressed: faster backup/restore, uses more storage. Works well on high-I/O dedicated servers.
• Incremental (if available in your environment): lowers daily I/O, adds complexity. Only use it if you’re committed to frequent restore testing.

On busy servers, compressed backups can spike CPU and stretch the backup window. If you host performance-sensitive sites, consider uncompressed weekly full backups plus compressed dailies. Another option is faster storage.

2) Define a schedule that avoids your real traffic

WHM lets you schedule backups by day and time. Don’t pick “2:00 AM” just because it feels standard. Pick a window where:

• customer activity is lowest (use access logs or analytics), and
• your server isn’t also running heavy cron jobs (imports, reports, batch tasks).

If your WordPress sites still rely on wp-cron, backup windows can collide with request bursts. Fixing wp-cron often reduces surprise load spikes. Use: replace wp-cron with a real server cron.

3) Retention: set numbers you can defend

Retention is where WHM backup plans quietly fail. Set it too low and you can’t roll back past a slow-burn compromise. Set it too high and /backup (or /home) fills up. Once that happens, multiple services can start failing.

• Daily: 14 days (typical minimum), 30 days (better for disputes and slow hacks).
• Weekly: 4–8 weeks if you can afford it.
• Monthly: optional; useful for business sites that change rarely.

Rule of thumb: budget local storage for at least 2× your live data size if you want 14–30 daily backups. Compression helps, but don’t design the plan around a specific compression ratio.

4) Backup directory: put backups somewhere that won’t collide with accounts

On many servers, user data lives under /home. If you keep backups in /home, account growth competes with your ability to back up. That’s a common way to fail backups at the worst possible time.

If you can, store backups on a separate mounted volume, usually:

• /backup (mounted on a dedicated disk/volume)
• or /mnt/backup

On a VPS or dedicated server, ask your provider to attach a separate volume. Mount it and make the mount persistent in /etc/fstab. Example:

lsblk
blkid
nano /etc/fstab
mount -a

Tip: formatting and mounting vary by distro and storage layer. If you’re not comfortable doing this safely, that’s a strong argument for managed service.

5) Include system files that matter (not everything)

Account backups don’t automatically include every piece you may need to rebuild service. In WHM backup configuration, review options such as:

• DNS zone backups (critical if your server runs nameservices)
• MySQL/MariaDB within account backups (usually enabled; verify it)
• Configuration files (selective)

Don’t try to “backup the whole OS” through WHM. For full-server recovery, use snapshots or image-based backups. Then layer WHM account backups on top.

If you want a safer rollback path before updates, pair WHM backups with snapshots: VPS snapshot tutorial (LVM/Btrfs).

Remote backup destinations: build off-server copies that don’t lie

Local backups are great for accidental deletions. They don’t help if the VPS dies, gets encrypted, or the datacenter has an incident. Off-server copies turn disasters into recoverable outages.

In WHM, use Home → Backup → Backup Configuration and/or Additional Destinations (the label varies). Depending on your WHM version and installed backends, you’ll typically see SFTP, FTP, and cloud options.

Option A: SFTP destination (simple, reliable)

SFTP to a second VPS is a clean setup with few moving parts. Keep the destination separate from the source. Ideally, use a different region or provider.

Create a dedicated user and lock it down.

On the destination server:

adduser whmbackup
passwd -l whmbackup
mkdir -p /srv/whm-backups
chown whmbackup:whmbackup /srv/whm-backups

Restrict the user to SFTP-only in sshd_config. Example:

nano /etc/ssh/sshd_config

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

systemctl restart sshd

If you want a hardened production layout (chroot jails, per-user limits), follow: VPS SFTP setup guide.

In WHM, add an SFTP destination with the destination host, port, and path. Authenticate using an SSH key.

Option B: Dedicated backup server or storage volume

If you run a reseller platform or multiple WHM servers, a dedicated backup server simplifies retention, monitoring, and capacity planning. It can also speed up restores, because you control bandwidth and storage IOPS.

This is where a dedicated server can pencil out: predictable I/O, larger disks, and no noisy neighbors. Use it as backup storage. Keep WHM nodes focused on serving sites.

Make failures loud: alerts and logs

Enable WHM notifications for backup warnings and failures. Then confirm those alerts arrive. Ops email needs deliverability too.

On the WHM server, watch logs during the first few runs:

tail -n 200 /usr/local/cpanel/logs/cpbackup/latest
ls -lah /usr/local/cpanel/logs/cpbackup/

If you see repeated timeouts to remote storage, treat it as a real incident. A “mostly successful” backup system is how teams get blindsided during a restore.

Performance tuning: stop backups from wrecking your sites

Backups compete for CPU, disk I/O, and sometimes RAM. If users say the server “gets slow at night,” backups are often the reason.

Quick diagnostics during the backup window

uptime
vmstat 1 5
iostat -xz 1 5
top -o %CPU

• High iowait usually means storage saturation.
• Load average spikes with low CPU usage often point to I/O contention.
• OOM or swap thrash suggests memory pressure during compression.

If you want a structured workflow, use: VPS performance troubleshooting and VPS disk I/O troubleshooting.

Practical mitigation options

• Move backups to a separate disk/volume (highest impact).
• Adjust schedule to avoid application batch jobs.
• Reduce compression or use uncompressed weekly backups.
• Exclude huge, regenerable caches where appropriate (be careful; don’t exclude uploads or mail).
• Upgrade the plan if I/O is the bottleneck. Cheap storage gets expensive during restores.

Restore drills: prove you can recover an account (without touching production)

Restores are where backup plans either hold up or fall apart. Run two drills: (1) a single-file restore, and (2) a full account restore into a quarantine environment.

Drill 1: single-file restore (fast sanity check)

Choose a low-risk account you control. Create a test file:

sudo -u testuser bash -lc 'echo restore-test-$(date -Iseconds) > ~/public_html/restore-test.txt'

Wait for the next backup to run (or trigger one manually if your policy allows). Then delete the file:

sudo -u testuser rm -f ~/public_html/restore-test.txt

Use WHM’s restore interface for that account backup to restore the missing file (the exact screen varies by WHM version). Confirm the file is back and permissions look right.

Drill 2: full-account restore into a staging/quarantine server

This is the drill that matters. Restoring onto the same production server can hide problems, because paths, configs, and DNS already match. A quarantine restore forces you to prove the backup is complete.

1. Provision a small VPS as a restore lab with cPanel/WHM (licensed as needed). Keep it firewalled and not publicly advertised.
2. Copy a backup archive from remote storage to the lab server.
3. Restore the account using WHM Restore a Full Backup/cpmove file.
4. Validate website content loads via hosts-file override, and confirm mailboxes exist.

If you need a clean staging approach for WordPress (password protection, SSL details, avoiding accidental email sends), adapt: WordPress staging setup guide.

Hardening the backup path (keys, permissions, and blast radius)

Backups contain everything: site code, configuration secrets, and customer data. Treat them like production credentials.

Lock down SSH keys used for remote backups

• Use a dedicated SSH keypair for backups.
• Restrict the destination user to SFTP-only (as shown earlier).
• Store private keys with root-only permissions on the WHM server.

chmod 600 /root/.ssh/whm-backup-key

If you rotate admin keys on a schedule, rotate backup keys on that same schedule: SSH key rotation tutorial.

Firewall rules: allow only what backups need

Don’t leave the backup destination open to the internet. Allow SSH/SFTP only from your WHM server IPs. For a baseline firewall pattern used in hosting environments, see: iptables/nftables firewall tutorial.

Operational checklist (print this before you trust your backups)

• Backups enabled in WHM, schedule set, retention set.
• Backups stored on a dedicated mounted path (ideally /backup).
• Remote destination configured and tested by downloading a recent archive.
• Backup logs reviewed after first 3 runs: /usr/local/cpanel/logs/cpbackup/.
• At least one account restore drill completed on a quarantine server.
• Access to remote backups restricted (SFTP-only user, IP allowlist).
• Alerting enabled and email deliverability confirmed.

FAQ

Should I rely on WHM backups alone for disaster recovery?

No. Use WHM account backups for account-level restores, and add snapshots/image backups for fast rollback of OS-level changes and full-server recovery.

How many days of backups should a hosting VPS keep in 2026?

For most small hosting operations, 14 daily backups is a minimum. If you can afford the storage, 30 daily backups plus weekly backups gives you better coverage for slow compromises.

Why do my sites slow down during backups?

Compression and archiving are CPU-heavy and can saturate disk I/O. Put backups on a separate disk, move the schedule, or reduce compression to avoid iowait spikes.

What’s the safest way to test restores without affecting customers?

Restore an account onto a quarantine WHM server, then test the site using a hosts-file override and ensure mailboxes and databases exist. Don’t test restores on live production unless you have a rollback plan.

Summary: a backup you can restore beats a backup you can’t

WHM can produce solid backups, but only if you plan for real-world failure. Use dedicated backup storage, retention that won’t fill disks, off-server copies, and restore drills you actually run.

Get those four right and the next incident becomes routine recovery, not an all-nighter.

If you want a server that can handle real backup I/O without turning every night into a performance incident, choose a plan built for it—start with a HostMyCode VPS, or step up to dedicated servers for larger WHM fleets and faster restores.