Pas de sauvegardes : la plus vieille horreur tech sans monstres

Ce que « pas de sauvegardes » signifie vraiment

La plupart des équipes qui « n’ont pas de sauvegardes » n’ont pas littéralement rien. Elles ont des artefacts. Des snapshots au mauvais endroit. Un cron qui a tourné une fois. Un bucket avec une règle de cycle de vie qui supprime silencieusement la seule copie. Une politique de rotation de bandes conçue en 2009 et jamais exécutée depuis que la personne qui la comprenait est partie.

En termes opérationnels, « pas de sauvegardes » signifie qu’au moins une des situations suivantes est vraie :

• Aucune copie indépendante n’existe. Toutes les copies partagent le même domaine de défaillance : même compte, même région, même système de stockage, mêmes identifiants, même rayon d’action d’un ransomware.
• Aucun chemin de restauration vérifié n’existe. La sauvegarde peut être présente, mais vous ne pouvez pas la restaurer dans votre RTO, ou pas du tout.
• Aucun point « connu bon » n’existe. Les sauvegardes peuvent être corrompues, incomplètes, chiffrées avec des clés manquantes, ou capturées en plein milieu d’une transaction sans consistance.
• Personne ne possède la récupération. Les sauvegardes « appartiennent à l’IT » et les restaurations « appartiennent à l’équipe applicative », ce qui se traduit par « personne n’y touchera tant que ce n’est pas trop tard ».
• Aucune surveillance ne détecte la défaillance. Le job ne s’est pas exécuté depuis 47 jours et personne ne l’a remarqué parce que les tableaux de bord verts sont décoratifs.

Vous pouvez stocker des données à dix endroits et ne pas avoir de sauvegardes. Les sauvegardes ne sont pas une question de copie. Elles concernent la récupération : une récupération contrôlée, répétable, bornée dans le temps, que vous pouvez exécuter sous stress avec peu de sommeil.

Un avis qui vous fera économiser de l’argent et des douleurs : si vous n’avez pas effectué un exercice de restauration récemment, vous n’avez pas de sauvegardes — vous avez de l’espoir.

Il y a une raison pour laquelle les équipes d’exploitation parlent des sauvegardes avec le ton généralement réservé aux incendies électriques. C’est la catégorie de défaillance où le système semble correct jusqu’au moment où il ne l’est plus, et alors ce n’est pas le système qui a échoué — c’est l’histoire que vous vous êtes racontée sur le système.

Petite blague #1 : Les sauvegardes sont comme des parachutes : si vous ne les testez qu’une fois, vous serez très confiant pour une courte durée.

RPO et RTO : les seuls mots qui comptent quand les lumières s’éteignent

RPO (Recovery Point Objective) est la quantité de données que vous acceptez de perdre. Si votre RPO est de 15 minutes, alors une sauvegarde qui tourne une fois par nuit n’est pas un plan de sauvegarde ; c’est une lettre de démission écrite en YAML.

RTO (Recovery Time Objective) est la durée pendant laquelle vous pouvez être en panne. Si votre RTO est d’une heure, alors une restauration qui exige qu’un humain retrouve une clé de déchiffrement dans le coffre personnel d’un ex-employé n’est pas une restauration ; c’est une chasse au trésor.

Ne négociez pas les RPO/RTO au milieu d’un incident. Décidez à l’avance, obtenez une validation, et construisez le système pour les respecter. Vous aurez toujours des incidents. Vous n’aurez juste pas de surprises.

Faits et historique : pourquoi cela se produit encore

« Pas de sauvegardes » existe depuis plus longtemps que la plupart des langages de programmation en production. Cela perdure parce que le problème se trouve à l’intersection de l’optimisme humain, de la pression budgétaire et des systèmes qui échouent de façon créative.

8 faits et points de contexte (brefs, concrets)

1. Les premières sauvegardes d’entreprise étaient basées sur les bandes parce que les disques coûtaient cher ; la discipline opérationnelle importait plus que le matériel. Le support a changé, la discipline pas assez.
2. La « règle 3-2-1 » (trois copies, deux types de média, une hors site) précède le battage autour du cloud et capture toujours une vérité centrale : l’indépendance vaut mieux que l’élégance.
3. RAID a été largement confondu avec « sauvegarde » pendant des décennies ; RAID est disponibilité, pas récupérabilité. Il empêche certaines pannes et en amplifie d’autres.
4. Les snapshots sont devenus courants parce qu’ils sont bon marché et rapides (copy-on-write), ce qui a facilité leur surconfiance — jusqu’à ce que le système de snapshot partage le même domaine de défaillance.
5. Le ransomware a changé le modèle de menace de « panne matérielle » à « adversaire actif ». Si des attaquants peuvent supprimer les sauvegardes, vous n’avez pas de sauvegardes.
6. Le cloud a introduit une nouvelle illusion : que la durabilité implique automatiquement la récupérabilité. La durabilité des objets n’aide pas si vous écrasez la mauvaise chose ou supprimez le bucket avec des identifiants admin.
7. Les défaillances des logiciels de sauvegarde sont souvent silencieuses parce que le succès est généralement mesuré par « job terminé » plutôt que « restauration vérifiée ». Vous pouvez « compléter » des données inutilisables.
8. Les régimes de conformité ont augmenté les exigences de rétention (et les coûts), ce qui a poussé des équipes vers une déduplication agressive et des règles de cycle de vie — deux outils puissants et dangereux quand ils sont mal configurés.

