Taking a backup is the easy half, and it is where nearly all advice stops. What decides whether a backup was worth having is the restore, which has an order and a scope decision and several things that are still broken when the files are back in place.
Creating and restoring backups in cPanel deals with the panel's tools, and managing WordPress backups explains what to capture and how long to keep it. This is about the day you need one.
Decide the scope first
The reflex is to restore everything. It is usually wrong.
A full restore returns the site to the backup's moment and discards every change made since: orders, comments, form submissions, content edited yesterday.
Ask what actually needs to come back. One deleted file is one file. A broken plugin is one directory. A corrupted table is one table. cPanel's partial restores exist for exactly this, and using them turns a day of lost work into a two-minute fix.
Full restores are for a site that is comprehensively broken or compromised, where nothing since the backup is trustworthy anyway.
Restore somewhere else first
Whenever the situation allows it, put the backup in a second location. A subdomain, a separate directory, before touching the live site.
The reason is that a restore over a live site cannot be undone. If the backup turns out to be older than you thought, or already contains the problem, you have replaced a damaged site with a differently damaged one and lost the evidence.
Restoring to a copy costs a few minutes and lets you confirm the backup is actually good before committing to it. Setting up a staging site deals with having somewhere ready.
The order
Files first, then the database.
This matters when the application was updated between the backup and now. A newer database against older code produces errors that look nothing like a version mismatch, and diagnosing them is slower than doing it in the right order.
If you are restoring only one of the two, be certain the other is from a compatible point. Mixing a fresh database with month-old files is the most common way a restore appears to succeed and behaves strangely.
What is still wrong afterwards
Three things, reliably.
Ownership. A restore performed as the wrong user leaves files the web server cannot read, and the site returns 403 errors while every file is present and correct. Understanding file permissions and ownership deals with fixing it.
Addresses inside the database. If the site was restored to a different location (a staging subdomain, a new domain) the old address is stored in the database and the site will try to send visitors back to where it used to live. Changing your site URL deals with correcting it properly rather than with a find-and-replace that breaks serialised data.
Everything since the backup. No restore recovers it. For a site taking orders, that gap has to be reconciled against the payment provider's own records. Backing up a store taking live orders deals with why that procedure should exist before it is needed.
Take a backup before restoring one
This sounds redundant and it is the single most useful habit here.
The current broken state contains today's data. If the restore goes badly, or restores the wrong thing, that state is the only way back, and once it has been overwritten, it is gone.
A copy of the current files and a database dump take a minute and remove the possibility of making a bad day worse.
If the site was compromised
A restore alone does not fix a compromise. It returns the site to a point that may already have been infected, and it does nothing about how the attacker got in.
Restore, then change every password, then update everything, then find the entry point. For the sequence, see cleaning up a hacked WordPress site. Skipping the last step means restoring again next week.
Do it once before you need it
Restore a backup to a subdomain, on an ordinary afternoon, with nothing at stake.
You will find out whether the backup is complete, whether you know where it is, and how long the whole thing takes, which is the number you will want during an outage and cannot estimate under pressure.
A backup nobody has restored is an assumption, and the failure mode is uniform: it existed, it was never tested, and it did not contain what was needed.
Confirm the backup is readable, not merely present
A backup file that exists and cannot be opened is the failure people discover during the restore, which is the worst moment to discover it.
tar -tzf backup-8.20.2026_00-00-00_user.tar.gz >/dev/null && echo "archive is intact" tar -tzf backup.tar.gz | grep -cE 'homedir/|mysql/' tail -2 mysql/database.sql
The first command reads the whole archive without extracting it, so a truncated or corrupt download fails here rather than halfway through a restore. The second confirms it contains both the files and the databases in place of one of them.
The last line of a database dump should be a completion marker in place of an arbitrary statement. A dump that ends mid-table was written while the export was interrupted, and it will import partially and silently, leaving a site that works until it reaches the missing rows.
Restore one thing rather than everything
Most restores are not a whole account. They are one file overwritten, one table emptied, one directory deleted, and replacing the entire account to recover a single file discards everything that happened since the backup was taken.
tar -xzf backup.tar.gz homedir/public_html/wp-config.php sed -n '/CREATE TABLE `wp_options`/,/UNLOCK TABLES/p' database.sql > one-table.sql
The first extracts a single path from the archive without touching anything else. The second pulls one table out of a dump, which can then be imported alone.
Import a single table into a temporary database first and read it there before replacing the live one. That way a table you thought was intact turns out not to be while it still costs nothing. Managing MySQL databases with phpMyAdmin explains the import.
The limits that stop a restore halfway
Restores fail on capacity more often than on corruption, and the constraints are predictable.
df -h ~ du -sh backup.tar.gz df -i ~ | tail -1
Extraction needs room for the archive and its contents at the same time, so an account near its quota cannot restore its own backup. The inode count matters equally: a mail directory with hundreds of thousands of small files exhausts the file allowance before the disk allowance.
Large database imports fail on their own limits rather than on disk. A query longer than the packet size, or an import that exceeds the time allowed through a web interface. Importing from the command line avoids both, and is worth reaching for as soon as a dump is more than a few tens of megabytes. Understanding inodes deals with the count that is easiest to miss.
When the account itself is gone
Everything above assumes an account to restore into. When the account has been terminated, the archive is not a file backup any more; it is the account.
A full cPanel backup recreates the account with its username, its domains, its databases, its mail and its cron jobs, and that has to be done from WHM rather than from inside cPanel.
Two details decide whether it goes smoothly. The username has to be available, if something else has taken it, the restore either fails or lands under a different name and every path referring to the old one breaks. And the package the account belonged to should exist before the restore, or the account arrives with whatever limits the restore chooses. Restoring a cPanel account from backup in WHM sets out the process.