cPanel Account Backup, Restore and Migration

At a glance#

• Purpose: Back up, restore and migrate individual cPanel accounts between servers.
• Applies to: cPanel & WHM on any supported Linux distribution.
• Risk: High — restoring over a live account overwrites current data; migrations involve DNS cutover.
• Time: 30 minutes for a small account; several hours for a large one, plus DNS propagation.

Overview#

A cPanel account backup is a single archive containing everything that account owns: website files, databases, email accounts and messages, DNS zone, cron jobs, SSL certificates and settings. That makes it the unit of both backup and migration.

Three operations are covered here:

Warning: Restoring an account overwrites the existing one of the same name — files, databases and email. If the account is live and has received data since the backup was taken, that data is lost. Always confirm what is currently on the server before restoring.

Before you start#

• Root access to the server(s).
• Sufficient free disk space — at least the size of the account, plus the same again for the archive.
• A maintenance window if the account is live.
• For migrations: root SSH access from the destination to the source.

Check space and account size first:

df -h /home
du -sh /home/username

Warning: pkgacct writes the archive to /home by default. Backing up a 40 GB account on a partition with 30 GB free fills the disk and takes every hosted site down. Check first, and use --dbbackup alternatives or a different destination if needed.

Part 1 — Backing up a single account#

1. Create the backup#

sudo /scripts/pkgacct username

This produces /home/cpmove-username.tar.gz.

Useful options:

# write somewhere other than /home
sudo /scripts/pkgacct username /backup

# skip the homedir - config, databases and mail only
sudo /scripts/pkgacct --skiphomedir username

# skip databases
sudo /scripts/pkgacct --skipdb username

# no compression - faster, much larger
sudo /scripts/pkgacct --nocompress username

2. Verify the archive#

Never assume a backup is good:

ls -lh /home/cpmove-username.tar.gz
tar -tzf /home/cpmove-username.tar.gz | head -20
tar -tzf /home/cpmove-username.tar.gz | wc -l

If tar -tzf errors, the archive is truncated or corrupt — usually because the disk filled during creation.

3. Move it off the server#

rsync -avz --progress /home/cpmove-username.tar.gz backup-server:/backups/cpanel/

A backup stored only on the server it protects is not a backup.

Part 2 — Restoring an account#

1. Check what is currently there#

sudo /scripts/whoowns domain.com
ls -la /home/username
sudo mysql -e "SHOW DATABASES;" | grep username

If the account exists and is live, take a fresh backup of the current state before overwriting it:

sudo /scripts/pkgacct username /backup/pre-restore

2. Restore#

cd /home
sudo /scripts/restorepkg username

To restore from an archive in a non-default location:

sudo /scripts/restorepkg --force /backup/cpmove-username.tar.gz

Restore only parts of the account:

# databases only
sudo /scripts/restorepkg --skipres --skiphomedir username

# files only
sudo /scripts/restorepkg --skipdb username

3. Fix ownership if needed#

sudo /scripts/mailperm username
sudo chown -R username:username /home/username/public_html

Part 3 — Migrating an account to another server#

Preparation#

1. Confirm the destination has the same or newer cPanel version.
2. Confirm PHP versions and required extensions match.
3. Lower the DNS TTL to 300 seconds at least 24 hours in advance.

Warning: Skipping the TTL reduction turns a 10-minute cutover into hours of split traffic, where some visitors reach the old server and some the new one. On a site with a database, that means writes landing on both — and data loss when the old server is decommissioned.

Option A — WHM Transfer Tool (preferred)#

On the destination server:

WHM → Transfers → Transfer Tool

1. Enter the source server's IP, SSH port and root credentials.
2. Click Fetch Account List.
3. Select the accounts to move.
4. Choose what to include — accounts, packages, service configuration.
5. Start the transfer.

The tool handles packaging, transfer, restore and ownership. Progress and errors appear live.

Option B — Manual transfer#

On the source server:

sudo /scripts/pkgacct username

Copy to the destination:

rsync -avz --progress /home/cpmove-username.tar.gz root@destination:/home/

On the destination:

cd /home
sudo /scripts/restorepkg username

After the transfer, before DNS cutover#

Test the site on the new server without changing DNS, by overriding resolution locally:

# on your workstation, add to /etc/hosts or C:\Windows\System32\drivers\etc\hosts
203.0.113.50   example.com www.example.com

Then browse the site. Check:

• Pages load and images resolve
• Database-driven content works (log in, submit a form)
• Email accounts appear in cPanel with the expected mailbox sizes
• SSL certificate is present and valid
• Cron jobs are listed

Remove the hosts entry afterwards.

DNS cutover#

1. Update the A records to the new server's IP.
2. Watch both servers' access logs to see traffic move:

# on the old server
sudo tail -f /usr/local/apache/logs/access_log | grep example.com

# on the new server
sudo tail -f /etc/apache2/logs/domlogs/example.com

1. Keep the old server running for at least 7 days — resolvers holding the old record will keep hitting it.

Final steps#

# reactivate the licence if the IP changed
sudo /usr/local/cpanel/cpkeyclt

# rebuild DNS
sudo /scripts/rebuilddnsconfig

# update SPF and PTR for the new IP
dig TXT example.com +short
dig -x 203.0.113.50 +short

Mail deliverability depends on both. See Change Primary IP of cPanel.

Automating account backups#

WHM has built-in scheduling: WHM → Backup → Backup Configuration.

Set:

• Backup type: Compressed
• Schedule: Daily retained 7, weekly retained 4, monthly retained 3
• Destination: an additional remote destination (SFTP or rsync), not just local
• Databases: per-account backup

Warning: Local-only backups do not survive the loss of the server. Configure a remote destination, and verify it is actually receiving files — a misconfigured remote destination fails silently and the backup page still shows green.

Verify backups are landing:

ls -lh /backup/$(date +%Y-%m-%d)/accounts/
sudo tail -50 /usr/local/cpanel/logs/cpbackup/$(date +%Y-%m-%d)*.log

Verification#

After any restore or migration:

# account exists and is owned correctly
sudo /scripts/whoowns example.com
sudo grep username /etc/trueuserdomains

# files present
ls -la /home/username/public_html | head

# databases restored
sudo mysql -e "SHOW DATABASES;" | grep username

# email accounts present
sudo ls -la /home/username/mail/example.com/

# DNS zone exists
sudo cat /var/named/example.com.db | head -20

# cron jobs carried over
sudo crontab -l -u username

# site responds
curl -sI https://example.com | head -1

Then have the site owner confirm — log in, place a test order, send and receive mail. A restore that looks complete at the filesystem level can still have a broken application config pointing at the old server's database host.

Rollback#

Warning: /scripts/removeacct deletes the account, its files, databases and email permanently. Confirm you have a verified backup before running it.

Troubleshooting#

Related#

• Restore Email of a Specific User from Backup in cPanel
• Change Primary IP of cPanel
• cPanel Configuration Tweak
• DNS Troubleshooting: dig, Propagation and Common Failures