Clone vs Image vs Sauvegarde : laquelle restaure le plus vite en cas de sinistre ?

Clones, images, sauvegardes : les définitions qui comptent réellement

Snapshot (le primitif sur lequel tout repose)

Un snapshot est une vue ponctuelle des données, généralement implémentée avec des métadonnées copy‑on‑write (CoW). Le snapshot lui‑même est souvent « peu coûteux » à créer parce que vous congelez principalement des métadonnées et redirigez les écritures futures ailleurs.

Les snapshots ne sont pas des sauvegardes. Les snapshots sont typiquement :

• Sur le même système de stockage (même domaine de défaillance sauf si répliqué).
• Rapides à créer mais peuvent devenir coûteux si vous en conservez trop indéfiniment.
• Pas toujours portables entre plateformes sans export/transfert.

Clone (l’enfant écrivable d’un snapshot)

Un clone est une copie écrivable qui partage des blocs avec son snapshot parent tant qu’ils ne sont pas modifiés. Du point de vue de la vitesse de restauration, un clone est souvent la chose la plus proche de la triche qu’on vous autorisera en production.

Mais les clones ne font pas de magie :

• Iels dépendent de l’existence et de l’accessibilité du snapshot parent.
• Iels peuvent contraindre vos opérations (vous ne pourrez peut‑être pas supprimer le parent sans gérer les dépendances).
• Les performances peuvent souffrir en cas d’écriture intensive si les métadonnées CoW sont sollicitées ou fragmentées.

Image (un artefact empaqueté que vous déployez)

Le terme « image » est surchargé. Dans la réalité, il signifie généralement une des options suivantes :

• Image de disque VM (qcow2, raw, VMDK) stockée quelque part et attachée à une VM.
• Image/gabarit golden utilisée pour démarrer des instances rapidement (OS + configuration de base).
• Image de conteneur (OCI) utilisée pour démarrer des pods (généralement sans contenir de données stateful).

Les images restaurent rapidement quand :

• Elles sont déjà dans la région/cluster cible.
• Elles sont thin‑provisioned et prennent en charge la récupération paresseuse.
• Votre plan de contrôle ne s’effondre pas.

Les images restaurent lentement quand vous devez copier de gros blobs sur des liens saturés ou les reconstruire depuis une chaîne de deltas sous pression.

Sauvegarde (une copie séparée et durable destinée à la perte)

Une sauvegarde est des données stockées séparément pour pouvoir récupérer après suppression, corruption, ransomware, ou « quelqu’un a lancé le mauvais terraform apply ». Les sauvegardes peuvent être complètes, incrémentales, ou basées sur des journaux. Elles peuvent être au niveau fichier, volume, natives à la base de données, ou conscientes de l’application.

Les sauvegardes sont la dernière ligne de défense, et la moins flatteuse. Elles doivent fonctionner quand tout le reste a échoué. C’est pourquoi elles sont généralement les plus lentes à restaurer — parce qu’elles sont conçues pour survivre à des domaines de défaillance et des timelines longues, pas pour fournir une gratification instantanée.

Traduction opérationnelle : les clones et snapshots visent la vitesse à l’intérieur d’un système de stockage ; les images visent le déploiement reproductible ; les sauvegardes visent la survie face à la catastrophe et au comportement humain.

Qu’est‑ce qui restaure le plus vite (et quand)

La réponse courte et opiniâtre

• Le plus rapide : clone local depuis un snapshot sur un stockage sain, sans transfert de données.
• Deuxième : image pré‑stagée (ou snapshot répliqué promu en région) où « restaurer » revient surtout à « attacher et démarrer ».
• Le plus lent (mais le plus robuste) : restauration depuis sauvegarde, surtout cross‑region, chiffrée et avec une chaîne incrémentale.

Quand on parle de « restauration », ce sont souvent trois problèmes différents

Quand quelqu’un demande « laquelle restaure le plus vite », clarifiez quelle horloge il mesure :

• Time to first byte (TTFB) : l’application peut‑elle démarrer et répondre aux requêtes, même si les caches se réchauffent ?
• Temps vers un état cohérent : les données sont‑elles correctes, pas seulement présentes ?
• Temps vers performance complète : respecte‑t‑elle les SLOs, ou fonctionne‑t‑elle au ralenti sur un stockage froid ?

Un clone peut gagner le TTFB, puis perdre la course de la « performance complète » s’il déclenche un énorme churn CoW ou force une réhydratation en arrière‑plan.

Quand les clones gagnent

Les clones gagnent quand le sinistre est « logique » et non « physique » : mauvais déploiement, suppression accidentelle, mauvaise migration de schéma, corruption détectée rapidement. Si votre système de stockage est intact, vous pouvez souvent :

• Cloner le snapshot d’hier.
• Pointer l’application dessus.
• Exécuter une requête de vérification.
• Passer à autre chose.

