Récupération de données sur disque virtuel VMDK et VHDX

Pour un VMDK, un VHDX ou un autre disque de machine virtuelle corrompu, Datastrophe protège l’espace de stockage virtualisé et toute la chaîne d’instantanés avant de reconstruire les segments, le volume invité et les données applicatives utiles.

Demander un devis

Machine virtuelle arrêtée devant une chaîne de disques figée avant toute consolidation automatique

Gel de l’incident

Une machine virtuelle qui ne démarre plus n’autorise pas une consolidation automatique

Arrêtez les redémarrages et suspendez les tâches de création d’instantanés. Une consolidation, une migration ou un redimensionnement peut modifier plusieurs gigaoctets et détacher la version recherchée. L’état de l’espace de stockage, les noms, les tailles et les dates de tous les fichiers doivent être inventoriés avant de laisser l’hyperviseur réparer quoi que ce soit.

Une copie réalisée après l’incident peut modifier les attributs et omettre des fichiers verrouillés. L’inventaire distingue la source, chaque copie et leur heure. Les outils de sauvegarde qui ont tenté une consolidation sont identifiés dans la chronologie.

Éteindre proprement la machine virtuelle si possible
Suspendre la consolidation et la sauvegarde
Inventorier les fichiers sans les modifier

Erreurs de descripteur

Un petit fichier VMDK peut décrire de grands segments ; le supprimer parce qu’il paraît insignifiant complique la reconstruction. Les identifiants du parent, la géométrie et les chemins sont comparés aux disques présents. Un descripteur peut être recréé sur une copie seulement après cette analyse.

Machine virtuelle suspendue ou arrêtée brutalement

Les fichiers mémoire et les journaux peuvent documenter le dernier état, mais ils ne remplacent pas le disque. Une suspension interrompue laisse parfois une cohérence applicative incertaine. La priorité est de figer tous les éléments, y compris ceux que l’interface n’affiche plus.

L’action proposée par l’hyperviseur vise la remise en service, pas nécessairement la conservation des anciennes données.

Chaîne d’instantanés avec chaque parent, chaque fichier différentiel et chaque identifiant de contenu vérifiés

Chaîne de versions

Instantanés : suivre chaque parent, chaque fichier différentiel et chaque identifiant de contenu

Un instantané ne contient généralement que les blocs modifiés depuis son parent. Omettre un fichier différentiel rend les versions suivantes incomplètes ; les assembler dans le mauvais ordre mélange des époques. Datastrophe vérifie les identifiants, les numéros de séquence et les plages de blocs avant de produire une vue logique.

Les identifiants de contenu et les identifiants uniques (UUID) ne sont pas corrigés simplement pour satisfaire l’interface. Leur divergence peut révéler une branche ou un parent manquant. Les modifications nécessaires sont appliquées uniquement à un descripteur de travail et restent traçables.

Conserver tous les fichiers différentiels
Comparer les CID et les autres identifiants
Tracer l’ordre parent-enfant

Instantanés orphelins

Un fichier différentiel non référencé peut contenir des blocs utiles ou appartenir à une branche abandonnée. Les dates et les journaux aident à l’attribuer. Il est testé séparément sur une copie au lieu d’être injecté directement dans la chaîne principale.

Consolidation partielle

Une opération interrompue peut avoir recopié certains blocs dans le parent et pas d’autres. Les tailles seules ne suffisent pas. L’analyse recherche les secteurs incohérents et choisit l’état qui correspond au moment métier attendu, avec signalement des incertitudes.

Le fichier le plus récent n’est pas autonome lorsqu’il dépend d’une chaîne d’instantanés.

Métadonnées distinctes des fichiers VMDK et VHDX et des disques dynamiques avant leur reconstruction

Format conteneur

Les fichiers VMDK et VHDX possèdent des métadonnées propres, comme les disques dynamiques

