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

Quand une machine virtuelle ne démarre plus, arrêtez les consolidations et copies improvisées. Un fichier delta ou parent manquant peut encore être identifié dans le stockage hôte.

Demander une soumission

Figer la machine virtuelle évite un nouveau delta

Chaque démarrage peut modifier la chaîne que l’on cherche à comprendre.

Arrêtez la VM et les tâches de consolidation, de réplication ou de sauvegarde. Ne créez pas un nouvel instantané pour tester. Relevez l’hyperviseur, le magasin de données, l’heure de l’incident et les messages exacts avant de copier quoi que ce soit.

Une VM en marche continue de modifier son disque, ses journaux et parfois plusieurs fichiers delta. Une consolidation automatique peut fusionner le mauvais état lorsque la chaîne est déjà incomplète. Suspendez aussi les politiques qui déplacent la VM vers un autre magasin de données ou suppriment les instantanés jugés anciens. L’évaluation diagnostique commence par une copie de l’inventaire et des métadonnées de configuration, sans ouvrir le disque invité en écriture. Cette photographie logique fixe les relations observables au moment de l’incident.

Arrêter les écritures invitées
Suspendre toute consolidation automatique
Exporter la configuration actuelle

Une copie de fichier isolée peut être incohérente

Un VMDK ou VHDX ouvert par l’hyperviseur évolue pendant sa copie. Sans gel applicatif ou arrêt confirmé, le début et la fin du fichier peuvent représenter deux états différents.

Les journaux doivent être conservés avec les horodatages

Ils indiquent les UUID, chemins et opérations récentes. Une rotation ou un redémarrage de l’hôte peut faire disparaître ces repères. Exportez-les sans lancer de réparation automatique.

Créer un instantané après la panne ajoute un nouveau delta et peut compliquer la chronologie déjà endommagée.

La chaîne parent-enfant doit être inventoriée avant assemblage

Le disque visible peut ne contenir que les modifications récentes.

Descripteurs, extensions, identifiants et ordre des instantanés sont comparés. Un delta rattaché au mauvais parent produit parfois un volume qui monte mais mélange des époques. Les noms de fichiers ne suffisent pas à déterminer cette relation.

Pour une chaîne VMDK avec descripteurs ou instantanés, les CID, parentCID et les fichiers `-flat` ou `-delta` présents doivent correspondre. Pour VHDX, les identifiants de disque et la relation AVHDX apportent d’autres repères. Les dates de modification peuvent être altérées par une copie ou une restauration et ne font pas autorité seules. L’analyse teste les branches sur des duplicatas, puis vérifie la cohérence du système de fichiers invité. Une chaîne qui se monte n’est pas forcément la bonne chaîne si elle associe des blocs de périodes différentes.

Identifiants parent-enfant concordants
Descripteurs complets et lisibles
Chronologie des instantanés connue

Un descripteur manquant peut être reconstruit prudemment

La géométrie, le type d’allocation et les identifiants sont déduits des fichiers existants et de la configuration. Le nouveau descripteur est créé à côté des copies, jamais à la place de l’original.

Un instantané n’est pas une sauvegarde indépendante

Il dépend généralement de sa base et de ses ancêtres. Supprimer ou déplacer le parent compromet le delta, même si sa taille paraît importante. Toute la chaîne est donc demandée.

Ne renommez aucun VMDK, VHDX, AVHDX ou delta avant l’inventaire : le nom peut encore aider à relier les pièces.

Le magasin de données physique reste la première source de preuve

Un disque virtuel supprimé peut laisser des blocs et métadonnées sur l’hôte.

Le stockage d’origine est protégé avant la recherche de fichiers virtuels. Le RAID, le NAS, le SAN ou le disque local doit cesser de recevoir de nouvelles VM, des sauvegardes et des journaux. Une acquisition du niveau physique précède les reconstructions de magasin de données.

Un VMDK supprimé sur VMFS, un VHDX tronqué sur NTFS et une chaîne stockée sur un RAID dégradé n’ont pas le même point de départ. Les membres physiques, les LUN, les volumes et les magasins de données sont figés dans leur ordre. Si un disque mécanique clique, une évaluation en salle blanche peut concerner ce support ; elle ne répare jamais un descripteur virtuel. Cette séparation évite d’appliquer une solution logique à une panne de stockage encore active.

Topologie physique documentée
Magasin de données monté sans écriture
Images des membres fragiles

Une suppression sur un volume mince évolue rapidement

TRIM, UNMAP et la réutilisation des blocs peuvent faire disparaître le contenu libéré. Éteindre la VM sans arrêter l’activité du magasin de données ne suffit pas si d’autres charges continuent d’écrire.