L’idée fiabilité à garder en tête

Voici une phrase unique qui devrait figurer dans vos runbooks :

« Tout échoue ; concevez pour que la défaillance soit survivable. » — Werner Vogels

Si vous construisez des systèmes, c’est le travail. Pas empêcher les défaillances. Survivre à celles-ci.

Modes de défaillance : comment « on a des sauvegardes » devient « on n’en a jamais eu »

1) Même compte, mêmes clés, même rayon d’action

Vos sauvegardes sont dans le même compte cloud que la production. Le même rôle IAM qui peut supprimer la prod peut supprimer les sauvegardes. Lors d’un ransomware ou d’une fuite d’identifiants, les attaquants n’évitent pas poliment votre bucket « backup ».

Correction : placez les sauvegardes dans un compte/projet/tenant séparé avec des identifiants distincts et des modèles stricts d’écriture cross-account en mode write-only. Si vous pouvez parcourir le référentiel de sauvegarde depuis votre laptop avec votre rôle SSO quotidien, vous avez déjà rendu la destruction trop facile.

2) Les snapshots pris pour des sauvegardes

Les snapshots sont excellents. Ils sont aussi fréquemment pas des sauvegardes :

• Les snapshots sur le même volume ne survivent pas à la perte du volume.
• Les snapshots sur la même baie ne survivent pas à la perte de la baie.
• Les snapshots accessibles avec les mêmes identifiants admin ne survivent pas à un ransomware.

Les snapshots sont mieux considérés comme une récupération locale rapide. Les sauvegardes sont une récupération indépendante.

3) « Les sauvegardes réussissent » mais les restaurations échouent

C’est le classique. Les logs de job indiquent « succès ». Le référentiel se remplit de fichiers. Puis vous tentez une restauration et découvrez :

• la chaîne dépend d’incrémentaux manquants,
• la clé de chiffrement a disparu,
• la sauvegarde de la base n’est pas cohérente,
• les instructions de restauration n’avaient jamais été consignées,
• la plateforme cible a changé (kernel, système de fichiers, version majeure de la DB).

Les sauvegardes sont un produit ; les restaurations en sont le test d’acceptation.

4) Politiques de rétention qui effacent votre passé

Une simple mauvaise configuration de cycle de vie peut supprimer les seuls points de restauration viables. Exemples courants :

• Rétention réglée pour le coût et par erreur sur « garder 7 jours » alors que le ransomware est resté indétecté 21 jours.
• Règles « déplacer vers un stockage moins cher » qui cassent les objectifs RTO parce que la récupération prend des heures.
• Versioning d’objet désactivé parce que « ça coûte trop cher », puis un job automatisé écrase tout.

5) Le piège de l’« optimisation » : déduplication et chaînes incrémentales

La dédup et les incrémentaux sont fantastiques quand vous garantissez l’intégrité et testez les restaurations. Ce sont aussi un moyen de concentrer le risque : corrompez un chunk dans le magasin de dédup, et beaucoup de sauvegardes deviennent simultanément inutilisables.

Quand quelqu’un dit « on a économisé 60% de stockage », votre prochaine question devrait être : « Montrez-moi le test de restauration complet du mois dernier. »

6) Sauvegardes sans identité ni provenance

Une sauvegarde sans métadonnées est une boîte scellée. Si vous ne savez pas ce qu’elle contient, ce qui l’a produite, quand elle a été prise, à quelle version elle correspond, et comment la restaurer, c’est une responsabilité qui coûte quelque chose en stockage.

Au minimum, chaque artefact de sauvegarde doit être traçable à :

• identité du système source (host/db/cluster),
• fenêtre temporelle,
• méthode de consistance (filesystem freeze, DB snapshot, WAL archive),
• classe de rétention (daily/weekly/monthly),
• méthode de chiffrement et propriété des clés,
• référence à la procédure de restauration (section du runbook, pas une mémoire tribale).

Trois mini-récits d’entreprise depuis les tranchées des sauvegardes

Mini-récit n°1 : l’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne exécutait sa base de données principale sur Postgres managé. Elle avait aussi des « sauvegardes » sur une VM séparée : un job nocturne qui exécutait pg_dump et copiait un fichier vers un stockage d’objets. Sur le papier, c’était sûr : sauvegardes managées plus leur copie « ceinture et bretelles ».

L’hypothèse erronée était subtile et extrêmement courante : ils supposaient que la sortie de pg_dump impliquait un snapshot cohérent et restaurable. La plupart du temps c’est vrai — jusqu’à ce que ça ne le soit plus. Leurs plus grandes tables subissaient des écritures constantes, et le dump tournait assez longtemps pour chevaucher plusieurs changements de schéma. Le dump s’est terminé, a rapporté un succès et a été uploadé. Tout le monde a dormi.

Puis une erreur d’opérateur est arrivée : un script de migration a supprimé une table dans le mauvais schéma. La reprise point-in-time managée existait, mais l’équipe ne l’avait jamais pratiquée et ne connaissait pas les contraintes du fournisseur. Ils se sont tournés vers le fichier dump « simple ».

