L’évolutivité de la sauvegarde désigne la capacité à maintenir les performances de sauvegarde et de restauration à mesure que les données, les charges de travail et les exigences de conservation augmentent.
Une plateforme de sauvegarde qui fonctionne bien pour 100 téraoctets (To) peut se comporter très différemment à 1 pétaoctet (Po).
À mesure que les environnements de sauvegarde se développent, des problèmes d’évolutivité peuvent apparaître. Ces problèmes incluent notamment des fenêtres de sauvegarde s’étendant sur des horaires de travail plus longs, des recherches de restauration plus longues et une charge administrative accrue.
L’évolutivité doit être évaluée à l’échelle de l’ensemble de l’architecture de sauvegarde et de restauration, et non pas uniquement en se basant sur la capacité de stockage. À mesure que votre environnement de données s’étend, le système devra prendre en charge des volumes de données plus importants, davantage de charges de travail, des périodes de conservation plus longues et des demandes de restauration plus lourdes, sans pour autant engendrer de coûts excessifs, de complexité ou de risques opérationnels. Il doit également continuer à respecter les objectifs de point de restauration (RPO) et les objectifs de délai de restauration (RTO) de l’entreprise.
Que signifie l’évolutivité dans un environnement de sauvegarde ?
L’évolutivité de la sauvegarde désigne la capacité d’un environnement de sauvegarde à protéger et à restaurer des quantités croissantes de données et de charges de travail tout en continuant à respecter les exigences définies en matière de performances, de coûts, de sécurité, de RPO et de RTO.
Les environnements de sauvegarde ne se développent pas selon un seul schéma. Le volume de données peut augmenter, mais il en va de même pour le nombre de fichiers, de charges de travail, d’emplacements et d’exigences de conservation. Chacun de ces éléments exerce une pression sur une partie différente de l’infrastructure de sauvegarde.
- Plus de données : un plus grand nombre de serveurs, de bases de données, d’applications et d’utilisateurs augmente la capacité à protéger.
- Plus de fichiers et d’objets : des milliards de fichiers peuvent exercer une pression considérable sur les catalogues de sauvegarde et les systèmes de métadonnées.
- Des taux de modification plus élevés : davantage de données modifiées chaque jour signifie qu’il faut sauvegarder plus d’informations dans le même créneau horaire.
- Plus de charges de travail : les machines virtuelles, les bases de données, les conteneurs, les applications SaaS (Software as a Service) et les comptes cloud imposent tous des exigences de protection différentes.
- Une conservation plus longue : les exigences réglementaires et les politiques d’entreprise peuvent imposer la conservation des données de sauvegarde pendant des mois, voire des années.
Pourquoi la capacité de sauvegarde et l’évolutivité de la sauvegarde ne sont pas synonymes
La capacité de sauvegarde correspond à la quantité de données qu’un système peut stocker et conserver. « La croissance de l’infrastructure de sauvegarde fait référence à la capacité de l’ensemble de l’environnement de protection des données à gérer des charges de travail croissantes tout en maintenant les objectifs de performances, de fiabilité, de sécurité et de restauration.
À mesure que l’environnement de sauvegarde se développe, la capacité de stockage n’est qu’un facteur parmi d’autres. Du point de vue des performances opérationnelles, des volumes de données plus importants peuvent accroître les exigences en matière de débit de sauvegarde, le traitement des métadonnées et des catalogues, le trafic de réplication et les coûts de conservation. Si ces composants ne s’adaptent pas à l’évolution du stockage, les opérations de sauvegarde courantes peuvent devenir plus lentes et plus coûteuses.
Implications de la croissance sur la restauration. Plus vous disposez de données, plus la restauration peut prendre du temps, en particulier si vous devez restaurer plusieurs systèmes simultanément. Même lorsque les tâches de sauvegarde sont menées à bien, une entreprise peut avoir des difficultés à respecter son RTO si elle ne dispose pas d’un débit de restauration et d’une capacité de récupération suffisants.
Une architecture de sauvegarde évolutive doit donc s’adapter à la croissance dans plusieurs domaines interconnectés :
- Les composants qui transfèrent et stockent les données de sauvegarde
- Les composants de catalogue et d’indexation utilisés pour localiser les points de restauration
- Les composants qui gèrent les politiques, la planification, la surveillance et les ressources
- Plan de reprise
Les performances de sauvegarde à grande échelle doivent être évaluées au regard des besoins de protection continus ainsi que des besoins de reprise. Une architecture évolutive doit être capable de maintenir les RPO et RTO définis à mesure que le volume de données, le nombre de charges de travail, la durée de conservation, la répartition géographique et la demande de reprise simultanée augmentent.
Quels goulots d’étranglement apparaissent en premier lorsque les environnements de sauvegarde se développent ?
Les premiers goulots d’étranglement liés à l’évolutivité de la sauvegarde apparaissent généralement au niveau des fenêtres de sauvegarde, du débit réseau, des services de métadonnées, de la réplication, des performances du référentiel ou de l’infrastructure de restauration. Le premier à apparaître dépend des caractéristiques des charges de travail et de l’architecture.
Les fenêtres de sauvegarde entrent en conflit avec l’activité de production
À mesure que la quantité de données modifiées chaque jour augmente, les tâches de sauvegarde peuvent occuper une part plus importante de la fenêtre de sauvegarde disponible. Les sauvegardes planifiées peuvent finir par empiéter sur les heures de travail ou déborder sur le cycle de protection suivant.
La croissance du catalogue et des métadonnées ralentit la restauration
À mesure que les systèmes, les points de restauration, les fichiers et les objets se multiplient, le catalogue de sauvegarde devient un composant de plus en plus important de l’architecture.
Le catalogue doit prendre en charge les mises à jour continues, ainsi que les opérations de recherche, de navigation, de création de rapports et de restauration. Si vous avez des durées de conservation longues et de nombreux objets, une infrastructure de métadonnées mal conçue peut rendre difficile la recherche rapide du bon point de restauration.
Les charges de travail composées de petits fichiers génèrent une surcharge disproportionnée
Le nombre et la taille des fichiers peuvent avoir un impact significatif sur les performances de sauvegarde. Un seul fichier de base de données volumineux et des millions de petits fichiers peuvent occuper le même espace de stockage, mais les charges de travail composées de petits fichiers génèrent généralement une surcharge de traitement bien plus importante. L’énumération des fichiers, la collecte des métadonnées, les vérifications des autorisations, l’indexation et la recréation des fichiers peuvent toutes allonger les durées de sauvegarde et de restauration.
Les tests de performances doivent donc refléter les caractéristiques réelles de la charge de travail plutôt que le seul volume de données.
Les choix d’architecture peuvent également devoir tenir compte de la densité des petits fichiers. En fonction de l’environnement, les entreprises peuvent envisager des stratégies telles que les instantanés du système de fichiers, les sauvegardes au niveau de l’image, le stockage objet ou le regroupement et l’archivage de vastes collections de petits fichiers avant leur protection.
Les charges de travail composées de petits fichiers surchargent les opérations liées aux métadonnées
Les architectures de sauvegarde modernes conservent généralement plusieurs copies des données protégées à des fins de résilience et de restauration. Chaque copie supplémentaire a une incidence sur la planification de la capacité, et les données de sauvegarde qui ne peuvent être ni modifiées ni supprimées pendant une période de conservation spécifiée peuvent amplifier cet impact, car les données protégées ne peuvent pas être supprimées avant l’expiration de leur période de conservation.
La planification de la croissance doit tenir compte des copies primaires et secondaires, de la réplication, de la conservation immuable, des conservations légales pouvant empêcher les données de sauvegarde d’expirer selon leur cycle de vie normal, des métadonnées, de l’espace de restauration temporaire et d’autres surcoûts liés à l’exploitation de l’environnement.
Le débit de restauration bénéficie d’un investissement moindre que celui de l’acquisition
L’acquisition des sauvegardes fait l’objet d’une attention constante, car les tâches de sauvegarde s’exécutent régulièrement. La restauration à grande échelle est testée moins fréquemment, ce qui signifie que les limitations de restauration peuvent passer inaperçues jusqu’à ce qu’elles deviennent critiques.
Les performances de restauration peuvent être affectées par la vitesse de lecture du référentiel, la fragmentation des sauvegardes, la déduplication et la reconstruction des données dédupliquées lors des processus de restauration, la capacité du réseau, la récupération et le trafic sortant vers le cloud, l’analyse antivirus et les performances de la destination de restauration.
Quels indicateurs permettent de détecter précocement les problèmes d’évolutivité ?
L’utilisation de la capacité ne donne qu’une vision partielle de la situation. La surveillance doit donc couvrir l’ensemble du service de protection et de restauration. Parmi les indicateurs utiles figurent notamment l’utilisation de la fenêtre de sauvegarde, le délai d’attente en file d’attente, le débit de sauvegarde et de restauration, le temps de réponse du catalogue, le décalage de réplication et la couverture du RPO.
Architecture de sauvegarde « scale-up » ou « scale-out »
Le « scale-up » consiste à étendre un système de sauvegarde existant en y ajoutant davantage de ressources. Le « scale-out » augmente la capacité en ajoutant des systèmes ou des nœuds et en répartissant les charges de travail entre eux.
Le « scale-up » ajoute des processeurs, de la mémoire, du stockage ou d’autres ressources à un système existant. Cette approche est généralement simple à mettre en œuvre, mais l’architecture reste soumise à la capacité maximale de ce système.
L’extension horizontale (scale-out) ajoute des nœuds, des nœuds de travail, des unités de stockage ou d’autres services. Cette méthode peut offrir une croissance plus progressive et permettre potentiellement de répartir les charges de travail sur plusieurs systèmes, mais elle implique également davantage de coordination et de besoins opérationnels.
Un processus étape par étape pour concevoir une solution de sauvegarde évolutive
Une architecture de sauvegarde évolutive doit d’abord tenir compte de la croissance prévue de l’environnement plutôt que de l’infrastructure actuelle seule.
1. Modélisez la croissance par charge de travail plutôt que d’utiliser un pourcentage annuel unique
Suivez la capacité protégée, le taux de variation quotidien, le nombre d’objets, le volume des tâches, la durée de conservation, le nombre de copies de sauvegarde et les fenêtres de sauvegarde disponibles pour chaque grande catégorie de charge de travail.
Les bases de données, les machines virtuelles, les serveurs de fichiers, les conteneurs et les charges de travail dans le cloud ont souvent des exigences de protection très différentes. Les prévisions doivent également tenir compte des déploiements d’applications prévus, des migrations vers le cloud, des acquisitions, des changements réglementaires et de la mise hors service d’infrastructures.
2. Convertir les objectifs de restauration en exigences de débit
Les objectifs de restauration doivent déterminer les besoins mesurables en matière d’infrastructure. Définissez les exigences de restauration en fonction de la priorité des applications, car toutes les charges de travail ne se valent pas. Certaines applications critiques peuvent nécessiter des ressources de restauration hautes performances, tandis que les données moins sensibles au facteur temps peuvent utiliser des solutions de stockage et de restauration moins coûteuses.
3. Cartographier l’intégralité des chemins de données de sauvegarde et de reprise
Documentez l’intégralité du chemin des données lors de la restauration, depuis le stockage de sauvegarde vers l’environnement de production et depuis l’environnement de production vers le stockage de sauvegarde. Cela doit inclure le stockage source, les agents de sauvegarde/outils de transfert de données, les liaisons réseau, les pare-feu, les étapes de chiffrement et de déduplication, les référentiels, les cibles de réplication, les services de catalogue et les destinations de reprise. La cartographie de chaque composant permet d’identifier les points où le débit peut être limité, car l’élément le plus lent de manière soutenue peut restreindre les performances de l’ensemble du processus de sauvegarde ou de restauration.
Les scénarios de sinistre introduisent une considération supplémentaire : la contention des ressources partagées. Lors de la restauration, les services réseau, de calcul, d’identité et de stockage peuvent déjà être soumis à une charge importante ou partiellement indisponibles. La planification de la restauration doit donc évaluer si ces ressources partagées peuvent prendre en charge la restauration des sauvegardes en même temps que la remise en ligne d’autres systèmes critiques.
4. Mettre en place des groupes de ressources de sauvegarde distincts
Les organisations doivent envisager la création de domaines de sauvegarde distincts lorsque la géographie, les limites de sécurité, la contention des charges de travail ou les exigences de restauration rendent difficile l’exploitation d’un domaine partagé unique. Vous pouvez réduire la contention et limiter l’impact d’une défaillance ou d’une charge de travail exceptionnellement exigeante en utilisant des nœuds de sauvegarde, des pools de stockage, des proxys ou d’autres ressources indépendants.
REMARQUE : Cette séparation engendre également une charge administrative supplémentaire. Chaque nouveau domaine nécessite une surveillance, l’application de correctifs, la gestion des identifiants, la planification des capacités et des tests.
5. Automatiser les décisions relatives au cycle de vie et au placement
Avec l’augmentation du nombre de charges de travail protégées, la configuration manuelle devient de plus en plus difficile. Les plannings de sauvegarde, les durées de conservation, les niveaux de stockage, les exigences de réplication et les politiques d’expiration peuvent être attribués via une automatisation basée sur des politiques. La découverte automatisée peut également aider à identifier les nouveaux systèmes qui ont été déployés sans protection appropriée.
6. Renforcer la sécurité sans créer de goulot d’étranglement non mesuré
Si la sécurité est un élément essentiel de l’architecture de sauvegarde moderne, les contrôles de sécurité s’accompagnent également d’exigences supplémentaires. La planification de la capacité et des performances doit prendre en compte le chiffrement, l’immuabilité, l’authentification multifactorielle, l’analyse anti-malware et les environnements de restauration isolés.
Les organisations doivent également conserver des sauvegardes hors ligne et régulièrement testées. La CISA recommande de stocker les sauvegardes hors ligne et chiffrées, et de tester régulièrement leur disponibilité et leur intégrité afin de s’assurer qu’elles restent utilisables en cas d’incident lié à un rançongiciel ou dans tout autre scénario de restauration.
7. Tester la croissance et la restauration avant que la production n’atteigne ses limites
Les tests doivent être basés sur les besoins prévisionnels, et non pas uniquement sur les niveaux de charge de travail actuels. Les tests de charge et de restauration doivent mesurer le volume de données, la concurrence des tâches, les performances du catalogue, l’utilisation du référentiel, la réplication, les scénarios de défaillance et le débit de restauration.
Liste de contrôle de l’évolutivité de la sauvegarde
Lors de la conception de l’architecture de sauvegarde, utilisez cette liste de contrôle pour vérifier si elle peut répondre aux exigences actuelles et à la croissance future :
- Capacité protégée actuelle : la quantité totale de données actuellement sauvegardées.
- Taux de croissance : le taux annuel de croissance prévu pour les données protégées.
- Taux de variation quotidien : pourcentage ou volume de données qui change entre deux cycles de sauvegarde.
- Nombre de fichiers ou d’objets : le nombre de fichiers, d’objets ou d’enregistrements individuels que le système de sauvegarde doit traiter.
- Fenêtre de sauvegarde : la période disponible pour l’exécution des sauvegardes planifiées.
- RPO requis : la perte de données maximale tolérable, mesurée en temps.
- RTO requis : le délai maximal acceptable pour restaurer les systèmes ou les données.
- Débit de restauration : la vitesse à laquelle l’environnement de sauvegarde peut restituer les données lors d’une restauration.
- Nombre de copies dans la sauvegarde : combien de copies doivent être conservées et où ?
- Période de conservation immuable : la durée minimale pendant laquelle les copies de sauvegarde doivent être protégées contre toute modification ou suppression.
- Bande passante de réplication : le débit requis par le réseau pour transférer les données de sauvegarde entre les environnements ou les sites.
Comment prouver qu’une architecture de sauvegarde est évolutive
Effectuez des tests de charge et de restauration pour démontrer l’évolutivité de la sauvegarde et de la restauration en fonction des volumes de données prévus, de la concurrence, de la rétention, des pannes et des exigences de restauration.
Les spécifications des fournisseurs et les chiffres de débit publiés sont utiles à des fins de comparaison, mais ils ne garantissent pas les performances dans un environnement particulier. Les résultats réels dépendent de facteurs tels que le type de données et la taille des fichiers, le taux de modification, la compression et la déduplication, le chiffrement, la latence du réseau, les performances de la source, la conception du référentiel et l’infrastructure de restauration.
Une validation de principe pertinente doit donc reproduire les conditions auxquelles l’organisation s’attend à être confrontée à mesure qu’elle se développe.
Les tests doivent également inclure la restauration après une attaque par ransomware et des incidents destructeurs affectant les données. La norme NIST SP 1800-11 fournit des recommandations sur la récupération des données après des événements destructeurs, en mettant particulièrement l’accent sur la validation de l’intégrité des données et sur la garantie que les informations récupérées sont fiables et peuvent être utilisées en toute sécurité.
Pourquoi les coûts de sauvegarde augmentent-ils souvent plus vite que les données ?
Les coûts de sauvegarde peuvent augmenter plus rapidement que les données protégées. En effet, la croissance peut entraîner simultanément une augmentation du nombre de copies de stockage, de la durée de conservation, de la réplication, des licences, du trafic réseau, des opérations de récupération dans le cloud, de l’infrastructure de gestion et de la charge administrative.
Vous devez élaborer un modèle de coûts réaliste qui tienne compte d’une période de planification d’au moins trois ans et qui inclue :
- La croissance des données et les taux de modification quotidiens
- La conservation, la réplication, l’immuabilité et les conservations légales
- Les licences logicielles et l’assistance
- Les besoins en matière de stockage et de renouvellement du matériel
- Le stockage dans le cloud, les opérations, la récupération et les frais de transfert de données sortants (egress)
- Les coûts de réseau et de transfert interrégional
- L’infrastructure de catalogage et de gestion
- Les tests de restauration et les ressources de restauration temporaires
- L’administration, la surveillance, l’application des correctifs et la réponse aux incidents
- Les coûts de migration ou de sortie de la plateforme
Comment Bacula Enterprise prend en charge la sauvegarde évolutive
Bacula Enterprise se distingue comme une solution de sauvegarde et de restauration particulièrement évolutive qui apporte des réponses concrètes aux problèmes liés à l’évolutivité évoqués ici. Elle utilise une architecture modulaire, ce qui permet de déployer séparément les composants de gestion des sauvegardes, de services clients, de stockage et de catalogue en fonction des besoins de l’environnement.
La plateforme prend en charge un large éventail de catégories de charges de travail, notamment les systèmes physiques et virtuels, les bases de données, les conteneurs et les environnements cloud. Elle est donc idéale pour les organisations qui doivent protéger plusieurs types d’infrastructures dans le cadre d’une stratégie de sauvegarde unique.
En termes d’évolutivité, la conception modulaire permet de répartir le traitement des sauvegardes, le stockage et les services associés à mesure que le volume de données et les exigences en matière de charges de travail augmentent. Par conséquent, pour les organisations en forte croissance, cette architecture peut être prise en compte dans le cadre d’une évaluation plus large de la capacité de l’infrastructure de sauvegarde à évoluer au fil du temps.
L’architecture de Bacula facilite l’évolutivité verticale et horizontale de nombreuses façons. En voici quelques exemples :
Volumes de données massifs : s’adapte aussi bien aux environnements d’entreprise classiques qu’aux infrastructures HPC et d’IA de plusieurs pétaoctets.
Des milliards de fichiers : HPCAccelerator répartit les charges de travail du système de fichiers entre plusieurs nœuds de traitement simultanés, permettant ainsi une protection efficace de milliards de fichiers.
Traitement parallèle : plusieurs flux de sauvegarde et de restauration peuvent s’exécuter simultanément, ce qui augmente considérablement le débit.
Haute concurrence des tâches : prend en charge des milliers de tâches de sauvegarde simultanées dans des environnements vastes et complexes.
Architecture distribuée : les composants de sauvegarde peuvent être répartis sur plusieurs serveurs, réseaux et sites afin d’éviter de dépendre d’un seul goulot d’étranglement au niveau du traitement.
Intégration parallèle des systèmes de fichiers : des fonctionnalités dédiées à Lustre et à IBM Storage Scale/GPFS permettent de protéger efficacement des systèmes de fichiers extrêmement volumineux et hautes performances.
Sauvegardes incrémentielles efficaces : des technologies telles que Lustre Changelog et BSnapDiff identifient les données modifiées sans avoir à analyser à plusieurs reprises l’intégralité d’un système de fichiers massif.
Évolutivité du stockage : les clients peuvent étendre leur infrastructure sur des ressources de stockage sur disque, sur bande, en stockage objet et dans le cloud, sans être liés à un seul fournisseur ou à une seule technologie de stockage.
Évolutivité des charges de travail : une seule plateforme permet de protéger les serveurs physiques, les machines virtuelles, les conteneurs, les bases de données, les charges de travail cloud et les environnements HPC à mesure que l’infrastructure s’étend.
Évolutivité économique : Bacula ne facture pas en fonction du volume de données protégées ; ainsi, la croissance rapide des ensembles de données n’entraîne pas automatiquement une augmentation rapide des coûts de licence.
Ces capacités rendent Bacula évolutif tant sur le plan technique qu’économique, en particulier pour le HPC, l’IA, les parcs informatiques complexes, la recherche et les environnements de grandes entreprises.
Foire aux questions
Le stockage dans le cloud peut-il rendre un système de sauvegarde automatiquement évolutif ?
Le stockage dans le cloud peut offrir une capacité pratiquement élastique, mais il ne supprime pas les autres limitations. Les logiciels de sauvegarde, la bande passante réseau, les limites des API (interfaces de programmation d’applications), les services de métadonnées, les performances de récupération, les coûts de sortie de données et l’infrastructure de restauration peuvent tous affecter l’évolutivité. Le stockage dans le cloud doit donc être évalué dans le cadre de l’architecture complète de sauvegarde et de restauration.
Quelle capacité de réserve un référentiel de sauvegarde évolutif doit-il maintenir ?
Il n’existe pas de pourcentage universel applicable à tous les environnements. La planification de la capacité doit tenir compte de la croissance prévue des données, des taux de modification quotidiens, des durées de conservation, des copies immuables, de la réplication, des pics de charge de travail temporaires, des pannes matérielles ou de nœuds, ainsi que du temps nécessaire pour acquérir et déployer de la capacité supplémentaire.
La déduplication améliore-t-elle toujours l’évolutivité de la sauvegarde ?
Non. La déduplication peut réduire la consommation de stockage et le trafic réseau, mais son efficacité dépend du type de données protégées. Elle nécessite également des ressources de traitement et de métadonnées et peut influencer les performances de restauration selon la mise en œuvre. L’efficacité de la sauvegarde et les performances de restauration doivent toutes deux être mesurées à l’aide de charges de travail représentatives.
Quand une entreprise doit-elle diviser un environnement de sauvegarde en plusieurs domaines ?
Vous pouvez envisager de créer des domaines de sauvegarde distincts lorsqu’un environnement unique entraîne des conflits d’accès aux ressources, des problèmes de sécurité, des exigences de localisation des données ou des dépendances opérationnelles entre des charges de travail géographiquement ou organisationnellement séparées. L’objectif doit être de créer des limites utiles sans pour autant générer de silos de gestion superflus. La surveillance centralisée, la gestion des politiques et le reporting peuvent vous offrir une visibilité sur plusieurs environnements.
Un système de sauvegarde peut-il évoluer si la restauration reste manuelle ?
Seulement dans une mesure limitée. À mesure que le nombre de charges de travail protégées augmente, les tâches de restauration manuelles telles que le séquençage des applications, la gestion des identifiants, la configuration des réseaux et la validation des données restaurées peuvent devenir des goulots d’étranglement importants.
