Restoring a Full cPanel Backup to a New Server

You've got a full cPanel backup and a brand-new server to put it on — a fresh VPS, a node migration, or a disaster-recovery box after the old one died. Restoring the backup onto the account it came from is easy. Restoring it onto a different server is where things go sideways: username collisions, DNS zones that refuse to overwrite, quota errors, and a MySQL user that "already exists" on a server that's never seen it before.

Symptom: the restore fails, half-restores, or "succeeds" with a broken site

You upload the .tar.gz (or cpmove-username.tar.gz) to the new server and run the restore from WHM. A few outcomes are common:

• WHM reports the restore finished, but the site 500s or the database is empty.
• The restore stalls or errors out with something like Account Creation for username Failed.
• The account restores, but email stops working or the old server keeps answering for the domain.
• MySQL throws ERROR 1396 (HY000): Operation CREATE USER failed partway through.

None of this means the backup is bad. It usually means the destination server has assumptions the restore process didn't expect.

Cause: a full backup assumes it's going home, not to a stranger

A cPanel full backup (cpmove file) bundles the home directory, MySQL databases, email configuration, DNS zone file, and account metadata — including the original UID, package name, and resource limits. When you restore it to the same server, all of that already matches. When you restore it to a different server, several of those assumptions break:

Fix: restore it the way WHM expects, not the way cPanel expects

1. Check what's already on the destination first

Before you touch the restore tool, confirm there's no collision waiting for you:

whmapi1 accountsummary user=username
whmapi1 listaccts search=username searchtype=user

Also check for a stray DNS zone from earlier testing or a previous partial migration:

whmapi1 domainuserdata domain=example.com

If either returns a hit, deal with it before restoring — don't let the restore process try to merge into an existing account.

2. Restore through WHM, not cPanel's own backup tool

Full-account restores to a different server go through WHM → Backup → Restore a Full Backup/cpmove File, not the per-account Backup Wizard in cPanel (that one assumes the account already exists). Upload the file to /home/cpmove-username.tar.gz on the new server first — pulling it through the WHM UI on a slow link is a common source of "corrupt archive" errors on large accounts.

From the command line as root, the equivalent (and more reliable for big accounts) is:

/scripts/restorepkg /home/cpmove-username.tar.gz

Watch the output — restorepkg logs every step, and the real error is almost always buried a few lines above the final failure message, not in it.

3. If the username is already taken

You can't restore two accounts with the same username on one server. Either free up the name or restore under a new one:

/scripts/restorepkg --user=newusername /home/cpmove-username.tar.gz

This renames the account on restore — home directory, MySQL database prefixes, and email all move to the new username. Update anything that hardcodes the old username (cron jobs, deployment scripts, SSH configs) afterward.

4. If the hosting package doesn't exist

cPanel tries to match the backup's package name to a package on the new server. If it can't find one, create a package with the same name first — even a placeholder with generous limits — so the restore doesn't fall back to server defaults that are smaller than the account actually needs:

whmapi1 addpkg name=original-package-name quota=unlimited bwlimit=unlimited

You can tighten the limits after the restore succeeds.

5. If the DNS zone already exists

WHM refuses to blindly overwrite an existing DNS zone during a restore — it's a safety measure, not a bug. If you're sure the old zone on the new server is stale (leftover from testing, or from an earlier attempt that partly failed), remove it first:

/scripts/killdns example.com

Then re-run the restore. If the zone is not stale — say, the domain is genuinely live elsewhere on this server — stop and figure out why before deleting anything.

6. If MySQL rejects the restore

ERROR 1396 and similar usually mean a database user with that name already has grants on the server, often from an old account or a leftover test. Check and drop it only if you're certain it's unused:

SELECT user, host FROM mysql.user WHERE user = 'username_db';
DROP USER 'username_db'@'localhost';

Then re-run restorepkg. It'll recreate the user with the correct grants from the backup.

7. Verify before you touch DNS

Once restorepkg finishes, don't cut DNS over yet. Confirm the account actually works on the new IP first:

• Edit your local hosts file to point the domain at the new server's IP and load the site directly.
• Log into the restored cPanel account and check file counts and database table counts against the source.
• Send a test email through the new server's mail settings before relying on it.

Only after that checks out should you update nameservers or A records — see our guide to pointing a domain to a new server if you need the DNS side of the cutover.

Prevention: make the next restore boring

• Match package names across servers if you regularly move accounts between them — create the same package names on every node so restores never have to guess.
• Keep a UID/username map for accounts you might migrate, so you're not discovering collisions mid-restore.
• Test-restore on a spare server occasionally. A backup you've never restored is a backup you don't actually have.
• Use WHM's Transfer Tool for live server-to-server moves instead of manual cpmove restores when both servers are online — it handles a lot of this collision-checking for you automatically.

A full backup restore to a new server is a routine operation for anyone running WHM day to day, but it's exactly the kind of task where skipping the pre-checks costs you an hour of digging through logs afterward. Check for collisions first, and the restore itself takes minutes.