Disable cPanel backups when JetBackup is running

Most cPanel + JetBackup installs leave the cPanel built-in backup system enabled by accident. It quietly writes full account tarballs to /backup every cycle, on top of JetBackup's incremental snapshots, until the partition fills and the next backup run aborts mid-flight. The fix is two minutes; the cleanup is one rm once you have verified JetBackup has enough history.

This is one of the most common "JetBackup stopped working" support tickets, and the cause is almost always disk pressure from the other backup system. Do this on every cPanel server that runs JetBackup.

Confirm the symptom

df -h /backup
du -sh /backup/cpbackup* /usr/local/jetapps/usr/jetbackup5/repository 2>/dev/null

If /backup/cpbackup/* exists and is non-trivial in size (anything over 1 GB on a server you thought was JetBackup-only), the built-in is still running. JetBackup writes to /usr/local/jetapps/... and never touches /backup unless you have explicitly configured a local destination there.

Disable cPanel's backup configuration

In WHM, Home → Backup → Backup Configuration. Set Backup Status to Disabled. Save.

Or from the CLI:

whmapi1 backup_config_set backupenable=0

Untick "Backup Accounts" or removing accounts from the user selection is not enough — those settings only affect which accounts get backed up, not whether the cron job runs. The cron still fires, creates the staging directories, and exits without doing useful work. Set the master switch off.

What to keep enabled

A couple of things are worth leaving on, even with JetBackup running:

• Backup User Selection — leave it populated with all accounts. If you ever need to re-enable cPanel backups in a hurry (JetBackup outage, destination unreachable for days), the account list is already correct.
• Account Suspension backup — under WHM → Account Functions, the "Back up account before suspension" option uses pkgacct directly, not the backup system. It is independent and worth keeping.

Clean up old backups

Before deleting anything in /backup, confirm JetBackup actually has working history. From WHM → JetBackup 5 → Backup Jobs, check the Last Run and Status of every job. From the CLI:

jetbackup5api -F listSnapshots -D '{"limit": 5}' | jq '.data.snapshots | length'

If you have at least 7 days of successful snapshots covering every account, the old cPanel backups are safe to delete:

# Look first
ls -lh /backup/cpbackup/

# Then remove, only when you have verified JetBackup history
rm -rf /backup/cpbackup
rm -rf /backup/cpbackup_transporter

Watch the disk free up:

df -h /backup

On a busy reseller server this typically frees 100-500 GB. Keep an eye on the partition for a few days — if JetBackup's local repository lives on /backup too, you have just made room for it to grow, which is fine.

Verify the cPanel backup cron is gone

grep -r backup /etc/cron.d/cpanel* /var/spool/cron/root 2>/dev/null

You should see no /usr/local/cpanel/scripts/cpbackup entries firing. If one remains, the disable did not stick — usually because WHM Tweak Settings has a separate "Backup Configuration" override. Check there too.

What you have just changed

• cPanel's built-in backup cron no longer runs.
• /backup is no longer written to (unless JetBackup has a local destination there).
• The user-facing backup section in cPanel still appears, but shows JetBackup's snapshots only.
• WHM Transfer Tool still works — pkgacct is called on demand during transfers, independent of the backup system.

If you ever need to fall back to cPanel built-in, flip Backup Status back to Enabled. The user list is preserved. Compare the two systems in JetBackup vs cPanel built-in backups before deciding.

Next steps

• Activate or expand at JetBackup licensing.
• Deciding which to keep? Read JetBackup vs cPanel built-in backups.
• Adding more destinations? See JetBackup 5 destinations for cPanel.