How to properly back up your store before an intervention
A backup that only contains the database, or that has never been restore-tested, isn't really a backup. Before any update or code change, two elements need to be backed up separately, and the backup needs to be verified before it can be trusted.
Building a complete backup
-
Export the database
Using phpMyAdmin or an export command, every table needs to be included, not just the ones that seem relevant to the intervention. One forgotten table can make the restore inconsistent.
-
Archive all the files
The source code, active theme, installed modules or extensions, and the media folder need to be copied in full, not just the files about to be changed.
-
Store the backup off the server
A backup that stays on the same server as the site offers no protection at all against hardware failure, a hack, or an accidental deletion affecting the whole server.
-
Check consistency between database and files
The database and the files need to come from the same point in time. A recent database paired with older files, or the reverse, can create inconsistencies that are hard to spot afterwards.
-
Test the restore if the intervention is risky
Before a heavy operation (migration, major update), restoring the backup on a separate environment confirms it's actually usable, rather than finding out only when it's needed.
Why the database alone isn't enough
On PrestaShop as on WooCommerce, the database holds the products, orders, customers and configuration, but not the code: the theme, the installed modules or extensions, or the product images stored as files. Restoring only the database onto a fresh install gives you an incomplete site, without its appearance or its custom functionality.
Conversely, files alone are useless without the database that matches them: the code references product, category or configuration IDs that only exist in the database. The two elements need to be treated as a single unit, backed up and restored together.
On a large store, exporting the database can take time and put load on the server: it's better to run it outside peak traffic periods, or to use a tool that locks tables for only as long as strictly necessary for the export.
Common mistakes
- Backing up only the modified files rather than the whole site: if something goes wrong, it becomes impossible to return precisely to the previous state.
- Leaving the backup in a publicly accessible folder on the same server, potentially exposing sensitive data to anyone who knows or guesses the address.
- Never checking the backup until it's actually needed: a corrupted archive or an incomplete SQL export is usually discovered at the worst possible moment.
- Waiting until right before a risky update to back up for the first time, without an already-proven method.
Frequently asked questions
How often should an online store be backed up?
Is an automatic backup from the hosting provider enough?
How long should old backups be kept?
Should server configuration files also be backed up (.htaccess, wp-config.php)?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.