cPanel Backup Storage Setup Tutorial (2026): Configure Remote Destinations, Retention, and Encryption in WHM

Backups are only as reliable as the place you store them. If your “backup” lives on the same disk as your accounts, one failed drive—or a ransomware hit—can take out production and the backup in the same event. This cPanel backup storage setup tutorial shows how to set up WHM so backups land off-server, follow a retention plan you can explain, and stay encrypted—without turning nightly backups into an overnight fire drill.

The steps below assume cPanel & WHM on AlmaLinux 9/10, Rocky Linux 9, or CloudLinux in 2026. Menu names and paths match the current WHM UI. Where it helps, you’ll also see CLI checks so you can confirm what’s actually happening.

What you’ll build (and what you’ll avoid)

• At least one remote destination (SFTP recommended) so backups survive local disk loss.
• Retention that matches your business (daily/weekly/monthly) and doesn’t quietly fill your storage.
• Encrypted backups so a stolen backup archive isn’t a customer data breach.
• Predictable bandwidth + runtime so backups don’t flatten I/O during peak traffic.

If you’re still designing your recovery plan (RPO/RTO, snapshots, DNS failover), pair this with our disaster recovery workflow: VPS disaster recovery tutorial.

Prerequisites checklist before touching WHM

Knock these out first. They prevent most “backup failed” tickets later.

• Disk space on the cPanel server: keep at least 15–20% free on the backup staging volume (even if sending remote).
• Time sync: NTP enabled and correct time zone (TLS and retention logic both depend on sane clocks).
• Firewall egress: allow outbound to your remote host (SFTP/22, or whatever port you choose).
• Backup user on remote host: restricted shell and restricted path (don’t give full access).

# Quick health check on the cPanel server
hostnamectl
uptime
chronyc tracking || timedatectl status

df -h /
df -ih /

If you manage multiple client sites and want backups to finish consistently, hardware matters. NVMe and sufficient RAM reduce the pain from compression and account packaging competing with active PHP workers. A right-sized HostMyCode VPS makes that contention far less noticeable.

cPanel backup storage setup tutorial: choose the right remote destination type

WHM supports several destination types. In practice, two options stay dependable across providers in 2026: SFTP and Amazon S3-compatible object storage. For most hosting operators, SFTP is simpler to troubleshoot and usually faster to restore from.

Option A: SFTP (recommended for straightforward restores)

Choose SFTP if you want “files on disk” backups you can browse, copy, and restore with standard tools.

Remote server hardening tip: put backups on a dedicated destination box (or separate VPS) and accept backups only. Don’t host customer sites there.

# On the remote backup server (Ubuntu example)
sudo adduser --disabled-password --gecos "" cpanelbackup
sudo mkdir -p /backups/cpanel
sudo chown cpanelbackup:cpanelbackup /backups/cpanel

Then restrict the user to SFTP-only and a single directory (Ubuntu/Debian OpenSSH):

# /etc/ssh/sshd_config
Match User cpanelbackup
  ChrootDirectory /backups
  ForceCommand internal-sftp
  X11Forwarding no
  AllowTcpForwarding no

sudo systemctl reload ssh

Chroot gotcha: the chroot directory must be owned by root and not writable by the user. A safe structure is:

# On remote server
sudo mkdir -p /backups/cpanel
sudo chown root:root /backups
sudo chmod 755 /backups
sudo chown cpanelbackup:cpanelbackup /backups/cpanel

Option B: S3-compatible object storage (best for cheap long retention)

Use S3-compatible storage when you want long retention without maintaining a backup server. It’s often cost-effective for monthly archives. The trade-off is restore speed: large, multi-account pulls can take longer.

If your provider rate-limits or charges for egress, don’t design a plan that requires frequent large downloads. A common pattern is a short “hot” window on SFTP, plus longer “cold” monthly retention on object storage—if your budget supports it.

Step-by-step: add a remote backup destination in WHM

With the remote side ready, configure the destination on your cPanel server.

1. Log in to WHM as root.
2. Go to Backup → Backup Configuration and ensure backups are enabled (this guide focuses on storage, not scheduling details).
3. Go to Backup → Backup Destination.
4. Click Create New Destination.
5. Select a destination type (SFTP is typically the least fragile choice).

