2 Le débit (le volume de données écrites ou lues par seconde) détermine votre capacité de restauration. Lors d’une reprise après ransomware, d’une extraction forensique ou d’une reprise après sinistre, le débit décide directement si la restauration respecte votre RTO et vos échéances de conformité. Un système capable de soutenir 2 Go/s plutôt que 500 Mo/s ne se contente pas de restaurer plus vite : il permet des architectures fondamentalement différentes. Pourtant, de nombreuses organisations dimensionnent leur infrastructure sans comprendre leurs besoins de débit, et créent des goulots d’étranglement aux moments critiques. Cet article explique pourquoi le débit compte, comment mesurer vos besoins et comment architecturer une infrastructure capable d’assurer la résilience à l’échelle de l’entreprise sans devenir un goulot. Pourquoi le débit compte davantage que la capacité Les discussions commencent souvent par la capacité, mais celle-ci ne dit pas si l’infrastructure peut protéger contre la perte de données. Prenons une plateforme de services financiers disposant de 100 To de données transactionnelles et soumise à un RPO de quatre heures. Les restaurations quotidiennes après ransomware ingèrent des sauvegardes qui créent plusieurs points de restauration. Avec un débit de 100 Mo/s, ingérer 100 To prend 11,5 jours, bien au-delà des objectifs de RPO. Deux options : manquer les objectifs ou investir davantage. L’export de données forensiques est un autre scénario critique. La détection d’une violation impose d’extraire des téraoctets de journaux, de bases de données et d’archives. Avec un débit de lecture de 200 Mo/s, exporter 10 To prend 13,8 heures : une détection le lundi matin signifie une arrivée des données le mardi après-midi, soit un temps précieux perdu pour l’enquête. Comprendre les performances du stockage haute densité (en anglais) permet de garantir un débit suffisant. La bascule de reprise après sinistre exige elle aussi du débit. Le data center principal est détruit ; la restauration vers le site secondaire doit respecter un RTO de quatre heures. Lire simultanément des téraoctets vers plusieurs cibles exige un débit soutenu. Avec seulement 1 Go/s agrégé, le goulot d’étranglement allonge la restauration et pèse sur la continuité d’activité. Comprendre vos besoins de débit Dimensionnez le débit de stockage en partant de la croissance des données, de la fréquence des sauvegardes et du RTO. Calculez l’ingestion de pointe : 500 Go de données quotidiennes avec une fenêtre de 8 heures exigent au minimum 17,36 Mo/s. En pratique, prévoyez 2 à 3 fois plus pour absorber les variations et la croissance. Les organisations sous-estiment les taux de croissance. Avec 20 à 30 % par an, 100 To deviennent 150 To en deux ans. Un dimensionnement sans marge impose une mise à niveau au bout de 18 à 24 mois, coûteuse et risquée : performances dégradées et RPO qui dérapent. Tenez compte des exigences de restauration. Un entrepôt de 50 To avec un RTO de 4 heures exige au minimum 3,47 Mo/s. En réalité, les lectures parallèles, les métadonnées et la vérification imposent au moins 10 fois plus, soit 35 Mo/s. La réplication multisite complique le calcul. L’ingestion sur le site principal et la réplication vers le site secondaire créent une demande de débit simultanée : 100 Mo/s d’ingestion deviennent 200 Mo/s au total. La déduplication et la compression ajoutent des nuances. La déduplication réduit le volume utile (200 Mo/s avant deviennent 50 Mo/s après), mais consomme du CPU et de la mémoire, au point de pouvoir devenir elle-même un goulot d’étranglement. Comprendre l’architecture de cible de sauvegarde évolutive (en anglais) et les performances du stockage (en anglais) aide à identifier ces goulots. Mesurer le débit en production Les chiffres théoriques aident à planifier, mais c’est le débit en production qui compte. Les organisations découvrent souvent un débit soutenu inférieur à celui des benchmarks, en raison de la saturation du réseau, de la contention, des limites thermiques ou de schémas d’accès inefficaces. Mesurez le débit réel en instrumentant les sauvegardes et les restaurations, et en enregistrant volumes et durées. Pendant une sauvegarde complète, relevez le débit soutenu maximal, et non la moyenne : c’est lui qui compte, car le RTO et le RPO dépendent d’un débit élevé et soutenu pendant les fenêtres. Lors des tests de restauration (à mener régulièrement), mesurez la vitesse de restauration pour différents volumes. La restauration de 10 To doit s’achever de manière prévisible, et celle de 100 To évoluer de façon linéaire. Si la montée en charge ne suit pas, vous avez trouvé un goulot d’étranglement. Le réseau limite souvent le débit avant le stockage. Une liaison à 10 Gb/s n’offre que 1,25 Go/s en théorie, et 70 à 80 % de cette valeur en pratique en raison des surcoûts protocolaires. Les opérations à grande échelle s’appuient de plus en plus sur des connexions directes à 25 voire 100 Gb/s pour supprimer ce goulot. Architecturer un débit à la mesure de la résilience Les opérations à l’échelle de l’entreprise imposent de repenser l’architecture. Les systèmes monolithiques dotés de contrôleurs centralisés deviennent des goulots d’étranglement. Un SAN traditionnel soutient 5 à 10 Go/s au total ; avec 20 clients, chacun obtient 250 à 500 Mo/s. Cela suffit pour des flux individuels, mais pose problème pour de grosses restaurations en parallèle. L’architecture scale-out supprime ces goulots. Chaque nœud apporte ses connexions réseau et sa bande passante, si bien que le débit agrégé évolue de façon linéaire : un cluster de 10 nœuds soutient 50 Go/s, un cluster de 20 nœuds 100 Go/s. Les restaurations parallèles se terminent plus vite grâce à des chemins dédiés. Le stockage objet diffère du stockage en mode bloc. Les API HTTP ou S3 impliquent une latence plus élevée par opération, mais se parallélisent sur de nombreuses connexions. Au lieu d’un flux unique à 10 Go/s, on établit 100 connexions simultanées à 100 Mo/s pour atteindre 10 Go/s. C’est pourquoi les plateformes modernes prennent en charge les envois S3 parallèles : la concurrence fait toute la différence. Évaluez la déduplication et la compression au regard du débit, et pas seulement de la capacité. Le traitement en ligne ralentit l’ingestion ; le traitement a posteriori permet d’écrire au débit maximal avec une déduplication asynchrone. Pour les fenêtres où le temps est critique, le traitement a posteriori est souvent préférable, malgré une hausse temporaire de la capacité utilisée. Débit et conformité Le débit de sauvegarde a des implications directes en matière de conformité. Si vos exigences de RTO et de RPO découlent de cadres réglementaires (DORA pour la finance, HIPAA pour la santé, NIST pour le secteur public), vous devez prouver que votre infrastructure atteint ces objectifs. Une documentation théorique ne suffit pas : il faut des preuves issues de tests en production. Lors des exercices de reprise après sinistre, mesurez le temps de restauration réel pour des volumes réalistes. Un RTO de quatre heures implique de tester la restauration de vos plus gros jeux de données et de vérifier qu’elle s’achève dans les délais. Si ce n’est pas le cas, l’écart constitue un risque de conformité qui impose une mise à niveau ou un ajustement du RTO. Beaucoup d’organisations découvrent lors des tests que les RTO annoncés sont inatteignables ; mieux vaut l’apprendre pendant un exercice que pendant un sinistre. Conclusion : le débit, un indicateur de résilience Le débit n’est pas un luxe de performance : c’est une contrainte fondamentale pour protéger les données et se remettre d’une catastrophe. Dimensionnez votre infrastructure en fonction d’un débit réaliste, et pas seulement de la capacité. Testez régulièrement pour vérifier que la production atteint les objectifs. Traitez les goulots d’étranglement avec la même urgence que la disponibilité, car en situation de crise, ils sont la disponibilité. Tout investissement d’infrastructure devrait commencer par la question du débit : quels sont vos taux de croissance réels et vos exigences de restauration ? Quel débit permet de tenir vos objectifs de RTO et de RPO ? Votre infrastructure actuelle peut-elle le fournir ? Sinon, quelles mises à niveau, et à quelle échéance ? Y répondre tôt évite de découvrir des lacunes en pleine restauration, alors qu’une architecture de reprise après ransomware (en anglais) exige des performances maximales. Pour aller plus loin Reprise après ransomware : des restaurations plus rapides avec le stockage objet (en anglais) Architecture de cible de sauvegarde évolutive (en anglais) RTO ou RPO : les principales différences (en anglais) L’architecture de stockage scale-out : transformer la sauvegarde (en anglais) Stratégie de sauvegarde d’entreprise (en anglais) Survivre à une panne de data center : planifier la résilience (en anglais)
