cPanel: configuring automatic backups

Built-in cPanel backups

cPanel → Backup Wizard or Backup. A full backup includes: files, databases, Email, DNS zones.

Setting up remote FTP storage

WHM → Backup Configuration:

Compression noticeably reduces the amount of data transferred, but it raises CPU load while the archive is being built — on busy servers it is better to schedule backups for nighttime, when traffic is lowest.

Real JetBackup and Built-in Backup Errors

If the remote storage is unreachable when the job runs, the WHM log shows an entry like:

Failed to establish connection to destination: Connection timed out
Backup transfer failed for destination: RemoteFTP-01

The cause is almost always one of three things: wrong FTP/S3 credentials, a firewall blocking the outbound connection from the hosting server, or the storage running out of space. The second common problem is the local disk filling up before the transfer to remote storage even starts:

Backup failed: not enough free space on /home to complete
local backup before transfer

A full backup is assembled locally first and only transferred afterward, so there must be enough free space for the whole archive even when the final destination is an external server.

Full, Incremental, and Files-Only Compared

Restoring via cPanel

# Files only
cPanel → Backup → Restore a Home Directory Backup

# Database only
cPanel → Backup → Restore a MySQL Database Backup

# Via WHM (if cPanel is unavailable)
WHM → Restore a Full Backup/cpmove File

The 3-2-1 Rule on Shared Hosting

The classic backup rule is three copies of the data, on two different types of media, with one copy stored off-site. On shared hosting it is not hard to satisfy, as long as you do not rely solely on the provider's automatic backup:

• Copy #1 — the live files and database on the hosting account itself
• Copy #2 — the daily automatic ZevsHost backup, stored separately from the working partition
• Copy #3 — a backup on external FTP/S3 storage, physically on a different server with a different provider

If all three copies sit on the same server, a disk failure or an account breach can wipe them out at once — which is exactly why the third copy has to be genuinely off-site.

When the Built-in Schedule Is Not Enough

• You need retention longer than 4 weeks — the built-in WHM scheduler does not keep history beyond the last weekly/monthly cycle
• You need backups more often than once a day for critical databases — that requires a separate cron job with mysqldump, independent of the WHM schedule
• The infrastructure has grown so large that a full backup no longer finishes within the nightly window — switching to JetBackup's incremental backups helps here
• You need automated integrity checking of a backup right after it is created, instead of manually unpacking it during the next incident

Recognizing a Skipped Backup

With notifications enabled, WHM sends an email after every backup attempt, even a failed one. A successful run looks like this:

Subject: Backup Completed for user
Backup Type: Full Backup
Status: Success
Duration: 00:14:32

If the email says Failed instead of Success, or no email arrives at all, check the job queue and free space right away — a skipped backup means that during the next incident you will have to restore an older version of the site than expected.

Verifying the Result

1. After the schedule runs for the first time, open WHM → Backup Configuration and confirm the last job finished with no errors
2. Download one archive from remote storage and unpack it locally to confirm it is not corrupted
3. Once a quarter, do a trial restore on a test account — that is the only way to know a backup actually works

Manually backing up a single site before risky edits is described in the article How to Create a Website Backup, and exporting and restoring large MySQL dumps is covered in the article mysqldump: backup and restore.