Chapitre 15.1 — Stratégie de sauvegarde

⏱️ TL;DR — Avant de choisir un outil, choisis une stratégie. Elle tient en quelques décisions : la règle 3-2-1 (au moins 3 copies, sur 2 supports différents, dont 1 hors-site) ; quoi sauvegarder (la base de données, les fichiers uploadés, les configs /etc, les secrets — pas le code, il est dans git) ; deux chiffres qui pilotent tout, le RPO (combien de données tu acceptes de perdre) et le RTO (en combien de temps tu dois remonter) ; enfin la fréquence et la rétention (quotidien, hebdo, mensuel — le schéma « grand-père-père-fils »). Et une distinction à ne jamais confondre : sauvegarde ≠ snapshot ≠ réplication. Ce chapitre pose le plan ; les chapitres suivants l’outillent.

🎯 Objectifs

• Comprendre pourquoi on sauvegarde (les vrais scénarios de perte, pas la théorie).
• Appliquer la règle 3-2-1 et savoir pourquoi chacun de ses trois chiffres compte.
• Décider quoi sauvegarder — et ce qui n’a pas besoin de l’être.
• Fixer un RPO et un RTO réalistes pour ton projet.
• Choisir une fréquence et une rétention (schéma grand-père-père-fils).
• Distinguer sauvegarde, snapshot et réplication — trois choses différentes.

Pourquoi on sauvegarde (les scénarios réels)

On ne sauvegarde pas « au cas où » de façon abstraite. On se protège contre des événements précis, tous vécus par quelqu’un un mauvais jour :

• Panne de disque. Le SSD de ton VPS meurt. Ça arrive — le matériel a un taux de panne non nul. Sans copie ailleurs, les données sont définitivement perdues.
• Erreur humaine. Un rm -rf lancé dans le mauvais répertoire, une clause WHERE oubliée dans un DELETE, un dossier écrasé par un déploiement raté. La première cause de perte de données, c’est nous.
• Ransomware. Un attaquant chiffre tes fichiers et réclame une rançon. Ta seule vraie défense : restaurer depuis une sauvegarde hors de portée de l’attaquant.
• Corruption. Un crash en pleine écriture, un bug applicatif, une migration foireuse laissent la base dans un état incohérent — silencieusement, parfois pendant des jours.
• Suppression accidentelle. Un utilisateur (ou toi) supprime un compte, un projet, un enregistrement. Il faut pouvoir revenir en arrière à une date précise.

⚠️ Piège — Croire que « c’est hébergé chez un gros fournisseur, donc c’est sauvegardé ». Faux par défaut. Le fournisseur garantit son infrastructure, pas tes données : si tu tapes rm -rf, il exécute la commande sans broncher. Les sauvegardes de ton contenu sont ta responsabilité, sauf option explicite que tu as activée et vérifiée.

La règle 3-2-1

C’est la règle d’or, mémorisable et universelle. Une sauvegarde correcte respecte 3-2-1 :

• 3 copies des données : l’original en production plus deux sauvegardes. Une seule copie de secours, c’est déjà mieux que rien, mais si elle échoue au moment critique, tu n’as plus de filet.
• 2 supports différents : ne mets pas tes deux sauvegardes au même endroit physique ni sur la même techno. Disque local et stockage objet distant, par exemple. Un incident qui touche un support ne doit pas emporter l’autre.
• 1 hors-site : au moins une copie loin du serveur d’origine — autre datacenter, autre région, autre fournisseur. C’est ce qui te sauve d’un incendie de datacenter, d’une panne régionale, ou d’un compte fournisseur compromis.

        Règle 3-2-1
  ┌──────────────────────────┐
  │  3 copies des données    │  original + 2 sauvegardes
  │  2 supports différents   │  ex. disque local + objet distant
  │  1 hors-site             │  autre datacenter / région
  └──────────────────────────┘

