cPanel Backup Tutorial (2026): Configure WHM Backup, Remote Storage, and Restore Testing

cPanel backups usually fail in three ways: the job never runs, it fills the disk, or the restore falls apart under pressure. This cPanel backup tutorial shows a production-ready WHM backup setup for a VPS or dedicated server. You’ll configure remote storage, retention rules, and restore tests you can repeat on a schedule.

You’ll work in WHM (root) and verify results from the shell. Examples assume cPanel & WHM on AlmaLinux/Rocky Linux or Ubuntu with a supported cPanel build. You’ll also need root SSH access.

Prerequisites and a quick decision: VPS vs dedicated for cPanel backups

Before you change anything in WHM, confirm the server has CPU, I/O, and disk headroom for backups. Building compressed account archives can spike load and disk writes for 15–60 minutes.

Impact depends on how many accounts you host and how much data you store.

• If you host multiple sites or client accounts: use a VPS with dedicated resources (or a dedicated server). This keeps backups from fighting with PHP-FPM, MySQL, and mail delivery.
• If you’re running a single business site: you can still use cPanel. Backups are more predictable when you avoid “backup to the same disk only”.

If you want consistent I/O and enough room for offsite retention, start with a HostMyCode VPS. If you’d rather not manage cPanel updates, backup policy, and restore drills yourself, managed VPS hosting is the simpler path.

Recommended baseline for cPanel in 2026:

• 2–4 vCPU minimum (more if you have many accounts)
• 4–8 GB RAM minimum
• NVMe storage (dramatically reduces backup runtime and UI stalls)
• Separate offsite storage for at least 7–30 days retention

What you’re building in this cPanel backup tutorial

The goal is a setup you can explain, audit, and trust:

1. Nightly incremental backups for fast day-to-day recovery.
2. Weekly full backups for clean “point snapshots”.
3. Offsite copies to remote storage so a disk failure or compromise doesn’t take backups with it.
4. Restore testing (the step most teams skip until it hurts).

If you’re also planning to move accounts onto this server, pair this guide with our near-zero downtime migration tutorial. It helps ensure your first full backup runs after a clean cutover.

Step 1: Verify disk space and backup staging capacity

cPanel usually writes backups to a local staging directory first. It then pushes those backups to remote storage.

If free space is tight, the run can fail mid-stream. You can also end up with partial archives left behind.

Run these checks over SSH:

df -hT

# Top 20 largest directories (adjust path if you store accounts elsewhere)
du -xhd1 /home 2>/dev/null | sort -h | tail -n 20

# Check inode exhaustion (common on small files-heavy servers)
df -hi

Rule of thumb: keep at least 20–30% free space on the filesystem used for /backup (or wherever your staging directory lives).

If you host email with large Maildir trees, budget extra space.

Step 2: Configure WHM backup settings (the core policy)

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

Set these fields deliberately. Don’t accept the defaults blindly:

• Backup Status: Enable
• Backup Type: Incremental (recommended for most multi-account servers)
• Retention: start with 7 daily + 4 weekly (adjust to your risk and storage budget)
• Backup Directory: /backup (use a dedicated mount if possible)
• Minimum disk space threshold: set a real number (not “0”). Example: 10240 MB (10 GB) so backups stop before the server paints itself into a corner.
• Compression: Use compressed backups unless your restore-time requirement is extremely strict. Compression usually saves space and offsite bandwidth.

Schedule suggestion (practical and gentle on load):

• Daily incremental: 02:00 server time
• Weekly full: Sunday 03:00 server time

After you save, WHM writes the configuration used for scheduled runs via cron.

Step 3: Decide what to include (and what to exclude) in backups

You don’t want “everything” if it turns backups into huge, slow, fragile jobs. You also don’t want clever exclusions that make restores incomplete.

Back in Backup Configuration, review:

• Back up system files: Enable (helps with full disaster recovery)
• Back up users: Enable
• Back up user configuration: Enable
• Back up mail: Enable if you host email; disable only if mailboxes live elsewhere
• Back up databases: Enable

Pitfall: if you disable mail backups but users rely on local IMAP mailboxes, “restoring a site” won’t restore the business.

Keep mail in scope unless you’ve formally moved it to an external provider.

Step 4: Add remote storage (don’t trust a single server)

Local backups are great for fast restores. They do nothing for disk failure, ransomware, or a compromised host.

If you’re hosting anything that matters, offsite copies are mandatory.

