Sauvegardes : ce qui change quand on les prend au sérieux
Règle 3-2-1, RPO/RTO mesurés, tests de restauration réels. Les principes qui transforment une sauvegarde en vraie résilience opérationnelle.
Tout le monde a des sauvegardes. Très peu d'entreprises ont des sauvegardes qui se restaurent. La différence se joue sur quatre principes simples qu'on traite avec rigueur, ou pas.
Pourquoi la sauvegarde reste cruciale en 2026
Dans un monde numérique où les données pilotent toutes les opérations, la sauvegarde reste le filet de sécurité qui distingue une crise gérable d'un incident existentiel. Quatre raisons la rendent non négociable :
- Prévention de la perte de données. Les sauvegardes permettent de restaurer après une défaillance matérielle, une erreur humaine, un logiciel malveillant ou un incident imprévu — sans dépendre du fournisseur d'origine.
- Protection contre les cyberattaques. Face à la multiplication des ransomwares, une sauvegarde à jour et hors ligne est ce qui permet de refuser de payer la rançon. Sans elle, vous êtes en position de négociation faible.
- Continuité des activités. Une bonne sauvegarde minimise les interruptions et permet une reprise rapide. Sans elle, chaque heure d'arrêt coûte un multiple de la prestation de backup que vous n'avez pas voulu signer.
- Conformité réglementaire. RGPD, secteur santé, audit financier : la sauvegarde régulière est une obligation dans nombre de cadres. Le contrôleur ne demande pas si elle existe — il demande la preuve qu'elle est testée.
La règle 3-2-1 (et son extension 3-2-1-1-0)
Le principe minimal : 3 copies de chaque donnée, sur 2 types de supports différents, dont 1 hors site. Décliné concrètement chez nos clients :
- 1 copie en production (la donnée vivante)
- 1 copie sur un Veeam / PBS / Restic local, sur stockage différent
- 1 copie répliquée vers un site tiers ou un objet S3 immuable
La version étendue ajoute 1 copie immuable (object lock S3 ou bande WORM) et 0 erreur détectée lors du dernier test de restauration. Cette version est celle que nous appliquons par défaut.
RPO et RTO : ce que vous mesurez vraiment
Le RPO (Recovery Point Objective) est la quantité maximale de données que vous acceptez de perdre, exprimée en temps. Un RPO de 4h signifie : si l'incident a lieu à 14h, vous redémarrez avec les données de 10h. Choisir un RPO trop ambitieux sans en mesurer le coût (réplication continue) est la première erreur classique.
Le RTO (Recovery Time Objective) est le temps maximal acceptable d'arrêt avant retour à un service nominal. Un RTO de 1h impose une bascule chaude — pas une restauration depuis S3. Là encore, l'engagement contractuel doit être tenable et testé.
Notre démarche : un atelier d'1h pour mettre des chiffres sur ces deux indicateurs application par application. Une boîte mail commerciale n'a pas le même RTO qu'un ERP de production.
Bonnes pratiques d'exécution
- Planification régulière. Quotidienne pour les données critiques, moins fréquente pour les archives historiques dont la fenêtre de variation est nulle.
- Stockage sécurisé. Les copies doivent être chiffrées au repos, idéalement avec une clef gérée par vous, pas par le fournisseur. La copie hors site est obligatoire — pas optionnelle.
- Automatisation. Une procédure manuelle finit toujours par être oubliée. Tout doit s'enchaîner sans intervention humaine, avec alerte immédiate sur échec.
- Tests réguliers de restauration. Une sauvegarde non testée est une supposition. Nous restaurons en environnement isolé chaque trimestre au minimum, et documentons le delta entre le RTO contractuel et le RTO mesuré.
En conclusion
La sauvegarde n'est pas une précaution — c'est un impératif. L'engagement opérationnel n'est pas « avoir des sauvegardes », c'est « pouvoir restaurer en moins de N heures, avec un delta de moins de M minutes, et l'avoir prouvé cette année ». Le reste est de la communication.
Si votre dispositif actuel ne tient pas cette phrase debout, parlons-en — un audit de 2h sur votre stack actuelle suffit en général à dire ce qu'il faut conserver et ce qu'il faut changer.