C’est ainsi que vous obtenez des restaurations en minutes plutôt qu’en heures. C’est aussi comme on se retrouve à restaurer une base de données sans rejouer les logs et à passer la matinée à expliquer les « écritures perdues ». Choisissez judicieusement.

Quand les images gagnent

Les images gagnent quand l’état est ailleurs (DB gérée, stockage répliqué, object store) et que votre besoin principal est de remettre le calcul en ligne rapidement et de manière cohérente. Une image golden pré‑bâtie plus de l’infrastructure‑as‑code peut être une fusée.

Mais les images ne sont pas une récupération d’état. Elles sont une récupération d’environnement d’exécution. Si votre base de données est morte, un AMI parfait et un sourire assuré ne la ressusciteront pas.

Quand les sauvegardes gagnent (en ne perdant pas)

Les sauvegardes gagnent quand :

• Le système de stockage a échoué (bug de contrôleur, perte d’array, firmware défectueux, compromission de compte cloud).
• Les snapshots ont été supprimés/chiffrés par un attaquant.
• La réplication a fidèlement répliqué la corruption (félicitations, vous avez construit un système de distribution de corruption).
• La conformité exige une rétention au‑delà de ce que les snapshots peuvent raisonnablement fournir.

Les sauvegardes sont généralement plus lentes parce qu’elles sont distantes, compressées, chiffrées, chunkées, dédupliquées et stockées sur des médias moins chers. Toutes de bonnes idées — jusqu’au moment où vous devez restaurer à grande échelle rapidement. Alors elles représentent la facture que vous payez pour être responsable.

Une règle heuristique direct que vous pouvez utiliser en réunion

Si votre RTO se mesure en minutes, vous voulez snapshots + réplication + un plan de promotion bascule. Si votre RTO est en heures et que votre modèle de menaces inclut ransomware et erreur opérateur, vous voulez sauvegardes immuables + tests de restauration périodiques. La plupart des organisations ont besoin des deux, car le monde n’est pas poli au point de ne tomber que d’une seule manière.

Blague #1 : Les sauvegardes sont comme les abonnements à la salle de sport — tout le monde se sent plus en sécurité en les payant, et presque personne ne les teste jusqu’à ce que ce soit embarrassant.

La vitesse de restauration, c’est des goulots d’étranglement : les maths désagréables

Le pipeline de restauration que vous exécutez réellement

Que vous cloniez, utilisiez une image ou restauriez une sauvegarde, votre « restauration » est un pipeline :

1. Actions plan de contrôle : créer un volume, attacher, définir des ACL, publier des endpoints.
2. Actions plan des données : copier des blocs, hydrater des chunks, rejouer des logs, reconstruire des index.
3. Actions plan applicatif : migrations, réchauffement de cache, compactage en arrière‑plan.
4. Actions plan humain : approbations, « est‑ce le bon snapshot ? », archéologie Slack.

Votre restauration est aussi rapide que l’étape la plus lente que vous ne pouvez pas paralléliser.

Goulots clés par méthode

Clones

• Pression sur les métadonnées : cloner est bon marché ; gérer des milliers de snapshots/clones peut ne pas l’être.
• Amplification d’écriture CoW : fortes écritures sur des clones peuvent fragmenter et dégrader la latence.
• Chaînes de dépendance : vous ne pouvez pas supprimer les parents ; vous ne pouvez pas vous déplacer librement ; vous terminez avec de « l’archéologie de snapshots ».

Images

• Largeur de bande de distribution : tirer une image de plusieurs Go vers une nouvelle région en incident est une comédie, pas un plan.
• Surcharge de format : les chaînes qcow2 et les images CoW peuvent ajouter de la latence au démarrage et aux E/S.
• Limites du plan de contrôle : vous les trouverez durant la pire semaine possible.

Sauvegardes

• Débit de réhydratation : les vitesses object store→disque sont bornées par le réseau, l’API et le parallélisme.
• CPU pour décompression/chiffrement : vos nœuds de restauration peuvent être limités par le calcul.
• Parcours de chaîne incrémentale : restaurer le « dernier » point peut nécessiter une complète plus N incrémentales.
• Consistance applicative : les restaurations de BD nécessitent souvent le replay des journaux et des vérifications, pas seulement une copie de fichiers.

Mesurez la bonne chose : RTO, RPO et « time to safe »

RTO (recovery time objective) est le temps pendant lequel vous pouvez être indisponible. RPO (recovery point objective) est la quantité de données que vous pouvez perdre. Mais les systèmes de production ont un troisième métrique : le temps jusqu’à être en sécurité — le temps jusqu’à ce que vous soyez confiant de ne pas restaurer une corruption ou de ne pas réintroduire la même défaillance.

