Sauvegarde de site web : fichiers, base de données et test de restauration

Une sauvegarde de site web est une copie récupérable des fichiers, du contenu et de la configuration nécessaires à son fonctionnement. Pour un site auto-hébergé, elle peut inclure une base de données, des images et du code. Sur une plateforme hébergée de création de sites, la récupération dépend des fonctions de sauvegarde et d’export du service.

La question utile est de savoir si vous pouvez restaurer le site voulu, à partir d’une date connue, dans un délai acceptable. Une archive téléchargée ou une notification de sauvegarde réussie ne fournit qu’une partie de cette preuve. Ce guide explique quoi conserver, comment protéger les copies et comment tester une restauration sans écraser le site en ligne.

Commencer par identifier le type de site

Déterminez qui contrôle l’hébergement, la base de données, le domaine et les sauvegardes. Une installation WordPress auto-hébergée, un abonnement WordPress.com et une plateforme comme Webflow ont des procédures de récupération différentes. Les instructions de l’un ne s’appliquent pas nécessairement aux autres.

Pour un site auto-hébergé, demandez à l’hébergeur ou à l’administrateur ce que contient la sauvegarde et comment la restaurer à un emplacement distinct. Pour une plateforme hébergée, vérifiez le périmètre de restauration, les limites des exports, l’abonnement requis et les conditions d’accès au compte. Notre guide de la sauvegarde cloud présente les notions générales de stockage.

Que doit contenir une sauvegarde de site web ?

Faites un inventaire avant de choisir un outil. Incluez les éléments nécessaires à l’affichage des pages et les services qui permettent les actions importantes des visiteurs, comme passer une commande ou envoyer un formulaire.

Les fichiers du site et les médias

Pour WordPress auto-hébergé, conservez les thèmes, extensions, fichiers téléversés, code personnalisé et éléments de configuration nécessaires. Le guide officiel de sauvegarde des fichiers WordPress précise ce que couvrent ces fichiers. Incluez les fichiers de configuration que votre outil de transfert peut masquer et notez les versions logicielles nécessaires pour reconstruire l’environnement.

Si des images ou des documents se trouvent dans un service de stockage distinct, ajoutez-le à l’inventaire. Une copie du répertoire du serveur web ne contient pas les fichiers stockés ailleurs, sauf si le processus les inclut explicitement.

La base de données

Le guide de sauvegarde de la base de données WordPress distingue les articles, pages, commentaires et réglages des thèmes, extensions et fichiers téléversés. Lors d’une récupération, l’export doit généralement être importé dans un système de base de données compatible. Télécharger le répertoire du site ne réalise pas cette opération.

Vérifiez les tables créées par des extensions et les bases utilisées par d’autres applications. Notez quelle base correspond au site, plutôt que de vous fier à un nom qui pourrait être peu clair pour la personne chargée de la restauration.

La configuration et les dépendances externes

Conservez une fiche de reprise pour le DNS, les redirections, les tâches planifiées, les certificats, les paramètres d’exécution et les intégrations externes. Gérez les secrets avec la méthode de gestion des identifiants approuvée dans votre organisation et expliquez comment une personne autorisée peut les récupérer. La fiche doit identifier les responsables des comptes sans devenir une liste de mots de passe en clair.

Prévoyez séparément la récupération des données détenues hors du site : transactions de paiement, listes de diffusion ou soumissions de formulaires stockées ailleurs. Restaurer le site ne ramène pas nécessairement ces services au même état.

Maintenir la cohérence entre fichiers et base de données

Traitez les fichiers et la base comme un ensemble de sauvegarde coordonné, avec un identifiant et une date de capture communs. La documentation WordPress recommande de les conserver ensemble. Des dates correspondantes sont utiles, mais ne prouvent pas à elles seules la cohérence d’un site actif.

Par exemple, la base peut référencer une image récemment téléversée qu’une copie antérieure des fichiers n’a pas capturée. Une boutique peut recevoir des commandes pendant la sauvegarde. Demandez comment l’outil coordonne ces changements et quelles activités doivent être suspendues pendant la capture.

Pour les administrateurs MySQL, un export avec transaction unique fournit un instantané cohérent des tables transactionnelles comme InnoDB, avec des limites documentées pour les autres types de tables et les changements de structure simultanés. Il ne coordonne pas une copie séparée des fichiers téléversés. Choisissez une procédure adaptée à l’application.

