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

Un disque virtuel n’est pas un fichier isolé : un parent, des snapshots et le stockage hôte peuvent tous être nécessaires pour retrouver la dernière version cohérente.

Demander un devis

La première mesure consiste à figer la chaîne

Démarrer, fusionner ou supprimer un snapshot réécrit des blocs et peut casser la relation avec son parent.

Arrêtez les opérations automatiques de l’hyperviseur sans lancer de consolidation. Relevez les noms, les tailles, les horodatages et la configuration de la machine. Une copie cohérente inclut les descripteurs, les parents, les deltas et les fichiers associés. Déplacer seulement le dernier VMDK ou VHDX produit souvent un disque incomplet, même si sa taille paraît plausible.

Le gel concerne aussi les sauvegardes, réplications et logiciels de supervision capables de créer ou supprimer un checkpoint. Les tâches actives sont notées avec leur heure sans attendre qu’elles terminent si elles écrivent encore sur la chaîne. Lorsque l’arrêt de l’hôte n’est pas immédiat, l’équipe isole la VM et organise une copie cohérente vers un stockage sain, sans utiliser une exportation qui fusionnerait silencieusement les couches.

Aucun redémarrage de test
Aucune suppression de snapshot
Inventaire avant déplacement

Les dates ne suffisent pas à identifier le parent

Des copies, restaurations ou changements d’heure peuvent tromper. Les identifiants et références internes sont croisés avec la configuration de la VM. Toute chaîne ambiguë est testée sur un clone, jamais sur le stockage original.

Le système hôte doit rester documenté

La version de VMware, d’Hyper-V ou d’un autre hyperviseur, le type de magasin de données et les actions récentes expliquent le format. Exporter au hasard peut modifier des fichiers. Les journaux déjà présents sont copiés sans relancer de tâche.

Une consolidation est une écriture massive, pas une opération de diagnostic.

Parent, delta et snapshot doivent former une histoire continue

Chaque couche ne contient que les blocs modifiés depuis la précédente.

Un delta seul ne possède pas tous les secteurs de la machine. Il faut retrouver sa base et appliquer les couches dans le bon ordre. Un identifiant divergent, un descripteur absent ou un snapshot tronqué interrompt cette histoire. La reconstruction peut corriger une référence sur une copie, mais ne fabrique pas les blocs qui n’existent dans aucun membre.

La chaîne est représentée avant toute correction : identifiant du contenu, parent attendu, taille virtuelle, type d’allocation et branche éventuelle. Les blocs hérités et modifiés sont ensuite résolus sur une copie. Un fichier au nom plus récent ne prend pas automatiquement la priorité ; une restauration ou un déplacement peut avoir changé ses dates. Les métadonnées internes et la cohérence du système invité départagent les candidats.

Vérification des identifiants parents
Classement des deltas sans les fusionner
Conservation des fichiers de configuration

Les descripteurs peuvent être reconstruits avec prudence

Géométrie, type d’allocation et références doivent correspondre aux fichiers de données. Une correction syntaxique sur clone peut rendre la chaîne lisible. Elle ne résout pas un extent absent ou écrasé.

Les branches concurrentes ne se mélangent pas

Deux snapshots issus du même parent peuvent représenter des états différents. Ils sont examinés séparément pour éviter de créer une chronologie artificielle. L’état recherché est choisi selon date et application critique.

Un snapshot n’est pas une sauvegarde autonome ; il dépend de toute sa chaîne.

Le stockage hôte peut être la vraie source de la panne

Un VMDK corrompu peut provenir d’un RAID dégradé, d’un NAS, d’un SSD ou d’une copie interrompue.

Avant d’analyser le conteneur, il faut sécuriser les supports qui le portent. Des secteurs absents ou des membres RAID désordonnés se propagent à chaque couche virtuelle. Les disques et métadonnées de l’hôte sont acquis sans reconstruction en place. La page RAID et NAS explique cette préservation multi-disques.

Le magasin de données peut ajouter thin provisioning, déduplication ou snapshots au niveau baie. Une zone logique absente dans le VMDK ne signifie donc pas toujours que le fichier lui-même a été modifié ; elle peut provenir d’un mapping perdu dessous. Le contrôleur, le cache, les LUN et les journaux existants sont inventoriés avec les fichiers virtuels. Cette cartographie relie les erreurs physiques aux extents réellement affectés dans chaque machine.

Arrêt des écritures du magasin de données
Identification de chaque membre
Copies avant reconstruction logique

Un support instable se lit avec priorité

Si un disque physique se dégrade, les zones contenant descripteurs, tables et VM critique peuvent passer en premier. Les erreurs restent cartographiées afin de relier chaque lacune au conteneur virtuel.

La salle blanche n’intervient qu’au niveau physique

