Aller au contenu

Sauvegarde — méthodologie

Une sauvegarde n’est pas une copie de fichiers faite une fois — c’est une stratégie répondant à deux questions précises : combien de temps peut-on tolérer avant que le service soit rétabli, et combien de données récentes peut-on se permettre de perdre. Sans ces deux réponses posées à l’avance, aucune sauvegarde ne peut être jugée “suffisante” ou non.

RPO et RTO : les deux métriques qui définissent tout le reste

Section intitulée « RPO et RTO : les deux métriques qui définissent tout le reste »
  • RPO (Recovery Point Objective) : la quantité de données qu’on accepte de perdre, exprimée en temps — un RPO de 1 heure signifie qu’après un incident, on peut perdre jusqu’à 1 heure de données produites depuis la dernière sauvegarde valide.
  • RTO (Recovery Time Objective) : le temps maximal toléré pour restaurer le service après un incident — un RTO de 4 heures signifie que le service doit être de nouveau opérationnel dans les 4 heures suivant la décision de restaurer.

Ces deux valeurs, définies avec les responsables métier (pas seulement techniquement), déterminent directement la fréquence des sauvegardes, la technologie utilisée et son coût. Un RPO de quelques minutes exige une réplication quasi continue, pas un simple job de sauvegarde nocturne.

  • 3 copies des données au total (l’original + 2 sauvegardes).
  • 2 supports différents (ex. disque local + stockage objet cloud) — pour ne pas dépendre d’un seul type de matériel.
  • 1 copie hors site — pour survivre à un sinistre physique (incendie, inondation, vol) touchant le site principal.

L’extension moderne 3-2-1-1-0 ajoute :

  • 1 copie hors ligne ou immuable (air-gapped, ou stockage à écriture unique) — pour survivre à un ransomware qui chiffrerait ou supprimerait délibérément les sauvegardes accessibles en ligne, une tactique désormais systématique dans ces attaques.
  • 0 erreur lors des tests de restauration — voir plus bas.
Type Principe Compromis
Complète (full) Copie intégrale de toutes les données Simple à restaurer (un seul jeu de données), mais lourde en temps et en stockage
Incrémentielle Ne copie que ce qui a changé depuis la dernière sauvegarde (quel que soit son type) Rapide et légère, mais restauration plus lente (rejouer toute la chaîne depuis la dernière full)
Différentielle Ne copie que ce qui a changé depuis la dernière sauvegarde complète Restauration plus rapide qu’incrémentielle (2 jeux de données seulement), mais chaque différentielle grossit jusqu’à la prochaine full

En pratique, la plupart des politiques combinent une complète périodique (hebdomadaire par exemple) avec des incrémentielles quotidiennes entre les deux.

Le point le plus négligé : tester la restauration

Section intitulée « Le point le plus négligé : tester la restauration »

Une sauvegarde qui n’a jamais été restaurée pour test n’est, par définition, pas prouvée fonctionnelle — un job de sauvegarde peut échouer silencieusement (support plein, permissions, corruption) pendant des mois sans que personne ne s’en aperçoive, jusqu’au jour où la restauration est réellement nécessaire. Un test de restauration régulier et documenté (pas seulement “vérifier que le job s’est terminé sans erreur”) est ce qui distingue une stratégie de sauvegarde sérieuse d’un faux sentiment de sécurité.