Un disque virtuel à allocation dynamique ou différenciée associe des tables de blocs et des zones de données. Une corruption de l’en-tête peut rendre le fichier non montable sans effacer les secteurs invités. Le laboratoire reconstruit les métadonnées du conteneur sur une copie avant d’interpréter NTFS, ext4, LVM ou un autre volume interne.

Les formats à allocation dynamique n’allouent pas tous les blocs du disque présenté à la machine virtuelle. Une zone non allouée du conteneur et une zone contenant des zéros ne signifient pas la même chose. Les tables internes doivent conserver cette distinction pendant la reconstruction.

Identifier le type exact
Valider les tables de blocs
Séparer le conteneur du système invité

Segments fractionnés

Certains VMDK sont découpés en segments numérotés. Un seul segment absent crée une plage vide qui touche des fichiers précis. L’inventaire vérifie la continuité, la taille et l’empreinte. Les lacunes restent cartographiées pendant la reconstruction du système invité.

Disques de différenciation Hyper-V

Le fichier AVHDX et son parent VHDX doivent conserver leurs identifiants et leur ordre. Une fusion lancée au hasard peut écraser l’état voulu. La reconstruction vise d’abord une image indépendante correspondant au point de contrôle sélectionné, sans modifier l’arborescence de production.

Renommer une extension ne convertit pas le format et peut masquer les fichiers associés.

Acquisition

Copier l’espace de stockage virtualisé et le stockage physique avant l’analyse

Les fichiers virtuels reposent sur un ensemble RAID, un NAS, un réseau SAN ou un disque local qui peut être lui-même instable. Une simple copie de fichier échoue ou remplit les trous sans les signaler. Datastrophe évalue la couche physique, image les membres nécessaires et conserve les erreurs avant d’extraire les fichiers de la machine virtuelle.

Si l’espace de stockage virtualisé repose sur un support instable, les petits descripteurs et les métadonnées sont priorisés avec les segments critiques. Une copie de fichier classique peut remplir silencieusement une erreur ; l’acquisition doit conserver la position exacte de chaque lacune.

Contrôler le support sous-jacent
Copier les métadonnées et les journaux
Créer une source de travail figée

Espace VMFS ou volume partagé

Une suppression sur VMFS ne se traite pas comme un fichier effacé sur un poste. Les allocations, les segments et les métadonnées de l’espace de stockage doivent être analysés. Toute nouvelle machine virtuelle ou migration peut réutiliser les blocs libres et diminuer les possibilités.

RAID sous l’hyperviseur

Si plusieurs disques physiques sont impliqués, le diagnostic RAID et NAS préserve leur ordre, leur parité et la taille de bande avant d’extraire l’espace de stockage virtualisé. Reconstruire seulement le fichier virtuel ne corrige pas une agrégation physique mal assemblée.

Une reconstruction virtuelle fiable dépend d’abord d’une lecture fidèle du stockage qui l’héberge.

Copie d’un disque virtuel montée en lecture seule avant tout redémarrage du système invité

Exploration

Monter une copie en lecture seule avant de relancer le système invité

Une fois la chaîne reconstruite, le disque est exposé à des outils d’analyse sans démarrer la machine virtuelle. Le démarrage pourrait déclencher l’écriture de journaux, appliquer des mises à jour et lancer des services qui écrivent immédiatement. Le montage en lecture seule permet de vérifier les partitions et les fichiers avant toute tentative de démarrage d’une copie isolée.

Le montage hors ligne permet aussi de calculer des empreintes avant tout test. Les essais de réparation ou de démarrage sont dérivés de cette référence. Un résultat peut ainsi être reproduit ou abandonné sans altérer la version reconstruite initiale.

Aucun démarrage sur l’original
Les volumes invités sont inspectés
Des copies sont dédiées aux essais

Systèmes de fichiers invités