Pour un petit site, une plage convenue qui suspend toutes les écritures concernées peut être envisageable. Afficher une page de maintenance ne suffit pas si des tâches de fond, des administrateurs ou des intégrations peuvent encore modifier les données. Un service très actif nécessite une méthode adaptée à son fonctionnement.

Choisir entre sauvegardes manuelles et automatiques

Pour un site auto-hébergé, comparez le service de l’hébergeur, une extension de sauvegarde WordPress et un processus géré par un administrateur. Posez les mêmes questions : que contient la copie, où est-elle stockée, comment les échecs sont-ils signalés et peut-on restaurer sans que le site d’origine fonctionne ?

Une sauvegarde manuelle peut fournir un point de reprise avant une modification. Les sauvegardes automatiques peuvent couvrir le travail courant selon un calendrier défini, mais nécessitent un suivi et une procédure de restauration testée. Vérifiez que le calendrier est configuré : le terme « automatique » n’indique ni la fréquence ni l’historique conservé.

Avant de vous fier à un outil, créez un ensemble de sauvegarde, vérifiez son contenu et réalisez le test ci-dessous. Choisissez selon la couverture de récupération démontrée et l’effort de suivi, plutôt que le nombre de fonctions annoncées.

Choisir une fréquence et une durée de conservation justifiables

Définissez la fréquence selon la quantité de travail récent que le site peut se permettre de perdre. Un portfolio modifié occasionnellement n’a pas les mêmes besoins qu’une boutique recevant des commandes toute la journée. Créez une copie récupérable supplémentaire avant un changement important, tout en maintenant le programme habituel.

Prenons un exemple simple : un point de restauration capturé à minuit ne contient pas une page écrite à 10 heures. Si le site tombe en panne à 18 heures et qu’il s’agit du point utilisable le plus récent, l’intervalle manquant est de 18 heures. Cet exemple suppose que la sauvegarde a réussi ; un échec peut laisser un point de restauration plus ancien.

Définissez combien de temps conserver les versions, qui peut les supprimer et quand revoir cette règle. Gardez un historique suffisant pour examiner les problèmes découverts tardivement, dans le respect des exigences de conservation de l’organisation. Si l’outil utilise des sauvegardes incrémentales, vérifiez quels fichiers de sauvegarde antérieurs sont nécessaires à la restauration avant de supprimer une partie de l’ensemble.

Adressez les alertes d’échec à un responsable et à un suppléant. Vérifiez la dernière capture réussie, les composants inclus, la destination et l’espace disponible. Une automatisation qui applique de mauvaises exclusions peut produire régulièrement des sauvegardes incomplètes.

Protéger la sauvegarde séparément du site

Une sauvegarde conservée uniquement sur le même serveur peut disparaître avec lui. Gardez une copie distincte dont l’accès et la récupération ne dépendent pas entièrement du site en ligne. Notre guide de la stratégie de sauvegarde 3-2-1 explique comment plusieurs copies et emplacements peuvent réduire les risques de perte simultanée.

Les recommandations de la CISA sur les rançongiciels préconisent des sauvegardes hors ligne et chiffrées, ainsi que des tests réguliers de récupération. Une deuxième copie en ligne n’est pas automatiquement isolée d’un attaquant qui accède aux deux emplacements.

Limitez les accès, protégez les comptes d’administration et vérifiez que les personnes autorisées peuvent obtenir les clés de déchiffrement si le compte du site est indisponible. Testez ce parcours d’accès avant un incident.

Ne laissez pas d’exports de base de données ou d’archives dans un répertoire web ou un espace de stockage accessible au public. OWASP explique comment des fichiers de sauvegarde oubliés peuvent exposer du code source, des identifiants et des informations sensibles. Un nom difficile à deviner ne rend pas privée une archive publiquement téléchargeable.

Comprendre les limites des plateformes hébergées

Un point de restauration de la plateforme et un export répondent à des besoins différents. Vérifiez les deux avant de considérer un téléchargement comme une sauvegarde complète du site.

Webflow propose, par exemple, des points de restauration automatiques et manuels. Sa documentation des sauvegardes décrit les effets sur les données et paramètres, notamment les éléments CMS planifiés et les langues. Examinez ces effets avant une restauration, puis vérifiez la file de publication obtenue.

La documentation d’export du code Webflow précise que les contenus CMS et Ecommerce, les contenus localisés et plusieurs fonctions hébergées sont exclus. Le ZIP ne constitue donc pas une copie complète et fonctionnelle d’un site dynamique. Exportez séparément les données de collections nécessaires et documentez ce qui dépend encore de la plateforme.