In WHM, go to: Home → Backup → Backup Configuration, then find Additional Destinations. Or use: Home → Backup → Destination Configuration (the label varies slightly by cPanel build).

Common destination types in cPanel include SFTP, FTP, and cloud object storage (depending on your environment). If you control a second server, SFTP is usually the cleanest option.

Option A: Remote SFTP destination (recommended for most resellers)

Create a restricted user on the remote backup server:

# On the remote backup server
sudo adduser backupcp
sudo mkdir -p /srv/backups/cpanel
sudo chown -R backupcp:backupcp /srv/backups/cpanel

Lock it down in /etc/ssh/sshd_config on the remote host:

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

Then reload SSH:

sudo systemctl reload sshd

In WHM, add an SFTP destination and point it to the remote host. Use a key-based login if possible.

Test the connection before saving.

Hardening note: if SSH and basic firewall rules aren’t in place yet, do that first.

Use our UFW firewall setup tutorial as a checklist for an Ubuntu-based backup node.

Option B: Object storage (good for long retention and geography)

Object storage is a solid fit for longer retention because it scales cheaply. The trade-off is restore speed for very large accounts.

You’ll notice it most when you need to pull everything back over the network.

If your restore targets are strict, keep 3–7 days of local incremental backups and push weekly full backups offsite.

Step 5: Make backup runs predictable (reduce load spikes)

On busy servers, backups compete with PHP workers, MySQL, and mail. If the job saturates I/O, you’ll see sluggish admin pages, WordPress timeouts, and delayed email delivery.

Focus on these three levers:

• Run backups off-peak: choose hours when your audience is asleep, not “midnight by habit”.
• Avoid huge single-job bursts: incremental helps because it doesn’t rebuild every archive nightly.
• Separate backup storage: a dedicated mount or volume for /backup prevents backup writes from choking /home.

If you use Nginx as a reverse proxy in front of cPanel-hosted sites, caching can mask short load spikes during backup windows.

Our Nginx reverse proxy setup guide shows a practical configuration with SSL and caching controls.

Step 6: Run a manual backup and read the logs

Don’t wait for the nightly schedule to find out something is broken. Trigger a run, then verify what actually happened.

In WHM, use: Home → Backup → Backup Status to see running jobs.

From SSH, exact log locations vary by build. These are commonly helpful:

# Search for backup-related logs
ls -lah /usr/local/cpanel/logs/ | grep -i backup

# Grep for errors in the cPanel error log
grep -iE "backup|transport|sftp|failure|error" /usr/local/cpanel/logs/error_log | tail -n 200

What “good” looks like: completion messages with no retries, plus a successful transport to the remote destination (if configured).

What “bad” looks like: partial archives, repeated retries, “disk full”, permission errors on the remote path, or timeouts during transport.

Step 7: Confirm retention is actually working

Retention isn’t real until you verify it. Old backups should disappear on schedule.

New backups should show up on time, both locally and remotely.

Check local directories:

ls -lah /backup
find /backup -maxdepth 2 -type f | wc -l

On the remote server, check that backups are arriving and aging out:

# On remote backup server
ls -lah /srv/backups/cpanel
find /srv/backups/cpanel -type f -mtime +35 | head

If files older than your policy still exist, you likely set retention locally but not on the remote destination.

Another common cause is a destination method that doesn’t support deletion.

Fix it now, before storage costs creep up and the backlog becomes “someone else’s problem”.

Step 8: Do a restore test (account-level, then file-level)

This is where backup plans stop being theoretical.

Two tests that reflect real-world recovery work:

• Account-level restore to a staging server (best for resellers and agencies)
• File-level restore of a single site file or email folder (fast and practical)

Account-level restore to a staging VPS

Spin up a small staging VPS and install cPanel (or use an existing lab box). Don’t “test” by restoring onto production.

That’s an easy way to create downtime.

In WHM on the staging server:

• Go to Home → Backup → Restore a Full Backup/cpmove File
• Select a recent backup file (download from remote if needed)
• Restore and then check: DNS zone, site loads, database connects, email accounts exist

For WordPress sites, verify the homepage, wp-admin login, and a basic content edit.

If your staging environment uses HTTPS, you may also need a test certificate.

Use our Let’s Encrypt SSL setup tutorial to get a working staging certificate quickly.

File-level restore (fast validation)

Pick one known file (a theme file works well). Then prove you can pull it from an archive without relying on WHM restore screens.

On your server, locate a backup archive and extract a single path into a temp directory:

mkdir -p /root/restore-test
cd /root/restore-test