Les systèmes de fichiers NTFS, ReFS, ext4 ou XFS disposent de journaux et de structures propres. Ils sont analysés après le conteneur virtuel. Une lacune du VMDK peut traverser une base, un répertoire ou l’espace libre ; la correspondance aide à évaluer les fichiers touchés.

LVM, volumes dynamiques et chiffrement

La machine virtuelle peut ajouter LVM, Storage Spaces ou un volume chiffré. Les métadonnées et les clés doivent être disponibles. La reconstruction extérieure n’autorise pas à promettre l’accès à une couche chiffrée dont le secret interne manque.

Un écran de connexion réussi ne prouve pas la cohérence des bases et des services de la machine virtuelle.

Contrôle de la cohérence des bases et des services après le montage d’une copie du disque virtuel

Validation métier

Les bases et les services exigent une cohérence applicative, pas un simple montage

Une base SQL peut exister mais avoir perdu des pages ou des journaux de transactions. Un serveur de fichiers peut présenter des noms tout en contenant des blocs nuls. Les applications prioritaires sont identifiées et contrôlées selon leur format, en distinguant la cohérence du volume de la cohérence métier.

Les journaux d’une base et ceux du système invité sont rapprochés du point temporel choisi. Leur présence ne garantit pas qu’ils forment une séquence complète. Le propriétaire de l’application participe à la définition du contrôle métier acceptable.

Les bases applicatives sont vérifiées
Les partages prioritaires sont échantillonnés
Les journaux système sont analysés

Choisir un point dans le temps

La meilleure version technique n’est pas toujours la plus récente si un instantané contient déjà la corruption. L’utilisateur doit préciser le dernier état métier fiable. Les fichiers et les journaux sont comparés à cette période pour éviter de livrer une machine virtuelle récente mais inutilisable.

Extraire ou redémarrer

Selon les dommages, il peut être plus sûr d’extraire les bases, les configurations et les documents que de reconstruire une machine amorçable. Le résultat attendu est défini avant les essais. Une copie de test peut être démarrée dans un réseau isolé seulement si cela apporte une validation utile.

La récupération d’un disque virtuel ne garantit pas le redémarrage propre de tous les services qu’il hébergeait.

Version reconstruite du disque virtuel accompagnée d’un relevé des blocs manquants et des limites

Restitution

Documenter la version reconstruite et les blocs manquants

Le résultat précise la chaîne d’instantanés retenue, le point temporel, les volumes montés et les lacunes. Les données peuvent être livrées sous la forme de fichiers extraits, d’une image virtuelle reconstruite ou d’une combinaison des deux. Chaque format est contrôlé sur un stockage sain distinct de l’espace de stockage incident.

La livraison indique les parents utilisés, les fichiers différentiels exclus et les opérations appliquées. Un administrateur peut ainsi décider d’importer l’image ou seulement les données. Cette trace évite de réintroduire une branche inconnue dans l’infrastructure de production.

La version et la date sont identifiées
L’image et les fichiers exportés sont séparés
Les limites sont localisées par zone

Confidentialité des images complètes

Un disque virtuel contient souvent des systèmes, des secrets, des journaux et des données appartenant à plusieurs utilisateurs. Le périmètre de validation doit rester ciblé. Les fichiers utiles exportés réduisent parfois l’exposition par rapport à la livraison d’une image complète, selon le besoin convenu.

Lien avec la récupération serveur

Lorsque l’incident concerne plusieurs rôles applicatifs, plusieurs bases et plusieurs espaces de stockage, la récupération sur serveur aide à prioriser les services métier et leurs dépendances. Le disque virtuel reste alors une couche d’un dossier plus large.

Une machine virtuelle reconstruite sans documentation devient difficile à auditer et risquée à remettre en production.

Inventaire de la machine virtuelle, de l’hyperviseur et de la chaîne d’instantanés avant la récupération du disque virtuel

Préparation du dossier

Préparer l’inventaire de la machine virtuelle, de l’hyperviseur et de la chaîne d’instantanés