La restauration a échoué avec des erreurs sur des relations manquantes et un état de schéma incohérent. Le dump n’était pas une vue propre à un point dans le temps de la base telle que l’application l’attendait ; c’était un artefact d’un système en évolution. Leur « sauvegarde » n’était pas fausse ; elle n’était simplement pas la sauvegarde dont ils avaient besoin pour la restauration qu’ils tentaient.

Ils ont finalement récupéré via le PITR managé après une longue et stressante séance d’apprentissage et beaucoup de temps d’indisponibilité. La correction n’était pas exotique : arrêter de traiter les dumps comme filet de sécurité principal pour une base de données chaude et changeante. Utilisez une méthode de sauvegarde conçue pour la consistance (sauvegardes physiques avec WAL, snapshots coordonnés avec la DB, ou PITR natif du fournisseur), et effectuez des exercices de restauration trimestriels.

Mini-récit n°2 : l’optimisation qui a mal tourné

Une équipe de services financiers a décidé de réduire les coûts de sauvegarde. Leur référentiel grossissait vite, et la facture mensuelle a attiré l’attention des dirigeants — le genre d’intérêt qui arrive sans contexte technique et repart avec des « actions à mener ». Un ingénieur bien intentionné a activé une déduplication agressive et changé les sauvegardes complètes de hebdomadaires à mensuelles, comptant fortement sur les incrémentaux.

Tout avait l’air mieux. La croissance du stockage s’est aplatie. Les sauvegardes tournaient plus vite. Les tableaux de bord étaient verts. Ils se sont même vantés de la « victoire d’efficacité » lors d’un review coûts. La partie effrayante de l’histoire est qu’aucune de ces choses n’était un mensonge.

Trois mois plus tard, un bug de contrôleur de stockage a corrompu une petite portion du magasin de déduplication. Pas assez pour planter le système de sauvegarde. Pas assez pour apparaître dans les métriques « job success ». Juste assez pour rendre les chaînes de restauration peu fiables.

Quand ils ont dû récupérer un serveur applicatif après une mise à jour d’OS ratée, la restauration échouait à plusieurs reprises tard dans le processus. Des fichiers différents à chaque fois. Le système lisait des chunks corrompus référencés par de nombreuses sauvegardes. L’optimisation avait concentré le risque dans une piscine partagée de blocs, et les longues chaînes incrémentales faisaient qu’il n’y avait pas de « ancre complète » récente à laquelle revenir.

Ils ont reconstruit le référentiel, ajouté des fulls synthétiques périodiques (vérifiés), et implémenté des tests de restauration automatisés qui montaient les systèmes de fichiers restaurés et validaient les checksums. Le coût a augmenté. Leur capacité à dormir aussi.

Mini-récit n°3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise de manufacturing avait une petite équipe SRE supportant un mélange de VMs legacy et de services conteneurisés. Leur système de sauvegarde n’était pas sophistiqué : snapshots ZFS répliqués chaque nuit vers un second site, plus des exports hebdomadaires vers un stockage d’objets immuable. Les runbooks étaient douloureusement détaillés, et l’équipe réalisait un exercice de restauration chaque mois.

Pendant une fenêtre de patch routine, une mise à jour du firmware sur la baie de stockage primaire a mal tourné. La baie n’est pas morte de façon dramatique ; elle a juste cessé de présenter correctement plusieurs LUNs. Du point de vue de l’OS, les systèmes de fichiers sont devenus en lecture seule puis incohérents. Les applications ont commencé à échouer de façon déroutante. L’incident n’était pas spectaculaire. C’était une chute au ralenti.

L’équipe n’a pas tergiversé. Ils ont exécuté le plan documenté : geler les écritures, basculer les services vers le dataset répliqué, et démarrer un ensemble minimal d’apps critiques en premier. Leur première cible de restauration n’était pas « tout » — c’étaient les systèmes qui faisaient de l’argent et payaient les gens.

Ils étaient de nouveau en service avant que l’entreprise n’ait vraiment compris ce qui s’était passé. Le postmortem était presque ennuyeux : pas d’héroïsme, pas de scripts magiques, pas de « on a trouvé une copie sur l’ordinateur de Bob ». Juste réplication, immutabilité et une procédure pratiquée.

La leçon discrète : la récupération ennuyeuse bat la sauvegarde intelligente. Si votre plan de sauvegarde exige du génie pendant une panne, ce n’est pas un plan.

Manuel de diagnostic rapide : trouver le goulot d’étranglement vite

Quand quelqu’un dit « la sauvegarde échoue » ou « la restauration est trop lente », vous avez besoin d’un chemin rapide vers le facteur limitant. Ne commencez pas par réécrire tout le système. Commencez par trouver ce qui est réellement contraint : identifiants, capacité, IOPS, réseau, CPU, santé du référentiel ou justesse.

Première étape : vérifiez quel type de défaillance vous avez (disponibilité vs cohérence vs temps)