Une panne RAID doit être traitée avant VMFS ou NTFS

Si les membres physiques sont instables, reconstruire le volume en place ajoute du risque. La récupération RAID et NAS acquiert d’abord les disques et reconstitue leur géométrie sur des images.

La salle blanche traite un disque mécanique défaillant, pas la cohérence d’une chaîne d’instantanés.

Le volume invité est analysé après le conteneur virtuel

Réparer la partition interne ne corrige pas une chaîne d’instantanés incohérente.

Les couches sont ouvertes dans l’ordre : magasin de données, disque virtuel, partitions, système de fichiers, application. Chaque niveau est monté sans écriture lorsqu’il le permet. Les corrections logiques sont appliquées à une copie dérivée et documentée.

Sauter une couche peut cacher la cause réelle. Un système de fichiers invité marqué RAW peut provenir d’un delta manquant plutôt que d’une corruption interne ; lancer une réparation à ce niveau écrirait sur une reconstruction fausse. Les tailles de disque, secteurs, partitions et identifiants sont comparés à la configuration connue. Une fois le conteneur cohérent, NTFS, ReFS, ext4, XFS ou un autre format est analysé sur une branche distincte. Les résultats conservent ainsi leur provenance jusqu’au fichier final.

Magasin de données avant conteneur virtuel
Conteneur avant volume invité
Volume avant application métier

Un système invité peut contenir LVM, Storage Spaces ou chiffrement

Le VMDK ou VHDX n’est qu’un contenant. À l’intérieur, plusieurs volumes peuvent dépendre les uns des autres. Les métadonnées de chaque couche sont conservées avant extraction.

BitLocker et vTPM nécessitent leurs éléments légitimes

Une VM chiffrée peut dépendre d’une clé, d’un fichier de configuration, d’un gestionnaire de clés ou d’un TPM virtuel. Datastrophe ne contourne pas ces contrôles ; l’administrateur fournit les accès autorisés.

Réparer le système invité sur une chaîne mal assemblée peut valider un état hybride et détruire les indices utiles.

Les bases et services doivent être cohérents, pas seulement présents

Une VM qui démarre ne prouve pas l’intégrité de ses applications.

Bases SQL, annuaires, serveurs de fichiers et systèmes comptables sont contrôlés selon leur structure. Un démarrage forcé peut rejouer des journaux sur un état hybride. Les fichiers applicatifs sont plutôt extraits sur une copie et testés avec des versions compatibles.

La présence d’un MDF, d’un fichier de messagerie ou d’un répertoire d’annuaire ne garantit pas une reprise. Les journaux, fichiers de contrôle, clés et horodatages doivent appartenir au même état. Lorsque plusieurs VM formaient une application, leur cohérence temporelle est comparée : base, serveur de fichiers et contrôleur d’identité peuvent avoir été capturés à des instants différents. La validation privilégie des contrôles hors production et documente les transactions perdues ou les dépendances absentes plutôt que de promettre un redémarrage complet.

Les journaux de transaction peuvent compléter une base

Ils doivent appartenir à la même chronologie que les fichiers de données. Mélanger une base ancienne et un journal récent peut empêcher l’ouverture ou créer un résultat incohérent.

Un contrôleur de domaine demande une prudence particulière

Le remettre en réseau depuis un instantané ancien peut provoquer des conflits. La récupération des objets et la remise en service de l’infrastructure sont deux décisions séparées.

Les copies de travail portent une provenance claire

Plusieurs scénarios peuvent être testés sans modifier les fichiers reçus.

Chaque parent, delta et image physique conserve son empreinte et son rôle. Une branche de travail sert à réassembler la chaîne ; une autre à analyser le volume invité ; une autre encore à rechercher un disque supprimé. Cette séparation rend les résultats comparables.

Les fichiers volumineux sont identifiés par chemin, taille, empreinte et source, car une copie partielle peut conserver le même nom. Les ajustements de descripteur ne sont jamais appliqués à l’unique exemplaire reçu. Une branche peut reconstruire l’état juste avant l’incident ; une autre tester un instantané plus ancien mais complet. Les écarts sont consignés. Cette méthode permet de revenir sur une hypothèse sans recopier le magasin de données fragile et d’expliquer précisément de quel état provient chaque donnée remise.

Les fichiers volumineux ne sont pas recopiés au hasard

Des copies répétées consomment le magasin de données de destination et multiplient les risques de confusion. Un plan indique quelles sources sont immuables et quelles images peuvent recevoir des modifications.

La chronologie est conservée pendant l’extraction

Dates des fichiers hôtes, événements de l’hyperviseur et horloge invitée peuvent différer. Elles sont documentées pour retrouver la bonne version d’un document ou d’une base.

