# 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.

- Source canonique : [https://allaux.fr/en/guides/sauvegarder-boutique-avant-intervention](https://allaux.fr/en/guides/sauvegarder-boutique-avant-intervention)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Back up the database (a complete SQL export) and all the site's files (code, theme, media) separately, store both away from the original server, and check that they're usable before starting the intervention.

## Building a complete backup

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## FAQ

### How often should an online store be backed up?

At minimum before every technical intervention, and ideally on a regular automated schedule: daily for the database on an active store, less often for files that rarely change.

### Is an automatic backup from the hosting provider enough?

It's a good safety net, but it's worth checking exactly what it covers (files, database, or both) and how long it keeps versions, before relying on it entirely for a specific intervention.

### How long should old backups be kept?

It depends on the storage available, but keeping several restore points spread out over time, not just the latest backup, makes it possible to roll back even if a problem is only detected days after it occurred.

### Should server configuration files also be backed up (.htaccess, wp-config.php)?

Yes, these files are an integral part of the site and contain settings that can be hard to reconstruct from memory, such as custom URL rewrite rules or specific configuration constants.