• Disponibilité : jobs de sauvegarde qui ne tournent pas, référentiel inaccessible, permissions refusées.
• Cohérence : sauvegardes « réussies » mais restauration qui échoue ou données manquantes/corrompues.
• Temps : restauration plus longue que le RTO, sauvegardes qui se chevauchent et ne se terminent jamais, latence de réplication qui casse le RPO.

Deuxième étape : vérifiez les quatre points d’étranglement dans l’ordre

1. Identité et permissions : identifiants expirés, politiques IAM cassées, clés remplacées, modifications MFA/SSO.
2. Capacité et rétention du stockage : repo plein, snapshots supprimés prématurément, cycle de vie d’objets en suppression.
3. Débit : réseau saturé, I/O disque limité, throttling cloud, compression mono-thread.
4. Cohérence : absence de quiesce applicatif, sauvegardes DB non coordonnées avec les logs.

Troisième étape : prouvez la faisabilité de la restauration avec un test petit et déterministe

Ne visez pas d’abord une restauration complète de l’environnement. Choisissez un artefact et restaurez-le sur un hôte scratch :

• restaurez un disque VM et montez-le en lecture seule,
• restaurez un Postgres base backup + rejouez les WAL jusqu’à un timestamp connu,
• restaurez un arbre de répertoires et vérifiez checksums et comptages.

Cela réduit le problème à des faits : pouvez-vous récupérer les données, pouvez-vous les déchiffrer, pouvez-vous les monter, l’application peut-elle les lire, et combien de temps ça prend ?

Tâches pratiques (avec commandes) : prouvez que vous pouvez restaurer

Ci-dessous des tâches réelles que vous pouvez exécuter aujourd’hui. Chacune inclut : une commande, un exemple de sortie, ce que cela signifie et la décision que vous prenez. Le but n’est pas d’admirer la sortie des commandes. Le but est de passer de « on pense » à « on sait ».

Tâche 1 : Confirmez que vous avez réellement des sauvegardes récentes (niveau système de fichiers)

cr0x@server:~$ ls -lh /backups/daily | tail -n 5
-rw-r----- 1 root backup 1.8G Jan 22 01:05 app01-etc-2026-01-22.tar.zst
-rw-r----- 1 root backup  22G Jan 22 01:12 app01-varlib-2026-01-22.tar.zst
-rw-r----- 1 root backup 4.1G Jan 22 01:18 db01-config-2026-01-22.tar.zst
-rw-r----- 1 root backup  91G Jan 22 01:55 db01-basebackup-2026-01-22.tar.zst
-rw-r----- 1 root backup 3.4M Jan 22 02:01 manifest-2026-01-22.json

Sens de la sortie : Vous voyez les artefacts du jour et leurs tailles, plus un manifest. Des anomalies de taille (trop petit/trop grand) sont des premiers signaux d’alerte.

Décision : Si les fichiers du jour sont manquants ou clairement de mauvaise taille, ne faites plus confiance aux emails de succès. Examinez immédiatement les logs de jobs et les permissions en amont.

Tâche 2 : Vérifier le succès des jobs via systemd timers

cr0x@server:~$ systemctl list-timers --all | grep backup
Tue 2026-01-22 01:00:00 UTC  6h left  Tue 2026-01-21 01:00:04 UTC  18h ago backup-daily.timer   backup-daily.service
Tue 2026-01-22 02:30:00 UTC  8h left  Tue 2026-01-21 02:30:02 UTC  16h ago backup-verify.timer  backup-verify.service

Sens de la sortie : Les timers existent et ont tourné récemment. Si l’heure « last » est ancienne, vos sauvegardes ont peut-être cessé il y a des semaines.

Décision : Si les timers ne tournent pas, traitez ça comme un risque de perte de données, pas comme un ticket mineur. Corrigez la planification et l’alerte avant toute autre chose.

Tâche 3 : Inspecter le dernier statut du service de sauvegarde

cr0x@server:~$ systemctl status backup-daily.service --no-pager
● backup-daily.service - Nightly backup job
     Loaded: loaded (/etc/systemd/system/backup-daily.service; enabled)
     Active: inactive (dead) since Tue 2026-01-21 01:55:13 UTC; 18h ago
    Process: 18422 ExecStart=/usr/local/sbin/backup-daily.sh (code=exited, status=0/SUCCESS)
   Main PID: 18422 (code=exited, status=0/SUCCESS)

Jan 21 01:00:04 server backup-daily.sh[18422]: starting backup run id=2026-01-21T010004Z
Jan 21 01:55:12 server backup-daily.sh[18422]: upload complete: s3://backup-prod/daily/...
Jan 21 01:55:13 server backup-daily.sh[18422]: finished OK

Sens de la sortie : L’unité s’est terminée avec succès et a loggé la fin de l’upload.

Décision : Le succès ici est nécessaire mais pas suffisant. Vous devez toujours vérifier l’intégrité et la restaurabilité (tâches ci-dessous).

Tâche 4 : Détecter « référentiel plein » avant que cela devienne une panne

cr0x@server:~$ df -h /backups
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       7.3T  7.1T  110G  99% /backups

Sens de la sortie : 99% utilisé est une défaillance en cours. Beaucoup d’outils de sauvegarde commenceront à échouer, certains commenceront à supprimer, et quelques-uns mentiront.

