3 Les données et les charges de travail IA des organisations sont réparties : sur site, dans plusieurs clouds et en edge. Concevoir la sauvegarde pour cette répartition exige de repenser l’infrastructure de sauvegarde. Les solutions purement sur site laissent les données cloud dépendantes des services natifs du cloud. Les solutions purement cloud créent de la gravité des données (en anglais) — un egress coûteux pour déplacer les données d’un cloud à l’autre. La sauvegarde hybride combine infrastructure sur site et infrastructure cloud pour cumuler leurs avantages. L’infrastructure sur site sert les charges sur site avec une faible latence. L’infrastructure cloud sert les charges cloud avec souplesse. Les données sont hiérarchisées entre les stockages selon l’accès et le coût. L’architecture reflète la réalité : les données sont partout. Cet article explique comment concevoir une sauvegarde hybride pour les charges d’IA, gérer la gravité des données et l’egress, et faire en sorte que la sauvegarde serve votre infrastructure au lieu de la contraindre. Une réalité distribuée : pourquoi la sauvegarde hybride est nécessaire La plupart des organisations opèrent sur plusieurs sites. Les services cloud offrent des capacités économiques. Le déploiement multirégion améliore la disponibilité. Les charges de travail ont des exigences différentes. Les données se répartissent donc entre sites et fournisseurs. Pour l’IA, cette répartition est marquée : données d’entraînement sur site, entraînement dans le cloud, feature stores dans le cloud, inférence dans plusieurs régions. Les sauvegardes doivent protéger les données partout. Les stratégies à site unique posent problème. Une approche uniquement sur site impose de sauvegarder toutes les données cloud sur site. Cela ajoute une charge réseau, augmente la latence et couple étroitement les systèmes. Les stratégies uniquement cloud créent de l’enfermement et de la gravité des données. Si toutes les sauvegardes se trouvent dans une seule région, restaurer sur site exige de transférer les données via Internet avec des frais d’egress importants. Plusieurs fournisseurs ajoutent de la complexité, avec des outils différents. La sauvegarde hybride répond à ces problèmes en répartissant l’infrastructure de sauvegarde entre les sites, de manière optimisée pour chacun. Hiérarchiser l’infrastructure de sauvegarde : localité et performances Déployez des cibles de sauvegarde sur plusieurs sites, optimisées pour les charges et les données locales. L’infrastructure de sauvegarde sur site sert les charges sur site. Il peut s’agir de stockage objet, d’appliances traditionnelles ou des deux. L’optimisation porte sur la vitesse : le débit du réseau local permet des sauvegardes et des restaurations rapides. Dimensionnez l’infrastructure selon les données locales et leurs caractéristiques. L’infrastructure de sauvegarde cloud sert les charges cloud. Les données AWS disposent d’une infrastructure de sauvegarde AWS. Les données Azure disposent d’une infrastructure Azure. Le Kubernetes sur site dispose d’outils hybrides. Le principe : déployer la sauvegarde au plus près des données protégées. L’avantage est la performance. Les sauvegardes vers une infrastructure locale sont rapides. La restauration depuis une infrastructure locale aussi. Pas d’allers-retours sur Internet. Pas d’egress coûteux. Cette localité simplifie l’exploitation. Chaque système gère des données et des charges bien délimitées. Les systèmes cloud régionaux gèrent les sauvegardes régionales. Les systèmes sur site gèrent les sauvegardes sur site. Les équipes se spécialisent sur leur périmètre au lieu de gérer plusieurs clouds. Hiérarchisation des données : équilibrer coût et accessibilité Au-delà de la multiplicité des sites, la sauvegarde hybride met en œuvre une hiérarchisation qui déplace les données entre niveaux de stockage selon leur âge, leur fréquence d’accès et leur coût. Une stratégie type : les sauvegardes récentes sur un stockage rapide (SSD, stockage objet hautes performances), les sauvegardes d’âge moyen sur un stockage standard, les sauvegardes anciennes et rarement consultées sur un niveau d’archivage (AWS Glacier, Azure Archive). On concilie ainsi reprise rapide et maîtrise des coûts. En mode hybride, la hiérarchisation tient compte de la localisation. Les sauvegardes récentes des bases de données cloud restent dans le stockage cloud pour une reprise rapide. Les sauvegardes plus anciennes sont archivées sur site ou dans une archive cloud, selon des stratégies de stockage cloud ou local (en anglais). La reprise finit par puiser dans l’archive, ce qui évite un stockage à accès immédiat coûteux sur le long terme. Les décisions de hiérarchisation doivent refléter les schémas de reprise réels. Pour les bases de données critiques exigeant une reprise rapide, conservez les sauvegardes récentes sur un stockage local rapide. Pour les archives rarement consultées, un stockage moins cher se justifie. Alignez les choix de niveau sur les exigences. Gravité des données et maîtrise des coûts d’egress La gravité des données est essentielle : c’est le coût et la complexité du déplacement de grands volumes de données entre sites. L’egress cloud — la sortie de données d’une région cloud — coûte cher. Les architectures hybrides qui imposent, souvent par inadvertance, de sortir des téraoctets du cloud entraînent des coûts vertigineux. Une sauvegarde hybride efficace gère explicitement la gravité des données. Conservez les données là où la reprise a le plus de chances d’avoir lieu. Si des données sont sauvegardées dans le cloud parce que les charges y tournent, stockez les sauvegardes dans le cloud. Ne les répliquez pas sur site au motif qu’il serait « principal » : la réplication (en anglais) entraîne des frais d’egress. Cela exige la rigueur de comprendre les schémas de reprise. Pour chaque catégorie de données, demandez-vous : où tourne-t-elle ? Où la reprise est-elle la plus probable ? Où doit se trouver la sauvegarde principale ? Où les copies secondaires ? Pour l’IA, les sauvegardes des données d’entraînement se trouvent au même endroit que l’infrastructure d’entraînement. Un entraînement sur AWS implique des sauvegardes sur AWS. Les feature stores sont sauvegardés là où le service est rendu. Les checkpoints de modèles sont sauvegardés là où l’entraînement a lieu. Cela n’empêche pas les copies inter-sites pour la reprise après sinistre. Cela signifie que les sauvegardes principales, fréquemment consultées, se trouvent au même endroit que les charges protégées. Les copies secondaires peuvent être ailleurs pour la reprise après sinistre. Une gestion unifiée sur une infrastructure de sauvegarde distribuée Le défi opérationnel consiste à gérer une infrastructure de sauvegarde distribuée sans gestion unifiée. Sans elle, vous maintenez des outils distincts pour chaque site, ce qui annule les bénéfices de l’hybride. Les couches de gestion unifiée font abstraction de l’infrastructure distribuée. Plutôt que de gérer séparément le site et le cloud, vous gérez un système unique qui comprend l’ensemble de l’infrastructure. Vous définissez les politiques une fois et les appliquez de façon cohérente. Vous disposez d’une visibilité sur l’ensemble et orchestrez la reprise partout. La gestion unifiée peut s’appuyer sur des plateformes d’orchestration dédiées ou sur des outils multicloud natifs. Le principe compte plus que l’outil : les opérations de sauvegarde doivent être unifiées, et non fragmentées. La gestion unifiée simplifie la conformité et l’audit. Vous auditez depuis une interface unique, appliquez la rétention de manière cohérente et maintenez un chiffrement uniforme. Reprise après sinistre dans les architectures hybrides La sauvegarde hybride exige une planification explicite de la reprise après sinistre. Si le site principal tombe, comment restaurer ? Où sont les copies ? Pouvez-vous restaurer rapidement ? En mode hybride, conservez des copies secondaires sur d’autres sites. Les bases de données sur site ont une copie principale sur site et une copie secondaire dans le cloud. L’entraînement dans le cloud a une copie principale dans le cloud et une copie secondaire sur site. Appuyez-vous sur une stratégie de sauvegarde d’entreprise (en anglais) qui tient compte du RTO et du RPO. Si le site principal est inaccessible, les autres sites disposent de données restaurables. Cela exige une connectivité réseau entre les sites et des processus de réplication. La réplication doit être asynchrone et planifiée en heures creuses pour ne pas pénaliser les charges. L’objectif est une reprise après sinistre sans surcoût permanent. Construire votre architecture de sauvegarde hybride Une sauvegarde hybride efficace commence par la cartographie de l’emplacement des données et des lieux de reprise. Déployez l’infrastructure de sauvegarde au plus près des données. Mettez en place une hiérarchisation qui équilibre coût et exigences. Gérez explicitement la gravité des données. Mettez en œuvre une gestion unifiée pour la visibilité et la cohérence. Les organisations qui gèrent efficacement la sauvegarde hybride la traitent comme une architecture stratégique, et non comme une contrainte. Elles investissent dans des outils unifiés, mettent en place une hiérarchisation réfléchie, comprennent les coûts liés à la gravité des données et prennent des décisions de placement délibérées. Elles testent régulièrement la reprise après sinistre. À mesure que l’infrastructure se distribue, la sauvegarde hybride devient indispensable pour gérer la protection. Construisez-la de manière délibérée, mesurez en continu et investissez dans des outils qui offrent une gestion et une visibilité unifiées sur l’ensemble de l’infrastructure. Pour aller plus loin RTO ou RPO : les principales différences expliquées (en anglais) DRaaS : la reprise après sinistre en tant que service (en anglais) Stockage multicloud : architecture, avantages et stratégie (en anglais) Stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) Stratégie de données cloud hybride pour les charges IA (en anglais) Architecture de cible de sauvegarde évolutive (en anglais)
