Une politique de rétention des sauvegardes qui fonctionne pour les sites web
Publié le 14 août 2026
Une politique de rétention des sauvegardes pour les sites web doit vous offrir plusieurs points de restauration récents, quelques options de récupération plus anciennes et au moins une copie en dehors du serveur qui exécute le site. Si une mise à jour d’extension casse le paiement à 10 h 15, vous avez besoin d’une version propre de 10 h 00, pas d’une sauvegarde du mardi dernier et d’un air plein d’espoir.
Le bon calendrier dépend de la fréquence à laquelle vos données changent, du coût des temps d’arrêt et de la rapidité avec laquelle votre équipe peut identifier quand le problème a commencé. Un site d’entreprise statique et une boutique WooCommerce très active ne doivent pas être protégés de la même manière. Le service est peut-être en ligne, mais si les commandes d’hier, les soumissions de formulaires ou les modifications des clients manquent, le calme n’est pas vraiment revenu.
Ce que doit couvrir une politique de rétention des sauvegardes de site web
La rétention n’est pas simplement le nombre de sauvegardes que vous conservez. C’est l’ensemble des règles qui détermine quelles copies de sauvegarde restent disponibles, où elles sont stockées, combien de temps elles y restent et quand elles sont supprimées.
Une politique utile tient compte de trois besoins de récupération distincts. Premièrement, vous avez besoin d’une récupération opérationnelle rapide pour les erreurs récentes : un mauvais déploiement, des fichiers supprimés, une mise à jour échouée ou un changement de configuration accidentel. Deuxièmement, vous avez besoin d’une récupération historique lorsqu’un problème est resté silencieux pendant des semaines, comme un accès administrateur compromis ou du code infecté. Troisièmement, vous pouvez avoir besoin de conserver des enregistrements pour des raisons commerciales, contractuelles ou réglementaires.
Ces objectifs peuvent entrer en conflit. Conserver chaque sauvegarde pour toujours entraîne des coûts de stockage, des tâches de sauvegarde plus lentes et une liste de restauration déroutante. Trop peu conserver économise de l’espace jusqu’au moment précis où la seule sauvegarde dont vous avez besoin a déjà expiré. La réponse sensée est une rétention à plusieurs niveaux, pas une longue rangée de sauvegardes quotidiennes identiques.
Commencez par les objectifs de récupération, pas par un chiffre de stockage
Avant de définir des périodes de rétention, définissez deux cibles pratiques : l’objectif de point de récupération et l’objectif de temps de récupération.
Votre objectif de point de récupération, souvent appelé RPO, indique quelle quantité de données récentes vous pouvez vous permettre de perdre. Une boutique e-commerce qui traite des commandes tout au long de la journée peut avoir besoin de sauvegardes horaires de la base de données ou de sauvegardes tenant compte des transactions. Un site vitrine mis à jour deux fois par mois peut accepter une sauvegarde quotidienne, à condition que les données critiques des formulaires de contact soient gérées ailleurs.
Votre objectif de temps de récupération, ou RTO, indique à quelle vitesse le site doit être restauré. Une sauvegarde récente stockée localement ou dans un stockage de sauvegarde proche peut généralement être restaurée plus vite qu’une archive froide. Mais les copies locales seules ne suffisent pas. Une panne de serveur, un incident de ransomware, une mauvaise opération sur disque ou la compromission d’un compte peuvent affecter ensemble le site et ses sauvegardes locales.
Pour la plupart des sites web d’entreprise, définissez ces objectifs en langage clair. Par exemple : « Nous ne pouvons pas perdre plus d’une heure de commandes, et la vitrine doit être restaurée dans les deux heures. ». C’est bien plus utile que de dire « nous faisons des sauvegardes quotidiennes » pour découvrir plus tard que quotidien signifie une fois toutes les 24 heures.
Vérifiez ce qui change réellement
Les fichiers du site web et les données de la base de données ne changent pas au même rythme. Les fichiers du cœur de WordPress peuvent rester inchangés pendant des mois, tandis que la base de données reçoit toute la journée des commandes, des commentaires, des réservations, des changements d’adhésion et des entrées de formulaire.
Une sauvegarde complète doit inclure les fichiers de l’application, les bases de données, les fichiers de configuration, les médias téléversés, la configuration liée à SSL le cas échéant, les définitions des tâches planifiées et toutes les données d’application personnalisées stockées en dehors de la racine web. Si une sauvegarde de la base de données réussit mais que le répertoire de téléversement est exclu, le site restauré peut fonctionner tandis que les images de produits ou les documents clients disparaissent discrètement.
Pour une application plus importante, documentez aussi les dépendances. Le stockage objet, les services de messagerie, les systèmes de paiement, les bases de données externes et les enregistrements DNS n’appartiennent pas forcément à une sauvegarde de serveur. Ils doivent tout de même figurer dans le plan de récupération.
Un calendrier de rétention pratique pour la plupart des sites web
Un point de départ courant consiste à conserver les sauvegardes fréquentes pendant une courte période et les sauvegardes moins fréquentes plus longtemps. Cela offre des choix de restauration utiles sans faire croître l’utilisation du stockage comme un garage abandonné.
Pour un site typique de petite entreprise, un site géré par une agence ou un site marketing, conservez les sauvegardes quotidiennes pendant 14 à 30 jours, les sauvegardes hebdomadaires pendant 8 à 12 semaines et les sauvegardes mensuelles pendant 6 à 12 mois. Effectuez une sauvegarde supplémentaire avant des changements majeurs tels qu’une mise à niveau du CMS, le lancement d’une refonte, une migration, le remplacement d’une extension ou des travaux de configuration du serveur.
Pour les boutiques, les tableaux de bord SaaS, les sites d’adhésion, les plateformes de réservation et les autres services fortement axés sur la base de données, ajoutez une protection plus fréquente de la base de données. Des sauvegardes horaires de la base de données conservées pendant 24 à 72 heures peuvent être appropriées, suivies de sauvegardes quotidiennes pendant 30 jours, de sauvegardes hebdomadaires pendant 12 semaines et de sauvegardes mensuelles pendant 12 mois. L’intervalle exact dépend du volume de transactions et de la capacité de l’application à sauvegarder de manière fiable les données actives.
Les agences devraient envisager des politiques spécifiques à chaque client plutôt que d’appliquer un seul calendrier à tous les comptes. Le site d’un menu de restaurant n’a pas besoin de la même rétention qu’un portail client qui gère des documents téléversés. Regroupez les sites par risque et impact métier, puis rendez la politique visible dans le contrat client ou le périmètre du service.
Conservez séparément les points de restauration avant changement
Les calendriers automatisés ne remplacent pas les sauvegardes délibérées avant des travaux risqués. Créez un point de restauration étiqueté avant les mises à jour, les migrations, la maintenance de la base de données, les modifications de modèle ou les ajustements au niveau du serveur.
Conservez les sauvegardes avant changement pendant au moins sept à quatorze jours après la fin des travaux. Certains problèmes n’apparaissent qu’après un cycle de facturation, une tâche en arrière-plan ou l’exécution d’une intégration. Une fois le changement confirmé comme stable, la rétention normale peut reprendre le relais.
Suivez le principe 3-2-1, avec des opérations réalistes
Le modèle classique 3-2-1 reste pratique : conservez trois copies des données, sur deux types de stockage différents, avec une copie hors site. Pour l’exploitation d’un site web, cela signifie souvent les données de production, une copie de sauvegarde dans l’environnement d’hébergement et une copie chiffrée dans un stockage hors site indépendant.
Le mot clé est indépendant. Une sauvegarde stockée sur le même serveur virtuel est pratique, mais elle ne protège pas contre une panne au niveau du serveur. Une sauvegarde stockée dans le même compte d’hébergement peut aussi être exposée si un attaquant obtient les identifiants du compte ou si une action de suppression étendue est effectuée.
Les copies hors site doivent être chiffrées en transit et au repos. L’accès devrait utiliser des identifiants séparés lorsque c’est possible, idéalement avec une authentification multifacteur et des permissions limitées. Les permissions de suppression des sauvegardes méritent une attention particulière. Si un ransomware ou un administrateur compromis peut effacer les données de production et chaque point de récupération en une seule session, le calendrier de rétention aura l’air excellent sur le papier et impuissant en pratique.
Chez kodu.cloud, les dispositifs de sauvegarde gérée et de surveillance peuvent réduire le travail de routine, mais la responsabilité des exigences de récupération doit tout de même rester claire. Votre fournisseur peut maintenir le système ; votre entreprise doit décider quelle perte de données et quel temps d’arrêt elle peut accepter.
Rendez la rétention sensible aux incidents de sécurité
Une fenêtre de rétention courte peut être dangereuse lorsque des logiciels malveillants sont découverts tardivement. Un site peut être compromis pendant plusieurs semaines avant que des redirections suspectes, une activité de spam ou des comptes administrateur non autorisés ne deviennent visibles. Si chaque sauvegarde est écrasée au bout de sept jours, vous ne conserverez peut-être que des copies infectées.
C’est pourquoi les points de restauration hebdomadaires et mensuels sont importants. Pour les environnements à plus haut risque, envisagez des copies de sauvegarde immuables ou protégées en écriture pendant une période définie. L’immuabilité ne rend pas une sauvegarde magiquement correcte, mais elle peut empêcher un attaquant de la modifier ou de la supprimer après une compromission.
Conservez des journaux de réussite, d’échec, de suppression et d’activité de restauration des sauvegardes. Les alertes doivent atteindre une personne capable d’agir, pas une boîte de réception devenue un petit musée numérique. La surveillance doit aussi vérifier la capacité de stockage, la durée des sauvegardes et les changements inhabituels de taille des sauvegardes. Une sauvegarde soudainement minuscule peut indiquer une base de données exclue ou une collecte de fichiers échouée ; une sauvegarde soudainement énorme peut indiquer des journaux, des fichiers de cache ou des données indésirables entrant dans l’ensemble de sauvegarde.
Testez les restaurations avant d’en avoir besoin
Une sauvegarde n’est un outil de récupération qu’après avoir été restaurée avec succès. Le statut d’une tâche de sauvegarde confirme que les données ont été copiées. Il ne prouve pas que l’archive est complète, lisible, compatible avec l’environnement actuel ou utilisable sous pression de temps.
Testez une restauration au moins chaque trimestre pour un site web d’entreprise standard, et plus souvent pour les applications critiques pour les revenus. Restaurez dans un environnement de staging ou un emplacement isolé où cela ne peut pas écraser la production. Vérifiez que l’application démarre, que la base de données se connecte, que les fichiers multimédias se chargent, que les formulaires fonctionnent, que les tâches planifiées sont présentes et que les actions critiques des utilisateurs se comportent normalement.
Consignez la durée de la restauration et toutes les étapes manuelles requises. Si la récupération dépend d’un développeur se souvenant d’un mot de passe de base de données, d’une séquence DNS et d’une commande shell vieille de cinq ans, ce n’est pas un plan. C’est un artefact folklorique.
Documentez les exceptions et révisez la politique
Votre politique de rétention devrait tenir sur une page et répondre à quelques questions directes : qu’est-ce qui est sauvegardé, à quelle fréquence, où les copies sont stockées, combien de temps chaque copie est conservée, qui peut demander une restauration et comment les tests de restauration sont documentés. Indiquez également les systèmes qui ne sont pas inclus, afin que personne ne suppose qu’une sauvegarde couvre un service tiers auquel elle ne peut pas accéder.
Révisez la politique après un changement majeur du site, une nouvelle exigence de conformité, une croissance du trafic ou un incident de récupération. Des sauvegardes plus fréquentes peuvent devenir nécessaires à mesure qu’une boutique en ligne se développe. À l’inverse, stocker des sauvegardes quotidiennes sur plusieurs années pour un site qui change peu peut représenter un coût sans protection utile.
Définissez la politique de rétention autour du moment où vous en aurez le plus besoin : un déploiement précipité un vendredi, une mise à jour d’extension malveillante ou un problème de disque à la mauvaise heure. Des points de restauration clairs, une copie indépendante et un processus testé donnent à votre équipe quelque chose de mieux que la confiance. Ils vous donnent une prochaine étape praticable.
Andres Saar Ingénieur Customer Care