Restoring a backup: if you have not tested it, you do not have it

«We have daily backups.» That is what almost everyone says, and it is usually true. What people do not usually know is whether those backups can be restored, how long it takes and what gets lost along the way. There are only two ways to find out: in a calm drill or on the day the shop is down. The second is the usual one.

This article is not about how many backups to make or where to keep them, but about the step almost nobody takes: checking that they come back.

What goes wrong when restoring a shop

These are the problems that come up most often when a backup is used for the first time:

• The backup only has files, or only the database. The hosting copies the web folder, but the database is on another server and is not included. Or the other way round: there are daily SQL dumps, but the product images are not copied.
• The dump is truncated. It was generated with a time or size limit and is missing the last tables. The file exists, it is fairly large and nobody has ever opened it.
• The backup is of the already infected shop. If the problem is a hack, the backups from the last few weeks may contain the same back door.
• Only a few days are kept. By the time you discover the problem, the last good backup has already been deleted.
• Nobody has access. The backups are in the control panel of a hosting account whose password belonged to someone who has left, or in a storage account in the previous agency's name.
• Restoring takes hours. A shop with a large catalogue can have tens of gigabytes of images. Downloading and uploading them takes time, and nobody had worked it out.
• The restored shop does not start. Because of different PHP or MySQL versions between the original server and the new one, caches pointing to old paths or a configuration with the wrong domain.

What a PrestaShop backup must include

1. The full database, as a consistent dump (not by copying the MySQL files while the server is running).
2. All the files: core, modules, theme, img/ with the product images, download/ if you sell downloadable products, upload/ with customers' files, and invoices if they are stored on disk.
3. The configuration: the parameters file with the installation keys. Without the original cookie key, customers' old passwords cannot be verified.
4. What lives outside the web folder: scheduled tasks, server configuration, redirect rules, certificates.

How to run a drill without touching production

A drill means restoring a real backup somewhere other than the shop, as if the shop had disappeared. There is no need to stop anything.

1. Pick a backup at random, not last night's. If you only test the latest one, you do not know whether the ones from a week ago are any good.
2. Restore it in a separate environment: a password-protected test subdomain, a local server or temporary hosting.
3. Isolate the copy before opening it. Disable outgoing email, put the payment gateways in test mode, block indexing and remove the scheduled tasks. A restored shop with everything switched on can email your customers or charge them.
4. Time each step: downloading, uploading files, importing the database, adjusting the domain, clearing the cache.
5. Check that it really works: home page, a category, a product page with images, the back office, a test order all the way through, the invoices of an old order, the search.
6. Compare with production: number of products, customers and orders, and the date of the last order in the backup.
7. Write down what failed and fix it in the backup system, not in the backup.

Two figures you need to know

The drill gives you the two answers that matter on the day of the problem:

• How much you can lose: the time between the last backup and the moment of failure. With daily backups, up to a day of orders, customers and catalogue changes. If that is too much, you need more frequent database backups.
• How long it takes you to get back: the real time the drill took, plus the margin for doing it in a hurry and under stress. If it is six hours, the shop will be down for six hours.

With those two figures you can decide, based on data, whether your backup system is enough or whether you need another one.

Restoring after a hack

This is the trickiest case. Going back to the last backup is not enough:

• Find out when the problem started and restore an earlier backup, or restore the most recent one and clean it by comparing it with the original core and modules.
• Recover the orders and customers created after the backup from the current database, taking care not to bring back what the attacker added as well.
• Close the way in before reopening. Otherwise the restored shop will be just as exposed.
• Change all credentials after restoring.

Write it down

The restore procedure has to be written down: where the backups are, which account gives access to them, which steps to follow, who does it and whom to call if that person is not available. The day you need it will not be a calm day, and anything not written down will be forgotten. Repeat the drill every few months and always after changing hosting, PrestaShop version or PHP version: a backup that restored fine on the previous server may not do so on the new one.

How to solve it in PrestaShop

Rekire's Hosting plan profesional is designed to host PrestaShop shops. If you would rather stay with your current hosting, with a Rekire support hours pack we review what backups you have, run the restore drill in an isolated environment (no outgoing email, gateways in test mode and no indexing), measure how long it takes and what gets lost, and leave you a written procedure for the day you need it.