Le secteur a massivement intensifié ses investissements en sauvegarde, deduplication et conservation après la vague de ransomware des dernières années. Cependant, lorsque se présente le « jour J », le même obstacle semble inévitable : l’entreprise possède des copies , mais ne peut pas restaurer à temps . Le RTO (temps objectif de récupération) s’allonge de plusieurs heures à plusieurs jours, entraînant une explosion de l’impact opérationnel et financier.

Dans des échanges avec plusieurs experts, un point commun émerge : les dépôts et appliances de sauvegarde sont optimisés pour ingérer et stocker de manière efficace — compression, déduplication, erasure coding —, mais pas pour desservir des centaines de restaurations simultanées avec une rehydratation intensive et des pics d’I/O. La symptomatologie est bien connue : CPU surmenée, disques à 100 %, IOPS saturés, files d’attente interminables. Le diagnostic est aussi évident : l’architecture privilégie l’écriture, non la lecture à grande échelle.

“Le jour le plus coûteux en sauvegarde, c’est celui où l’on restaure. Si vous dépendez d’un stockage optimisé pour la déduplication mais pas pour la lecture simultanée, vous avez acheté du stockage, pas la continuité d’activité”, résume David Carrero, cofondateur de Stackscale (Groupe Aire), fournisseur européen d’infrastructure cloud privée et bare-metal, spécialisé en missions critiques et disaster recovery.

Le piège du “90:1” : quand le ratio de déduplication masque le vrai coût du RTO

La déduplication de petits blocs et la compression agressive, ça marche : elles réduisent le capex, prolongent la vie des CPD et aident à respecter les politiques de conservation. Mais le problème commence lors du rehydratation. Pour reconstruire quelques téraoctets « logiques », il faut parfois des centaines de milliers de lectures dispersées. Ce modèle — aléatoire et massif — va à l’encontre de l’ingestion séquentielle des sauvegardes, multipliant les coûts en latence et IOPS. Si en plus il y a chiffrement ou compression en ligne, la CPU devient un goulet d’étranglement supplémentaire.

“Chaque point d’extrême déduplication représente une promesse en I/O pour le jour J. La métrique essentielle, ce n’est pas le ‘ratio’, mais combien de téraoctets par heure vous pouvez fournir en rehydratant avec 100, 200 ou 400 VM en parallèle”, met en garde Carrero.

La métrique oubliée : mesurer en TB/h service rendu par la restauration (Indice de Performance de Récupération)

Des experts recommandent d’établir un KPI spécifique : le Indice de Performance de Récupération (RPI), basé sur le TB/h réels que la plateforme peut fournir avec N restaurations simultanées, dans la topologie réelle de l’entreprise (pas en laboratoire). Cette valeur, et non le simple ratio de déduplication, devrait alimenter à la fois les investissements et les plans de continuité.

Un exemple : récupérer 50 TB à un débit effectif de 600 MB/s (hors rehydratation, files d’attente et latence) nécessite environ 25 heures pour le transfert, sans considérer le rescanning du hyperviseur, les démarrages massifs (boot storms), la validation des applications ou la lutte contre les malwares. Avec 100 TB, ce délai double.

“Tout programme de sauvegarde sérieux devrait publier un RPI trimestriel : TB/h fournis avec X restaurations en parallèle. Cela, et non l’économie en TB, constitue la véritable KPI de la rentabilité”, affirme le cofondateur de Stackscale.

Concevoir pour la récupération : dissocier “stockage” de “reproduction”

Les spécialistes recommandent une architecture en couches :

1) Couche chaude pour récupération instantanée
Dépôts utilisant du flash/cache ou offrant de hauts profils de lecture pour pouvoir démonter des VM directement du backup et maintenir un service « acceptable » pendant la migration vers la production. La couche froide — déduplication, objets — reste hors du chemin critique durant les premières heures.

2) Répliques / snapshots pour le 5–10 % de services critiques
Pour ceux qui ne tolèrent pas d’arrêt, utiliser snapshots de cabine, répliques synchrones/asynchrones, et là où c’est pertinent, du CDP avec un RPO très faible. C’est coûteux, mais réservé à un sous-ensemble essentiel.