Pour toute plateforme hébergée, prévoyez la récupération après une modification accidentelle et après une perte d’accès au compte. Ce sont deux situations différentes. Notez qui peut demander de l’aide et quelles données vous détenez indépendamment.

Tester une restauration dans un environnement distinct

Utilisez un environnement de test avec sa propre base de données et ses propres contrôles d’accès. Séparez-le de la production, bloquez l’accès public et désactivez les e-mails sortants, paiements réels, webhooks et intégrations planifiées jusqu’à pouvoir les tester sans effet indésirable. Un site restauré pourrait sinon agir sur de vrais clients ou systèmes externes.

Suivez la procédure de l’hébergeur ou de l’outil de sauvegarde. Si le site de test utilise un autre domaine, les URL enregistrées peuvent nécessiter une adaptation. Le guide officiel de migration WordPress avertit que des remplacements non adaptés dans la base peuvent endommager les données sérialisées. Utilisez une méthode conçue pour WordPress et examinez les changements proposés avant de les appliquer.

Ne vérifiez pas seulement l’accueil. Contrôlez des pages représentatives, les images, les téléchargements, l’accès administrateur, la navigation, la recherche et les formulaires importants. Testez les paiements uniquement dans un mode prévu à cet effet. Mesurez le temps nécessaire pour récupérer la sauvegarde, reconstruire l’environnement et valider le résultat.

Un petit exercice de restauration WordPress

Cet exercice concerne un site WordPress hors production utilisant du contenu de test. Il s’agit d’une procédure à réaliser avec l’outil choisi, pas du compte rendu d’un test effectué.

1. Créez une page contenant le texte « Test de sauvegarde A ». Téléversez une nouvelle image de test et placez-la sur cette page. Notez l’URL de la page et le nom du fichier image.
2. Capturez une sauvegarde coordonnée de la base et des fichiers. Notez son identifiant, la date de capture, son état de réussite et son emplacement.
3. Sur le site de test source, remplacez le texte par « Test de sauvegarde B » et téléversez une deuxième image après la fin de la sauvegarde.
4. Restaurez la sauvegarde enregistrée dans un environnement de test distinct et vide, selon la procédure documentée de l’outil. Effectuez les adaptations nécessaires au domaine de test dans cet environnement.
5. Ouvrez la page restaurée. Elle doit afficher « Test de sauvegarde A » et la première image. Le texte modifié et la deuxième image doivent être absents de l’état restauré.
6. Vérifiez que l’image provient de l’environnement restauré et n’est pas chargée discrètement depuis le site source. Confirmez l’accès administrateur et testez les fonctions importantes.
7. Notez la durée, les composants manquants, les erreurs et les corrections nécessaires. Recommencez après avoir corrigé un problème.

Cet exercice vérifie un petit exemple associant contenu et fichier. Il ne valide pas toutes les extensions, intégrations ou situations de reprise. Étendez-le aux fonctions dont votre site dépend. Notre guide des tests de récupérabilité couvre une validation plus large.

Préparer la décision de restauration en production

Avant une restauration réelle, identifiez le point de reprise et les données plus récentes qu’il remplacerait. Un retour en arrière peut supprimer des commandes, modifications ou soumissions créées après ce point. Décidez comment préserver ou rapprocher ces enregistrements avant de modifier la production.

Si une compromission a provoqué l’incident, restaurer une ancienne copie ne règle pas sa cause à elle seule. Suivez la procédure de réponse à incident pour évaluer la sauvegarde, sécuriser les accès et corriger la faiblesse avant la remise en service.

Gardez une procédure courte indiquant l’emplacement des sauvegardes, les moyens d’accès, les étapes de restauration, les contrôles et la personne autorisée à approuver la remise en service. Mettez-la à jour après un changement d’hébergeur, d’outil de sauvegarde ou d’intégration importante.

Checklist de sauvegarde d’un site web

• Le périmètre inclut les fichiers, la base de données et les données externes nécessaires.
• La méthode de capture maintient la cohérence des composants liés.
• La fréquence et l’historique conservé correspondent aux besoins de reprise.
• Une copie distincte et protégée ainsi que les identifiants de récupération sont disponibles.
• Les échecs sont signalés à une personne capable d’enquêter.
• Une restauration a été testée hors production et son résultat est consigné.
• Le responsable comprend ce qu’un retour en arrière en production pourrait remplacer.

Un plan de sauvegarde utile laisse à la personne qui devra intervenir un point de reprise connu, des copies accessibles et une procédure de restauration dont la fiabilité a été vérifiée.