Décision : Suspendez les sauvegardes non essentielles, étendez la capacité et révisez la rétention. Vérifiez aussi que la dernière sauvegarde est complète ; les disques presque pleins conduisent à des artefacts partiels.

Tâche 5 : Valider les checksums d’un artefact de sauvegarde (vérification ponctuelle)

cr0x@server:~$ sha256sum -c /backups/daily/manifest-2026-01-22.sha256 | head
app01-etc-2026-01-22.tar.zst: OK
app01-varlib-2026-01-22.tar.zst: OK
db01-config-2026-01-22.tar.zst: OK
db01-basebackup-2026-01-22.tar.zst: OK

Sens de la sortie : Les fichiers correspondent aux hashs enregistrés. Cela détecte la corruption en stockage ou en transfert.

Décision : Si un fichier est « FAILED », mettez ce jeu de sauvegardes en quarantaine, inspectez la santé du stockage et confirmez que vous avez un autre point de restauration.

Tâche 6 : Vérifier la versioning et l’état de lock du stockage d’objets (résilience ransomware)

cr0x@server:~$ aws s3api get-bucket-versioning --bucket backup-prod
{
    "Status": "Enabled"
}

Sens de la sortie : Le versioning est activé ; les suppressions deviennent des delete-markers et les réécritures conservent les versions précédentes.

Décision : Si le versioning est « Suspended » ou vide, vous êtes plus facile à effacer. Activez le versioning et envisagez Object Lock (immutabilité) où approprié.

Tâche 7 : Confirmer la configuration S3 Object Lock (immutabilité)

cr0x@server:~$ aws s3api get-object-lock-configuration --bucket backup-prod
{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }
}

Sens de la sortie : La rétention par défaut est immuable pendant 30 jours en mode compliance. Même les admins ne peuvent pas la raccourcir.

Décision : Si Object Lock est absent et que votre modèle de menace inclut le ransomware, vous avez besoin d’un niveau immuable (Object Lock, WORM, hors-ligne ou système contrôlé séparé).

Tâche 8 : Vérifier la latence de réplication des snapshots ZFS (vérification RPO)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 3
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026
tank/appdata@2026-01-22T0300Z  Tue Jan 22 03:00 2026

Sens de la sortie : Des snapshots existent chaque heure. C’est votre meilleur RPO théorique local.

Décision : Ensuite, confirmez que ces snapshots sont répliqués hors hôte. Les snapshots locaux seuls ne répondent pas aux besoins de reprise après sinistre.

Tâche 9 : Confirmer que la réplication ZFS a bien avancé sur la cible

cr0x@server:~$ ssh backup-target "zfs list -t snapshot -o name,creation -s creation | grep tank/appdata | tail -n 3"
tank/appdata@2026-01-22T0000Z  Tue Jan 22 00:00 2026
tank/appdata@2026-01-22T0100Z  Tue Jan 22 01:00 2026
tank/appdata@2026-01-22T0200Z  Tue Jan 22 02:00 2026

Sens de la sortie : La cible a un snapshot de retard sur la source. C’est une latence de réplication : votre RPO réel est actuellement ~1 heure, pas « horaire ».

Décision : Si le retard dépasse votre RPO, enquêtez sur le débit de réplication, les échecs ou la planification. Envisagez la réplication continue pour les bases de données ou le WAL shipping.

Tâche 10 : Mesurer le débit du référentiel pendant une restauration (vérification RTO)

cr0x@server:~$ pv /backups/daily/db01-basebackup-2026-01-22.tar.zst > /dev/null
 91.2GiB 0:12:31 [ 124MiB/s] [==================================>] 100%

Sens de la sortie : Vous pouvez lire le fichier de sauvegarde à ~124 MiB/s depuis le repo. C’est un plafond dur sur la vitesse de restauration avant décompression et rejouage applicatif.

Décision : Si votre RTO exige de restaurer 2 TB en moins d’une heure, ce chemin de repo ne peut pas le faire. Ajoutez du parallélisme, du stockage plus rapide ou des stratégies de restauration en niveaux.

Tâche 11 : Valider que votre sauvegarde contient ce que vous pensez (liste tar)

cr0x@server:~$ zstd -t /backups/daily/app01-etc-2026-01-22.tar.zst
/backups/daily/app01-etc-2026-01-22.tar.zst : OK

Sens de la sortie : Le fichier compressé passe les contrôles d’intégrité au niveau compression.

Décision : Si cela échoue, n’essayez pas de restaurer depuis ce fichier. Trouvez un autre point dans le temps et examinez le hardware et les chemins d’upload.

Tâche 12 : Effectuer un vrai exercice de restauration d’un répertoire vers un chemin scratch

cr0x@server:~$ mkdir -p /restore-test/app01-etc && tar -I zstd -xpf /backups/daily/app01-etc-2026-01-22.tar.zst -C /restore-test/app01-etc
cr0x@server:~$ ls -l /restore-test/app01-etc/etc | head
total 64
-rw-r--r-- 1 root root  296 Jan 21 23:59 hostname
-rw-r--r-- 1 root root 1177 Jan 21 23:59 hosts
drwxr-xr-x 2 root root 4096 Jan 21 23:59 systemd
drwxr-xr-x 2 root root 4096 Jan 21 23:59 ssh