Un disque dur appartenant à un magasin de données et dont les têtes sont défaillantes peut nécessiter une ouverture contrôlée. Un VMDK incohérent n’en bénéficie pas directement. Le diagnostic distingue clairement support, conteneur et invité.

Réparer le système de fichiers invité ne compense pas des blocs manquants sur le stockage physique.

Le conteneur et son système invité se réparent séparément

Rendre la chaîne lisible ne garantit pas que NTFS, ext4 ou la base interne soit cohérente.

La reconstruction du disque virtuel produit une vue de blocs, pas encore des fichiers validés. Partitions, volumes LVM, systèmes de fichiers et applications sont ensuite examinés en lecture seule. Une tentative de démarrage peut écrire des journaux et lancer des réparations ; elle n’est pas la première preuve recherchée.

Une copie de travail peut recevoir une réparation du conteneur, une autre une reconstruction du système de fichiers et une troisième rester comme référence. Ce découpage évite d’attribuer au mauvais niveau un dossier revenu après correction. Les secteurs absents sont conservés dans une carte et rapprochés des métadonnées invitées ; un volume montable avec des fichiers troués n’est pas déclaré cohérent.

Montage sans écriture
Analyse du volume invité
Tests d’applications sur des copies

Les partitions invitées ont leurs propres métadonnées

NTFS, ReFS, ext4 ou XFS réagissent différemment aux blocs absents. Journaux et copies de secours sont comparés sur un clone. Les fichiers par signature sont séparés de l’arborescence démontrée.

Les bases demandent une cohérence applicative

SQL, Exchange ou annuaires utilisent plusieurs fichiers et journaux. Un fichier présent n’est pas forcément montable. Une version compatible est utilisée pour contrôler pages, transactions et dépendances sans toucher à l’image de référence.

Une VM qui démarre peut modifier l’état que l’on cherchait à comprendre.

Chiffrement et clés restent attachés à chaque couche

Le magasin de données, le VMDK et le système invité peuvent être protégés indépendamment.

Une acquisition complète peut cumuler plusieurs chiffrements. Le gestionnaire, un coffre de clés, BitLocker ou LUKS peuvent intervenir. Conservez les configurations, le TPM virtuel, les certificats et les secrets légitimes. Datastrophe ne contourne pas les accès ; il détermine quelle couche bloque et si les éléments autorisés permettent de l’ouvrir.

Les sauvegardes de configuration du gestionnaire de clés, les certificats et les mots de passe sont datés et associés à la bonne infrastructure. Une clé valide pour le magasin de données ne remplace pas celle du système invité. L’ouverture s’effectue couche après couche sur des clones, avec un contrôle du volume obtenu à chaque étape. Les secrets sont transmis séparément des disques et ne sont pas réinscrits dans les sources.

Conservation des clés et certificats
Sauvegarde de la configuration du vTPM
Secrets transmis séparément

Le vTPM ne se recrée pas par simple import

Une nouvelle machine portant le même nom ne possède pas forcément les secrets de l’ancienne. Les fichiers et paramètres de sécurité d’origine doivent rester associés à la VM.

Déchiffrer n’efface pas les dommages de blocs

Une fois la clé appliquée, le volume peut encore contenir des secteurs absents. Le rapport distingue donc échec cryptographique, conteneur incomplet et corruption du système invité.

Sans la clé d’une couche, les blocs suivants restent inintelligibles même s’ils sont intacts.

Les copies de travail permettent de tester sans consolider

Chaque hypothèse est appliquée à un clone identifiable.

Les fichiers source sont protégés et copiés avec contrôle d’intégrité. Une chaîne reconstruite, un descripteur corrigé ou un volume réparé vit dans un espace séparé. Le processus de récupération conserve cette traçabilité depuis l’inventaire jusqu’à la validation. Les résultats peuvent ainsi être reproduits ou comparés.

Une empreinte est calculée pour chaque élément copié, y compris les petits descripteurs dont quelques octets peuvent changer toute la parenté. Les dossiers de travail indiquent la chaîne utilisée et les corrections appliquées. Si l’espace disponible impose une sélection, les VM et services prioritaires sont définis avant la copie ; un stockage presque plein ne doit pas provoquer un nouveau snapshot ou une interruption au milieu d’un delta critique.

Empreintes des fichiers sources
Clone distinct par hypothèse
Aucune écriture sur le magasin de données original

La capacité de travail se prévoit avant la copie

Snapshots, images et duplicatas exigent souvent plusieurs fois la taille apparente de la VM. Un espace sain, stable et non dédupliqué à l’aveugle évite d’interrompre l’acquisition.

Les priorités réduisent la remise en route aveugle

Si seules une base et quelques dossiers sont essentiels, ils sont vérifiés avant de tenter un démarrage complet. Cette approche mesure rapidement l’utilité du résultat sans déclencher des services qui écrivent.