⚠️ Piège — La sauvegarde sur le même disque (ou même datacenter) que la prod. Un dump quotidien posé dans /var/backups sur le même serveur ne te protège pas de la panne disque ni du ransomware : quand le disque meurt, la sauvegarde meurt avec. C’est le « 1 hors-site » qui fait la différence — le reste n’est qu’un confort.

💡 Réflexe — Relis ta config de sauvegarde à travers la grille 3-2-1 et compte à voix haute : « combien de copies ? sur combien de supports ? combien hors-site ? ». Si l’une des trois réponses est zéro ou un doute, tu n’as pas encore de vraie sauvegarde — juste une illusion de sécurité.

Quoi sauvegarder (et quoi ignorer)

Tout sauvegarder « pour être sûr » gaspille de l’espace et ralentit la restauration. On cible ce qui est irremplaçable :

Et ce qu’on ne sauvegarde pas (ou peu) :

• Le code applicatif : il est déjà versionné dans git. Un git clone le restaure. Sauvegarder le code, c’est dupliquer ce que git fait déjà mieux.
• Les dépendances (node_modules, vendor) : régénérables par npm ci / composer install. Inutile et volumineux.
• Le système d’exploitation et les paquets : réinstallables via ton runbook (15.3) ou un provisioning scripté.
• Caches, fichiers temporaires, logs : régénérables ou peu utiles à restaurer.

🔒 Sécurité — Les secrets (.env, clés privées, mots de passe de base) doivent être sauvegardés chiffrés et séparément du reste, avec un accès restreint. Une sauvegarde qui traîne un .env en clair sur un stockage objet mal configuré, c’est ta base de données grande ouverte. On chiffre systématiquement les sauvegardes au chapitre 15.2.

💡 Réflexe — Pose-toi la question de tri : « si je perds ça, est-ce que git ou une réinstallation me le rend ? ». Oui → pas besoin de sauvegarde. Non (données utilisateurs, uploads, secrets) → sauvegarde obligatoire. Ce tri divise souvent la taille des sauvegardes par dix et accélère d’autant la restauration.

RPO et RTO : les deux chiffres qui pilotent tout

Deux objectifs chiffrés définissent le niveau de ta sauvegarde. Les fixer avant de choisir la fréquence évite le sur- comme le sous-dimensionnement.

• RPO — Recovery Point Objective : combien de données tu acceptes de perdre, exprimé en temps. Un RPO de 24 h veut dire « au pire, je reperds une journée de données ». C’est ta fréquence de sauvegarde qui le détermine : sauvegarder une fois par jour → RPO de 24 h ; toutes les heures → RPO d’1 h.
• RTO — Recovery Time Objective : en combien de temps tu dois être de nouveau en ligne après un sinistre. Un RTO de 2 h veut dire « le service doit revenir en moins de deux heures ». C’est ta procédure de restauration (et son entraînement) qui le détermine.

   Dernière        SINISTRE        Service
   sauvegarde         │            rétabli
      │               │               │
      ▼               ▼               ▼
      ├───────────────┼───────────────┤
        ◄── RPO ──►     ◄── RTO ──►
     données perdues   temps d'indispo

Un RPO/RTO serré (minutes) coûte cher : sauvegardes fréquentes, restauration quasi automatisée, souvent de la réplication. Un RPO/RTO large (heures/jours) est bon marché mais assume plus de perte et d’indisponibilité. La plupart des projets vivent très bien avec un RPO de 24 h et un RTO de quelques heures — inutile de viser la seconde si tes utilisateurs ne le réclament pas.

💡 Réflexe — Traduis toujours une intuition en chiffres : « je ne veux pas perdre plus d’une journée de données » = RPO 24 h ; « je dois pouvoir remonter dans la matinée » = **RTO 4 h ». Ces deux nombres, écrits noir sur blanc, transforment un vague « il faut sauvegarder » en décisions concrètes de fréquence et de procédure.

Fréquence et rétention

