Une migration Move inter-clusters réussie ne dit rien de la sauvegarde : si les groupes de protection sont des listes explicites de VM, la VM arrivée sur le cluster cible n’est protégée par rien. Voici pourquoi, et la routine de contrôle retenue.
Ce que Move fait vraiment
Move ne déplace pas la VM : il en crée une nouvelle sur le cluster cible, avec un nouvel UUID Nutanix. Pour l’outil de sauvegarde, ce n’est pas un déplacement mais un nouvel objet, sans historique, que les groupes de protection en liste explicite ne connaissent pas.
Ce qui suit a été observé avec Cohesity, d’où le vocabulaire : Protection Groups (PG), sources, runs.
Étape 1 : rafraîchir la source
Tant que l’inventaire du cluster cible n’est pas à jour dans l’outil de sauvegarde, la VM migrée n’apparaît tout simplement pas : impossible de la sélectionner. Premier geste après la bascule : lancer un refresh de la source correspondant au cluster cible.
Étape 2 : le groupe de protection, liste ou automatique
Tout dépend de la façon dont les PG sont définis.
- PG en liste explicite d’objets, par cluster : la VM arrivée n’est dans aucun PG. Il faut l’ajouter au PG du cluster cible. Côté source, l’ancienne VM reste listée dans l’ancien PG et déclenche une alerte « entity not found » jusqu’à ce qu’on la retire.
- PG qui protège le cluster entier (mode automatique) : l’ancienne VM sort seule du périmètre.
Les snapshots de l’ancien objet ne disparaissent pas : ils restent sous l’ancien PG, selon sa rétention.
Le piège du double enregistrement PC + PE
Si Prism Central et les Prism Element sont enregistrés comme sources, chaque VM apparaît deux fois dans la hiérarchie, avec deux identifiants différents. Les PG s’appuient sur les identifiants côté PE.
Conséquence observée : en choisissant l’objet côté PC, on obtient un groupe d’apparence parfaitement correcte, qui ne sauvegarde rien.
Ne pas relancer le PG pour rattraper
Le réflexe de relancer tout le PG pour sauvegarder immédiatement les VM ajoutées est à éviter. Règle retenue : laisser le run planifié suivant faire le travail.
Le contrôle J+1
Le lendemain de la migration, vérifier pour chaque VM migrée qu’elle a un snapshot récent dans le PG du nouveau cluster.
Point important : faire ce contrôle en lisant le cluster de sauvegarde actif. Une réplique peut afficher un état différent et rassurer à tort.
Checklist par VM :
- présente dans le PG du cluster cible, sous la source PE ;
- snapshot récent dans ce PG ;
- retirée du PG source si celui-ci est en liste explicite (plus d’alerte « entity not found ») ;
- état lu sur le cluster de sauvegarde actif.
Ce qu’il faut retenir
- Move crée une nouvelle VM, avec un nouvel UUID : pour la sauvegarde, c’est un nouvel objet à protéger.
- Rafraîchir la source du cluster cible avant de chercher la VM, puis l’ajouter au PG si celui-ci est en liste explicite.
- PC et PE enregistrés tous les deux : sélectionner l’objet côté PE, par UUID Nutanix, sinon le groupe ne sauvegarde rien.
- Pas de relance manuelle du PG : le run planifié suivant suffit.
- Contrôle à J+1, VM par VM, sur le cluster de sauvegarde actif.
In English
Move creates a new VM on the target cluster, so the backup tool sees a new object with a new Nutanix UUID. Refresh the source, fix protection groups built on an explicit list, and check the next day on the active backup cluster rather than on a replica.
Sources & vérification
Testé sur : Migration Move inter-clusters AHV, sauvegarde Cohesity
- Expérience directe de l’auteur, en production (versions ci-dessus)