Sauvegardes de base de données : la règle que presque personne ne respecte

Presque tous les sites ont un système de sauvegarde. Beaucoup moins savent avec certitude que leurs sauvegardes fonctionnent réellement, c’est-à-dire qu’elles peuvent être restaurées sans erreur le jour où c’est nécessaire. Cet article explique la règle qui fait la différence, puis comment la mettre en place concrètement pour une base MySQL ou MariaDB.

Une sauvegarde jamais testée n’est pas une garantie

Une sauvegarde peut être incomplète, corrompue, ou simplement incompatible avec la version du serveur au moment de la restaurer, sans que personne ne le remarque tant qu’elle n’a jamais servi. La seule façon de savoir qu’une sauvegarde fonctionne est de l’avoir déjà restaurée, sur un environnement de test, au moins une fois. C’est la règle que presque personne ne respecte.

Que faut-il sauvegarder ?

Un site, ce sont deux choses qui doivent rester cohérentes entre elles :

• la base de données : contenus, commandes, clients, réglages ;
• les fichiers : images et documents envoyés (par exemple wp-content/uploads sous WordPress, img/ sous PrestaShop), fichiers de configuration, thème et modules personnalisés.

Restaurer une base sans les images correspondantes, ou l’inverse, donne un site cassé. Les deux doivent être sauvegardés au même rythme.

Combien de données pouvez-vous vous permettre de perdre ?

La fréquence ne se choisit pas au hasard : elle dépend de ce que vous accepteriez de perdre. Pour un site vitrine qui change une fois par mois, une sauvegarde par jour est largement suffisante. Pour une boutique qui reçoit des commandes toute la journée, perdre une journée de données veut dire perdre des commandes : il faut sauvegarder plus souvent, ou s’appuyer sur la réplication proposée par l’hébergeur.

Il faut aussi décider combien de versions garder. Une erreur ou un piratage n’est pas toujours détecté le jour même : avec seulement la sauvegarde de la veille, on risque de restaurer un site déjà abîmé. Un rythme courant : 7 sauvegardes quotidiennes, 4 hebdomadaires et quelques mensuelles.

La règle 3-2-1

Le repère le plus connu : trois copies des données, sur deux supports différents, dont une conservée hors du site. En pratique, pour un site web : la base en production, une sauvegarde sur le serveur pour les restaurations rapides, et une copie envoyée automatiquement ailleurs (stockage chez un autre fournisseur), pour survivre à une panne serveur ou à un piratage.

Sauvegarder une base MySQL proprement

Avec mysqldump, l’option --single-transaction permet d’obtenir une copie cohérente des tables InnoDB sans bloquer le site pendant la sauvegarde :

mysqldump --single-transaction --routines --triggers \
  -u utilisateur -p nom_de_la_base | gzip > sauvegarde-$(date +%F).sql.gz

Les options --routines et --triggers incluent les procédures stockées et les déclencheurs, souvent oubliés. Le mot de passe ne doit pas être écrit en clair dans le script : un fichier d’options MySQL protégé est préférable.

Tester la restauration

Le test n’a pas besoin d’être compliqué. Une fois par mois, par exemple :

1. créer une base de test vide ;
2. y importer la dernière sauvegarde ;
3. comparer quelques chiffres avec la production : nombre de commandes, de produits, d’articles ;
4. idéalement, brancher une copie du site sur cette base et l’ouvrir dans un navigateur.

gunzip < sauvegarde-2026-11-01.sql.gz | mysql -u utilisateur -p base_de_test

Si l’import échoue, ou si les chiffres ne correspondent pas, vous l’aurez découvert un jour calme, et pas le jour d’une panne.

Automatiser et surveiller

Une sauvegarde manuelle finit toujours par être oubliée. Elle doit être planifiée (tâche cron ou outil de l’hébergeur), et surveillée : une alerte quand elle échoue, et un coup d’œil régulier à la taille des fichiers. Une sauvegarde soudain beaucoup plus petite que la veille est le signe d’un problème, repérable en quelques secondes.

Les erreurs les plus fréquentes

• Sauvegarder uniquement les fichiers du site, en oubliant la base de données (ou l’inverse).
• Garder toutes les sauvegardes au même endroit que le site : en cas de panne serveur ou de piratage, elles disparaissent avec le reste.
• Ne garder que la dernière sauvegarde, qui contient peut-être déjà le problème.
• Laisser les sauvegardes accessibles depuis le web, dans un dossier public du site.
• Ne jamais vérifier la taille des fichiers de sauvegarde.
• Ne jamais avoir essayé de restaurer.

La check-list

1. Base de données et fichiers sauvegardés au même rythme.
2. Fréquence adaptée à ce que vous pouvez vous permettre de perdre.
3. Plusieurs versions conservées (quotidiennes, hebdomadaires, mensuelles).
4. Une copie hors du serveur, chez un autre fournisseur.
5. Sauvegardes planifiées, alerte en cas d’échec, taille surveillée.
6. Un test de restauration régulier, noté avec sa date.

Ce que cela change en pratique

Le jour où un problème survient — erreur humaine, mise à jour ratée, incident serveur — la différence entre une interruption de quelques minutes et une perte de données définitive tient presque toujours à une seule chose : est-ce que la sauvegarde a déjà été testée, ou est-ce la première fois qu’on essaie de s’en servir.

Pour aller plus loin : mon expertise : Développeur SQL / MySQL freelance · à lire aussi : Pourquoi votre site devient lent quand la base de données grossit