Sens de la sortie : Vous avez extrait avec succès la sauvegarde et pouvez voir les fichiers attendus. C’est un test de restauration minimum viable.

Décision : Si l’extraction échoue ou des fichiers manquent, considérez les sauvegardes comme compromises. Corrigez avant que le prochain incident ne vous force la main.

Tâche 13 : Vérifier les sauvegardes Postgres : l’archivage WAL est-il configuré ?

cr0x@server:~$ sudo -u postgres psql -c "show wal_level; show archive_mode; show archive_command;"
 wal_level
----------
 replica
(1 row)

 archive_mode
--------------
 on
(1 row)

           archive_command
-------------------------------------
 test ! -f /wal-archive/%f && cp %p /wal-archive/%f
(1 row)

Sens de la sortie : L’archivage WAL est activé. C’est essentiel pour la reprise point-in-time au-delà de la base backup.

Décision : Si l’archivage est désactivé, vos « sauvegardes » ne pourront peut-être restaurer qu’au dernier base backup. Activez l’archivage et testez le PITR.

Tâche 14 : Vérifier que l’archive WAL reçoit réellement des fichiers (pas seulement configuré)

cr0x@server:~$ ls -lh /wal-archive | tail -n 3
-rw------- 1 postgres postgres 16M Jan 22 02:54 00000001000000A7000000FE
-rw------- 1 postgres postgres 16M Jan 22 02:58 00000001000000A7000000FF
-rw------- 1 postgres postgres 16M Jan 22 03:02 00000001000000A700000100

Sens de la sortie : De nouveaux segments WAL arrivent toutes les quelques minutes. C’est une preuve vivante que votre chaîne PITR progresse.

Décision : Si le répertoire est inactif, votre RPO dérive silencieusement. Corrigez l’archivage avant de faire confiance à tout plan de restauration.

Tâche 15 : Confirmer que les sauvegardes sont non seulement présentes mais restaurables (test Postgres smoke)

cr0x@server:~$ createdb restore_smoke
cr0x@server:~$ pg_restore --list /backups/daily/appdb-2026-01-22.dump | head
;
; Archive created at 2026-01-22 01:10:02 UTC
;     dbname: appdb
;     TOC Entries: 248
;     Compression: -1
;     Dump Version: 1.14-0

Sens de la sortie : Le dump est lisible et contient des objets. C’est une vérification légère avant une restauration complète.

Décision : Si pg_restore ne peut pas lire le fichier, votre sauvegarde est effectivement imaginaire. Passez à un autre type de sauvegarde et ajoutez des étapes de vérification.

Tâche 16 : Vérifier que vous pouvez déchiffrer vos sauvegardes (réalité de gestion des clés)

cr0x@server:~$ gpg --decrypt /backups/daily/secrets-2026-01-22.tar.gpg > /dev/null
gpg: encrypted with 4096-bit RSA key, ID 7A1C2B3D4E5F6789, created 2025-10-03
gpg: decryption ok

Sens de la sortie : L’opération de déchiffrement réussit avec les clés actuellement disponibles.

Décision : Si le déchiffrement échoue, vous n’avez pas de sauvegardes — vous avez des presse-papiers chiffrés. Réparez l’escalade de clés, les procédures d’accès et les politiques de rotation.

Petite blague #2 : La seule chose pire que de ne pas avoir de sauvegardes, c’est d’avoir des sauvegardes que vous ne pouvez pas déchiffrer — comme un coffre où vous avez mis la clé à l’intérieur.

Erreurs courantes : symptômes → cause racine → correction

Cette section est conçue pour la réponse aux incidents et les postmortems. Les symptômes sont ce que vous voyez à 2 h du matin. Les causes racines expliquent pourquoi c’est arrivé. Les corrections sont des actions spécifiques que vous pouvez exécuter.

1) « Les sauvegardes indiquent SUCCESS, mais les restaurations échouent »

Symptômes : Les logs de job affichent un succès ; les erreurs de restauration incluent incrémentaux manquants, archive corrompue, mismatch de checksum, ou l’application ne démarre pas.

Cause racine : Les critères de succès étaient « le fichier uploadé existe » plutôt que « restauration complétée et validée ». Ou corruption dans le magasin de dédup, ou snapshot DB incohérent.

Correction : Ajoutez une vérification de restauration automatisée (monter/extraire + checksum + test smoke au niveau application). Gardez des sauvegardes complètes périodiques vérifiées. Pour les bases, utilisez des méthodes applicatives-aware et validez en restaurant sur une instance scratch.

2) « On peut restaurer, mais ça prend des jours »

Symptômes : Le débit de restauration est faible ; la récupération depuis le stockage froid prend des heures ; la décompression est liée au CPU ; le réseau est saturé.

Cause racine : Le RTO n’a jamais informé l’architecture. Les sauvegardes sont stockées dans la couche la moins chère sans modéliser le temps de récupération. Le pipeline de restauration est mono-thread ou contraint par les IOPS du référentiel.

Correction : Mesurez le débit de restauration (pas seulement celui de sauvegarde). Utilisez des sauvegardes en niveaux : points récents rapides, anciens en froid. Parallélisez les restaurations, pré-stagiez les datasets critiques et assurez la possibilité de monter des cibles de restauration à l’échelle.