Sauvegarder une fois ne suffit pas : il faut un rythme et une durée de conservation. Le schéma classique est grand-père-père-fils (grandfather-father-son), qui garde beaucoup de points récents et de moins en moins en remontant dans le temps :

L’idée : tu n’as pas besoin de garder chaque sauvegarde quotidienne pendant un an. Tu gardes les 7 dernières journalières, les 4 dernières hebdomadaires, les 12 dernières mensuelles — une granularité fine récemment, grossière en remontant. Les outils modernes (restic, borg) automatisent cette politique de rétention avec une seule commande de nettoyage (voir 15.2).

🔒 Sécurité — La rétention n’est pas qu’une affaire technique : côté RGPD, garder des données personnelles indéfiniment dans tes sauvegardes est un problème de conformité (principe de limitation de conservation). Ta politique de rétention doit être documentée et bornée. Inversement, certaines données (comptables, par exemple) ont une durée de conservation minimale légale. Aligne la rétention sur ces obligations, pas sur « le plus longtemps possible ». (Voir le cours RGPD.)

Sauvegarde ≠ snapshot ≠ réplication

Trois mots qu’on confond, trois usages différents. Les mélanger mène à croire qu’on est protégé alors qu’on ne l’est pas.

Le point crucial : la réplication n’est pas une sauvegarde. Si tu tapes DELETE FROM users sur la base primaire, la commande se réplique en une fraction de seconde sur le réplica — les données sont perdues des deux côtés. Le snapshot, lui, vit chez ton fournisseur, souvent dans le même datacenter : pratique pour un rollback avant une migration, mais ce n’est pas du « hors-site » et il n’est pas granulaire (tu restaures tout le disque, pas un seul fichier).

⚠️ Piège — « J’ai un réplica de ma base, donc je suis sauvegardé. » Non. La réplication te protège de la panne matérielle d’un serveur, pas de l’erreur humaine ni de la corruption, qui se propagent au réplica. Il te faut en plus une vraie sauvegarde datée et indépendante. Snapshot, réplica et sauvegarde sont complémentaires, jamais interchangeables.

🧭 Sur FormaCampus — L’équipe pose sa stratégie noir sur blanc avant de toucher au moindre outil. Données à protéger : la base PostgreSQL (comptes apprenants, progression, résultats), les vidéos et PDF de cours uploadés dans /var/www/shared, et le .env (chiffré, à part). Le code Next.js et l’API Symfony ? Dans git, pas sauvegardés. Objectifs fixés : RPO 24 h (une sauvegarde quotidienne suffit, on accepte de reperdre au pire une journée) et RTO 4 h (remonter dans la demi-journée). Rétention grand-père-père-fils : 7 quotidiennes, 4 hebdomadaires, 6 mensuelles — la conservation étant bornée pour rester conforme au RGPD. Les snapshots du fournisseur servent de rollback avant migration, mais la vraie sauvegarde part hors-site, comme on le voit au chapitre suivant.

✏️ Exercices

Exercice 1 — Audite une « sauvegarde ». Un dev te dit : « je suis tranquille, un cron fait pg_dump tous les soirs dans /var/backups sur le serveur de prod. » Passe cette configuration à la grille 3-2-1 et liste ce qui manque.

Exercice 2 — Fixe RPO et RTO. Une petite boutique en ligne traite ~30 commandes par jour. Le patron dit : « perdre les commandes d’une journée entière serait catastrophique, mais si le site est down 3 h une nuit, tant pis. » Propose un RPO, un RTO, et une fréquence de sauvegarde cohérente.

Exercice 3 — Trie ce qui doit être sauvegardé. Tu déploies une app Next.js + Postgres avec des avatars uploadés par les utilisateurs. Sur cette liste, coche ce qui doit être sauvegardé et justifie : (A) node_modules, (B) la base Postgres, (C) le dossier /uploads/avatars, (D) le code source, (E) le fichier .env.

🧠 Quiz de révision

Chapitre suivant : Outils de backup — restic, borg, offsite chiffré et automatisation : la stratégie devient exécutable.