SFTP destination fields that matter

• Destination Name: make it recognizable (e.g., sftp-backups-ams-01).
• Host: backup server FQDN (preferred) or IP.
• Port: 22 or custom.
• Username: the restricted user (e.g., cpanelbackup).
• Path: within chroot (e.g., /cpanel if chroot is /backups).

Authentication: use SSH keys, not passwords. In WHM, upload the private key for the destination (or generate one on the cPanel server and paste the public key into ~cpanelbackup/.ssh/authorized_keys on the remote).

# On the cPanel server
ssh-keygen -t ed25519 -a 64 -f /root/.ssh/cpanelbackup_ed25519 -C "whm-backups"

# Copy public key to remote (if password login allowed temporarily)
ssh-copy-id -i /root/.ssh/cpanelbackup_ed25519.pub cpanelbackup@backup.example.com

# Test
ssh -i /root/.ssh/cpanelbackup_ed25519 cpanelbackup@backup.example.com

Back in WHM, run Test Connection. Don’t move on until it passes. If it fails, test from the CLI with verbose SSH so you can see exactly where it breaks:

ssh -vvv -i /root/.ssh/cpanelbackup_ed25519 cpanelbackup@backup.example.com

If a firewall is blocking you, fix that first. If you’re not sure where traffic is dying, this checklist covers the usual culprits: VPS firewall troubleshooting tutorial.

Retention policy: pick numbers you can defend to a customer

Retention is where storage budgets quietly get destroyed. You need enough history to catch silent corruption and enough granularity to undo “oops” deletes.

A practical baseline for shared/reseller servers:

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

For WooCommerce or frequently updated sites, push daily to 14. For brochure sites with a low change rate, 7 daily is usually fine. If clients insist on 30+ daily copies, price it accordingly. Retention costs you storage, CPU time, and I/O.

WHM settings to confirm:

• Backup Type: Compressed is usually the right trade-off for storage vs CPU.
• Retention: set daily/weekly/monthly explicitly (avoid “keep all”).
• Staging directory: keep it on a fast disk (NVMe) if possible.

If you want a deeper walkthrough of scheduling mechanics, keep it separate from today’s goal and follow our companion guide: WHM backup configuration tutorial.

Enable encryption (and store the key like you mean it)

Backups contain mailboxes, databases, API keys, and password hashes. Treat them like production data—because they are.

In WHM, enable backup encryption if your version/build supports it for your chosen destination type. If you’re using SFTP to a Linux destination you control, you can add a second encryption layer using GPG or age on the destination server. Just go in with eyes open: it adds moving parts and operational overhead.

Operational rules for encryption keys

• Never store the only copy of the backup key on the cPanel server. If the server is compromised, the key is compromised.
• Store a sealed copy in a password manager vault with restricted access (break-glass policy).
• Document recovery steps so a second admin can restore under pressure.

If you already run a dedicated backup box, keep keys there and restrict interactive shell access. Better yet, isolate backups on a separate VPS for backup storage that does nothing else.

Performance tuning: stop backups from trashing your server at 2 a.m.

cPanel packaging is I/O heavy. On busy nodes, that shows up as slow WHM sessions, delayed cron jobs, and sluggish PHP requests. It’s especially obvious on systems with limited NVMe or oversold resources.

Quick levers inside WHM

• Backup schedule: run during the lowest write-activity window (which isn’t always midnight).
• Minimum free space threshold: fail early rather than filling disks.
• Exclude non-critical paths: large cache directories or backups inside home directories (common in WordPress).

Throttle at the OS level (safe, reversible)

On the cPanel server, you can reduce impact using ionice and nice for heavy backup-related jobs if you wrap them via cron or scripts. For WHM-managed backups, use OS-level tuning sparingly and test carefully. The target is “less impact,” not “backups that never complete.”

# Example: verify you have ionice/nice available
which ionice
which nice

If sites feel slow during backups, measure before you tweak. This guide helps you separate “backup I/O” pain from PHP-FPM capacity problems: VPS performance optimization tutorial.

Validate the destination: prove backups are actually arriving

This guide doesn’t cover restore testing. It’s a separate topic and already covered elsewhere. Here, you’ll confirm that backups are created, transferred, and retained the way you expect.

