How to Back Up and Restore a cPanel Account

A backup you have never restored is a guess. On a cPanel account, the files, the databases, the email and the cron jobs all live in different places, so a backup only helps if you know which pieces it holds and how to put them back. This guide shows how to make a full cPanel backup, how to copy it somewhere safe, how to restore it into an account, and how to check that the restored site really works. It is written for the account owner, not the server administrator, so every step is done in cPanel or over SSH with your own account.

SiteHarbour’s cPanel hosting plans include daily backups, so the server is not your only copy. The steps below give you a copy you control, which you can restore on your own schedule and keep off the server.

What a full cPanel backup contains#

A full backup is an archive of the whole account. It normally includes:

• Your files in public_html and the other home folders, including .htaccess files and uploads.
• Your MySQL databases and users, exported as SQL.
• Email accounts, forwarders and filters, with their settings.
• Cron jobs, domain settings and SSL certificates, as configuration.

Two things are often left out, so check for them yourself: databases created by an application outside cPanel, and any file kept outside your home folder. Make a note of both before you start.

Step 1: Create a full backup in cPanel#

Log in to cPanel and open Backup under Files. Choose Download a Full Website Backup, select the archive type, and enter an email address for the completion notice. For a large account, download the file while the account is quiet, not during peak traffic.

Expected: an email with a download link when the archive is ready. Keep the archive as it is. Do not open it and re-save it, because that changes the file.

If you only need the website files and one database, use the Backup Wizard instead, and choose Partial Backup. The wizard lets you pick the home directory and individual databases.

Step 2: Take a separate copy of the databases#

A full backup is useful, but a database export you can read on its own is faster to restore after a single table goes wrong. Connect over SSH with your own cPanel user and run:

mysqldump -u cpuser_dbuser -p cpuser_dbname > ~/backup-cpuser_dbname-$(date +%F).sql

Replace the three names with the database user and database shown in MySQL Databases. The command asks for the password, which you should not put in the command line where it would be saved in your shell history. Expected: a .sql file in your home folder with a date in its name. Check the end of the file, which should say the dump completed.

Step 3: Copy the backup off the server#

A backup on the same server is lost with it. Download the archive and the SQL file to a computer or a storage service you control. From your own computer, use SFTP or an SCP client with your SSH key, and keep the copy in at least two places. Store it encrypted if it holds customer data, because it includes database contents and email.

Step 4: Restore into a clean test account first#

Restore into a new account or a test subdomain before you touch the live site. This shows whether the backup is complete. In cPanel, open Backup, then Restore a Full Backup or the Backup Wizard, and upload the archive. For a file-level restore, extract the archive into the target home folder with the extraction tool in File Manager, or over SSH:

tar -xzf backup-cpuser.tar.gz -C ~/restore-test

Import each database into its matching database with the same user privileges. Then check the restored site in a browser: the home page, a logged-in page, a form that writes to the database, and an uploaded image. A WordPress site should also show the dashboard after you log in.

Step 5: Restore the live site when you need it#

Restore to the live account only after the test restore works. Put the site into maintenance mode first, or tell your users it will be down. Restore the files, then the databases, then check the DNS and SSL. A restore that replaces files but not the matching database leaves a site that looks correct and fails on the first login, so restore both.

Common mistakes#

• Trusting the backup without a test. The first real restore should not be the first time you have tried it.
• Keeping every copy in one place. If the account is compromised, a backup in the same account can be deleted too.
• Restoring over a newer database. Export the current database before a restore, in case you need to recover data written after the backup.
• Forgetting email. A full backup includes mailboxes, but mail that arrives during the restore can land in the wrong place. Pause delivery or warn users.

Frequently asked questions#

How often should I back up a cPanel account?#

Back up before every major change, such as a plugin update, a theme change or a PHP version switch. For ongoing protection, keep at least one copy from the last 7 days and one from the last month, off the server.

Can I restore one file without restoring the whole account?#

Yes. Extract just that file from the archive with tar -xzf backup.tar.gz path/to/file, and copy it into place. Check the file’s permissions afterwards.

Does the backup include my SSL certificate?#

A full backup includes the certificates on the account. After a restore to a different server or IP address, check that AutoSSL or your certificate still applies to the domain.

Why does the restored site show a database error?#

Usually the database user, password or name in wp-config.php or the application’s configuration file does not match the restored database. Compare them with the values in MySQL Databases.

A cPanel backup is only as good as your last test restore. Create a full backup, copy it off the server, restore it into a test account, and check the site and the database together. Then you know that when something breaks, you can put it back. For the wider picture of keeping an account safe, read how to keep your cPanel account and sites secure.