Copier vers un volume insuffisant ou synchronisé peut créer une nouvelle chaîne incomplète.

Une VM récupérée se juge par ses services et fichiers

L’écran de connexion n’est pas un contrôle suffisant.

La validation combine volumes, fichiers et applications prioritaires. Documents, partages, bases et journaux sont testés sur une copie isolée. Si un démarrage est utile, il se fait sans réseau de production et après duplication. Les fichiers partiels et les services non validés restent explicitement signalés.

L’environnement de contrôle neutralise les interfaces réseau, les tâches planifiées et les réplications avant le premier démarrage. Une base est testée avec sa version compatible et un partage avec des fichiers représentatifs, pas seulement par l’apparition d’une lettre de lecteur. Les identifiants de machine, adresses et rôles sont consignés pour éviter qu’une copie récupérée se présente comme le service actif lors de la migration.

Contrôle des systèmes de fichiers
Test des applications critiques
Isolement de tout démarrage

La restauration vers la production vient en dernier

Après validation, les données ou la VM sont copiées vers une infrastructure saine. Les adresses, tâches et réplications sont contrôlées avant connexion afin d’éviter doubles services et écritures concurrentes.

Les limites suivent les blocs absents

Une carte de lacunes permet de relier un snapshot tronqué à des fichiers ou pages de base touchés. Cette précision vaut davantage qu’un pourcentage global de disque virtuel récupéré.

Une machine qui boote peut encore cacher une base incohérente ou un snapshot manquant.

L’inventaire initial évite de perdre un membre de chaîne

L’hyperviseur, le magasin de données, les instantanés, le chiffrement et l’application doivent être décrits ensemble.

Préparez la version de l’hyperviseur, la liste des fichiers, leurs tailles et leurs dates, ainsi que la dernière opération. Indiquez la panne de stockage, la consolidation, la restauration ou la copie interrompue. Listez les VM, les services et les périodes prioritaires, ainsi que les clés et les sauvegardes. N’exportez pas et ne redémarrez pas pour compléter ces informations.

Un inventaire de répertoire ou des captures déjà disponibles peuvent être transmis avant les supports, avec les noms complets plutôt qu’une sélection renommée. Pour un dossier pris en charge depuis la Belgique, le volume à transférer, le chiffrement et le mode d’acheminement sont définis avant toute copie. Les secrets suivent un canal séparé. L’évaluation précise ensuite si le besoin porte sur des fichiers, une application ou une machine amorçable.

Copie des configurations existantes
Identification des parents et deltas
Liste des applications critiques

Les journaux existants apportent le contexte

Ils peuvent confirmer une chaîne ou une erreur de magasin de données. Ils sont copiés tels quels ; aucun nouveau cycle de consolidation n’est lancé pour produire davantage de traces.

Le devis cadre le niveau attendu

La demande de devis précise s’il faut des fichiers, une base ou une VM amorçable. Après inventaire, la méthode et les limites sont annoncées selon les éléments réellement disponibles.

Un fichier manquant doit être signalé avant toute reconstruction, pas remplacé silencieusement par un snapshot plus ancien.

FAQ

Questions fréquentes

Faut-il consolider les snapshots avant l’analyse ?

Non. La consolidation écrit beaucoup de blocs et peut échouer au milieu. Figez la machine, inventoriez les parents et deltas, puis copiez l’ensemble. Toute reconstruction est tentée sur un clone.

Le dernier VMDK suffit-il pour récupérer la VM ?

Pas toujours. Un delta contient seulement les changements depuis son parent. Il faut généralement le fichier de base, les snapshots précédents, les descripteurs et la configuration. Un membre absent laisse des blocs impossibles à inventer.

Peut-on simplement démarrer la copie de la VM ?

Le démarrage écrit des journaux et peut lancer des réparations ou services. Il intervient seulement sur une copie isolée, après examen du conteneur et du volume invité, puis sert à valider une fonction précise.

Que se passe-t-il si le magasin de données RAID est endommagé ?

Les membres physiques et les métadonnées RAID sont préservés avant la VM. Le stockage est reconstruit sur des copies, puis les fichiers virtuels sont extraits. Réparer uniquement le VMDK ne compense pas les blocs manquants dessous.

Une VM récupérée est-elle forcément prête pour la production ?

Non. Elle peut démarrer tout en contenant une base incohérente ou des fichiers partiels. Applications et données prioritaires sont contrôlées hors production. La remise en ligne vient après validation et sur une infrastructure saine.

Supports

Autres expertises

Diagnostic

Un doute sur un support ou une panne ?

Datastrophe évalue le risque avant toute intervention et vous oriente vers la démarche la plus prudente.

Demander un diagnostic