Taking and restoring backups in Plesk
By Datafex Engineering TeamPublished 4 min read
The most expensive myth about backups is that once configured they take care of themselves. Taking a backup in the panel is easy; whether it is any use depends on where it is kept and whether it has ever been restored. Below is how to build a backup routine through the panel on the web hosting plans.
What a panel backup covers
A subscription backup looks like a single file, but inside it there are four independent sets, and you choose which of them you want when you take it.
| Set | Contents | What happens if you skip it |
|---|---|---|
| Configuration | Domain, PHP settings, mail and DNS definitions | The site runs, but you rebuild its settings by hand |
| Files | Everything in the site's document root | Themes, plugins and media are gone |
| Databases | Every database attached to the subscription | No posts and no settings |
| The contents of the mailboxes | The mailboxes come back empty |
Taking a configuration-only backup and assuming it also carries the data is a common mistake. In a disaster scenario you need all four sets.
Taking a backup by hand
Enter the panel with the Open Plesk panel button in your customer panel and go to the subscription's backup section.
- Choose the scope; unless you have a reason not to, tick all four sets.
- Write a note saying what this backup is — "before the plugin update", for example. Three months later a date alone will not tell you which backup is which.
- When it finishes, look at the size in the list. If it is much smaller than you expected, the scope was chosen incompletely.
- Download it. Until you do, the backup is sitting inside the very server it is supposed to protect.
The job does not stop the site, but while a large database backup is running the site may slow down briefly, so do not start one during peak hours.
There has to be a copy outside the server
A backup taken in the panel is stored on the server side by default. That copy is for a quick rollback: undoing a bad update in half an hour. In a scenario where the server is unreachable, that copy is unreachable too.
So every backup routine needs at least one copy outside the server. There are two routes: download the backup and keep it in your own environment, or define remote storage in the panel so backups are shipped there. How many copies, at what frequency and with what retention is covered in detail in server backup strategy.
Scheduled backups
A backup taken by hand is, over time, a backup not taken. Set up a daily or weekly schedule in the panel and watch two settings: how many backups are kept, and where they are written. Keeping only one is dangerous — if corruption goes unnoticed for a week, the corrupted copy is all you have.
After creating the schedule, follow its first run and confirm in the list that the backup really appeared. A backup job that quietly stops running is discovered months later, at the worst possible moment.
Restoring: everything, or one object
The panel offers two kinds of restore. A full restore returns the subscription to its state in the backup, and every change made since then is gone. A selective restore brings back only a particular domain, database or mailbox.
In practice what you need is almost always the second one: a single plugin is broken, a single table was dropped, or a user emptied their own mailbox. A full restore usually makes things worse by wiping the orders and comments that arrived in between.
If you want a handful of deleted rows back, the cleanest route is to import the database from the backup as a second database and copy the rows you need across, leaving live data untouched.
Backups use your disk allowance too
Backups held on the server side take up space, and they grow as the retention count rises. On plans pressed against the disk limit this is one of the first places to look; the order to follow when a plan fills up is collected in when the disk or traffic limit fills up.
The step that matters most: restore one, once
An untested backup is an assumption. Once a year, restore a backup onto a subdomain or a domain that is not live, open the site and count the rows in the database. Until you have done that, what you have is not a backup — it is a backup file.
If you administer your own machine, building this routine falls to you. On the virtual server side a snapshot of the machine is a separate option, but a snapshot is a photograph of the whole machine; it is not a consistent copy of a running database, and the application-level backup is still yours to set up.