La validation suit les applications prioritaires

Le nombre de gigaoctets récupérés ne mesure pas la reprise d’activité.

Les volumes sont parcourus et les données essentielles ouvertes hors production. Partages, bases, courriels, configurations et profils sont testés selon l’objectif. Les fichiers incomplets ou provenant d’un instantané différent restent identifiés.

Le contrôle ne se limite pas à amorcer la VM. Un démarrage peut masquer des erreurs, lancer des mises à niveau ou modifier les journaux. Les dossiers prioritaires sont comparés à l’inventaire, les bases reçoivent des tests structurels et les services sont évalués dans un réseau isolé lorsque cela est approprié. Les identifiants, dates et versions d’application accompagnent le résultat. Une VM partiellement amorçable peut encore contenir des données valides, tandis qu’une VM qui démarre peut conserver des fichiers incohérents.

Une nouvelle VM est créée seulement à partir d’une copie

Elle utilise des interfaces et un réseau contrôlés pour éviter l’écriture sur les originaux ou un démarrage accidentel de services. Le premier démarrage n’est jamais le seul test.

La remise peut cibler des données plutôt qu’un serveur complet

Lorsque l’infrastructure doit être reconstruite, extraire une base saine ou un partage cohérent peut être plus sûr que livrer une VM fragile. Le format de sortie est convenu selon la reprise prévue.

L’inventaire technique accélère la soumission

Les relations entre les fichiers comptent davantage que leur taille totale.

Préparez le nom et la version de l’hyperviseur, les noms des magasins de données, les chemins, les UUID et la liste des instantanés. Indiquez l’événement, les consolidations tentées, le chiffrement, les sauvegardes et les services prioritaires. Ne renommez pas les fichiers avant de transmettre l’inventaire.

Ajoutez la topologie du stockage, les capacités, le type de provisionnement, la date du dernier démarrage sain et les tâches automatiques encore actives. Les journaux de l’hyperviseur et les fichiers de configuration sont utiles s’ils peuvent être copiés sans modifier le magasin de données ; n’exécutez pas de nettoyage pour les obtenir. La demande de soumission classe les bases, partages ou services essentiels. L’évaluation précise ensuite les copies nécessaires, les limites de cohérence et les validations possibles avant toute tentative de remise en service.

Indiquez enfin si plusieurs VM participaient au même service et si leurs instantanés ont été pris ensemble. Une base, son serveur applicatif et son annuaire récupérés à trois moments différents peuvent être individuellement lisibles mais collectivement incohérents. Cette dépendance temporelle oriente les branches à reconstruire et les tests à prévoir, sans confondre disponibilité d’un fichier et reprise fonctionnelle.

Une arborescence et des journaux peuvent précéder les médias

Ils permettent de vérifier que parents, deltas et configurations sont bien présents. Le transfert volumineux est ensuite organisé sans omettre un petit fichier indispensable.

La demande distingue données et remise en service

La demande de soumission précise les applications attendues et les délais. L’évaluation explique le périmètre récupérable ; elle ne promet pas qu’une VM endommagée redémarrera telle quelle.

FAQ

Questions fréquentes

Faut-il consolider les instantanés avant d’envoyer les fichiers ?

Non. Une consolidation écrit dans la chaîne et peut échouer en cours de route. Arrêtez les tâches, conservez tous les parents et deltas, puis fournissez l’inventaire et les journaux.

Un fichier VMDK sans descripteur peut-il être utilisé ?

Parfois. Le descripteur peut être recréé sur une copie si la géométrie, le type et les identifiants sont déterminables. Il faut aussi vérifier les parents et instantanés associés.

Pourquoi arrêter les autres VM du même magasin de données ?

Après une suppression ou une corruption, leurs écritures peuvent réutiliser les blocs recherchés. Selon l’architecture, il faut au minimum isoler le magasin de données affecté et préserver son support physique.

Une machine virtuelle récupérée peut-elle être remise en production directement ?

Elle doit d’abord être testée hors réseau et sur une copie. Les systèmes de fichiers et applications peuvent être incohérents malgré un démarrage réussi. Une reconstruction propre peut être préférable.

Que faut-il fournir pour une VM chiffrée avec vTPM ?

Conservez la configuration, les fichiers de clés ou le gestionnaire de clés, le vTPM, les identifiants et les accès autorisés. Le disque virtuel seul peut rester indéchiffrable.

Supports

Autres expertises

Évaluation

Un doute sur un support ou une panne ?

Datastrophe qualifie le risque avant toute intervention et vous indique la marche à suivre la plus prudente.

Demander une évaluation