Stratégie de sauvegarde : quoi sauvegarder et à quelle fréquence
La plupart des sites ont des sauvegardes. Moins en ont qui aient déjà été restaurées. L'écart entre les deux se découvre au pire moment possible, généralement en même temps que la découverte que la sauvegarde n'avait pas la base de données, ou les fichiers téléversés, ou les trois dernières semaines.
Ce guide couvre quoi sauvegarder, à quelle fréquence, où le conserver, et comment vérifier qu'une restauration fonctionne vraiment.
Ce que contient une sauvegarde complète#
Un site n'est pas une seule chose. L'absence de l'un de ces éléments rend une restauration partielle, et une restauration partielle est souvent pire qu'aucune, car elle donne l'impression d'avoir fonctionné.
- Base de données — contenu, utilisateurs, commandes, réglages. La partie qui change constamment.
- Fichiers téléversés — images, documents, tout ce que des utilisateurs ou la rédaction ont ajouté.
- Code applicatif — idéalement en gestion de versions, qui est une forme de sauvegarde avec historique.
- Configuration — variables d'environnement, configuration serveur, tâches planifiées, règles de redirection.
- Certificats et enregistrements DNS — peu coûteux à exporter, pénibles à reconstituer sous pression.
- Réglages tiers — URL de webhook de paiement, configuration e-mail, clés d'API.
La configuration est la partie la plus souvent oubliée. Une base de données et des fichiers restaurés sur un serveur configuré différemment ne constituent pas le même site.
À quelle fréquence, et combien de temps conserver#
La fréquence découle d'une question : combien de travail pouvez-vous vous permettre de perdre ? La rétention découle d'une autre : combien de temps avant que vous remarquiez un problème ?
| Type de site | Base de données | Fichiers | Rétention |
|---|---|---|---|
| Site vitrine statique | Hebdomadaire | Hebdomadaire | 30 jours |
| Site d'entreprise avec blog | Quotidienne | Quotidienne | 30–60 jours |
| Site éditorial très fréquenté | Quotidienne, ou horaire | Quotidienne | 60–90 jours |
| Boutique en ligne | Horaire ou continue | Quotidienne | Plus de 90 jours, plus des archives mensuelles |
| Application web | Continue avec restauration à un instant donné | Quotidienne | Selon votre politique de données |
La rétention compte parce qu'il existe des problèmes à évolution lente. Un import corrompu ou une compromission discrète peuvent passer inaperçus des semaines, et alors une rotation de 7 jours ne contient plus que de mauvaises copies.
Où les stocker#
La règle classique tient toujours : trois copies, sur deux types de supports, dont une hors site. Adaptée aux sites web, cela signifie que la sauvegarde doit survivre à la panne du serveur comme à sa compromission.
- Ne stockez jamais l'unique copie sur le même serveur que le site.
- Utilisez un autre fournisseur pour au moins une copie, afin qu'une défaillance au niveau du fournisseur n'emporte pas les deux.
- Rendez au moins une copie immuable ou en écriture unique, pour que les identifiants qui font tourner le site ne puissent pas la supprimer.
- Chiffrez les sauvegardes au repos : elles contiennent tout, données personnelles comprises.
- Conservez une archive mensuelle hors de la rotation pour les problèmes à découverte lente.
- Documentez où elles sont et comment restaurer, ailleurs que sur le site lui-même.
Tester : l'étape qui rend la chose réelle#
Une sauvegarde que vous n'avez jamais restaurée est une hypothèse. La tester prend une heure et la transforme en fait.
- Restaurez dans un environnement de préproduction distinct, pas par-dessus le site en ligne.
- Vérifiez que la base de données a été restaurée intégralement : comptez les lignes dans les tables qui comptent.
- Vérifiez que les fichiers téléversés sont présents, y compris les récents.
- Connectez-vous et accomplissez une vraie tâche : publier une page, passer une commande de test.
- Chronométrez. « Combien de temps prendrait une restauration ? » est une question dont vous voulez la réponse à l'avance.
- Écrivez la procédure pour qu'elle ne soit pas détenue uniquement par la personne qui l'a mise en place.
- Recommencez chaque mois et après toute modification de l'hébergement.
Chronométrez la restauration. Savoir qu'elle prend quatre heures change ce que vous promettez aux parties prenantes pendant une panne, et c'est le chiffre que personne n'a quand il en a besoin.
Questions fréquentes
La sauvegarde de mon hébergeur suffit-elle ?
C'est une bonne base et une mauvaise stratégie unique. Les sauvegardes d'hébergeur ont typiquement une rétention courte, sont stockées sur la même infrastructure, et sont perdues avec le compte en cas de litige de facturation ou de défaillance du fournisseur. Gardez votre propre copie ailleurs : le coût est faible et c'est la copie dont vous aurez besoin dans le scénario où les sauvegardes de l'hébergeur n'aident pas.
Combien de temps conserver les sauvegardes ?
Assez longtemps pour couvrir un problème à découverte lente. Trente jours est un minimum raisonnable, quatre-vingt-dix est plus sûr pour une boutique, et une archive mensuelle conservée un an ne coûte presque rien. Équilibrez cela avec les obligations de protection des données : les sauvegardes contenant des données personnelles sont aussi soumises à des règles de conservation.
Ai-je besoin de sauvegardes si mon code est en gestion de versions ?
Oui. La gestion de versions couvre le code et son historique, et ne contient ni la base de données, ni les fichiers téléversés, ni la configuration serveur. C'est là que vivent le contenu et les données clients, c'est-à-dire la partie qu'on ne peut pas recréer en relançant un déploiement.
Qu'est-ce que la restauration à un instant donné ?
La capacité de restaurer la base de données à n'importe quel moment, plutôt qu'au dernier instantané planifié, obtenue en archivant en continu le journal des transactions. Cela compte quand perdre ne serait-ce qu'une heure de commandes est inacceptable. Pour un site vitrine c'est inutile ; pour une boutique qui prend des commandes la nuit, cela vaut la configuration supplémentaire.
sauvegarde site webstratégie de sauvegardereprise après sinistrerestaurer un site websauvegarde base de donnéesrécupération site web
