Sauvegarde VMware : la réalité après le rachat par Broadcom

Deux ans d’échanges avec les clients

Depuis que Broadcom a finalisé l’acquisition de VMware en novembre 2023, j’ai participé à des dizaines d’échanges avec des clients de VMware afin de déterminer la marche à suivre. Le ton des conversations a évolué au cours de ces 24 mois. Au cours des six premiers mois, la question était : « À quel point la situation va-t-elle réellement se détériorer ? » Aujourd’hui, la question est : « Que faisons-nous pour y remédier ? » Le choix de l’architecture de sauvegarde est intimement lié à cette seconde question, bien plus que la plupart des équipes ne le réalisent. 

Cet article présente ce que je dirais à un collègue qui me demanderait comment aborder la protection des données VMware dans l’environnement « post-Broadcom ». Je commencerai par les faits concernant Broadcom, car ils déterminent les choix. Je poursuivrai en expliquant comment les décisions en matière de sauvegarde doivent évoluer. Je passerai ensuite aux principes techniques fondamentaux, qui restent essentiels. Enfin, je présenterai les trois scénarios dans lesquels s’inscrivent la plupart des équipes avec lesquelles je m’entretiens.

Que signifie réellement « l’après-Broadcom » ?

Broadcom a finalisé l’acquisition en novembre 2023. Les premiers changements en matière de licences sont intervenus en décembre 2023, et ces changements se sont poursuivis tout au long de 2024, 2025 et jusqu’en 2026. L’effet cumulé est un VMware qui fonctionne selon des règles commerciales fondamentalement différentes de celles que la plupart des entreprises avaient adoptées il y a des années.

Les changements qui ressortent de chaque entretien avec les clients :

Fin des licences perpétuelles. Les licences perpétuelles avec support annuel ont disparu. Tous les nouveaux droits d’utilisation sont exclusivement sous forme d’abonnement. Les clients disposant de licences perpétuelles ne peuvent pas les renouveler. Les déploiements existants continuent de fonctionner, mais toute extension ou tout renouvellement nécessite le passage à un abonnement.

Regroupement du catalogue, passant d’environ 168 produits à 4 offres groupées. L’ancien catalogue a été regroupé en VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard (VVS) et vSphere Essential Plus (VVEP). Les clients qui n’achetaient auparavant que des composants spécifiques achètent désormais des offres groupées plus complètes.

Hausses de prix significatives. Les hausses signalées par les clients vont de 8 à 15 fois les coûts antérieurs, en fonction de la configuration précédente et de la nouvelle offre groupée qui s’en rapproche le plus. Le seuil minimum de 72 cœurs pour l’octroi de licence pénalise particulièrement les petits déploiements.

Réduction du programme de partenariat. Le programme VMware Cloud Service Provider est passé de plus de 4 500 fournisseurs agréés à l’échelle mondiale à un programme beaucoup plus restreint, accessible uniquement sur invitation et axé sur VCF. Cela affecte les canaux de commercialisation, en particulier pour les PME et les entreprises de taille intermédiaire.

Modifications des licences pour les hyperscalers. À compter du 1er novembre 2025, les clients utilisant VMware sur Azure VMware Solution ou AWS Elastic VMware Service devront disposer de leur propre abonnement VCF portable, acheté directement auprès de Broadcom. L’ancien modèle de licence groupée via les hyperscalers n’est plus disponible pour les nouveaux déploiements.

Il ne s’agit pas de prévisions. Ce sont des faits avérés début 2026. Les clients avisés peuvent avoir des avis divergents sur la manière d’y faire face. La plupart évaluent leurs options.

Pourquoi l’architecture de sauvegarde revêt davantage d’importance aujourd’hui qu’il y a trois ans

Avant Broadcom, le choix d’un outil de sauvegarde VMware relevait principalement d’une décision technique. Quel produit gérait le mieux les instantanés vSphere, s’intégrait parfaitement à vCenter et offrait la restauration la plus rapide ? Les questions d’architecture — dans quelle mesure la solution de sauvegarde était-elle spécifiquement liée à VMware, pouvait-elle fonctionner avec d’autres hyperviseurs ? — avaient certes leur importance, mais figuraient rarement en tête de la liste des critères d’évaluation.

Trois implications déterminent désormais une évaluation différente.

Les solutions de sauvegarde sous licence associées à VMware héritent de la trajectoire tarifaire de VMware. Les outils de sauvegarde fournis avec VCF ou vendus comme des produits spécifiques à VMware sont exposés aux décisions futures de Broadcom. Ce n’est pas le cas des plateformes de sauvegarde indépendantes fonctionnant via les API de vCenter.

La flexibilité stratégique revêt désormais une valeur économique mesurable. Une plateforme de sauvegarde qui protège VMware aujourd’hui et Nutanix ou AWS demain offre à l’entreprise une marge de manœuvre. Une plateforme de sauvegarde qui ne fonctionne que sur VMware enferme le client dans les futures décisions tarifaires de Broadcom, quelles qu’elles soient.

