Pas de backup, pas de prod

TL;DR

📌 En résumé :

Sans backup testé, isolé et immuable, vous n’êtes pas en prod

La règle 3-2-1-1-0 : 3 copies, 2 supports, 1 hors site, 1 immuable, 0 erreur de restauration

Les backups de votre fournisseur cloud ne suffisent pas (modèle de responsabilité partagée)

Une sauvegarde non testée est une simple hypothèse de récupération

Le droit d’être en “Production”

Soyons brutaux : si vous n’avez pas de stratégie de sauvegarde testée, isolée et immuable, vous n’êtes pas en production. Vous faites simplement du développement exposé publiquement.

Penser que votre application est “en ligne” sans backup n’est pas de l’optimisme, c’est une faute professionnelle. Le passage en production est un engagement de responsabilité envers vos utilisateurs ; l’espoir n’est pas une stratégie d’infrastructure.

Pour illustrer cette fragilité, regardons le cas de Maersk lors de l’attaque NotPetya en 2017. Le géant logistique a vu ses 150 contrôleurs de domaine s’effacer simultanément. Pourquoi ? Parce qu’ils étaient parfaitement synchronisés pour la “résilience”. En clair, la réplication a servi de vecteur de destruction massive.

Le salut de l’entreprise a tenu à un miracle : une panne de courant fortuite dans un bureau isolé au Ghana avait maintenu un seul serveur hors ligne. C’est cet unique exemplaire, rescapé par pur accident électrique, qui a permis de reconstruire tout le réseau mondial.

Ne pariez pas l’avenir de votre SaaS sur une panne de courant providentielle.

L’illusion du “Tout Géré” : le modèle de responsabilité partagée

Croire que confier vos données à AWS, Azure ou Supabase vous dispense de gérer les sauvegardes est une erreur qui tuera votre business. C’est le piège classique du modèle de responsabilité partagée.

Le fournisseur gère la sécurité “du” cloud (les datacenters physiques, le réseau, l’hyperviseur), mais vous êtes contractuellement seul responsable de la sécurité “dans” le cloud (vos données, vos comptes, vos accès et vos configurations).

Responsabilité	IaaS (EC2, Azure VM)	PaaS (Supabase, Azure SQL)	SaaS (M365, Salesforce)
Sécurité physique	Fournisseur	Fournisseur	Fournisseur
Infrastructure et réseau	Fournisseur	Fournisseur	Fournisseur
Système d’exploitation	Client	Fournisseur	Fournisseur
Configuration application	Client	Partagé	Partagé
Données, comptes et accès	Client	Client	Client

Même en SaaS, si un utilisateur supprime par erreur (ou malice) une base de données, Microsoft ou Salesforce ne viendront pas vous sauver gratuitement. La donnée vous appartient, sa perte aussi.

Pourquoi les backups de votre fournisseur ne suffisent pas

Il est vital de distinguer la Résilience (haute disponibilité via réplication) de la Sauvegarde (possibilité de remonter dans le temps).

La réplication est instantanée : si votre base est corrompue ou chiffrée par un ransomware, la réplication propage la destruction en quelques millisecondes sur toutes vos instances.

Voici trois cas réels qui devraient vous empêcher de dormir :

Le mensonge des politiques de rétention (Cas Seuros, 2025)

Abdelkader Boudih (Seuros) avait tout bien fait : multi-région, chiffrement ségrégué. Pourtant, suite à une erreur administrative interne, AWS a supprimé son compte et 10 ans de données en moins de 20 jours, malgré une documentation officielle promettant un délai de grâce de 90 jours.

Les politiques des géants du cloud ne sont pas des garanties, ce sont des intentions.

Le Single Point of Failure administratif (Cas CodeSpaces, 2014)

CodeSpaces a disparu en 12 heures. Un intrus a accédé à leur console AWS et a tout supprimé : instances de production ET snapshots. La cause ? L’absence de Multi-Factor Authentication (MFA) sur leur compte racine.

Si vos backups sont accessibles via la même console d’administration que votre prod sans isolation stricte, ils ne comptent pas comme des backups, mais comme des actifs vulnérables.

L’entreprise a dû cesser ses activités le jour même.

La catastrophe physique (Cas OVHcloud, 2021)

L’incendie de Strasbourg a prouvé que stocker des sauvegardes dans le même bâtiment (ou même la même zone géographique) est inutile. Des entreprises ont perdu leurs données et leurs backups simultanément parce qu’ils partageaient le même toit.

