How to Create Database Backups via cPanel

Why database backups deserve their own routine

For most dynamic websites, the database is the part you cannot recreate. Theme files and plugins can be downloaded again, but posts, orders, customer accounts, form submissions and settings live only in MySQL or MariaDB. A failed plugin update, a compromised admin account, an accidental DELETE query or a hosting account suspension can all leave you needing yesterday’s data rather than last month’s.

Many hosts run their own server-level backups, but their frequency, retention and restore process vary widely and are not always guaranteed in the plan terms. Treat host backups as a safety net, not your strategy. This guide walks through every practical way to back up a database from cPanel, how to automate it, and how to confirm the backups actually work.

Before you start: find the right database

Accounts often accumulate databases from old installs, staging copies and abandoned plugins. Before backing anything up, confirm which database your live site uses.

• WordPress: open wp-config.php and read the DB_NAME value.
• Other PHP apps: look for a config.php, .env or settings.php file containing the database name and user.
• cPanel: go to Databases > Manage My Databases (shown as MySQL Databases in many themes) to see every database, its size and the users assigned to it.

cPanel prefixes database and user names with your account username, for example acct_wp482. Note the full name, because you will need it in commands and when restoring.

Method 1: the cPanel Backup page

The quickest manual option is the Files > Backup page. Under Download a MySQL Database Backup, cPanel lists each database as a link. Clicking one downloads a compressed .sql.gz file to your computer.

1. Log in to cPanel and open Backup.
2. Scroll to the database section and click the database name.
3. Save the file somewhere outside your hosting account, ideally with the date in the filename.

The same page has a Restore a MySQL Database Backup upload field, which imports a .sql or .sql.gz file into the database of the same name. Be careful: restoring overwrites the existing tables with the contents of the dump.

The Backup Wizard offers the same functions in a step-by-step layout. Some hosts disable or customise these tools, so if you do not see them, check your provider’s documentation.

Method 2: export with phpMyAdmin

phpMyAdmin, found under Databases > phpMyAdmin, gives you more control over what is exported.

1. Select the database in the left sidebar.
2. Open the Export tab.
3. Choose Quick for a standard SQL dump, or Custom to select specific tables, enable compression (gzip) and add DROP TABLE statements.
4. Keep the format as SQL and click Export (or Go).

phpMyAdmin runs inside PHP, so it is subject to execution time and memory limits. For databases larger than a few hundred megabytes, exports may time out or produce truncated files. If that happens, switch to the command-line method below.

Choosing the right export options

• Custom > Compression: gzipped reduces download size significantly for text-heavy data.
• Add DROP TABLE makes restores cleaner, because existing tables are replaced rather than causing errors.
• Character set: keep utf8mb4 if your site uses it; mismatched character sets are a common cause of garbled text after a restore.

Method 3: mysqldump over SSH

If your plan includes SSH or the cPanel Terminal, mysqldump is the most reliable way to back up a database of any size. It does not depend on PHP limits and can stream directly into a compressed file.

mkdir -p ~/db-backups
mysqldump --single-transaction --quick --routines --triggers acct_wp482 | gzip > ~/db-backups/acct_wp482-$(date +%F).sql.gz

A few notes on those options:

• --single-transaction takes a consistent snapshot of InnoDB tables without locking the site.
• --quick streams rows instead of buffering whole tables in memory.
• --routines and --triggers include stored procedures and triggers, which some applications rely on.

Avoid typing the password on the command line, where it can appear in process lists and shell history. Instead, create a ~/.my.cnf file readable only by you:

[client]
user=acct_wpuser
password=YourStrongPasswordHere

chmod 600 ~/.my.cnf

Keep backup folders outside public_html. A dump sitting in a web-accessible directory can be downloaded by anyone who guesses the URL, which exposes every user record and password hash in the database.

Comparing the backup methods

Automating backups with cron

Manual backups get forgotten. The Advanced > Cron Jobs page lets you run the dump on a schedule, and cPanel will email output to the address you set at the top of the page. A simple nightly job at 03:15 server time:

15 3 * * * mysqldump --single-transaction --quick acct_wp482 | gzip > $HOME/db-backups/acct_wp482-$(date +%F).sql.gz

In crontab, the percent sign has a special meaning and usually needs escaping. To avoid escaping issues entirely, put the commands in a small script and call that from cron instead:

#!/bin/bash
DB=acct_wp482
DIR=$HOME/db-backups
mkdir -p "$DIR"
mysqldump --single-transaction --quick "$DB" | gzip > "$DIR/$DB-$(date +%F).sql.gz"
find "$DIR" -name "*.sql.gz" -mtime +14 -delete

15 3 * * * /bin/bash $HOME/bin/db-backup.sh

The final find line deletes dumps older than 14 days, so backups do not quietly fill your disk quota. Adjust retention to your needs; a common pattern is daily copies for two weeks plus a weekly copy kept longer.

If you are building more automation around your account, our guide to cPanel hosting automation tips covers cron hygiene and related tasks.

Storing backups off the server

A backup stored only in the same hosting account shares every risk with the original: the same disk, the same account suspension, the same compromised password. Follow the familiar 3-2-1 idea where practical: several copies, on more than one type of storage, with at least one copy off-site.

• cPanel remote destinations: on servers where the host allows it, backups can be sent to SFTP, S3-compatible storage or similar targets.
• Pull from your own machine: use rsync or scp from a computer or NAS to fetch the db-backups folder regularly.
• Encrypt sensitive dumps before uploading them to third-party storage, especially if they contain customer data.

Backups also do not help if the account itself lapses. Hosting renewals and domain expirations are a common cause of sudden data loss. Tracking renewal dates in TLDix hosting monitoring gives you advance alerts before a plan expires and takes the databases with it.

Testing restores and common problems

Restore tests are where backup plans usually fail. At least monthly, create an empty test database in cPanel, assign a user, and import a recent dump:

gunzip < ~/db-backups/acct_wp482-2026-10-07.sql.gz | mysql acct_restoretest

Then check that table counts look right and that recent records, such as the latest order or post, are present. Drop the test database afterwards so it does not consume quota.

Frequent issues

• “MySQL server has gone away” on import: often a packet size or timeout limit; import via the command line rather than phpMyAdmin.
• Definer errors on views or triggers: the dump references a user that does not exist on the new server; edit or remove the DEFINER clauses.
• Empty or tiny files: the dump failed silently, usually due to a wrong password or database name. Check cron email output and file sizes.
• Quota exceeded: old backups piled up. Enforce retention and watch disk usage.

Finally, remember that a database dump is only half a restore. Keep copies of your site files and configuration as well, so you can rebuild a working site rather than just a set of tables.