Sauvegarde de site web : les quatre couches à copier, la règle 3-2-1 de l'ANSSI, la bonne fréquence et le test de restauration qui valide le dispositif.
Une sauvegarde de site web copie quatre choses : la base de données, les fichiers, la configuration serveur et la zone DNS. Elle vit ailleurs que sur la machine de production, avec au moins une copie déconnectée du réseau. Et elle ne vaut rien tant qu’une restauration complète n’a pas été chronométrée en conditions réelles.
Les quatre couches qu’une archive doit couvrir
Un site ne tient pas dans un fichier unique. Le remettre en ligne suppose de retrouver quatre couches distinctes, et l’oubli d’une seule transforme la reprise en reconstruction.
La première, c’est la base de données. Sur un CMS, elle porte les articles, les pages, les comptes utilisateurs, les commandes et les réglages. Un site sous WordPress dont le dump SQL manque perd la totalité de son contenu, même avec les fichiers intacts.
Viennent ensuite les fichiers applicatifs et les médias : code du thème, extensions, images téléversées, documents joints. Le dossier des médias grossit sans bruit et pèse souvent plus lourd que tout le reste réuni.
La troisième couche est la configuration : règles de réécriture d’URL, variables d’environnement, tâches planifiées, certificats. Elle échappe à la majorité des sauvegardes artisanales parce qu’elle vit hors du répertoire du site.
La quatrième est la plus négligée : la zone DNS et les accès au registrar du nom de domaine. Le jour où l’infrastructure tombe, savoir vers quelle adresse repointer le domaine compte autant que l’archive. Consignez ces enregistrements dans un document tenu à jour, stocké ailleurs que chez l’hébergeur.
Un site statique généré par Hugo ou Astro allège l’équation sans la supprimer. Le dépôt Git porte le contenu et les gabarits, mais rarement les médias optimisés ni la configuration de déploiement. Ce paramètre pèse dans le choix du CMS, entre moteurs dynamiques adossés à une base et générateurs de fichiers plats.
La règle 3-2-1, traduite pour un site web
L’ANSSI a publié en octobre 2023 son guide « Sauvegarde des systèmes d’information, les fondamentaux », révisé en novembre 2025. Le principe qu’elle met en avant tient en trois chiffres : trois copies des données, sur deux supports de nature différente, dont une conservée hors site. La CNIL, dans l’édition 2024 de son guide de la sécurité des données personnelles, ajoute une exigence complémentaire : isoler au moins une sauvegarde hors ligne, déconnectée du réseau de l’organisation.
Sur un site web, cette doctrine se traduit sans effort :
- la copie de production, celle qui tourne chez l’hébergeur, sert de référence courante ;
- une copie automatique quotidienne part vers un stockage distant, chez un fournisseur différent du premier ;
- une copie mensuelle atterrit sur un disque externe, débranché entre deux écritures.
Deux copies chez le même hébergeur ne comptent pas pour deux. Un incident d’infrastructure les emporte ensemble, et l’illusion de sécurité coûte plus cher que l’absence de sauvegarde, parce qu’elle dispense de vérifier.
Le chiffrement clôt le dispositif. Une archive de site contient des adresses e-mail, des mots de passe hachés, parfois des données de commande. Elle mérite le même niveau de protection que le serveur d’origine, ce que rappelle explicitement la CNIL dans sa fiche consacrée aux sauvegardes.
Ce que la sauvegarde de l’hébergeur ne couvre pas
Presque tous les hébergeurs annoncent une sauvegarde incluse. Trois angles morts reviennent, et tous se découvrent au pire moment.
Le premier tient à la rétention réelle. Beaucoup d’offres mutualisées conservent les copies sur une fenêtre courte, de quelques jours à deux semaines. Une corruption silencieuse découverte au bout d’un mois, typiquement une extension qui a détruit des contenus sans alerte, se retrouve hors de portée : toutes les copies disponibles contiennent déjà le dégât.
Le deuxième tient à la localisation. Une copie stockée dans le même centre de données que le serveur partage son destin. Dans la nuit du 10 mars 2021, l’incendie du site strasbourgeois d’OVHcloud a détruit intégralement le centre SBG2 et endommagé une partie de SBG1. Les chiffres publiés à l’époque évoquaient environ 3,6 millions de sites web hors service et 464 000 noms de domaine touchés. Les clients qui disposaient d’une copie externe ont redéployé ailleurs en quelques heures. Les autres ont perdu leurs données définitivement.
Le troisième porte sur le périmètre. Un snapshot de machine virtuelle fige un état système, pas un jeu de données exploitable ailleurs. Restaurer un snapshot chez un autre fournisseur relève souvent de l’impossible, faute de format portable. Une archive utile se compose d’un dump SQL lisible et d’une arborescence de fichiers standard, deux formats que n’importe quel serveur sait ingérer.
La sauvegarde de l’hébergeur garde toute son utilité comme filet de première intention, pour rattraper une fausse manipulation la veille. Elle ne constitue jamais le dispositif principal.
Fixer la fréquence sur la perte acceptable
La question « à quelle fréquence sauvegarder » n’a pas de réponse universelle. Elle se déduit d’un seul paramètre, le RPO, autrement dit le volume de travail que vous acceptez de refaire après un incident. Une sauvegarde quotidienne signifie qu’au pire, vous perdez vingt-quatre heures de contenu et de commandes.
| Type de site | Rythme de modification | Fréquence adaptée |
|---|---|---|
| Vitrine institutionnelle | Quelques changements par an | Hebdomadaire |
| Blog éditorial | Une à trois publications par semaine | Quotidienne |
| Site à comptes utilisateurs | Inscriptions continues | Quotidienne, base incluse |
| Boutique en ligne | Commandes toute la journée | Base plusieurs fois par jour |
Deux moments imposent une copie manuelle en plus du rythme automatique : avant toute mise à jour majeure du CMS ou d’une extension, et avant une intervention sur le serveur. Ces deux opérations concentrent l’essentiel des sinistres évitables.
La rotation compte autant que la fréquence. Un schéma éprouvé conserve sept copies quotidiennes, quatre hebdomadaires et douze mensuelles. Il couvre à la fois l’erreur de la veille et la corruption découverte six mois plus tard, sans faire exploser le volume stocké.
Automatiser la copie, sans dépendre d’un humain
Une sauvegarde manuelle finit toujours par sauter. Vacances, urgence, oubli : la régularité ne survit pas à la charge quotidienne. L’automatisation reste la seule mécanique qui tienne dans la durée.
Sur un serveur classique, une tâche planifiée suffit. Elle enchaîne trois opérations : un export de la base via mysqldump, une archive compressée du répertoire du site, puis un transfert chiffré vers le stockage distant. Le script complet tient en une vingtaine de lignes et tourne pendant la nuit, quand le trafic est au plus bas.
Sur un site statique, le dépôt Git joue déjà le rôle d’historique du contenu, avec en prime la traçabilité de chaque modification. Complétez-le par une copie des médias et du fichier de configuration de déploiement, les deux éléments qui échappent souvent au versionnement.
Trois garde-fous transforment un script fragile en dispositif fiable :
- une notification en cas d’échec, car un script muet qui ne tourne plus reste invisible pendant des mois ;
- un contrôle de taille du fichier produit, une archive anormalement légère signalant un export tronqué ;
- une vérification d’intégrité de l’archive, avant même de parler de restauration.
Les stockages objet modernes proposent des sauvegardes immuables, verrouillées en écriture pendant une durée définie. Personne ne les supprime avant l’échéance, pas même un compte administrateur compromis. Cette option constitue aujourd’hui la meilleure défense contre un attaquant qui cherche d’abord à détruire les copies avant de chiffrer le serveur.
Tester la restauration, le seul contrôle qui compte
Une sauvegarde jamais restaurée n’est qu’un fichier avec une bonne réputation. L’article 32 du RGPD ne dit pas autre chose : il impose la capacité à rétablir la disponibilité des données dans des délais appropriés en cas d’incident, et une procédure de test régulier des mesures de sécurité mises en place. La CNIL décline cette obligation en pratique en demandant de tester régulièrement l’intégrité des sauvegardes et la capacité effective à les restaurer.
Le test se déroule en cinq temps, une à deux fois par an :
- Provisionner un environnement vierge, distinct de la production, sur un sous-domaine protégé.
- Importer l’archive de fichiers, puis le dump de base, comme si le serveur d’origine avait disparu.
- Reconstituer la configuration à partir de la documentation, jamais de mémoire.
- Parcourir le site restauré : page d’accueil, formulaire, tunnel de commande, accès administrateur.
- Chronométrer l’ensemble, du déclenchement à la validation finale.
Ce chronomètre donne le RTO, la durée réelle de remise en ligne. La plupart des équipes découvrent lors du premier essai un écart considérable entre l’estimation et le résultat. Le fichier de configuration du serveur web manquait, le mot de passe de la base n’était noté nulle part, l’extension de paiement exigeait une réactivation de licence.
Consignez le déroulé dans un journal de restauration daté, avec les blocages rencontrés et leur correction. Ce document vaut mieux qu’une procédure théorique le jour où la panne survient sous pression. Une restauration testée transforme un incident majeur en interruption gérable, avec un impact limité sur les positions acquises grâce au SEO technique.
Rançongiciel : pourquoi la copie déconnectée change tout
Le rançongiciel a fait de la sauvegarde sa cible prioritaire. Un attaquant qui prend la main sur un serveur commence par chercher les copies accessibles depuis ce serveur, les efface, puis chiffre les données restantes. Une sauvegarde montée en permanence sur un partage réseau disparaît dans le même mouvement que la production.
Le rapport d’activité 2025 de Cybermalveillance.gouv.fr, publié en mars 2026, recense plus de 504 000 demandes d’assistance sur l’année, en hausse de 20 % par rapport à 2024. Le rançongiciel y compte environ 2 700 demandes, dont 1 691 émanant d’entreprises, soit une progression de 10 % après une accalmie en 2024.
La copie hors ligne casse cette mécanique. Un disque débranché, une bande stockée dans un autre bâtiment ou une archive immuable chez un fournisseur tiers restent hors d’atteinte du poste compromis. La restauration devient alors une opération technique de quelques heures plutôt qu’une négociation. Ce raisonnement rejoint les fondamentaux exposés dans notre guide de cybersécurité pour les PME, où la sauvegarde figure parmi les premières mesures à mettre en place.
Les erreurs qui vident une sauvegarde de sa valeur
Cinq pièges reviennent sur le terrain, tous silencieux jusqu’au jour de l’incident.
Le script qui ne tourne plus arrive en tête. Une mise à jour du serveur, un mot de passe changé, un espace disque saturé : la tâche échoue en silence et personne ne s’en aperçoit avant la panne. La notification d’échec règle ce problème en dix minutes de configuration.
Vient la sauvegarde partielle, limitée aux fichiers ou à la base. Les deux moitiés d’un site n’ont aucune valeur séparément, et une archive de médias sans son dump SQL ne remet rien en ligne.
Le troisième piège concerne la cohérence temporelle. Un export de base réalisé à 3 heures et une copie de fichiers lancée à 5 heures créent un décalage : les articles publiés entre les deux pointent vers des images absentes de la base, ou l’inverse.
Le quatrième touche les identifiants. Clés d’API, licences d’extensions, accès SMTP, certificats : ces éléments vivent souvent hors du site et bloquent la remise en service. Un gestionnaire de mots de passe partagé, sauvegardé lui aussi, lève l’obstacle.
Le dernier concerne l’après-restauration. Un site remis en ligne se vérifie : redirections en place, sitemap régénéré, temps de réponse conforme à ce que mesurent les Core Web Vitals. Une restauration réussie techniquement mais qui casse cinquante URL laisse une trace durable dans les résultats de recherche.
FAQ
Que doit contenir la sauvegarde d’un site web ?
Quatre couches, pas une seule. La base de données, qui porte les contenus, les comptes et les réglages. Les fichiers applicatifs et les médias téléversés. La configuration serveur, avec les règles de réécriture, les tâches planifiées et les variables d’environnement. Enfin la zone DNS et les accès au registrar, indispensables pour repointer le domaine si l’hébergeur devient inaccessible. Une archive qui oublie une couche allonge la reprise de plusieurs jours.
À quelle fréquence sauvegarder un site internet ?
La fréquence découle de la perte de données acceptable, pas d’une habitude. Un site vitrine modifié une fois par mois se contente d’une copie hebdomadaire. Un blog qui publie chaque semaine demande une copie quotidienne. Une boutique en ligne, où chaque commande perdue devient un litige client, exige une sauvegarde de la base plusieurs fois par jour. Ajoutez toujours une copie manuelle avant chaque mise à jour majeure du CMS.
Les sauvegardes de l’hébergeur suffisent-elles ?
Rarement. Beaucoup d’offres mutualisées gardent une copie sur une durée courte, souvent quelques jours, et la stockent dans la même infrastructure que le site. L’incendie du centre de données OVHcloud de Strasbourg en mars 2021 a montré les limites du modèle : les clients dépourvus de copie externe ont perdu leurs données. La sauvegarde de l’hébergeur reste un filet de secours pratique, jamais le dispositif principal.
Prochaine étape
Ouvrez le tableau de bord de votre hébergeur et notez deux informations : la durée de rétention des copies et leur localisation. Si la rétention descend sous trente jours ou si le stockage partage l’infrastructure du site, mettez en place une copie quotidienne chez un fournisseur tiers cette semaine. Puis bloquez une demi-journée dans le trimestre pour la restaurer sur un sous-domaine de test et chronométrer l’opération.
