Applies to: All plans. Self-Managed plans self-restore from JetBackup in cPanel; on Managed plans you can self-restore the same way, and our team can also restore for you.
Before you start: You need access to cPanel for the hosting account (open your service in the client area, then choose Log in to cPanel), and you should know the exact database name you want to restore. Restoring a database overwrites its current contents with the snapshot version, so take a fresh export first if the live data might still be useful.
A database restore replaces one MySQL database with a copy saved in a backup snapshot. This is the right tool when an import went wrong, a plugin corrupted your tables, or you need yesterday's data back — without touching your files or the rest of your account.
When to restore a database (and when not to)
- Restore a database when only your data is broken but your files are fine — for example after a bad SQL import or a database error.
- If your files are the problem instead, see How to restore a file or folder.
- If the whole site is broken, see How to restore a full account or website.
Step-by-step: restore a database from a snapshot
- Log in to cPanel for the affected account (client area -> Services -> My Services -> open the service -> Log in to cPanel).
- Open the JetBackup tool — look under the Files or Jetbackup section of the cPanel home screen for the option labelled JetBackup (it may be shown as "JetBackup 5").
- Choose the database restore option — the item labelled Database Backups (sometimes shown as "Databases").
- You will see a list of available snapshots by date. Pick the date you want to restore from. Your retention depends on your plan: Self-Managed Lite keeps a weekly snapshot, Self-Managed Plus keeps 7 days, Self-Managed Pro keeps 14 days, and Managed keeps 30 days off-site. See Backup retention by plan for the full list.
- Find the database you want in that snapshot and select Restore next to it. If you are asked to confirm, read the warning — the restore will overwrite the current database of the same name.
- Confirm and wait. The restore is queued and runs in the background; larger databases take longer.
Result: When the job finishes, your database is back to the state it was in on the snapshot date. Reload your site and check that the data you expected has returned.
After the restore
- Your database user and its password do not change during a database restore, so you usually do not need to edit your site's config. If your application still cannot connect, check its database credentials. For WordPress see Fixing "Error establishing a database connection".
- Clear any caching (for example LiteSpeed Cache) so visitors see the restored data, not a stale page.
Troubleshooting this task
- No snapshots listed: backups are taken daily but a brand-new account may not have one yet, and Self-Managed Lite only keeps a single weekly snapshot. Check again later or pick the most recent available date.
- The database you want is not in the snapshot: it may have been created after that snapshot was taken. Choose a more recent snapshot, or restore a snapshot from after the database existed.
- Restore seems stuck: large databases queue and can take a while — give it time before retrying. If it never completes, contact us with the database name and snapshot date.
- You only need part of the data: a full database restore is all-or-nothing. To pull individual rows or tables instead, use phpMyAdmin to export from a snapshot-restored copy, or ask support.
Comments
0 comments
Please sign in to leave a comment.