Tout le monde croit avoir des sauvegardes. Presque personne n’en a vérifié une. Le scénario se répète toujours de la même façon : le jour où il faut restaurer, on découvre que la copie de l’hébergeur remonte à trois jours, qu’elle ne contient pas la base de données, ou qu’elle est stockée sur le serveur qui vient précisément d’être compromis. Cet article ne compare pas des extensions : il pose une politique de sauvegarde, et surtout la seule étape qui la valide, le test de restauration. Si votre site est déjà tombé, commencez plutôt par que faire quand le site est déjà tombé.
Ce qu’une sauvegarde doit contenir
Un site n’est pas un dossier de fichiers. C’est un assemblage de quatre briques, et il suffit qu’une seule manque pour que la restauration échoue.
- Les fichiers. Le cœur applicatif, le thème, les extensions et surtout le dossier des envois. C’est la brique la plus volumineuse et la moins critique : le cœur et les extensions se retéléchargent depuis leurs sources officielles, vos photos non.
- La base de données. Tout ce qui fait votre site vivant : pages, articles, produits, commandes, comptes clients, réglages des extensions. Une sauvegarde de fichiers sans base rend un site vide et inutilisable.
- La configuration serveur. Version de PHP, limites de mémoire, tâches planifiées, règles de réécriture, certificats. Rarement sauvegardée, souvent redécouverte dans la douleur.
- Ce qui vit hors du serveur. La zone DNS, les enregistrements de messagerie, les clés d’API des services de paiement. Un export de la zone dans un fichier texte prend deux minutes et évite une soirée de reconstitution.
Pour la base, la commande de référence reste la même depuis vingt ans, avec deux options qui changent tout : --single-transaction évite de verrouiller le site pendant l’export, --quick évite de saturer la mémoire sur les grosses tables.
mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
-u UTILISATEUR -p BASE | gzip > base-$(date +%F).sql.gzSur WordPress, la ligne de commande officielle fait la même chose en tenant compte des préfixes de tables :
wp db export - | gzip > base-$(date +%F).sql.gz
tar -czf fichiers-$(date +%F).tar.gz wp-content/uploads wp-content/themesLa règle 3-2-1, expliquée sans jargon
Trois copies des données, sur deux supports différents, dont une hors du site principal. Cette règle, reprise par Cybermalveillance.gouv.fr, donne trois emplacements très concrets pour un site web : la copie vivante sur le serveur de production, une copie chez l’hébergeur, une copie déportée chez un fournisseur qui n’a rien à voir avec le premier.
La troisième est la seule qui compte vraiment, et c’est celle que l’on saute. Elle est la seule à survivre à trois scénarios que les deux premières ne couvrent pas : un rançongiciel qui chiffre le serveur et les sauvegardes locales au passage, une suspension de compte pour facture impayée ou litige, et la défaillance du prestataire lui-même. Une sauvegarde stockée sur le serveur qu’elle est censée protéger ne compte pas comme une copie : c’est une archive de confort, utile pour rattraper une erreur d’édition, inutile le jour d’un vrai sinistre.
La copie déportée se met en place en une ligne, vers un stockage objet ou un simple serveur distant :
rsync -az --delete /var/sauvegardes/ sauvegarde@stockage-distant:/backups/monsite/Deux précautions qui font la différence, et que reprend le guide d’hygiène informatique de l’ANSSI : le compte utilisé pour déposer les sauvegardes ne doit pas avoir le droit de les effacer, et la clé de chiffrement ne doit jamais dormir à côté des archives qu’elle protège.
À quelle fréquence, et pendant combien de temps
La bonne question n’est pas « à quelle fréquence sauvegarder » mais « combien de données puis-je accepter de perdre ». Un site vitrine modifié trois fois par an peut perdre une journée sans conséquence. Une boutique qui encaisse quarante commandes par jour ne peut pas perdre une heure. Cette tolérance décide de tout le reste.
| Type de site | Perte acceptable | Fréquence | Rétention |
|---|---|---|---|
| Vitrine peu modifiée | Une semaine | Hebdomadaire, plus un instantané avant chaque mise à jour | 30 jours |
| Site avec blog actif | Une journée | Quotidienne | 30 jours, plus une copie mensuelle sur 12 mois |
| Boutique en ligne | Une heure | Base toutes les heures, fichiers une fois par jour | 60 jours, plus 12 copies mensuelles |
| Site avec espace client | Quelques minutes | Journaux binaires en continu, dump quotidien | 90 jours |
La rétention est le paramètre que l’on sous-estime le plus. Une infection découverte au bout de trois semaines rend inutiles des sauvegardes conservées sept jours : toutes contiennent déjà la porte d’entrée. C’est exactement pour cette raison qu’une conservation de trente jours est un plancher, pas un luxe. Prévoyez aussi l’instantané pris avant chaque mise à jour : c’est la sauvegarde la plus utilisée de toutes, et vous en trouverez la logique détaillée dans notre guide pour sécuriser un site WordPress pas à pas.
Le test de restauration, l’étape que personne ne fait
Une sauvegarde non testée est une hypothèse. Le test se fait sur un environnement séparé, jamais sur la production, et suit toujours le même parcours en sept points : la page d’accueil, une page profonde tirée au hasard, un formulaire réellement envoyé, le tunnel de commande jusqu’à la page de paiement, l’affichage des images, la connexion d’un compte, et la cohérence des dates du contenu le plus récent.
Deux vérifications techniques valent d’être ajoutées avant même de restaurer, parce qu’elles prennent dix secondes et évitent des heures de fausse route :
gunzip -t base-2026-08-06.sql.gz && echo "archive intacte"
zcat base-2026-08-06.sql.gz | grep -c "INSERT INTO"Une archive qui passe le test d’intégrité mais ne contient aucune ligne d’insertion est un fichier vide de 40 octets, résultat classique d’un identifiant de base expiré depuis des mois sans que personne ne lise les courriels d’échec.
Quant à la fréquence : un test à chaque changement structurant, et au minimum deux fois par an. La seule métrique qui comptera le jour venu n’est pas la taille de vos archives, c’est la durée entre la décision de restaurer et le retour du service. Chronométrez-la pendant le test. Si elle dépasse deux heures sur un site vitrine, votre procédure est à revoir.
Les cinq fausses sauvegardes
- La sauvegarde de l’hébergeur dont personne n’a lu les conditions. Souvent quotidienne, souvent conservée sept jours, parfois hors périmètre en cas de compromission, et fréquemment facturée à la restauration.
- L’extension qui écrit dans le dossier des envois. Elle place les archives à l’intérieur même du périmètre attaqué, parfois accessibles publiquement à qui devine l’adresse.
- L’export manuel du jour de la mise en ligne. Il fige un site qui n’existe plus. Sa valeur décroît chaque semaine.
- La synchronisation de dossier. Une synchronisation recopie fidèlement une suppression ou un chiffrement malveillant, en général dans les minutes qui suivent. Ce n’est pas une sauvegarde, c’est un miroir.
- L’archive chiffrée dont la clé dort sur le même serveur. Techniquement irréprochable, opérationnellement nulle.
Sauvegarde et migration : le même outil sert deux fois
Une sauvegarde complète et testée n’est pas seulement une assurance contre le sinistre, c’est le filet de toute opération risquée : changement d’hébergeur, montée de version majeure, refonte, reprise par un nouveau prestataire. La règle de bascule est toujours la même et elle tient en une phrase : on ne coupe rien tant qu’on n’a pas vérifié que la copie fonctionne.
Concrètement, l’ancien environnement reste intact et accessible pendant plusieurs semaines après la bascule, en lecture seule si nécessaire. C’est ce qui permet de récupérer un fichier oublié ou de comparer un comportement, sans avoir à restaurer quoi que ce soit. La même exigence vaut pour une refonte de site réussie et pour changer de prestataire sans casser son site : le nouveau site ne remplace l’ancien qu’après validation, jamais avant.
Notre position : la valeur n’est pas la sauvegarde, c’est la restauration
Un prestataire qui vous vend « des sauvegardes quotidiennes » ne vous vend rien tant qu’il n’a pas répondu à cinq questions : où sont-elles stockées, combien de temps sont-elles conservées, qui les teste et à quelle fréquence, en combien de temps le site revient-il, et qui appuie sur le bouton un dimanche matin. Nous répondons à ces cinq questions par écrit avant de signer, parce que ce sont les seules qui comptent.
Pour les sites que nous suivons, la politique est la suivante : sauvegarde quotidienne déportée hors de l’infrastructure de production, instantané systématique avant chaque mise à jour, rétention gérée par l’hébergeur cloud, test de restauration documenté deux fois par an, et une personne joignable qui restaure à votre place. Une intervention ponctuelle passe par un ticket d’assistance à 89 € (TVA non applicable, art. 293 B du CGI), et un pack de cinq tickets à 399 € (TVA non applicable, art. 293 B du CGI) couvre confortablement une année d’incidents pour un site vitrine. Le détail figure sur notre page de suivi technique et sauvegardes gérées.
Une dernière chose, souvent oubliée : un dépôt de code n’est pas une sauvegarde. Il protège admirablement le thème et les développements sur mesure, mais il ne contient ni la base ni les médias. Les deux dispositifs sont complémentaires, comme nous l’expliquons dans l’article consacré à suivre son site dans un dépôt Git.
Les sauvegardes testées font partie de notre maintenance WordPress à Pau.
Questions fréquentes
Mon hébergeur sauvegarde, est-ce suffisant ?
Rarement seul. Vérifiez quatre points dans vos conditions : la fréquence réelle, la durée de conservation, l’emplacement de stockage et la procédure de restauration. Beaucoup d’offres conservent sept jours sur la même infrastructure, ce qui ne protège ni d’une infection ancienne ni d’un incident chez l’hébergeur.
Une sauvegarde ralentit-elle le site ?
Si elle tourne aux heures de trafic, oui : la copie des fichiers et le verrouillage des tables consomment des entrées-sorties. Planifiez-la en creux d’activité et privilégiez un dump transactionnel, qui ne bloque pas les écritures.
Combien de temps faut-il garder les sauvegardes ?
Assez longtemps pour couvrir le délai de découverte d’un problème. Trente jours au minimum pour un site actif, complétés par une copie mensuelle conservée un an. Sept jours ne couvrent aucun scénario réaliste d’infection.
Peut-on sauvegarder un site marchand en continu ?
Oui, en dissociant les rythmes : la base de données plusieurs fois par jour, voire en flux continu via les journaux binaires, et les fichiers une fois par jour. Les commandes sont la donnée irremplaçable, pas les images du thème.
On ne juge pas une sauvegarde à sa présence, mais à la vitesse avec laquelle elle vous remet debout. Faites le test une fois, sur un site réel, chronomètre en main : en une heure vous saurez exactement ce qui manque, et vous ne dormirez plus jamais sur la même hypothèse.
À lire aussi : Maintenance de site web : ce qui arrive quand vous l’ignorez