3) « Le ransomware a aussi supprimé nos sauvegardes »

Symptômes : Le bucket de sauvegarde vidé, snapshots supprimés, référentiel chiffré, serveur de backup compromis.

Cause racine : Identifiants partagés et absence d’immuabilité. Sauvegardes accessibles avec des rôles admin. Pas de séparation des tâches.

Correction : Séparez comptes et identifiants, appliquez des rôles write-only pour l’upload, activez Object Lock/WORM, restreignez les suppressions et conservez une copie hors-ligne ou logiquement isolée. Auditez les permissions IAM pour la suppression des sauvegardes.

4) « On a restauré la mauvaise chose »

Symptômes : Restauration complétée mais les données sont plus anciennes que prévu, tables manquantes, mauvais environnement ou mauvais jeu de données client.

Cause racine : Mauvais étiquetage/métadonnées, nommage incohérent, pas de manifest, pas de runbook pour choisir les points de restauration.

Correction : Standardisez le nommage des sauvegardes et les manifests. Suivez la provenance des sauvegardes (identité source, timestamp, méthode de consistance). Créez une procédure de sélection de restauration avec étapes d’approbation pour les restaurations en production.

5) « Les sauvegardes se sont arrêtées il y a des semaines ; personne ne l’a remarqué »

Symptômes : La dernière sauvegarde réussie est ancienne. La surveillance n’a pas alerté.

Cause racine : La surveillance regarde l’exécution du job, pas le succès end-to-end. Les alertes sont routées vers des canaux morts. L’on-call n’est pas pagé pour les échecs de sauvegarde.

Correction : Alertez sur le « temps depuis le dernier point de restauration vérifié ». Ajoutez des métriques de fraîcheur du référentiel. Pagez l’équipe responsable de la récupération.

6) « On a des snapshots, donc on est bon »

Symptômes : Déclarations confiantes jusqu’à ce que le disque/la baie/le compte meure ; puis il n’existe plus de copie hors hôte.

Cause racine : Confusion entre outils de disponibilité (RAID, snapshots) et indépendance des sauvegardes.

Correction : Répliquez les snapshots vers un autre système/compte/région. Ajoutez une rétention immuable. Documentez quelles pannes les snapshots couvrent et lesquelles non.

7) « La rétention a élagué notre seul bon point de restauration »

Symptômes : Vous avez besoin de restaurer plus ancien que la fenêtre de rétention (par ex. temps de détection d’un ransomware), mais c’est parti.

Cause racine : Rétention basée sur le coût, pas sur le temps de détection et le risque business. Règles de cycle de vie trop agressives.

Correction : Définissez la rétention avec les inputs sécurité et juridique. Gardez des points « mensuels » ou « trimestriels » plus longs. Utilisez un stockage immuable pour un sous-ensemble de sauvegardes.

Listes de contrôle / plan étape par étape

Étape par étape : passer de « on pense » à « on peut restaurer » en 10 étapes

1. Définissez RPO et RTO par système. Pas « l’entreprise ». La base de paie et le wiki marketing ne méritent pas la même ingénierie.
2. Classez les données par méthode de récupération. Restauration d’image VM, restauration fichier, PITR base de données, rollback de version d’objet, etc.
3. Cartographiez les domaines de défaillance. Identifiez ce qui peut échouer ensemble : compte, région, baie, identifiants, serveur de backup, clés KMS.
4. Implémentez au moins une copie indépendante. Compte/tenant séparé avec permissions restreintes. Préférez l’immutabilité pour les scénarios ransomware.
5. Rendez les sauvegardes cohérentes. Snapshots applicatif-aware, archivage WAL, filesystem freeze, ou outils natifs DB.
6. Rédigez le runbook de restauration. Incluez prérequis, clés, étapes d’accès, commandes et comment valider le succès. Traitez-le comme une fonctionnalité de production.
7. Automatisez la vérification. Au minimum : vérification checksum + restauration sur scratch mensuelle. Mieux : petits tests de restauration continus.
8. Surveillez le « temps depuis le dernier point de restauration vérifié ». Pas « job réussi ». Alertez l’on-call.
9. Réalisez un exercice DR trimestriel. Choisissez un système critique. Restaurez-le sous chronomètre et documentez ce qui a cassé.
10. Revue et renforcement des permissions. Séparez les responsabilités : les admins prod ne doivent pas pouvoir supprimer les sauvegardes immuables à la légère.

Checklist opérationnelle : avant d’approuver un design de sauvegarde

• Les identifiants de production peuvent-ils supprimer les sauvegardes ? Si oui, corrigez d’abord.
• Existe-t-il un niveau de rétention immuable pour les systèmes critiques ? Si non, ajoutez-en un.
• La restauration est-elle testée sur la plateforme/version actuelle ? Si non, planifiez un exercice.
• Le design respecte-t-il RPO/RTO dans des tests mesurés, pas dans des estimations ?
• Les clés de chiffrement sont-elles récupérables en conditions d’incident (SSO down, on-call avec accès limité) ?
• La surveillance se base-t-elle sur des points de restauration vérifiés et la vérification, pas sur la fin de job ?
• La rétention couvre-t-elle les délais de détection (sécurité) et les obligations légales ?
• Le runbook est-il rédigé de sorte qu’un ingénieur compétent mais non familier avec le système puisse l’exécuter ?