Conservez le dossier complet de la machine, y compris les petits descripteurs, les fichiers différentiels, les journaux, les fichiers de configuration et la mémoire. Indiquez l’environnement utilisé — VMware, Hyper-V ou un autre hyperviseur —, sa version, l’espace de stockage, la date de la dernière sauvegarde et les opérations lancées après l’incident.

Le transfert doit conserver les horodatages de la source sans leur substituer ceux créés par la copie. L’inventaire original, la configuration de la machine virtuelle et les fuseaux horaires accompagnent le dossier afin de maintenir une chronologie exploitable.

Pour chaque disque virtuel, relevez le nom de la machine virtuelle, sa taille provisionnée, son contrôleur virtuel, son espace de stockage et la chaîne d’instantanés attendue. Les fichiers de faible taille — les descripteurs, les journaux et les configurations — sont aussi importants que les grands conteneurs, car ils documentent les relations parent-enfant. Une copie partielle ou un instantané isolé n’est jamais consolidé sur place. Les hypothèses sont testées sur un duplicata, puis la cohérence des volumes invités et des services prioritaires est vérifiée avant tout démarrage dans un réseau isolé.

Tous les fichiers associés
La topologie du stockage
Le point temporel recherché

Figer les empreintes et les horaires

Une liste avec les tailles, les dates et les empreintes aide à confirmer qu’aucun fichier n’a changé pendant le transfert. Les fuseaux horaires des journaux doivent être précisés lorsque la chronologie compte. L’original reste hors des essais de montage et de consolidation.

Définir les données indispensables

Dans la demande de diagnostic, citez les bases, les partages, les applications et la dernière date cohérente. Ces critères permettent de choisir entre la reconstruction de la machine virtuelle, l’extraction ciblée et la récupération du stockage sous-jacent sans confondre la remise en ligne avec la qualité des données.

Ne copiez pas uniquement le plus gros fichier en supposant qu’il contient toute la machine virtuelle.

FAQ

Questions fréquentes

Faut-il consolider les instantanés avant d’envoyer une machine virtuelle ?

Non. La consolidation modifie les disques parents et les fichiers différentiels, et peut écraser le point temporel recherché. Suspendez l’activité, conservez tous les fichiers et inventoriez leurs tailles et leurs dates. La chaîne sera reconstruite sur une copie après la vérification des identifiants.

Un fichier VMDK très petit est-il inutile ?

Non. Il peut s’agir du descripteur qui référence les grands segments, précise la géométrie du disque et, lorsqu’une chaîne d’instantanés existe, indique le fichier parent. Le supprimer complique l’assemblage. Tous les fichiers du dossier, même petits, ainsi que les journaux et les configurations doivent être conservés.

Peut-on démarrer la machine virtuelle pour vérifier si les données sont revenues ?

Pas sur la copie reconstruite qui sert de référence. Le démarrage écrit des journaux et lance des services. Les volumes sont d’abord montés en lecture seule ; une copie séparée peut ensuite être testée dans un environnement isolé si le démarrage apporte une validation utile.

Quelle différence entre récupérer le VMDK et récupérer la base qu’il contient ?

Le conteneur peut être cohérent alors que la base a perdu des pages, ou l’inverse. Il faut vérifier le système de fichiers invité puis la structure applicative, les journaux et les données métier. Un fichier présent n’est pas automatiquement exploitable.

Que fournir pour une machine virtuelle corrompue ?

Fournissez le dossier complet, tous les instantanés et les fichiers différentiels, les descripteurs, les journaux, la configuration, la version de l’hyperviseur et la topologie du stockage. Indiquez aussi le dernier point temporel fiable et les services prioritaires à contrôler.

Supports

Autres expertises

Diagnostic

Un doute sur un support ou une panne ?

Datastrophe qualifie le risque avant toute intervention et vous indique le chemin le plus prudent.

Demander un diagnostic