Check 1: WHM logs show transfer success

In WHM, review the most recent backup run status and confirm your destination shows success, not “skipped.” Then verify from the CLI:

# cPanel backup logs vary by configuration, but these are common places to search
ls -lah /usr/local/cpanel/logs/
grep -R "Backup" /usr/local/cpanel/logs 2>/dev/null | tail -n 50

Check 2: remote path contains new files and retention is working

# From the cPanel server
sftp -i /root/.ssh/cpanelbackup_ed25519 cpanelbackup@backup.example.com
sftp> cd /cpanel
sftp> ls -lah

You’re looking for a predictable directory structure and timestamps that match your schedule. If files pile up indefinitely, retention isn’t set correctly—or you’re writing outside WHM’s managed destination path.

Check 3: bandwidth and runtime are stable

Track total runtime for a week. If it creeps up every day, you’re probably backing up junk (cache directories, node_modules, old archives in home folders), or you’ve outgrown your CPU/I/O headroom.

On busy reseller nodes, a managed environment can save hours. Managed VPS hosting from HostMyCode is a good fit if you’d rather focus on customers and let engineers deal with noisy backup failures and performance regressions.

Common failure modes (and quick fixes)

“Destination failed: Permission denied” on SFTP

• Re-check chroot ownership (root-owned, not writable).
• Confirm the destination path is inside the writable directory (e.g., /cpanel within chroot).
• Verify authorized_keys permissions (usually 700 for .ssh, 600 for authorized_keys).

Backups succeed locally but don’t transfer remotely

• Check outbound firewall rules on the cPanel server.
• Confirm DNS resolution from the cPanel server (dig backup.example.com).
• Look for ISP/provider rate limits on SSH or object storage.

Retention deletes the wrong set (or nothing at all)

• Avoid manual edits inside the destination folder that WHM manages.
• Don’t mix two different backup systems writing into the same directory.
• If you migrated from another server, start with a clean destination path.

Mini checklist: your “backup storage ready” sign-off

• Remote destination created and passes connection test.
• SSH key-based auth in place; password login disabled for backup user.
• Retention configured (daily/weekly/monthly) and verified on remote storage.
• Encryption enabled; recovery key stored off-server with limited access.
• Runtime tracked; excludes configured for obvious junk directories.
• Alerting/monitoring set for backup failures (email or external monitor).

If you’re migrating cPanel accounts to a new server and want storage ready before cutover, read: cPanel account migration tutorial. And if you need a low-downtime DNS plan, this TTL workflow is the safest start: DNS TTL reduction tutorial.

Summary: a backup destination strategy that scales past one server

You’ve configured remote storage in WHM, set retention that won’t quietly blow up your storage spend, and enabled encryption to reduce exposure if archives leak. What keeps this working is the routine: monitor backup runs and review retention every quarter. Your server changes over time; your backup policy should change with it.

If you’re building a new hosting node or splitting roles (web + mail + backups), choose infrastructure you can grow into. A properly sized HostMyCode VPS or HostMyCode dedicated servers gives you the I/O headroom and isolation that makes backups boring—in the best way.

FAQ

Is SFTP or S3 better for cPanel backups in 2026?

SFTP is easier for fast restores and simple auditing. S3-compatible storage is usually cheaper for long retention and offsite durability. Many hosts use both: short retention on SFTP, longer monthly archives on object storage.

Can I store backups on the same server if I also take snapshots?

Local backups help with quick “oops” restores, but they don’t protect you from disk loss or a full-host compromise. Keep at least one remote destination. Snapshots are a strong extra layer, not a replacement for offsite backups.

How much storage should I budget for remote backups?

As a rule of thumb, start with 2–3× your total used home directory space for compressed backups, then validate after a week of runs. Mail-heavy accounts and large public_html media libraries can push that higher.

Why do my backups keep getting bigger every day?

Common causes are cache directories, WordPress backup plugins writing archives into home folders, and log accumulation. Exclude obvious junk and move site-level backups to a different location so you’re not backing up backups.

Do I need to open inbound ports on the cPanel server for remote backups?

No. cPanel pushes backups outbound to the destination. You typically only need outbound access from the cPanel server (for example, TCP/22 to the SFTP host), plus inbound access on the destination server to accept that connection.