Le tribunal de commerce de Lille a condamné OVH à payer plus de 400 000 € à des entreprises. Les juges ont rejeté l’argument de la “force majeure”, statuant qu’un hébergeur manque à son obligation contractuelle s’il ne garantit pas la sécurité physique des sauvegardes par une séparation géographique réelle.

Les standards de l’industrie : de la règle 3-2-1 à la 3-2-1-1-0

Pour sortir du bricolage, appliquez la méthodologie moderne utilisée par les experts DevOps.

La règle 3-2-1 (le minimum)

Théorisée par le photographe Peter Krogh, elle repose sur trois principes simples :

3 copies de vos données (1 originale + 2 sauvegardes)
2 supports différents (ex: disque local et stockage objet)
1 copie hors site (autre région géographique ou autre fournisseur)

L’évolution 3-2-1-1-0 (le standard actuel)

Face aux ransomwares qui cherchent activement à supprimer vos sauvegardes connectées au réseau, cette version est devenue le standard :

1 copie Immuable ou “Air-gapped” : Utilisez du stockage WORM (Write Once, Read Many) ou déconnecté du réseau. Une fois écrit, le backup ne peut être ni modifié ni supprimé, même par un admin root, pendant une période définie.
0 erreur : Aucun backup n’est valide sans un test de restauration automatisé. Une sauvegarde non testée est une simple hypothèse de récupération.

⚠️ L’application stricte de cette règle permet de passer d’une simple “espérance” de récupération à une certitude opérationnelle.

RPO et RTO : Vos métriques de survie

Deux métriques fondamentales doivent être définies pour chaque application :

RPO (Recovery Point Objective) : Quelle quantité de données pouvez-vous vous permettre de perdre ? Si votre dernier backup date de 24h, vous risquez de perdre jusqu’à 24h de travail. Pour les systèmes critiques, on vise un RPO proche de zéro grâce à des sauvegardes continues (CDP).
RTO (Recovery Time Objective) : Combien de temps pouvez-vous rester offline ? Si votre RTO est de 4 heures, vous devez pouvoir restaurer un système fonctionnel dans ce délai. Cela détermine si vous restaurez depuis un dump lent (RTO de plusieurs heures) ou une Instant Recovery (RTO de quelques minutes).

Le cas GitLab : l’échec systémique (2017)

L’incident GitLab est devenu un cas d’école illustrant une faillite systémique où la technologie, les processus et l’humain ont échoué simultanément.

Ce qui s’est passé

Un ingénieur système, opérant sous une pression intense pour stabiliser une réplication PostgreSQL, a exécuté une commande de suppression sur le mauvais serveur (le serveur primaire au lieu du secondaire). 300 Go de données de production perdues.

L’illusion de la multiplicité des sauvegardes

GitLab disposait théoriquement de cinq mécanismes de sauvegarde différents. Au moment de l’incident, aucun n’était fonctionnel :

Les sauvegardes vers S3 échouaient silencieusement (binaires PostgreSQL incompatibles)
Les snapshots Azure n’étaient pas activés pour les serveurs de base de données
Les notifications d’échec étaient rejetées par le serveur mail (problème DMARC)

Le miracle

Le salut de GitLab est venu d’un instantané manuel pris par hasard par un ingénieur six heures avant l’incident pour des tests en environnement de staging. Sans ce coup du sort, la perte de données aurait été totale.

Les leçons

Les commandes critiques nécessitent une double vérification : les humains, comme les systèmes, ont besoin de redondance
Ne jamais supposer qu’une sauvegarde fonctionne sans preuve : plusieurs méthodes ne garantissent rien si elles ne sont pas testées
Les systèmes de backup doivent être activement monitorés : un système de notification défaillant rend la stratégie de protection inexistante
Une sauvegarde non testée n’existe pas : seuls les tests de restauration réguliers valident l’intégralité de la chaîne

Les risques du vendor lock-in pour vos backups

Confier l’intégralité de ses sauvegardes à un fournisseur unique fait peser des risques majeurs sur la survie d’une organisation, car cela crée un point de défaillance unique (SPOF).

Perte totale en cas de catastrophe chez le fournisseur

Si l’infrastructure du fournisseur subit un sinistre majeur et que vos sauvegardes ne sont pas géographiquement isolées, vous risquez une perte irrémédiable. L’incendie OVHcloud l’a tragiquement illustré.

Compromission de la console d’administration

Rattacher toutes ses sauvegardes au même compte ou à la même console logique que la production est une erreur critique (cf. cas CodeSpaces ci-dessus).

Erreurs administratives du fournisseur

