Une machine virtuelle inaccessible ou qui ne démarre plus peut rapidement bloquer une activité complète. Pour une TPE, une PME, un cabinet, une association ou un prestataire informatique, cela peut concerner un serveur de fichiers, une application métier, une base de données, un contrôleur de domaine, un serveur comptable ou un environnement de production.
Dans ce type de situation, le problème ne vient pas toujours de l’hyperviseur lui-même. La panne peut concerner le fichier disque virtuel, le système invité, le stockage physique, le NAS, le RAID, un snapshot, une corruption logique ou une chaîne de sauvegarde défaillante.
Si la machine virtuelle contient des données importantes, il est préférable d’éviter les tentatives de réparation au hasard, les conversions non maîtrisées ou les restaurations qui écrasent l’existant. Un diagnostic permet d’identifier l’origine du problème avant d’aggraver la situation.
Qu’est-ce qu’un fichier VMDK ou VHDX ?
Une machine virtuelle fonctionne comme un ordinateur logiciel. Elle possède généralement un ou plusieurs fichiers représentant ses disques virtuels. Ces fichiers contiennent le système d’exploitation, les applications et les données de la machine virtuelle.
Les formats les plus courants sont notamment :
- VMDK, utilisé dans les environnements VMware ;
- VHD et VHDX, utilisés dans les environnements Microsoft Hyper-V ;
- d’autres formats selon les solutions de virtualisation ou de sauvegarde.
Dans le cadre d’une récupération de données, l’objectif n’est pas seulement de “relancer la VM”. Il faut surtout comprendre si les données contenues dans le disque virtuel sont encore cohérentes et accessibles.
Pour les environnements serveurs, RAID ou virtualisés, AxonRecup propose une prise en charge dédiée à la récupération de données RAID, serveur et une autre dédiée uniquement à la récupération de données à l’intérieur des machines virtuelles.
Pourquoi une machine virtuelle peut-elle devenir inaccessible ?
Une machine virtuelle peut devenir inaccessible pour de nombreuses raisons. La difficulté vient du fait que plusieurs couches techniques sont impliquées : l’hyperviseur, le système invité, le fichier disque virtuel, le datastore, le NAS, le serveur physique ou encore le RAID sous-jacent.
Un fichier disque virtuel endommagé
Le fichier VMDK, VHD ou VHDX peut être corrompu, incomplet, tronqué ou incohérent. La machine virtuelle peut alors refuser de démarrer, afficher une erreur ou ne plus accéder à certaines données.
Un snapshot problématique
Les snapshots peuvent être utiles, mais ils ajoutent une dépendance supplémentaire. Un snapshot supprimé, incomplet, mal consolidé ou corrompu peut empêcher la VM de retrouver un état cohérent.
Un datastore inaccessible
Le problème peut venir du stockage qui héberge la machine virtuelle : volume NAS, baie RAID, datastore VMFS, partage réseau, disque externe, serveur ou support de sauvegarde.
Une panne du serveur ou du NAS
Si la machine virtuelle est stockée sur un serveur, un NAS ou une configuration RAID, la panne peut se situer au niveau physique : disque défaillant, erreurs de lecture, volume inaccessible, RAID dégradé ou système de fichiers endommagé.
Une corruption du système invité
Dans certains cas, le fichier disque virtuel est encore exploitable, mais le système installé dans la VM ne démarre plus. Les données peuvent alors être récupérées sans nécessairement remettre la machine virtuelle en état de fonctionnement complet.
Une sauvegarde inutilisable
Une sauvegarde de VM peut être incomplète, trop ancienne, corrompue ou impossible à restaurer. Il arrive aussi qu’une restauration écrase un état plus récent contenant encore des données utiles.
Les signes qui doivent alerter
Une machine virtuelle inaccessible ne se manifeste pas toujours de la même manière. Certains symptômes permettent cependant d’orienter le diagnostic.
- la VM ne démarre plus ;
- l’hyperviseur indique un disque virtuel manquant ou invalide ;
- un fichier VMDK, VHD ou VHDX semble incomplet ;
- un snapshot ne se consolide pas correctement ;
- le datastore n’est plus monté ;
- le NAS ou le serveur hébergeant la VM est inaccessible ;
- la restauration d’une sauvegarde échoue ;
- la VM démarre mais certains volumes internes sont absents ;
- des fichiers métier, bases de données ou dossiers partagés ne sont plus accessibles.
Ces symptômes ne permettent pas toujours de savoir immédiatement si le problème vient du fichier virtuel, du stockage physique ou du système invité. C’est justement l’intérêt d’un diagnostic structuré.
Ce qu’il ne faut surtout pas faire avec une machine virtuelle inaccessible
Lorsqu’une VM ne démarre plus, certaines manipulations peuvent compliquer l’analyse ou rendre la récupération plus difficile.
Ne pas supprimer les snapshots sans analyse
Supprimer ou consolider des snapshots sans comprendre la chaîne existante peut modifier l’état de la machine virtuelle. Si les fichiers sont incohérents ou si le stockage est instable, cette opération peut aggraver la situation.
Ne pas déplacer les fichiers au hasard
Déplacer uniquement certains fichiers VMDK, VHDX, AVHDX, delta ou fichiers de configuration peut casser les liens nécessaires au remontage de la machine virtuelle. Il faut conserver l’arborescence complète autant que possible.
Ne pas lancer plusieurs conversions successives
Convertir un VMDK en VHDX, puis tenter une autre conversion ou une importation dans un nouvel hyperviseur peut modifier les métadonnées ou produire des fichiers incomplets si la source est déjà corrompue. Évitez de faire ces manipulations sur les fichiers originaux.
Ne pas restaurer une sauvegarde par-dessus l’environnement existant
Une restauration mal ciblée peut écraser des fichiers encore utiles. Avant toute restauration, il est préférable de préserver une copie de l’état actuel, même si la VM ne démarre plus.
Ne pas réparer le système invité avant de sécuriser les données
Les commandes de réparation du système, les corrections de démarrage ou les outils automatiques peuvent écrire dans le disque virtuel. Si les données sont prioritaires, il faut d’abord sécuriser le contenu récupérable.
Ne pas continuer à solliciter un stockage physique instable
Si la VM est hébergée sur un NAS, un RAID ou un serveur dont un disque est défaillant, chaque tentative de démarrage ou de copie peut solliciter davantage les supports physiques.
Si la machine virtuelle contient des données importantes, le bon réflexe est de conserver l’état actuel des fichiers et de demander un diagnostic avant toute manipulation irréversible.
Les bons réflexes avant toute récupération
Avant de tenter une réparation ou une restauration, l’objectif est de préserver les éléments nécessaires à l’analyse.
Conserver tous les fichiers liés à la VM
Il ne faut pas isoler uniquement le fichier principal. Les fichiers de configuration, snapshots, disques différentiels, journaux et fichiers associés peuvent être utiles pour comprendre l’état de la machine virtuelle.
Noter l’environnement d’origine
Il est utile de conserver les informations disponibles : solution utilisée, version de l’hyperviseur, emplacement du datastore, type de stockage, présence de snapshots, type de sauvegarde, messages d’erreur et date de la panne.
Éviter les écritures sur le stockage source
Si la VM est stockée sur un NAS, un serveur ou un RAID instable, il faut éviter les opérations lourdes ou les restaurations sur le même volume avant diagnostic.
Identifier les données prioritaires
La récupération ne vise pas toujours à redémarrer la VM complète. Dans certains cas, le plus important est d’extraire une base de données, un dossier partagé, une comptabilité, une application métier ou des documents clients.
Vérifier l’existence d’une sauvegarde exploitable
Une sauvegarde peut permettre une restauration rapide si elle est saine, complète et suffisamment récente. En revanche, si la sauvegarde est corrompue, ancienne ou incomplète, l’analyse de l’état actuel de la VM reste importante. Pour limiter ce type de situation, les fondamentaux de l’ANSSI sur la sauvegarde des systèmes d’information rappellent l’importance d’organiser, protéger et vérifier régulièrement ses sauvegardes.
Quand contacter un spécialiste ?
Une assistance spécialisée est recommandée lorsque la machine virtuelle contient des données importantes ou que plusieurs couches techniques sont en cause.
Un diagnostic est particulièrement conseillé si :
- la VM ne démarre plus ;
- le fichier VMDK, VHD ou VHDX est corrompu ou incomplet ;
- un snapshot pose problème ;
- le datastore n’est plus accessible ;
- la VM était hébergée sur un NAS, un serveur ou un RAID en erreur ;
- la restauration de sauvegarde échoue ;
- la VM contient des bases de données, fichiers clients, données comptables ou documents métier ;
- les tentatives de conversion ou d’importation ne donnent aucun résultat fiable.
Dans ces cas, la priorité est d’éviter les opérations qui modifient les fichiers sources et de travailler sur une copie lorsque cela est possible.
Combien coûte une récupération de données sur machine virtuelle ?
La récupération de données sur machine virtuelle concerne principalement les environnements professionnels : serveur, NAS, RAID, sauvegarde, Hyper-V, VMware, VirtualBox ou Proxmox.
Le tarif dépend de la complexité du dossier : type de fichier virtuel, présence de snapshots, taille du volume, etc.
À titre indicatif, une récupération sur machine virtuelle démarre généralement à partir de 390 € HT par VM.
Les dossiers plus complexes, impliquant par exemple un NAS, un serveur RAID ou plusieurs supports en erreur, font l’objet d’une prise en charge dédiée à la récupération de données RAID, serveur avec un devis spécifique.
Le diagnostic permet d’évaluer la faisabilité, les données prioritaires et les opérations nécessaires avant toute intervention.
Comment AxonRecup prend en charge une VM inaccessible
La prise en charge commence par l’analyse de l’environnement fourni : fichiers de la machine virtuelle, disques virtuels, snapshots, support source, NAS, RAID, serveur ou sauvegarde.
Selon le cas, l’intervention peut comprendre :
- l’analyse des fichiers VMDK, VHD ou VHDX ;
- la vérification de la cohérence des snapshots ;
- la reconstruction logique du disque virtuel lorsque cela est possible ;
- l’analyse du système de fichiers interne de la VM ;
- l’extraction des fichiers prioritaires ;
- la prise en charge du support physique si le stockage source est défaillant ;
- la reconstruction d’un RAID ou d’un volume NAS lorsque la VM dépend d’un stockage multi-disques.
Lorsque le problème vient du support physique, l’analyse ne se limite pas au fichier virtuel. Il peut être nécessaire de sécuriser les disques sources, de cloner les supports ou de reconstruire le volume avant d’accéder à la machine virtuelle.
Le dossier est traité directement par AxonRecup, sans intermédiaire. Les fichiers confiés sont manipulés dans un environnement dédié à la récupération de données, avec une attention particulière portée à la confidentialité des informations professionnelles ou personnelles.
Après le diagnostic, un retour clair vous est transmis avec les possibilités de récupération, les limites éventuelles et le tarif proposé. L’intervention complète ne démarre qu’après validation du devis.
Faut-il récupérer toute la machine virtuelle ou seulement les fichiers ?
Dans certains dossiers, il est possible de récupérer suffisamment d’éléments pour relancer la machine virtuelle. Dans d’autres cas, l’objectif le plus réaliste consiste à extraire les données importantes depuis le disque virtuel.
La meilleure approche dépend du besoin réel :
- redémarrer une application métier ;
- récupérer une base de données ;
- extraire des dossiers partagés ;
- retrouver des fichiers utilisateurs ;
- récupérer une archive ou un export ;
- restaurer un serveur complet dans un nouvel environnement.
Lors du diagnostic, il est donc important d’indiquer les données prioritaires. Cela permet d’orienter la récupération vers ce qui a le plus de valeur pour l’activité ou pour l’utilisateur.
Besoin d’un diagnostic pour une machine virtuelle inaccessible ?
Si une machine virtuelle ne démarre plus, si un fichier VMDK ou VHDX semble corrompu, ou si une sauvegarde de VM ne se restaure pas correctement, il est préférable d’éviter les manipulations qui modifient l’état actuel des fichiers.
AxonRecup peut analyser votre environnement, identifier l’origine de la panne et évaluer les possibilités de récupération. La prise en charge est réalisée directement au laboratoire, avec confidentialité et validation du devis avant intervention.
Demandez un diagnostic pour évaluer les chances de récupération de vos données.
FAQ – Machine virtuelle inaccessible, VMDK et VHDX
Peut-on récupérer les données d’une machine virtuelle qui ne démarre plus ?
Oui, dans de nombreux cas. Même si la VM ne démarre plus, les données peuvent encore être présentes dans le disque virtuel ou dans le stockage source.
Quelle différence entre VMDK et VHDX ?
VMDK est un format de disque virtuel utilisé dans les environnements VMware. VHDX est un format de disque virtuel utilisé notamment avec Microsoft Hyper-V.
Faut-il essayer de convertir un VMDK en VHDX ?
Pas sans diagnostic si le fichier source est suspect ou si les données sont importantes. Une conversion réalisée sur un fichier corrompu peut produire un résultat incomplet ou inexploitable.
Un snapshot supprimé peut-il empêcher une récupération ?
Un snapshot supprimé, incomplet ou mal consolidé peut compliquer l’analyse. Il est important de conserver tous les fichiers restants et d’éviter de modifier davantage l’état de la VM.
Peut-on récupérer uniquement certains dossiers d’une VM ?
Oui, dans certains cas. Il n’est pas toujours nécessaire de redémarrer la machine virtuelle complète. L’extraction de dossiers, bases de données ou fichiers prioritaires peut être possible.
Que faire si la VM est stockée sur un NAS en panne ?
Il faut d’abord analyser le stockage source. Si le NAS ou le RAID est défaillant, la récupération de la VM dépendra de l’état des disques et de la possibilité de reconstruire le volume.
Combien coûte une récupération de données sur VMDK ou VHDX ?
Le tarif dépend de la panne, de la taille de la VM, de l’état du support source, de la présence de snapshots et du niveau de reconstruction nécessaire.