La restauration la plus rapide qui redémarre la même configuration cassée, ou restaure des données déjà corrompues, n’est qu’une course vers votre prochain incident.

Citation (idée paraphrasée) : Le message de John Allspaw sur la fiabilité : traitez la défaillance comme normale, concevez pour elle, et apprenez vite de chaque panne.

Faits intéressants et un peu d’histoire

• Fait 1 : Les techniques de type snapshot préexistent aux nuages modernes ; les arrays d’entreprise classiques utilisaient redirect‑on‑write et copy‑on‑write bien avant que « DevOps » soit un intitulé de poste.
• Fait 2 : Les sauvegardes incrémentales se sont popularisées parce que les sauvegardes complètes des systèmes de fichiers en croissance ne rentraient plus dans la fenêtre nocturne — les bandes ne sont pas devenues plus rapides aussi vite que les données ont grandi.
• Fait 3 : Les systèmes de fichiers CoW (comme ZFS et btrfs) ont fait des snapshots des citoyens de première classe, ce qui a changé les habitudes opérationnelles : « prendre un snapshot d’abord » est devenu un réflexe.
• Fait 4 : Les images VM étaient à l’origine optimisées pour la portabilité et la reproductibilité, pas pour une récupération rapide ; le mouvement des « golden images » a émergé quand la dérive de configuration est devenue un coût opérationnel réel.
• Fait 5 : La déduplication a rendu les sauvegardes moins chères mais parfois plus lentes à restaurer, parce que la reconstruction nécessite plus de lectures aléatoires et de recherches de métadonnées.
• Fait 6 : Les premiers plans DR supposaient souvent un datacenter secondaire avec matériel identique ; le DR cloud a remplacé la symétrie matérielle par la symétrie d’API — et de nouveaux modes de défaillance.
• Fait 7 : « Une réplique n’est pas une sauvegarde » est devenu un mantra après plusieurs incidents où la corruption ou la suppression se répliquaient instantanément sur le standby.
• Fait 8 : L’essor du ransomware a orienté les bonnes pratiques vers des stockages immuables, air‑gapped, ou de type WORM ; la planification de la récupération est devenue adversariale, pas juste accidentelle.
• Fait 9 : Les sauvegardes natives aux bases de données (dumps logiques, récupération basée sur WAL/binlog) surpassent souvent les sauvegardes génériques au niveau fichier en exactitude, même si elles perdent sur la vitesse brute.

Pratique : 12+ tâches pour prouver la vitesse de restauration (avec commandes)

Ces tâches sont écrites comme si vous étiez en astreinte : exécutez une commande, interprétez la sortie, prenez une décision. Je mélange Linux, ZFS, LVM, Ceph, Kubernetes et PostgreSQL parce que la reprise après sinistre ne respecte pas les frontières de plateforme.

Task 1: Confirm whether your “backup” is actually a snapshot on the same disk

cr0x@server:~$ zfs list -t snapshot -o name,creation,used,refer,mountpoint | head
NAME                          CREATION                 USED  REFER  MOUNTPOINT
tank/app@hourly-2026-02-04-01  Tue Feb  4 01:00 2026   128M  450G   -
tank/app@hourly-2026-02-04-02  Tue Feb  4 02:00 2026   140M  450G   -

Ce que cela signifie : Ce sont des snapshots locaux. Ils constituent un matériau de restauration rapide, pas une protection contre les catastrophes à eux seuls.

Décision : Si votre plan DR repose là‑dessus, ajoutez de la réplication ou des sauvegardes dans un domaine de défaillance séparé.

Task 2: Check snapshot dependency chains before you delete “old stuff”

cr0x@server:~$ zfs list -t all -o name,origin,used,refer,mountpoint | grep tank/app
tank/app                    -                         600G  450G   /tank/app
tank/app@hourly-2026-02-04-01 -                        128M  450G   -
tank/app-clone              tank/app@hourly-2026-02-04-01  40G  450G   /tank/app-clone

Ce que cela signifie : tank/app-clone dépend de tank/app@hourly-.... Supprimer ce snapshot peut être bloqué ou nécessiter une promotion/copie.

Décision : Ne nettoyez pas les snapshots à l’aveugle. Inventoriez d’abord les clones, puis choisissez : promouvez le clone, aplatissez‑le ou acceptez le coût de rétention.

Task 3: Estimate how “cheap” your snapshots really are

cr0x@server:~$ zfs get -o name,property,value -s local,received usedbysnapshots tank/app
NAME      PROPERTY         VALUE
tank/app  usedbysnapshots  2.8T

Ce que cela signifie : Les snapshots consomment 2,8T d’espace. Ils ne sont pas gratuits. C’est une facture différée.

Décision : Si les restaurations sont lentes parce que le pool est plein ou fragmenté, réduisez la rétention des snapshots, ajoutez de la capacité ou déplacez les anciens snapshots vers un stockage de sauvegarde.

