Objectif
Utiliser un checkpoint Hyper-V de façon contrôlée avant un changement, en privilégiant les checkpoints de production, en limitant leur durée de vie, en surveillant l’espace disque et en validant la fusion des fichiers différenciés après suppression.
Prérequis
- Sauvegarde récente de la VM et procédure de restauration connue.
- Espace libre suffisant sur le volume contenant les fichiers de la VM et ses checkpoints.
- Type de checkpoint configuré et compatibilité VSS
- Fenêtre de changement avec durée maximale pendant laquelle le checkpoint doit rester présent.
- Accès Hyper-V Manager ou module PowerShell Hyper-V.
Procédure pas à pas
Vérifier l’état de la VM et le type de checkpoint
Commencez par lister les checkpoints existants et le type configuré. Une VM qui possède déjà une longue chaîne doit être assainie avant d’ajouter un nouveau niveau. En production, utilisez ProductionOnly si vous préférez que la création échoue plutôt que de retomber automatiquement sur un checkpoint standard lorsque VSS ne peut pas produire un état cohérent.
Get-VM -Name "<VM-NAME>" | Select-Object Name,State,CheckpointType,AutomaticCheckpointsEnabledGet-VMCheckpoint -VMName "<VM-NAME>"- Le nombre de checkpoints existants est connu.
- Le type de checkpoint correspond au niveau de cohérence attendu.
Contrôler l’espace disponible et l’emplacement
Identifiez le volume qui stocke la configuration et les disques de la VM. Mesurez l’espace libre et estimez la croissance possible pendant le changement. Une base de données ou une VM à forte écriture peut produire un AVHDX rapidement volumineux. Si l’espace est déjà tendu, libérez ou augmentez la capacité avant de créer le checkpoint.
Get-VMHardDiskDrive -VMName "<VM-NAME>" | Select-Object PathGet-VM -Name "<VM-NAME>" | Select-Object Path,SnapshotFileLocation- Le volume possède une marge suffisante pour la durée de l’intervention.
Configurer ProductionOnly pour une charge sensible
Si la VM doit impérativement obtenir un checkpoint cohérent applicativement, configurez ProductionOnly. Hyper-V utilisera VSS pour Windows ou le mécanisme de gel de système de fichiers prévu pour Linux. Si la création échoue, traitez la cause plutôt que de basculer silencieusement sur un checkpoint standard.
Set-VM -Name "<VM-NAME>" -CheckpointType ProductionOnly- La VM est configurée pour refuser un fallback standard non souhaité.
Créer un checkpoint nommé et horodaté
Créez le checkpoint juste avant le changement et donnez-lui un nom qui décrit l’objectif, par exemple PRE-MAJ-ERP-2026-08-10. Évitez les noms vagues. Vérifiez que l’opération se termine correctement et qu’un nouveau checkpoint apparaît. Si la création échoue, consultez VSS et les événements Hyper-V avant toute nouvelle tentative.
Checkpoint-VM -Name "<VM-NAME>" -SnapshotName "PRE-CHANGE-YYYYMMDD"Get-VMCheckpoint -VMName "<VM-NAME>" | Select-Object Name,CreationTime,CheckpointType- Un seul checkpoint correspondant au changement est créé.
- Aucune erreur VSS ou Hyper-V n’est laissée sans analyse.
Réaliser le changement et tester sans multiplier les checkpoints
Effectuez l’opération prévue dans la VM puis testez l’application. Ne créez pas un checkpoint à chaque petite étape, sauf justification documentée : une chaîne profonde complique le retour arrière et augmente les besoins de stockage. Conservez une chronologie des modifications pour savoir exactement ce qui serait annulé en cas de restauration.
- Le changement est validé ou déclaré en échec dans la fenêtre prévue.
Appliquer le checkpoint uniquement si le rollback est nécessaire
Si le changement doit être annulé, arrêtez les écritures applicatives lorsque possible et appliquez le checkpoint choisi. L’application d’un checkpoint remplace l’état courant par l’état capturé. Hyper-V peut proposer de créer un checkpoint de l’état actuel avant l’application ; choisissez selon votre plan de retour et l’espace disponible.
Restore-VMCheckpoint -VMName "<VM-NAME>" -Name "PRE-CHANGE-YYYYMMDD" -Confirm:$false- La VM revient à l’état attendu et l’application est retestée après démarrage.
Supprimer le checkpoint après validation
Si le changement est réussi, supprimez le checkpoint dès que la période de validation est terminée. La suppression déclenche la fusion des disques différenciés. Ne supprimez pas les fichiers à la main et ne coupez pas le stockage pendant cette fusion. Surveillez l’activité et l’espace libre jusqu’à disparition de la chaîne concernée.
Remove-VMCheckpoint -VMName "<VM-NAME>" -Name "PRE-CHANGE-YYYYMMDD"Get-VMCheckpoint -VMName "<VM-NAME>"- Le checkpoint disparaît de Hyper-V.
- La fusion se termine sans erreur et l’espace disque se stabilise.
Contrôler qu’aucun AVHDX orphelin n’est traité manuellement
Après suppression, vérifiez les chemins de disques associés à la VM. La présence d’un AVHDX ne signifie pas automatiquement qu’il est orphelin : il peut encore appartenir à une chaîne active ou à une fusion en cours. En cas d’incohérence, collectez la configuration et utilisez les outils Hyper-V prévus avant toute manipulation de fichier.
Get-VMHardDiskDrive -VMName "<VM-NAME>" | Select-Object ControllerType,ControllerNumber,ControllerLocation,Path- La VM référence une chaîne de disques cohérente et aucun fichier n’est supprimé manuellement.
Documenter la durée et la croissance observée
Notez combien de temps le checkpoint est resté présent, l’espace consommé et la durée de fusion. Ces mesures permettent de fixer une limite réaliste pour les futures opérations. Pour des changements récurrents, formalisez une règle : checkpoint créé juste avant l’intervention, validation rapide, puis suppression systématique.
- La prochaine intervention dispose d’une estimation réelle de l’espace et du temps nécessaires.
Validation
La procédure est validée lorsque :
- Le type de checkpoint est adapté à la charge et les checkpoints de production sont privilégiés en production.
- Le checkpoint est utilisé sur une durée courte et son espace est surveillé.
- Après réussite du changement, le checkpoint est supprimé via Hyper-V et la fusion se termine sans erreur.
- La VM démarre, son application fonctionne et une sauvegarde indépendante reste disponible.
Retour arrière
- Si le changement échoue, appliquer le checkpoint prévu puis valider système et application.
- Si la fusion de checkpoint échoue, ne supprimer aucun AVHDX à la main ; conserver l’état et traiter la chaîne avec les outils Hyper-V adaptés.
- Si l’espace disque devient critique avant la fin de la validation, arrêter le changement, réduire les écritures et libérer/augmenter la capacité avant toute fusion.
- Restaurer depuis la sauvegarde indépendante si la chaîne de checkpoint est devenue inutilisable.
Dépannage / erreurs fréquentes
- Production checkpoint échoue : contrôler les writers VSS, l’intégration Hyper-V et les journaux de l’application invitée.
- Checkpoint grossit rapidement : identifier la charge en écriture et écourter la fenêtre de validation.
- Suppression terminée dans l’interface mais espace non libéré immédiatement : vérifier si une fusion est encore en cours.
- Erreur de chaîne ou AVHDX : ne pas renommer/supprimer arbitrairement ; collecter les chemins et traiter l’incohérence avant redémarrage.
- Contrôleur de domaine ou application répliquée : éviter les checkpoints standard et confirmer la méthode supportée par l’éditeur.