Le fournisseur lui-même peut devenir l’agent de destruction de vos données suite à des erreurs de procédure ou des problèmes de vérification de compte (cf. cas Seuros/AWS).

Propagation des erreurs logiques

La réplication synchronise les données entre centres de données pour assurer la haute disponibilité, mais elle propage instantanément les erreurs logiques (suppression accidentelle, corruption par malware). Si vous dépendez uniquement des outils natifs du fournisseur stockés dans le même environnement, une compromission de compte permet de supprimer les sauvegardes et la production en une seule action.

Recommandation : une stratégie multi-cloud ou l’utilisation d’une solution tierce indépendante pour garantir que vos données de secours restent hors de portée en cas de défaillance du fournisseur principal.

Le coût de la négligence

Le coût financier d’une perte de données est massif et continue de croître :

Coût moyen mondial d’une violation de données en 2025 : 4,44 millions de dollars (10,22 M$ aux États-Unis)
Coût de l’indisponibilité : 5 600 $ par minute selon Gartner, soit plus de 300 000 $ par heure
Amendes RGPD : jusqu’à 4 % du chiffre d’affaires mondial
60 % des PME victimes d’un piratage déposent le bilan dans les six mois

Les dommages réputationnels sont souvent irréparables : 85 % des consommateurs refusent de faire des achats auprès d’une entreprise s’ils ont des doutes sur ses pratiques de sécurité.

🎬 J’ai publié une vidéo sur Databasus, un outil open source parmi d’autres qui permet d’automatiser vos sauvegardes PostgreSQL, MySQL ou MongoDB vers différents stockages (S3, local, Google Drive…).

Par où commencer ?

Cette semaine, prenez 2 heures pour faire le point :

Listez vos données critiques : Quelles données, si perdues, mettraient votre activité en péril ?
Localisez vos backups actuels : Où sont-ils ? Sont-ils sur le même compte/fournisseur que la prod ?
Vérifiez l’isolation : Vos sauvegardes survivraient-elles à une compromission de votre console d’administration ?
Planifiez un test de restauration : Bloquez une demi-journée ce mois-ci pour restaurer réellement vos données sur une machine vierge
Définissez vos RPO/RTO : Combien de données et de temps pouvez-vous vous permettre de perdre ?

💡 Si vous ne pouvez pas répondre à ces 5 points, vous avez trouvé votre priorité de la semaine.

Conclusion : votre mission immédiate

La question n’est pas de savoir si vous allez subir une catastrophe, mais quand. Un bug, une erreur humaine ou un ransomware finira par frapper.

Votre mission : Arrêtez de lire cet article et lancez un test de restauration réel.

Si vous ne pouvez pas restaurer vos données en moins d’une heure sur une machine vierge, vous n’avez pas de backup.

La protection des données n’est plus une option mais une assurance-vie indispensable, car le prix de la négligence peut être la disparition pure et simple de l’organisation.

Ne laissez pas votre business dépendre d’un accident électrique providentiel.

Sources

Incidents et cas d’étude

Darknet Diaries - NotPetya - L’attaque NotPetya et Maersk
Availability Digest - GitLab - Analyse de l’incident GitLab 2017
ITWriting - CodeSpaces - Comment CodeSpaces a perdu son business
Transatlantic Lawyer - OVH - Condamnation d’OVH
Windows Central - AWS/Seuros - 10 ans de données supprimées par AWS

Bonnes pratiques et standards

Veeam - Règle 3-2-1 - La règle de backup expliquée
ORSYS - Règle 3-2-1-1-0 - Guide complet des bonnes pratiques
Veeam - RTO/RPO - Comprendre les objectifs de récupération
Object First - Best Practices - 9 bonnes pratiques de sauvegarde
Penntech - Testing is Essential - Pourquoi tester ses backups

Modèle de responsabilité partagée

AWS - Shared Responsibility Model - Documentation officielle AWS
Microsoft Learn - Shared Responsibility - Documentation officielle Azure
Veeam - Shared Responsibility Model - Explication du modèle

Statistiques et impacts

Flosum - Impact of Data Loss - Impact financier des pertes de données
Secureframe - Data Breach Statistics - Statistiques sur les violations de données
Worldpay - Data Breach Consequences - Impact sur les PME

Outils

Databasus - Outil open source de backup pour PostgreSQL, MySQL et MongoDB

Mon approche pour la création de cet article : recherche et compilation des sources avec NotebookLM, rédaction du brouillon à la main. Claude Code (Opus 4.5) m’a ensuite aidé à rendre le texte plus fluide, supprimer les répétitions, structurer l’article et corriger l’orthographe.