3) Plan de restauration – pas une “test de VM unique”
Orchestrer 200 VM implique AD/DNS/PKI, files d’attente, licences et dépendances applicatives. Il faut un runbook versionné : ordres de lancement, réseaux temporaires, critères de vérification et responsables.

4) Concurrence et réseau dimensionnés
Utiliser des proxies de sauvegarde suffisant, appliquer une QoS pour éviter la monopolisation, et adapter la bande passante (10/25/40/100 GbE) selon la taille. Restituer en lots avec une affiliation à la couche de stockage limite la contention.

5) Sécurité : inaltérabilité et “clean room”
Copie inaltérable (WORM/Object Lock), environnement isolé pour la restauration, avec scan anti-malware avant déploiement en production. MFA et RBAC stricts pour la plateforme de sauvegarde sécurisent l’ensemble.

“Tout le défi est de pouvoir retrouver données propres en quelques heures. Et de prouver qu’on ne réinjecte pas le virus. Sans inaltérabilité ni ‘clean room’, l’une ou l’autre de ces exigences échoue”, souligne Carrero.

Les erreurs qui transforment un incident en crise

• Confondre essais : restaurer une VM de laboratoire ≠ remettre en marche 80 services avec de vraies dépendances.
• Acheter uniquement sur fiche technique : privilégier le “90:1” sans se concentrer sur TB/h de restauration simultanée.
• Sous-dimensionner réseau et proxies : des 10 GbE partagés et des proxies sans CPU ne soutiennent pas les pics.
• Oublier l’essentiel : tous les services ne pèsent pas pareil dans le business ; la priorité doit être claire.
• Restaurer en production sans nettoyage préalable : procéder directement en environnement live sans passer par un clean room.

Plan d’action en 90 jours

Jours 0–15

• Définir avec le business le minimum vital (20 % des services apportant 80 % de valeur) et établir le RTO/RPO par service.
• Mesurer le RPI initial avec 50–100 restaurations simultanées incluant AD/DNS/PKI; analyser les résultats et les leçons.

Jours 16–45

• Installer une couche chaude pour restauration instantanée.
• Étendre proxies et réseau, orchestrer les restaurations par lots.
• Préparer l’environnement clean room et le processus de vérification.

Jours 46–90

• Renforcer la bóveda inaltérable, renforcer le MFA/RBAC pour la sauvegarde.
• Automatiser les runbooks (infrastructure en tant que code pour réseaux et démarrages).
• Réaliser une nouvelle série d’essais massifs ; publier le RPI et le délai vers un “service utile” à la direction.

“Si au bout de 90 jours, vous ne montrez pas à la direction un graphique du RPI en hausse et du RTO en baisse, vous gérez toujours du storage et non la continuité d’activité”, résume l’expert.

Cinq questions pointues pour le fournisseur

1. TB/h de restauration avec 200 VM en rehydratation parallèle dans la topologie réelle du client.
2. Latency et limites des streams lors du montage des VM en instant recovery.
3. Effet réel du Object Lock et du chiffrement sur le rendement en lecture.
4. Exigences en proxies et réseau pour soutenir ces performances.
5. SLA support « jour J » hors horaires habituels.

Coût et faux économies

Une couche chaude coûte plus par TB. Mais la stopper deux jours en cas de goulot prévisible coûte aussi cher. Le vrai coût total (TCO), ce n’est pas €/TB conservé, mais €/heure d’interruption évitée. Quand une couche rapide permet de réduire d’une journée le temps d’arrêt, elle s’autofinance souvent d’elle-même.

“Le graphique de la déduplication se regarde avant l’achat. La montre du RTO se montre au comité de crise. Devine qui décide de ton avenir”, ironise Carrero.

Conclusion

Le backup n’est plus un simple projet de stockage : c’est une capacité de continuité qu’il faut mesurer en temps et service. La majorité des sinistres récents ne s’expliquent pas uniquement par l’insuffisance de copies, mais surtout par une incapacité à les servir au rythme exigé par le métier. Changer l’état d’esprit — acheter pour restaurer, mesurer le RPI, dissocier couche chaude / conservation / inaltérabilité et tester en grandeur nature la restauration massive — constitue la frontière entre une crise bien gérée et une catastrophe.