Restoring is the half of backup that nobody practises, and it is where the surprises are. A backup you have never restored is a hypothesis.
The mechanics in WHM are straightforward. What matters is knowing what a restore overwrites, and choosing the smallest restore that solves the problem.
Restore the least you can
The instinct is to restore the whole account. That is right after a catastrophic loss and wrong for almost everything else.
A full restore replaces files, databases, mail and settings with the state at backup time. Anything that arrived since, orders, comments, mail, is gone, and there is no warning that names what you are about to lose.
So: one deleted file, restore one file. A corrupted database, restore that database. Only a genuinely destroyed account justifies restoring everything.
Restoring a full account
In WHM, Restore a Full Backup/cpmove File handles an account backup as one unit.
It recreates the account if it does not exist, and overwrites it if it does. Reseller ownership and the package are restored with it, which is why this is the right tool after an accidental termination.
Confirm the destination before starting. Restoring onto an account that still exists is a replacement, and it is not reversible unless you took a backup of the current state first, which is the step to take before any full restore, even of something broken.
Restoring parts
Restore a Backup lets you choose what: the home directory, individual databases, mail, or the DNS zone.
This is the tool for almost every real incident. A site broken by an update needs its files, not its mail. A database corrupted by a bad plugin needs that database, and restoring files alongside it would undo work that was fine.
Separating them takes a moment of thought and saves an afternoon of explaining what else went missing.
Single files, from cPanel instead
For one file, WHM is the wrong place. The account's own file restore in cPanel handles it, and clients can do it themselves without you.
Point clients at it. Every file restore they do without a ticket is worth more than the feature costs to explain. Backing up and restoring your website deals with the client's view.
Databases are the awkward part
Restoring a database replaces its contents entirely. Everything written since the backup is gone, and on a shop, that is orders.
Before restoring, export the current database first. It may be broken, and it contains today's data, and merging the two afterwards is possible only if you kept it.
Also check the database user and its grants. A restore can bring the database back without its user having access, and the symptom is an application reporting a connection error against a database that is plainly present. Managing databases with phpMyAdmin sets out checking.
What a restore does not bring back
Three things that catch people, all of them server-level rather than account-level.
The PHP version, if the account was set to inherit and the server default has since changed.
Certificates, which may need reissuing for the restored domain, run AutoSSL afterwards instead of assuming coverage came back.
Anything outside the account. A firewall rule, a server-level configuration, a cron job owned by root: none of that is in an account backup.
Restoring to a different server
An account backup restores onto another machine, which is how migrations work when you do not have root on the source.
Two things to check first. The destination must offer the PHP version the site needs, and there must be room for the archive and the extracted account simultaneously.
Do not point DNS at the new server until you have tested the restored site through your hosts file. That is the only way to find a missing extension before visitors do. There is more on the full sequence in transferring cPanel accounts.
Know what you actually have
Before an incident, not during it.
Check how far back your backups go and how often they run. A daily backup kept for seven days does not help with a compromise discovered after a fortnight, and compromises are usually discovered late.
Check where they are stored. Backups on the same server survive a mistake and not a server failure, and that distinction is the whole point of the offsite copy.
Test a restore before you need one
Restore an account to a test account on the server. Load the site. Check the database has recent data in it.
This finds the problems that only appear at restore time: a backup that was running but excluding a directory, a database too large to have completed, a job that silently stopped weeks ago.
Once a quarter is enough, and it converts your backup from an assumption into a known quantity. There is more on configuring what runs in WHM backup strategy.
During a real restore
Tell the client what you are doing and what window of data will be lost. That conversation is much easier before the restore than after.
Put the site into maintenance mode so nothing new arrives mid-restore. An order placed during a database restore is written into a database being replaced.
Then check the site properly afterwards: a page, a form, the admin login, and recent data. A restore that completed is not the same as a restore that worked.
Read the archive before restoring it
A restore is faster to start than to undo, and looking inside the file first costs a minute.
tar -tzf /backup/cpmove-user.tar.gz | head -20 tar -tzf /backup/cpmove-user.tar.gz | grep -cE '^[^/]+/homedir/' tar -tzf /backup/cpmove-user.tar.gz | grep -E 'mysql/.*\.sql$' | head
Confirm the account name inside the archive matches what you expect, that the home directory is present, and that the databases are there. An archive missing the database directory restores a working account with an empty site, and the failure is discovered after the old state is gone.
The username inside the archive is what the restore uses. If that name is taken by something else on the target server, the restore either fails or lands under a different name, and every path referencing the old one breaks.
Restoring over a live account
The most dangerous restore is the one performed onto an account that is currently serving, because it is partly destructive and partly not.
Files are replaced. Files that exist now and did not exist in the backup are frequently left in place, which produces a mixture rather than the state the backup captured. Databases are replaced wholesale, so anything written since is gone.
cp -a /home/user /home/user.before-restore-$(date +%F) du -sh /home/user /home/user.before-restore-* 2>/dev/null
Take a copy of the current state first, even though it is the broken state. It costs disk and it is the only way back if the restore turns out to be from the wrong date. Backup strategy for reseller accounts deals with having the right dates available.
What to check immediately afterwards
A restore that completes reports success. Several things are commonly wrong at that point and none of them is reported.
ls -la /var/cpanel/users/username quota -s -u username mysql -e "SELECT user, host FROM mysql.user WHERE user LIKE 'username\_%'" curl -sI https://example.com/ | head -1
Ownership of the restored files, the quota, and the database users and their grants are the three that fail most often. A restored database with no user granted access produces a site showing a connection error, which reads like a failed restore and is a two minute fix.
Check the site itself last, and check a page that uses the database rather than a static one. A home page served from cache proves nothing about whether the restore worked.