Task 4: Time a clone creation (the “restore” you wish you always had)

cr0x@server:~$ time zfs clone tank/app@hourly-2026-02-04-02 tank/app-restore-test
real    0m0.412s
user    0m0.010s
sys     0m0.055s

Ce que cela signifie : C’est une opération sur les métadonnées. C’est pourquoi les clones sont rapides — quand vous restez sur le même système de stockage.

Décision : Si votre RTO cible est en minutes, architectez autour de chemins de restauration snapshot/clone et d’une sauvegarde séparée pour la catastrophe.

Task 5: Identify whether your “image restore” is going to pull data over the network

cr0x@server:~$ qemu-img info /var/lib/libvirt/images/app.qcow2
image: /var/lib/libvirt/images/app.qcow2
file format: qcow2
virtual size: 200G (214748364800 bytes)
disk size: 37G
cluster_size: 65536
backing file: /var/lib/libvirt/images/base.qcow2

Ce que cela signifie : Il y a une chaîne de fichiers backing. La restauration peut nécessiter que l’image de base soit présente et cohérente.

Décision : Assurez‑vous que les images de base sont répliquées et épinglées sur le site DR. Sinon, aplatissez les images avant le jour de crise.

Task 6: Validate that your backup repository can actually read data (not just list it)

cr0x@server:~$ restic -r /mnt/backup-repo snapshots --last
repository 8b7c2d8d opened (version 2, compression level auto)
ID        Time                 Host        Tags        Paths
c2c1f7a9  2026-02-04 02:05:12  app01                   /var/lib/postgresql

Ce que cela signifie : Le repo est accessible et contient des snapshots récents.

Décision : Si cette commande est lente ou génère des erreurs, votre affirmation « la sauvegarde existe » n’est pas prouvée. Corrigez l’accès au repo, les identifiants et le verrouillage avant d’en avoir besoin.

Task 7: Measure restore throughput from backup storage (your real-world ceiling)

