cPanel Backups Done Right: Configuration, Remote Destinations, Retention and Restore Tests
A practical guide to WHM Backup Configuration: what to back up, where to send it, how retention really works, the database pitfalls, and how to prove your backups by restoring them.
A cPanel backup you have never restored is a hope, not a backup. To do it right, enable backups in WHM » Backup » Backup Configuration, back up both user accounts and system files, send copies to at least one remote destination that the server itself cannot easily erase, set retention by counting backups (not days), choose the per-account database option, and then prove it works by restoring an account and a single file on a schedule. This guide covers each setting with the names cPanel uses today, plus the warnings buried in the documentation.
Why the defaults are not enough
cPanel's backup system is capable, but it starts disabled, and the most common setups we see keep every copy on the same server, on the same disk, as the websites. A failed drive, a ransomware infection or a mistaken rm -rf then takes the backups along with the data. cPanel's own documentation recommends using a remote destination in addition to local backups.
Step 1: Global settings
Open WHM » Backup » Backup Configuration and start in the Backup Settings tab.
Turn it on and pick a type
- Select Enable Backups.
- Choose a Backup Type: Compressed uses less space but takes longer; Uncompressed is faster but larger; Incremental saves time and space using hard links. cPanel notes that the incremental type works only with Rsync remote destinations, so pick compressed if you plan to use S3, Backblaze B2, Google Drive or SFTP.
Protect the server while it backs up
- Keep Check the Available Disk Space enabled. cPanel warns that without it, backups can run on a nearly full disk and stop critical services.
- Set Maximum Destination Backup Timeout and Maximum Backup Restoration Timeout high enough for your largest account.
Step 2: Schedule and retention
Under Scheduling and Retention, choose daily, weekly and/or monthly backups. Then set retention carefully, because it is easy to misread.
Retention counts backups, not days
The retention field for each schedule is the number of backups to keep (1 to 9999). If you run daily backups on weekdays only and keep 7, you have about a week and a half of history, not seven calendar days. A practical starting point for a business server:
| Schedule | Example retention | What it gives you |
|---|---|---|
| Daily | 7 | A recent restore point for everyday mistakes |
| Weekly | 4 | About a month of weekly history |
| Monthly | 3 | Older copies for problems noticed late, such as a slow-acting infection |
Adjust these to your disk space and any legal retention needs. Leave Strictly enforce retention, regardless of backup success off unless you understand it: it deletes old backups even when new ones fail.
Step 3: What to back up
In the Files section:
- Back up User Accounts, and use Select Users to confirm no account is excluded by accident.
- Back up System Files. cPanel strongly recommends it and notes it is required to restore the server itself.
- Back up Suspended Accounts if suspended clients may come back.
Databases: the setting that bites
Under Back up SQL Databases you can choose Per Account Only, Entire MySQL Directory, or both. Know the trade-offs cPanel documents:
- Per Account Only creates
.sqldumps for each account and works with the normal restore tools. This is the right default. - Entire MySQL Directory copies
/var/lib/mysql/. cPanel warns that copying it while MySQL is running can cause InnoDB problems that make the backup unrestorable, and that these backups cannot be restored through the interface. - PostgreSQL is not backed up by default. If you use it, enable
PSQLBACKUPin/var/cpanel/backups/configas cPanel describes.
Step 4: Remote destinations
Switch to the Additional Destinations tab. cPanel supports Additional Local Directory, Amazon S3, Backblaze B2, Custom, FTP, Google Drive, Rsync, S3 Compatible, SFTP and WebDAV.
Choosing and configuring a destination
- Prefer encrypted transports. For SFTP and Rsync, cPanel strongly recommends key authentication over passwords. Avoid plain FTP for anything sensitive, and send system backups only over encrypted connections.
- Give the destination a clear Destination Name and select Transfer System Backups to this Destination if it should hold system files.
- Click Save and Validate Destination. The Validation Results tab shows a green check or a red X with a message. Do not move on until it is green.
Protect backups from the server itself
The credentials for each destination live on the server. If an attacker gains root, they can use them too. Reduce that risk on the storage side: use a dedicated account or bucket for backups, give it only the permissions it needs, and turn on the provider's versioning or object-lock features where available so older copies cannot be silently overwritten or deleted.
Things cPanel says not to do
- Do not back up to network filesystems such as NFS, CIFS or smbfs; cPanel does not support them.
- If several servers share one destination, give each a unique path.
- Watch overlap: each destination adds transfer time, and backups that outpace transfers can fill the local drive.
Step 5: Local copy, or not?
Retain Backups in the Default Backup Directory keeps a local copy (by default in /backup) after uploading. Local copies make restores fast and are what the File and Directory Restoration tool uses. If you turn this off, you must have a remote destination, and cPanel notes it also disables the restoration interfaces. For most servers, keep a short local history and a longer remote one.
Step 6: Test a restore, for real
Run a backup on demand
Do not wait for the schedule when testing. As root, /usr/local/cpanel/bin/backup --force runs a backup now; logs are written under /usr/local/cpanel/logs/cpbackup.
Restore a single file
In WHM » Backup » File and Directory Restoration, choose an account, browse to a file, pick a backup date and restore it. This tool works only with local backups, and it overwrites the existing file, so test on a harmless file first. cPanel users can do the same in their own cPanel.
Restore a whole account
WHM » Backup » Backup Restoration restores full accounts by account or by date, with options for subdomains, mail configuration and MySQL databases. Restoring over a live account replaces it, so the safest full test is on a separate test server: copy a backup file there and restore it with Transfer or Restore a cPanel Account.
What "passed" means
After the restore, check that the website loads, the database-driven pages work, email accounts and forwarders exist and files have the right ownership. Write down how long it took. That number is your real recovery time.
Backup checklist
- Backups enabled; type matches your destinations.
- User accounts and system files included; no accounts skipped.
- Per-account database dumps; PostgreSQL handled if used.
- Retention set as counts across daily, weekly and monthly.
- At least one validated, encrypted remote destination with versioning or object lock.
- Failure notifications reach a monitored inbox.
- A file restore and a full account restore tested, and repeated quarterly.
Let us verify your backups
Most businesses only discover their backups are incomplete on the day they need them. Max, our founder, is cPanel & WHM certified, and our team sets up and tests cPanel backups for businesses across Miami-Dade and South Florida, with remote support nationwide. Request a free IT assessment and we will review your backup configuration and run a test restore with you.
