Une sauvegarde n’a de valeur que le jour où elle restaure vraiment
Tout le monde pense avoir des sauvegardes. Très peu d’entreprises savent exactement ce qui est sauvegardé, à quelle fréquence, pendant combien de temps et en combien de temps le site peut revenir en ligne. Le jour où une mise à jour casse tout, où un plugin supprime des données, où un site est compromis ou où une erreur humaine efface un dossier, cette différence devient brutale.
Une vraie stratégie de sauvegarde ne se résume pas à “il y a un backup quelque part”. Elle doit répondre à quatre questions : qu’est-ce qu’on sauvegarde, à quelle fréquence, combien de temps on conserve, et comment on restaure. Sans réponse claire, vous n’avez pas une sauvegarde. Vous avez une hypothèse.
Pourquoi sauvegarder chaque nuit ?
La fréquence dépend du site. Une boutique très active peut nécessiter des sauvegardes plus rapprochées. Pour beaucoup de sites vitrines, blogs, sites PME ou WordPress d’entreprise, une sauvegarde quotidienne nocturne est une base solide. Elle permet de revenir à une version récente sans perturber les heures d’activité.
Le choix de la nuit est pratique : moins de visiteurs, moins de modifications, moins de risque de capturer une base de données en pleine activité. Mais l’essentiel reste la régularité. Une sauvegarde manuelle lancée “quand on y pense” n’est pas une stratégie.
Pourquoi conserver jusqu’à 3 ans ?
Beaucoup d’hébergements gardent quelques jours de sauvegardes. C’est utile pour une erreur immédiate, mais insuffisant pour certains incidents. Un piratage peut être découvert tard. Une suppression de page importante peut passer inaperçue. Une régression SEO peut apparaître après plusieurs semaines. Une ancienne version d’un contenu, d’un média ou d’une configuration peut devenir nécessaire longtemps après.
La conservation longue durée change le rapport au risque. Chez EchoDev, les sauvegardes quotidiennes de l’hébergement géré sont pensées avec une conservation pouvant aller jusqu’à 3 ans selon le cadre défini. Cela permet de ne pas dépendre d’une seule fenêtre de restauration très courte.
Ce qu’il faut sauvegarder exactement
Les fichiers
Les fichiers contiennent le thème, les plugins, les images, les documents, les fichiers applicatifs et parfois des éléments critiques de configuration. Sur WordPress, le dossier wp-content est particulièrement important. Sur un site sur mesure, le code et les fichiers uploadés doivent être couverts.
La base de données
La base contient les pages, les articles, les paramètres, les comptes, les menus, les formulaires, les commandes selon le site. Restaurer seulement les fichiers sans la base ne suffit pas. Restaurer seulement la base sans les fichiers ne suffit pas non plus.
Les configurations
Certains éléments vivent hors du site : configuration serveur, tâches cron, DNS, email, certificats, variables d’environnement. Ils ne sont pas toujours inclus dans les sauvegardes classiques, mais ils doivent être documentés.
Les scénarios où une sauvegarde longue sauve le projet
- Mise à jour ratée : le site casse après une mise à jour de thème ou plugin.
- Faille exploitée : il faut revenir à une version saine avant compromission.
- Erreur humaine : une page, un média ou un formulaire important est supprimé.
- Régression SEO : une ancienne structure de page doit être récupérée.
- Migration ratée : il faut revenir rapidement à l’environnement précédent.
- Conflit technique : une modification ancienne se révèle problématique plusieurs semaines après.
RPO et RTO : deux notions simples à connaître
Le RPO répond à la question : combien de données accepte-t-on de perdre ? Si la sauvegarde est quotidienne, on parle généralement d’une perte maximale autour de 24 heures pour un site peu transactionnel.
Le RTO répond à la question : en combien de temps peut-on revenir en ligne ? C’est ici que l’organisation compte. Avoir une sauvegarde est une chose. Savoir la restaurer proprement en est une autre.
| Situation | Sans sauvegarde fiable | Avec sauvegarde maîtrisée |
|---|---|---|
| Page supprimée | Recréation à la main | Récupération depuis une version antérieure |
| Site piraté | Nettoyage incertain | Retour à une base saine puis correction |
| Mise à jour cassée | Debug en urgence | Rollback puis analyse au calme |
| Hébergeur indisponible | Attente sans contrôle | Migration possible vers autre environnement |
La restauration doit être testée
Une sauvegarde non testée est une promesse. Il faut vérifier que les fichiers sont lisibles, que la base se réimporte, que les chemins sont cohérents et que le site redémarre. C’est particulièrement vrai pour les WordPress avec beaucoup de plugins, les sites multilingues, les boutiques et les sites avec formulaires avancés.
Dans l’hébergement géré EchoDev, l’objectif est de ne pas découvrir la procédure le jour de l’incident. Le serveur, les sauvegardes et le site sont pensés ensemble pour rendre le retour arrière concret.
Conclusion
Les sauvegardes quotidiennes avec longue rétention ne sont pas un luxe. Elles sont l’assurance vie de votre site. Elles transforment une panne ou une erreur en incident maîtrisable. Sans elles, vous dépendez de la chance, de la bonne volonté de l’hébergeur et de la mémoire de la personne qui a créé le site.
Le jour où tout casse, le meilleur argument n’est pas commercial. C’est simple : avez-vous une version saine, récente, restaurable, et quelqu’un qui sait la remettre en ligne ?
La règle 3-2-1 adaptée aux sites web de PME
En sauvegarde, on parle souvent de règle 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. Pour un site web de PME, l’idée peut être adaptée sans devenir excessive. Il faut une copie de production, des sauvegardes régulières stockées séparément et une capacité de restauration qui ne dépend pas uniquement du serveur principal.
Si le serveur et la sauvegarde sont au même endroit logique, le risque reste élevé. Une suppression de compte, une panne majeure ou une compromission peut toucher les deux. L’approche sérieuse consiste donc à penser séparation, rétention et restauration. La conservation sur plusieurs années donne une profondeur historique que les sauvegardes de quelques jours ne peuvent pas offrir.
Restaurer tout le site ou seulement une partie ?
Toutes les restaurations ne se ressemblent pas. Parfois, il faut remettre tout le site en ligne. Parfois, il faut seulement récupérer une page, une image, une configuration ou une ancienne version d’un formulaire. Une bonne organisation permet de ne pas utiliser un marteau pour chaque problème.
- Restauration complète : utile après piratage, crash sévère ou migration ratée.
- Restauration de base : utile pour retrouver des contenus ou paramètres.
- Restauration de fichiers : utile pour récupérer médias, thème ou documents.
- Comparaison d’anciennes versions : utile quand on ne sait pas quand l’erreur est apparue.
Les erreurs qui rendent une sauvegarde inutile
- Ne sauvegarder que les fichiers et oublier la base de données.
- Conserver une seule version qui écrase la précédente.
- Stocker la sauvegarde sur le même compte que le site sans copie séparée.
- Ne jamais tester la restauration.
- Oublier les dossiers d’uploads, factures, PDF ou médias clients.
- Ne pas sauvegarder avant une mise à jour majeure.
- Confondre sauvegarde et export manuel occasionnel.
Le bon réflexe avant chaque intervention sensible
Avant une migration, une mise à jour importante, un changement DNS ou une modification de thème, on doit pouvoir répondre : “si ça casse, quelle est la version de retour arrière ?”. Cette simple question évite beaucoup de décisions hasardeuses. Elle oblige à préparer, tester et documenter.
La sauvegarde n’est donc pas une option technique isolée. C’est un élément de gouvernance du site. Elle protège le temps passé à écrire les pages, les images, le SEO, les formulaires, les réglages et la relation client.