cr0x@server:~$ pv -ptrab /mnt/backup-repo/pack/*.pack | head -c 0
  1.31GiB 0:00:02 [ 645MiB/s] [ 645MiB/s] [=================================>]  3% ETA 0:00:55

Ce que cela signifie : Vous lisez à ~645MiB/s localement. Sur un réseau, attendez‑vous à moins. Avec déchiffrement et décompression, attendez encore moins.

Décision : Utilisez ceci pour valider le RTO. Si vous devez restaurer 10To et ne pouvez soutenir que 200MiB/s bout en bout, vous ne récupérez pas en une heure. Vous récupérez pendant une réunion.

Task 8: Check Ceph RBD image and snapshot layout (clone speed vs chaos)

cr0x@server:~$ rbd info -p volumes pvc-3f1c1b2a-7d9e-4d9f-a1f0-2c1d0b4a9e1a
rbd image 'pvc-3f1c1b2a-7d9e-4d9f-a1f0-2c1d0b4a9e1a':
        size 200 GiB in 51200 objects
        order 22 (4 MiB objects)
        snapshot_count: 18
        id: 1a2b3c4d5e6f

Ce que cela signifie : Beaucoup de snapshots. Les clones RBD peuvent être rapides, mais un historique de snapshots profond peut compliquer les performances et les suppressions.

Décision : Si la restauration est lente ou que les suppressions sont bloquées, réduisez le nombre de snapshots, aplatissez les clones ou ajustez la rétention CSI.

Task 9: Check Kubernetes PVC restore path (is it a VolumeSnapshot restore or a backup restore?)

cr0x@server:~$ kubectl get volumesnapshot,volumesnapshotcontent -A | head
NAMESPACE   NAME                      READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                                    CREATIONTIME
prod        pgdata-snap-20260204      true         pgdata      snapcontent-8f2d        200Gi        csi-rbd         snapcontent-8f2d                                  2h

Ce que cela signifie : Vous avez des snapshots CSI prêts. Restaurer depuis ceux‑ci se rapproche généralement d’un comportement « clone » plutôt que « sauvegarde ».

Décision : Pour un RTO rapide dans le même cluster/stockage, préférez les restaurations VolumeSnapshot. Pour les événements de type ransomware, utilisez un outil de sauvegarde qui stocke les données hors bande.

Task 10: Confirm filesystem-level consistency before you bring traffic back

cr0x@server:~$ mount /dev/mapper/vg0-restore /mnt/restore
cr0x@server:~$ dmesg | tail -n 3
[ 9123.112233] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none.
[ 9123.112240] EXT4-fs (dm-3): re-mounted. Opts: (null)
[ 9123.112241] EXT4-fs (dm-3): recovery complete

Ce que cela signifie : Le journal a été rejoué et a terminé. C’est bon ; cela signifie aussi que vous aviez un arrêt non propre ou une consistance crash, pas une consistance applicative.

Décision : Pour les bases de données, ne vous arrêtez pas là. Continuez aux vérifications natives BD (statut de replay WAL, checksums, requêtes d’intégrité) avant de déclarer la victoire.

Task 11: PostgreSQL: verify whether you’re restoring from base backup + WAL (speed vs correctness)

cr0x@server:~$ pg_controldata /var/lib/postgresql/15/main | egrep 'Latest checkpoint|Database cluster state'
Database cluster state:               in production
Latest checkpoint location:           2A/BC0012F8
Latest checkpoint's REDO location:    2A/BC0012C0

Ce que cela signifie : Le cluster pense être suffisamment cohérent pour être « in production », mais cela ne prouve pas la validité applicative.

Décision : Exécutez des requêtes de validation ciblées (comptes de lignes, invariants métiers). Si vous avez restauré depuis des snapshots au niveau fichier, soyez particulièrement méfiant.

Task 12: Measure IO latency on the restored volume (the hidden “restore is done but app is slow” trap)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server)  02/04/2026  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    6.22   18.45    0.00   63.22

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
dm-3            220.0  28160.0     0.0   0.00   12.10   128.0     90.0   10240.0     0.0   0.00   45.80   113.8   4.92  98.7

Ce que cela signifie : %util proche de 100% et un w_await élevé signifie que le stockage est saturé. Votre « restauration » peut être terminée, mais votre système est maintenant une panne au ralenti.

Décision : Limitez les travaux en arrière‑plan, augmentez les IOPS, migrez vers un stockage plus rapide ou retardez le trafic complet jusqu’à stabilisation de la latence.

Task 13: Detect whether you’re restoring into a CPU bottleneck (decompression/encryption)

cr0x@server:~$ mpstat -P ALL 1 2 | tail -n 6
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all   78.50    0.00   12.30    1.20    0.00    1.10    0.00    0.00    0.00    6.90
Average:       0   95.10    0.00    4.20    0.20    0.00    0.10    0.00    0.00    0.00    0.40
Average:       1   96.40    0.00    2.80    0.10    0.00    0.10    0.00    0.00    0.00    0.60

Ce que cela signifie : Les CPU sont saturés. Si vous restaurez depuis des sauvegardes dédupliquées/compressées/chiffrées, le CPU peut être votre facteur limitant.

Décision : Ajoutez des cœurs, utilisez des instances plus rapides pour les workers de restauration, ou ajustez les paramètres de compression pour équilibrer coût et vitesse de restauration.

Task 14: Prove your network is not the villain (it often is)

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,8p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321098 12345678     0    1200       0       0
    TX:  bytes packets errors dropped carrier collsns
    876543210987 11223344     0       0       0       0

Ce que cela signifie : Des paquets RX perdus pendant la restauration sont un indice : vous pourriez saturer des buffers, rencontrer des problèmes NIC/driver, ou saturer un intermédiaire.

Décision : Si les pertes augmentent pendant la restauration, ajustez les files NIC, vérifiez le MTU bout en bout et limitez le parallélisme des jobs de restauration.

Playbook de diagnostic rapide : trouver le goulot en quelques minutes

Quand une restauration est « lente », le chemin le plus rapide vers la raison est d’identifier quelle couche limite le débit. Ne devinez pas. Ne discutez pas. Mesurez.

Premièrement : plan de contrôle ou plan des données ?

• Si les volumes n’apparaissent/attachent pas : vous êtes bloqué au niveau du plan de contrôle (limites API, auth, quota, controllers bloqués).
• Si les volumes s’attachent mais que la copie est lente : vous êtes au niveau du plan des données (réseau/stockage/CPU).

Deuxièmement : est‑ce le réseau, le disque ou le CPU ?

1. Vérif saturation disque : iostat -xz 1. Recherchez un %util élevé et un await élevé.
2. Vérif saturation CPU : mpstat 1 et top. Recherchez des processus de restauration consommant du CPU et un idle faible.
3. Vérif saturation réseau : ip -s link, ss -s, et (si dispo) métriques du switch/NLB. Recherchez pertes/retransmissions et atteinte du débit ligne.

Troisièmement : payez‑vous une « taxe de format » ou une « taxe de consistance » ?

• Taxe de format : chaînes qcow2, réhydratation dedup, tailles de chunks trop petites, trop d’objets.
• Taxe de consistance : replay WAL/binlog, rebuild d’index, fsck, migrations applicatives, réchauffement de cache.

Quatrièmement : votre chemin de restauration est‑il parallélisé correctement ?

Les restaurations échouent souvent en étant soit :

• Sous‑parallélisées : un seul thread lit depuis l’object storage, laissant la bande passante inutilisée.
• Surdédiées : 200 workers DDoS votre propre service de métadonnées, et tout se fige.

Cinquièmement : validez les données restaurées avant de célébrer

Montez un endpoint en lecture seule, exécutez les invariants, comparez les comptes de transactions récents et vérifiez la santé applicative. La récupération n’est pas terminée quand le service démarre. Elle est terminée quand il est correct.

Erreurs courantes : symptômes → cause racine → correctif

1) « La restauration par snapshot est instantanée », mais l’app est inutilisable

Symptômes : Le volume apparaît vite ; l’app démarre ; la latence explose ; timeouts partout.

Cause racine : Le clone est rapide, mais vous avez restauré sur un stockage saturé, ou l’amplification d’écriture CoW vous tue sous charge.

Correctif : Pré‑allouez une marge de performances pour le DR. Envisagez d’aplatir les clones pour les charges écriture‑intensives, ou de promouvoir un snapshot répliqué sur des niveaux de stockage DR dédiés.

2) « Nous avons des sauvegardes », mais la restauration prend une éternité

Symptômes : Les jobs de restauration tournent pendant des heures/jours ; le débit est bien en dessous du débit du lien.

Cause racine : La restauration est CPU‑bound (chiffrement/décompression), liée aux métadonnées (dedup), ou coincée à parcourir une longue chaîne incrémentale.

Correctif : Mesurez CPU et IO. Ajoutez des workers de restauration, augmentez la taille des chunks lorsque pertinent, planifiez des restaurations complètes synthétiques périodiques, et gardez des sauvegardes complètes occasionnelles pour limiter la profondeur des chaînes.

3) Réplica promue avec succès, mais les données sont incorrectes

Symptômes : Le service est « up », mais les métriques métier sont fausses ; enregistrements récents manquent ; clients se plaignent.

Cause racine : Vous avez basculé vers une réplique avec un lag de réplication acceptable mais inacceptable pour l’intégrité ; ou vous avez promu une corruption préexistante.

Correctif : Conditionnez la bascule sur des seuils de lag et des contrôles applicatifs. Gardez des sauvegardes immuables et une récupération point‑in‑time pour pouvoir revenir avant la corruption.

4) L’environnement DR existe, mais vous n’y accédez pas

Symptômes : Les sauvegardes sont là ; les snapshots sont répliqués ; mais les clés/roles manquent ; les montages échouent.

Cause racine : Les clés KMS, les rôles IAM ou les certificats n’ont pas été répliqués ou documentés. C’est plus fréquent que la défaillance du stockage.

Correctif : Traitez les identifiants et le matériel de clés comme des artefacts DR de première classe. Entraînez l’accès break‑glass trimestriellement, avec des process auditables.

5) « On a optimisé les coûts de stockage », et maintenant la restauration est un cauchemar

Symptômes : Les sauvegardes sont bon marché ; la restauration est lente ; tout le monde est choqué sans raison valable.

Cause racine : Tiers froid, compression agressive, dédup profonde ou stockage objet peu performant ralentissent les restaurations.

Correctif : Alignez la classe de stockage sur le RTO. Gardez une copie « hot restore » pour les systèmes critiques, même si cela offense le tableur.

6) Les snapshots ont silencieusement cessé d’être pris

Symptômes : Vous pensez avoir des snapshots horaires ; le dernier date de la semaine dernière.

Cause racine : Échecs de cron, job de rétention qui supprime trop agressivement, erreurs de snapshot dues à la pression d’espace, ou identifiants expirés pour les appels API.

Correctif : Alertez sur la fraîcheur et le nombre d’échecs de snapshots. Suivez‑les comme vous suivez la latence. L’absence de preuve n’est pas une preuve de sécurité.

Trois micro‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Iels avaient un récit propre : « Nous prenons un snapshot toutes les heures, donc notre RPO est une heure. » Ça sonnait responsable. C’était même écrit dans une politique avec un joli en‑tête.

Puis un bug applicatif a été déployé et a commencé à corrompre des enregistrements — silencieusement. La corruption n’a rien crashé. Elle a juste écrit de mauvaises valeurs. L’astreinte a vu l’incident six heures plus tard, sous la pression client, et a rollbacké vers « le dernier bon snapshot ». Le dernier bon snapshot n’existait pas. Chaque snapshot horaire avait fidèlement conservé l’état corrompu parce que le bug tournait depuis le matin.

L’équipe a ensuite tenté une bascule sur une réplique. Même problème : la réplique était un miroir, pas une machine à remonter le temps. Finalement, ils ont restauré depuis des sauvegardes, mais le rythme et la rétention des sauvegardes les ont forcés à choisir entre perdre encore des données ou restaurer un point contenant encore les effets du bug.

Le postmortem a été gênant parce que rien n’« a cassé » dans l’infrastructure. L’échec était l’hypothèse que les snapshots équivalent à la récupération. Les snapshots sont des points temporels, pas des points de vérité.

Ils ont corrigé ça en ajoutant une récupération point‑in‑time DB, en renforçant la détection (pour attraper la corruption plus tôt), et en organisant des drills de restauration périodiques où quelqu’un devait prouver qu’il pouvait revenir à un état connu‑bon.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme s’est mise à fond sur la réduction des coûts de stockage. Ils ont réglé les sauvegardes pour une dédup maximale et une compression agressive. C’était beau sur les rapports mensuels. Le CFO était ravi. Les SREs restaient prudemment silencieux, ce qui aurait dû être lu comme un signe d’alerte.

Puis un incident régional a mis hors service le cluster primaire et ils ont lancé une restauration dans un environnement propre. Les jobs de restauration ont démarré vite puis stagnaient à une fraction du débit attendu. Les CPU des workers de restauration étaient saturés, tandis que le réseau restait à moitié inactif. Le système n’attendait pas d’octets ; il attendait de transformer les octets en données.

Ils ont essayé d’augmenter le nombre de workers. Ça a aidé un peu, puis ça a empiré : les services de métadonnées sont devenus chauds, les taux de requêtes ont grimpé et les retries se sont accumulés. Le pipeline de restauration se concurrençait lui‑même. Le responsable incident regardait le timeline glisser tandis que les tableaux de bord semblaient « ok » aux mauvais endroits.

La correction a été ennuyeuse : garder une couche de sauvegarde « optimisée pour restauration » pour les jeux de données critiques, avec moins de compression agressive, une profondeur incrémentale limitée, et une capacité pré‑chauffée dans la région DR. Les coûts ont augmenté. Le temps d’incident a baissé. C’est le compromis.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre entreprise avait une habitude dont personne ne se vantait : une fois par mois, ils effectuaient une restauration complète d’un service de production dans un environnement isolé. Ils ne le faisaient pas pour le plaisir. Le responsable des opérations avait été brûlé des années auparavant et avait décidé « plus jamais ».

Le drill incluait les parties ennuyeuses : récupération des clés, montée des dépendances, replay des logs, validation des invariants métier, et mesure du temps vers la première requête et vers la performance normale. Ils notaient ce qui cassait. Ils corrigeaient une chose chaque mois. Ce n’était pas glamour.

Quand un véritable incident est arrivé — un bug d’automatisation destructeur qui a supprimé des volumes — l’équipe savait déjà quelles sauvegardes étaient les plus rapides à restaurer, quels rôles IAM étaient requis, et quels services nécessitaient une récupération point‑in‑time vs une restauration au niveau fichier. Ils n’ont pas improvisé. Ils ont exécuté.

Ils ont quand même eu du downtime. Personne ne sort indemne d’une catastrophe. Mais ils ont respecté leur RTO parce qu’ils avaient pratiqué les gestes exacts, pas seulement admiré le diagramme d’architecture.

Blague #2 : La seule chose plus optimiste que « nous restaurerons depuis les sauvegardes » est « l’incident arrivera pendant les heures de bureau ».

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

Décidez ce que vous optimisez (arrêtez d’essayer de gagner sur tous les métriques)

1. Définissez des niveaux de service : Tier 0 (l’argent s’arrête), Tier 1 (les clients remarquent), Tier 2 (douleur interne).
2. Fixez RTO/RPO par niveau : écrivez‑les ; obtenez la validation du métier.
3. Choisissez le primitif de restauration par niveau :
   • Tier 0 : snapshots répliqués avec promotion + point‑in‑time + sauvegardes immuables.
   • Tier 1 : snapshots + sauvegardes fréquentes + runbooks répétés.
   • Tier 2 : seules sauvegardes si vous tolérez le temps.

Construisez un chemin de « restauration rapide » (clones/images) sans vous mentir

1. Snapshots haute fréquence (minutes à une heure, selon le taux d’écriture et le RPO).
2. Réplication vers un domaine de défaillance séparé (cluster différent, région différente, ou au moins rayon d’impact distinct).
3. Documentez la promotion/bascule (qui clique quoi, quelle automation s’exécute, comment vérifier).
4. Pré‑stabilisez les images pour le calcul : OS de base + agents + configs qui ne changent pas chaque heure.
5. Testez sous charge : les clones peuvent restaurer instantanément et pourtant être très mauvais en performance.

Construisez un chemin « survivre à tout » (sauvegardes) et limitez la douleur de restauration

1. Utilisez du stockage immutable ou append‑only quand possible pour les sauvegardes.
2. Gardez quelques sauvegardes complètes pour limiter la longueur des chaînes incrémentales.
3. Séparez les identifiants (écriture sauvegarde vs suppression sauvegarde) pour réduire le rayon d’impact d’un ransomware.
4. Enregistrez le débit de restauration comme métrique voisine SLO : s’il chute, vous perdez silencieusement la capacité DR.
5. Entraînez la récupération des clés (KMS, vault, chaînes de certificats) dans le drill.

Exécutez des drills de restauration comme un ingénieur, pas comme du théâtre

1. Choisissez un jeu de données cible (BD, volume, ou bucket objet) et un point de restauration.
2. Chronométrez chaque phase : provision, attacher, copier/rehydrater, rejouer, valider, prêt pour cutover.
3. Documentez le goulot avec des preuves (iostat, mpstat, compteurs réseau).
4. Corrigez un goulot et recommencez le mois suivant.
5. Conservez les artefacts : logs, commandes utilisées, sorties, et les points de décision exacts.

Fiche pratique : quoi choisir quand

• Besoin d’un rollback le plus rapide dans le même stockage ? Snapshot + clone.
• Besoin de reconstruire rapidement le compute avec une config connue ? Images pré‑stagées + IaC.
• Besoin de récupération après compromission de compte/ransomware ? Sauvegardes immuables (avec restauration testée).
• Besoin de correction pour bases de données ? Sauvegardes natives BD et PITR, même si vous snapshottez aussi les volumes.

FAQ

1) Les snapshots sont‑ils des sauvegardes ?

Non. Les snapshots sont généralement dans le même domaine de défaillance. Ils sont excellents pour rollback rapide et la sécurité opérationnelle, mais ne remplacent pas des sauvegardes hors‑système.

2) Les clones restaurent‑ils toujours instantanément ?

Créer un clone est souvent instantané. Rendre le système utilisable à performance normale peut ne pas l’être — spécialement pour les charges écriture‑intensives où la surcharge CoW apparaît après le cutover.

3) Quelle est la façon la plus rapide de restaurer une base de données ?

La méthode la plus rapide et correcte est généralement native DB : sauvegarde de base plus replay de journaux (WAL/binlog) jusqu’à un point précis. Les snapshots de volumes peuvent être rapides mais risquent des problèmes de consistance crash.

4) Si je réplique des snapshots vers une autre région, ai‑je encore besoin de sauvegardes ?

Oui. La réplication protège contre la défaillance de site, pas contre la corruption, la suppression malveillante ou les identifiants compromis. Les sauvegardes immuables sont votre protection contre les scénarios adversariaux.

5) Pourquoi les sauvegardes dédupliquées sont‑elles lentes à restaurer ?

La déduplication signifie que vos données sont reconstruites à partir de chunks dispersés. La restauration devient gourmande en métadonnées et en lectures aléatoires. Génial pour le coût, parfois brutal pour le RTO.

6) Que dois‑je mesurer pour prédire le temps de restauration ?

Mesurez le débit bout‑en‑bout du stockage de sauvegarde vers le disque cible, plus l’utilisation CPU pour déchiffrement/décompression, plus le temps du plan de contrôle pour provision/attach. Puis faites un drill complet de restauration pour valider.

7) Comment éviter de restaurer le mauvais snapshot ?

Étiquetez les snapshots avec la raison et la version de l’app, appliquez des garde‑fous aux politiques de rétention, et exigez une vérification à deux personnes pour les opérations destructrices pendant les incidents.

8) Les images de conteneurs peuvent‑elles remplacer les images VM pour le DR ?

Pour les services stateless, souvent oui — les conteneurs démarrent plus vite et sont plus faciles à distribuer. Pour les services stateful, les images ne résolvent pas la récupération des données ; vous avez toujours besoin de snapshots/réplication/sauvegardes.

9) Quel est le goulot DR le plus courant que vous observez ?

Les échecs d’identifiants et de dépendances (KMS/IAM/DNS), suivis de près par un débit de restauration bien inférieur aux attentes. Les pannes de stockage sont moins fréquentes que les erreurs de planification.

Prochaines étapes pratiques

• Décidez vos services « RTO en minutes » et fournissez‑leur un chemin de restauration qui n’implique pas de tirer des téraoctets depuis un stockage froid.
• Implémentez snapshots + réplication pour une restauration rapide, mais traitez‑les comme un outil de disponibilité, pas comme votre seul filet de sécurité.
• Conservez des sauvegardes immuables dans un domaine de défaillance séparé avec des identifiants séparés, et limitez la profondeur incrémentale avec des complètes périodiques.
• Exécutez un drill de restauration ce mois‑ci. Chronométrez‑le. Sauvegardez les sorties de commandes. Corrigez un goulot. Répétez.
• Rédigez un runbook de « diagnostic rapide » avec les mesures ci‑dessus pour que la version de vous à 03:12 n’ait pas à improviser.

Si vous voulez un principe directeur : optimisez pour la restauration que vous exécuterez réellement sous stress, pas pour celle qui paraît élégante sur une diapositive.