Les outils de migration ne sont plus facultatifs. Les clients qui migrent activement leurs charges de travail hors de VMware ont besoin d’une solution de sauvegarde qui fasse également office de plateforme de migration. Les mêmes données de sauvegarde, restaurées sur un autre hyperviseur ou dans un autre cloud. Les clients qui restent sur VMware pour l’instant ont tout de même intérêt à disposer de cette option.

Les principes techniques fondamentaux qui comptent toujours

L’environnement commercial a changé. Les exigences techniques, elles, sont restées les mêmes. Trois principes fondamentaux qu’une plateforme de sauvegarde VMware doit encore gérer correctement. 

Éviter le « VM stun » lors des instantanés au niveau de l’hyperviseur

Le « VM stun » correspond à la période, lors d’un instantané VMware, pendant laquelle la machine virtuelle ne répond plus tandis que l’hyperviseur met le système de fichiers en veille, capture un instantané et écrit l’état en mémoire sur le disque. La machine virtuelle est de fait inactive pendant ce « stun ». En cas de trafic d’E/S élevé, le « stun » peut s’étendre suffisamment longtemps pour déclencher un basculement du serveur principal. Le mécanisme de protection lui-même provoque alors l’indisponibilité qu’il est censé empêcher.

Une fois l’instantané terminé, un journal tampon capture les modifications survenues pendant le « stun », et ces modifications doivent être répercutées sur la machine virtuelle. Il s’agit là d’une autre opération chronophage. À mesure que la taille des machines virtuelles a augmenté (les disques virtuels de plusieurs téraoctets sont désormais courants), tant les périodes de mise en veille que la gestion du journal tampon ont pris de l’ampleur. L’approche VADP traditionnelle reconnaît ces compromis, mais ne les résout pas. 

L’alternative architecturale consiste à réaliser des instantanés au niveau du stockage, pris au niveau de la couche de stockage sous-jacente plutôt qu’au niveau de l’hyperviseur, qui capturent uniquement les mises à jour granulaires sans nécessiter d’étape de réapplication. Sur les déploiements Nutanix-on-ESXi, cela fonctionne grâce aux API d’instantanés natives de Nutanix, compatibles à la fois avec les machines virtuelles AHV et ESXi. Les performances de sauvegarde ne sont pas affectées par la taille de la machine virtuelle, il n’y a pas d’interruption de service des machines virtuelles de production, ni de surcharge liée aux journaux tampons.

Une protection adaptée aux applications, et pas seulement une sauvegarde au niveau des machines virtuelles

Une sauvegarde au niveau des machines virtuelles est nécessaire, mais insuffisante. Les applications critiques s’exécutant au sein de machines virtuelles (SQL Server, Oracle, Exchange, SAP) nécessitent une sauvegarde tenant compte des applications, qui se coordonne avec les mécanismes de cohérence propres à l’application (VSS Writers sous Windows, hooks de mise en veille des applications sous Linux). Sans cela, vous disposez de fichiers de sauvegarde, mais aucune garantie de cohérence transactionnelle.

La détection automatisée et sans configuration des applications rend cette solution évolutive. La plateforme de sauvegarde doit identifier quelles applications s’exécutent dans quelles machines virtuelles et appliquer automatiquement la protection appropriée, sans que l’administrateur ait à spécifier le mappage pour chaque machine virtuelle. 

Intégration à vCenter et déploiement sans impact

Les opérations de sauvegarde doivent s’intégrer via les API vCenter et hériter des autorisations, des rôles et des structures de pools de ressources existants. La plateforme de sauvegarde doit fonctionner exclusivement sous forme logicielle sur le cluster VMware lui-même. Pas de licences Windows Server supplémentaires, pas de licences de base de données supplémentaires, pas d’infrastructure distincte pour une restauration rapide. Toute solution de sauvegarde VMware nécessitant le déploiement d’une nouvelle infrastructure importante engendre des coûts supplémentaires, alors que les changements imposés par Broadcom ont déjà exercé une pression sur les budgets. 

Trois scénarios que j’observe lors de mes échanges avec les clients

La plupart des organisations évaluant une solution de sauvegarde VMware en 2026 s’inscrivent dans l’un de ces trois scénarios. Une plateforme de sauvegarde digne d’intérêt prend en charge ces trois scénarios, car la situation du client peut évoluer au cours de la durée du contrat. 

Un produit de sauvegarde exclusivement dédié à VMware gère bien le scénario 1, peine à gérer le scénario 2 et va à l’encontre des intérêts du client dans le scénario 3. Une plateforme de sauvegarde indépendante de l’hyperviseur gère les trois scénarios via le même plan de gestion.

Ce qu’il faut rechercher après l’acquisition par Broadcom

Six critères distinguent les options de sauvegarde VMware qui résisteront à l’épreuve du temps au cours des cinq prochaines années des options optimisées pour le marché d’avant l’acquisition par Broadcom. 

Indépendance vis-à-vis des licences VMware. Le modèle commercial et la feuille de route du fournisseur de solutions de sauvegarde ne doivent pas dépendre des décisions de Broadcom. L’intégration dans une offre groupée ou le co-marketing sont acceptables. Une dépendance technique ou commerciale ne l’est pas.