Checklist d’exercice de restauration : à quoi ressemble « fini »

• Restauration complétée dans un environnement isolé sans toucher la production.
• Intégrité validée (checksums, comptages de lignes, checks applicatifs).
• Temps de récupération mesuré et comparé au RTO.
• Point de récupération mesuré et comparé au RPO.
• Problèmes consignés en tâches avec propriétaires et dates.
• Runbook mis à jour immédiatement en fonction des surprises rencontrées.

FAQ

1) Les snapshots sont-ils des sauvegardes ?

Parfois. Si les snapshots sont répliqués vers un système indépendant et protégés contre la suppression, ils peuvent faire partie d’une stratégie de sauvegarde. Les snapshots locaux seulement sont un bouton d’annulation rapide, pas une reprise après sinistre.

2) RAID est-ce une sauvegarde ?

Non. RAID gère certaines pannes de disque sans interruption. Il n’aidera pas si des données sont supprimées, chiffrées, corrompues par un logiciel ou si toute la baie est perdue.

3) Quelle est la stratégie de sauvegarde minimale viable pour une petite équipe ?

Commencez par : (1) sauvegardes automatisées quotidiennes, (2) une copie hors-hôte dans un compte séparé, (3) exercice de restauration mensuel vers un environnement scratch, (4) alerting sur sauvegardes manquées. Ajoutez l’immutabilité si le ransomware est dans le périmètre (il l’est).

4) À quelle fréquence devons-nous tester les restaurations ?

Pour les systèmes critiques : au moins des exercices complets trimestriels, plus des vérifications automatisées plus petites fréquemment (hebdomadaires ou quotidiennes). Le bon rythme est celui qui attrape la dérive avant qu’un incident ne le fasse.

5) Quelle fenêtre de rétention est « suffisante » ?

Ça dépend du temps de détection et des obligations légales. Beaucoup d’incidents ransomware impliquent des durées de présence de l’attaquant de plusieurs jours à semaines. Si vous ne gardez que 7 jours, vous misez votre entreprise sur une détection parfaite. C’est un mauvais pari.

6) Peut-on se fier aux sauvegardes du fournisseur cloud ?

Les sauvegardes fournisseurs peuvent être excellentes, mais vous devez quand même valider les workflows de restauration, comprendre les contraintes et considérer l’indépendance. Une seconde copie sous votre contrôle (compte séparé, identifiants différents) est souvent justifiée pour les données critiques.

7) Les sauvegardes doivent-elles être chiffrées ?

Oui — généralement. Chiffrez en transit et au repos. Mais le chiffrement sans gestion des clés récupérable est de l’auto-sabotage. Traitez les clés comme partie intégrante du plan de restauration : accès contrôlé, audité et testable lors des exercices.

8) Que devons-nous surveiller : les jobs de sauvegarde ou les données de sauvegarde ?

Surveillez l’existence d’un point de restauration vérifié récent. Un job peut réussir tout en produisant une sortie inutilisable. Suivez l’« âge du dernier point de restauration vérifié », la capacité du référentiel et les résultats des tests de restauration.

9) Comment contrôler les coûts sans augmenter le risque ?

Mettez vos sauvegardes en niveaux : conservez les points récents dans une couche rapide, les anciens en couche moins chère. Utilisez la compression judicieusement. Soyez prudent avec la dédup agressive et les longues chaînes incrémentales sauf si vous avez de solides contrôles d’intégrité et des tests de restauration.

10) Qui doit posséder les sauvegardes et les restaurations ?

La propriété doit être explicite. Les équipes d’infrastructure peuvent posséder la plateforme, mais les équipes applicatives doivent posséder la justesse de la récupération (l’application fonctionne-t-elle après restauration ?). Un runbook partagé et des exercices conjoints évitent le jeu de la faute.

Conclusion : prochaines étapes réalisables cette semaine

Si vous êtes actuellement dans la phase « on devrait vraiment faire des sauvegardes », félicitations : vous avez identifié le problème tant que vous avez encore des choix. L’objectif n’est pas de construire le système de sauvegarde le plus sophistiqué. L’objectif est de rendre la perte de données un événement borné, pas une crise existentielle.

Actions pratiques qui font avancer :

1. Choisissez un système critique et définissez RPO/RTO avec le métier. Écrivez-les. Faites-en la responsabilité de quelqu’un.
2. Exécutez un exercice de restauration vers un environnement scratch. Chronométrez. Documentez chaque surprise. Corrigez une surprise.
3. Séparez les domaines de défaillance : assurez-vous qu’au moins une copie est hors-hôte et non supprimable par les identifiants de production quotidiens.
4. Activez l’immutabilité pour les sauvegardes qui seraient critiques en cas de ransomware.
5. Changez la surveillance de « job réussi » à « âge du dernier point de restauration vérifié ». Pagez en cas de dérive.

Les systèmes échouent. Les gens font des erreurs. Les attaquants existent. La seule réponse adulte est de concevoir pour la récupération et de la prouver par des exercices. Tout le reste est de la narration.