# Example: list archive contents first (file name will vary)
tar -tf /backup/2026-06-01/accounts/example.tar.gz | head

# Extract a specific file (adjust path)
tar -xzf /backup/2026-06-01/accounts/example.tar.gz home/example/public_html/wp-config.php

This doesn’t replace a full restore test. But it will catch corruption and permission problems early.

Step 9: Add monitoring you’ll actually notice

Backups fail quietly unless you force them into your line of sight. At minimum, set up two signals:

• Disk space alerting: warn at 80% and 90% usage on the backup filesystem.
• Backup freshness check: alert if no new backup appears within 36 hours.

A simple freshness check (run via cron) can be as basic as “latest backup file age”. Example for local backups:

#!/usr/bin/env bash
set -euo pipefail

LATEST=$(find /backup -type f -name "*.tar.gz" -o -name "*.tar" 2>/dev/null | xargs -r ls -t | head -n 1 || true)
if [[ -z "${LATEST}" ]]; then
  echo "No backup files found in /backup"; exit 2
fi

AGE_HOURS=$(( ( $(date +%s) - $(stat -c %Y "${LATEST}") ) / 3600 ))
if (( AGE_HOURS > 36 )); then
  echo "Backup too old: ${AGE_HOURS}h (${LATEST})"; exit 2
fi

echo "Backup OK: ${AGE_HOURS}h (${LATEST })"

Send the output to your preferred alerting channel (email, Slack, or a monitoring system).

If you host email on the same server, be careful. Mail outages can hide backup alerts.

Off-server alerting is safer.

Step 10: Tighten access and reduce backup data exposure

Backups contain everything: databases, config files, mailboxes, API keys. Treat them like production secrets.

• Limit who can access WHM backup screens: only root/admin roles that need it.
• Restrict remote backup credentials: a dedicated SFTP user, no shell, chrooted path.
• Don’t expose backup directories via the web: verify /backup is not under any DocumentRoot.

If you’re using a separate backup VPS, apply the same firewall discipline you use for production.

Limit SSH to your IP ranges where possible.

Operational checklist: what to review monthly

• One full restore test to staging (rotate accounts/sites so you cover different stacks)
• Verify offsite destination connectivity and free space
• Spot-check 2–3 archives for readable contents
• Confirm retention is deleting old backups (local and remote)
• Review cPanel update status and backup-related warnings in WHM

Common troubleshooting: quick fixes that save hours

Backups fail with “disk full” even though you have space

• Check the correct filesystem: df -hT /backup and df -hT /.
• Look for inode exhaustion: df -hi.
• Find leftover partials: find /backup -type f -name "*.partial" -o -name "*.tmp".

Remote transfers fail (SFTP timeouts, permission denied)

• Validate you can connect from the cPanel server: sftp backupcp@REMOTE_IP.
• Confirm the remote path ownership and chroot rules.
• Check firewall rules on both ends (22/tcp, and source restrictions).

Restores complete but the site is broken

• DNS mismatch: ensure the domain points to the restored server IP.
• SSL missing: install a certificate on the restored host.
• App config expects old paths or PHP version: confirm MultiPHP and handler settings match production.

Summary: a cPanel backup setup you can trust

Good backups are boring on purpose. You set retention, push copies offsite, and prove restores work before you need them.

After that, the only “backup drama” should be the restore drill you scheduled intentionally.

If you want backups that run reliably under real hosting load, put cPanel on a server with predictable resources. A HostMyCode VPS gives you clean performance isolation, and managed VPS hosting is there if you prefer a team to handle policy, monitoring, and recovery workflows.

FAQ

How many days of cPanel backups should I keep in 2026?

For most small hosting stacks: 7 daily incrementals and 4 weekly full backups is a sensible starting point. Increase retention if your change rate is high or you have compliance requirements.

Should I store cPanel backups on the same server?

Keep a short local retention for fast restores, but always maintain offsite backups. Same-server-only backups won’t help with disk failure or a compromised host.

Do incremental backups in WHM replace full backups?

No. Incrementals are great for day-to-day recovery, but weekly (or periodic) full backups make long-range recovery cleaner and simplify some restore scenarios.

What’s the simplest way to verify backups are usable?

Do a staging restore monthly and perform a quick functional test: site loads, admin login works, and email accounts exist (if you host mail). File-level extraction tests are a good weekly spot-check.

Will backups slow down my WordPress sites?

They can. Backups create I/O bursts, especially on shared disks. Scheduling off-peak, using incremental mode, and isolating backup storage reduces visible slowdown.