Architecture indépendante de l’hyperviseur. Prise en charge native de VMware ESXi, Nutanix AHV, Hyper-V et des principaux clouds publics. La migration entre hyperviseurs à partir des mêmes données de sauvegarde doit être une fonctionnalité documentée et prise en charge, et non une prestation de services ponctuelle.

Instantanés au niveau du stockage pour éviter les interruptions de service des machines virtuelles. Les instantanés VADP au niveau de l’hyperviseur sont fiables mais limités. L’intégration au niveau du stockage avec la plateforme de données sous-jacente (Nutanix, Pure, NetApp) offre une protection sans impact pour les machines virtuelles volumineuses ou à forte intensité d’E/S.

Déploiement exclusivement logiciel, sans licence supplémentaire. Une sauvegarde nécessitant des licences Windows Server supplémentaires, des licences SQL Server ou une infrastructure spécifique à la sauvegarde alourdit un budget déjà tendu. Un logiciel pur fonctionnant sur l’infrastructure existante doit constituer la norme.

Sauvegarde et restauration tenant compte des applications. Détection automatique de SQL Server, Oracle, Exchange, SAP et d’autres applications d’entreprise s’exécutant au sein de machines virtuelles. Sauvegardes cohérentes au niveau des applications. Récupération granulaire au niveau des fichiers, des applications ou des machines virtuelles.

Préparation face aux ransomwares sur tous les hyperviseurs. Stockage de sauvegarde compatible WORM, copies de sauvegarde isolées physiquement, détection des anomalies entre les sauvegardes, intégration via webhooks avec les outils de sécurité. Les ransomwares ne respectent pas les limites des hyperviseurs. La protection par sauvegarde ne devrait pas non plus les respecter.

Questions fréquentes sur la sauvegarde VMware après le rachat par Broadcom

Dois-je abandonner VMware en raison des changements liés à Broadcom ?

Il s’agit d’une décision organisationnelle, et non d’une décision relative à la sauvegarde. La bonne réponse dépend des investissements existants dans les charges de travail, de l’expertise de l’équipe, des dépendances des applications et de l’augmentation réelle des coûts à laquelle votre organisation est confrontée. L’architecture de sauvegarde doit vous offrir la possibilité de prendre cette décision ultérieurement, en étant indépendante des licences VMware et capable de prendre en charge la migration si vous décidez de quitter la plateforme. La décision relative à la sauvegarde ne doit ni vous enfermer dans VMware ni vous en exclure. 

Que signifie concrètement la « migration d’un cluster ESX vers un cluster non-ESX » ?

Il s’agit d’utiliser les données de sauvegarde capturées à partir d’un cluster VMware ESXi pour restaurer les mêmes charges de travail sur un autre hyperviseur, le plus souvent Nutanix AHV, mais également vers des destinations de cloud public. La plateforme de sauvegarde gère la conversion de format, la traduction de la configuration et l’orchestration de la restauration. Si l’opération est correctement effectuée, la charge de travail est déployée sur le nouvel hyperviseur tout en préservant la cohérence des applications tout au long du transfert. Il s’agit du même mécanisme qui prend en charge la reprise après sinistre inter-cloud, réadapté pour une migration permanente. 

Si je reste sur VMware, Broadcom modifie-t-il réellement les critères que je dois prendre en compte en matière de sauvegarde ?

Oui, car la sauvegarde est un engagement sur plusieurs années, et le bon choix aujourd’hui doit rester valable au cours des cinq prochaines années, quelles que soient les décisions futures de Broadcom. Même si vous vous engagez à utiliser VMware dans un avenir prévisible, choisir une solution de sauvegarde indépendante de l’évolution commerciale de VMware protège votre budget de protection des données contre les répercussions des décisions tarifaires de VMware. La possibilité de choix a une valeur intrinsèque, même lorsque vous n’exercez pas cette option.

Combien de temps dure la migration de VMware vers Nutanix lorsque la sauvegarde sert de source de migration ?

La migration technique d’une charge de travail individuelle prend généralement quelques heures, et non plusieurs jours. Restaurez la sauvegarde sur le cluster Nutanix, validez la charge de travail, puis basculez le DNS et le trafic. La migration complète de l’organisation est généralement limitée par les dépendances des applications, les tests et la capacité des équipes plutôt que par le mécanisme de sauvegarde et de restauration. La plupart des organisations mènent ces migrations sur une période de 12 à 36 mois, application par application ou unité opérationnelle par unité opérationnelle.

Par où commencer

Si vous réévaluez la protection des données VMware, l’exercice le plus utile consiste à identifier en toute honnêteté dans lequel des trois scénarios vous vous trouvez. Cette clarté fait souvent défaut dans les échanges avec les clients, en partie parce que la réponse évolue au fil de l’année. Une fois que vous savez dans quel scénario vous vous trouvez, les exigences en matière de sauvegarde deviennent concrètes. Nous serons ravis de vous accompagner dans cette réflexion. Contactez votre équipe commerciale ou commencez par hycu.com/trial.