L'utilisation de ce site, notamment notre base de connaissances, est soumise à l'acceptation de nos « conditions générales d'utilisation ». BSC DataRecovery ne pourra être tenue responsable des conséquences éventuelles relatives à l'application des conseils de cet article. Pour toute question concernant la récupération de vos données, n'hésitez pas à nous contacter via notre page « contact ».
Le serveur hôte redémarre et le datastore n'apparaît plus. Ou une machine virtuelle a été supprimée « du disque » par erreur. Ou encore un snapshot oublié depuis des mois a rempli le stockage, la consolidation a échoué, et la VM refuse de démarrer. Dans tous les cas, c'est rarement un seul poste qui s'arrête : c'est le serveur de fichiers, la comptabilité, la base métier, parfois toute l'informatique de l'entreprise, rangée dans quelques gros fichiers.
Le réflexe est de lancer un logiciel de récupération. Il tourne des heures et ne trouve rien d'utile, ou une montagne de fichiers sans nom. Ce n'est pas parce que les données ont disparu : c'est parce qu'une machine virtuelle est un conteneur rangé dans un conteneur, lui-même rangé dans un autre. Voici comment c'est construit, ce qui se récupère selon la panne, et les gestes qui font perdre ce qui était encore récupérable.
Arrêtez toute écriture sur le stockage concerné : éteignez les VM qui y tournent encore, suspendez sauvegardes et réplications
N'acceptez aucune proposition de l'hyperviseur qui touche au volume : formatage, nouvelle signature, réparation, réinitialisation du pool
Un datastore inaccessible ne veut pas dire des VM perdues : dans la plupart des cas, les disques virtuels sont intacts
VM supprimée : sur SSD ou baie flash, la récupération automatique d'espace peut vider les blocs libérés très vite. Chaque heure compte
Snapshot cassé : ne revenez pas au snapshot, ne supprimez pas de fichiers de différences, ne lancez pas chkdsk dans la VM
Tarifs de 90 € à 790 € TTC et plus pour un disque, 190 € de reconstruction pour un datastore RAID ou NAS. Diagnostic gratuit, pas de données, pas de frais (hors forfait salle blanche)
Une machine virtuelle croit avoir un vrai disque dur. En réalité, ce disque est un fichier (ou un volume logique) posé sur le stockage de l'hôte. Pour atteindre un document Word rangé dans la VM, il faut traverser plusieurs couches, dans l'ordre :
1. Les disques physiques du serveur ou de la baie de stockage.
2. Le RAID qui les assemble en un seul volume (contrôleur matériel, RAID logiciel, NAS).
3. Le système de fichiers de l'hôte, celui du datastore : VMFS chez VMware ESXi, NTFS ou ReFS chez Hyper-V, et chez Proxmox selon l'installation un groupe de volumes LVM-thin, un pool ZFS ou un simple répertoire.
4. Le disque virtuel de la VM : fichiers .vmdk chez VMware, .vhdx chez Hyper-V, fichiers .qcow2 ou .raw, ou volumes logiques chez Proxmox. S'il y a des snapshots, ce n'est pas un fichier mais une chaîne de fichiers qui dépendent les uns des autres.
5. La table de partitions et le système de fichiers de la VM (NTFS pour un Windows Server, ext4 ou XFS pour un Linux).
6. Vos fichiers, enfin.
Une panne peut toucher n'importe laquelle de ces couches, et chacune doit être rouverte correctement pour que la suivante soit lisible. C'est ce qui rend ces dossiers techniques, mais aussi ce qui les rend souvent très favorables : une couche abîmée n'efface pas les autres.
Pourquoi les logiciels classiques ne voient rien
Un logiciel de récupération grand public sait lire une couche : il cherche des partitions et des fichiers sur un disque. Face à une infrastructure virtuelle, il bute sur trois obstacles.
Lancé sur un seul disque d'un RAID, il ne voit que des tranches de fichiers entrecoupées de parité. Aucun disque virtuel n'est lisible tant que la grappe n'est pas réassemblée
Le système de fichiers de l'hôte n'est pas toujours reconnu. VMFS, LVM-thin ou ZFS ne sont pas des formats de PC de bureau : beaucoup d'outils ne les ouvrent tout simplement pas, ou mal
Un disque virtuel est un fichier géant et sans signature exploitable. La recherche « par signature » retrouve des photos ou des PDF grâce à leur en-tête. Un disque virtuel de 500 Go ou 2 To n'est pas un fichier qu'on repère ainsi, surtout s'il était en allocation dynamique (thin provisioning) et donc éparpillé sur le datastore au fil de sa croissance. Le logiciel ressort, au mieux, des milliers de fichiers anonymes trouvés à l'intérieur, sans leur nom ni leur dossier
Il y a pire : lancer ce logiciel depuis l'hôte, sur le datastore en panne, ou y enregistrer le résultat, écrit précisément là où se trouvent les données à sauver. Voir les limites des logiciels de récupération gratuits.
Datastore inaccessible ou disparu
C'est le cas le plus fréquent, et le plus favorable. Le datastore ne remonte plus après une coupure de courant, un contrôleur RAID mort, une grappe dégradée qui a perdu un second disque, ou une corruption des métadonnées du système de fichiers de l'hôte. L'hyperviseur annonce un volume introuvable, non monté, ou un disque « vierge ».
Dans l'immense majorité de ces cas, les disques virtuels sont intacts : c'est l'accès qui est cassé, pas le contenu. Une fois le RAID reconstruit et le système de fichiers de l'hôte relu, les VM ressortent complètes.
Le danger vient de l'hyperviseur lui-même. Quand il découvre un volume qu'il ne reconnaît plus, il propose volontiers de l'ajouter comme nouveau stockage, avec une option de formatage, ou de lui attribuer une nouvelle signature. Formater efface l'index du datastore. Changer la signature modifie les métadonnées d'un volume qu'on n'a pas encore sauvé. Dans le doute, n'acceptez rien : notez le message exact, faites une capture d'écran, et arrêtez-vous là.
Si le datastore est hébergé sur un NAS (partage NFS ou volume iSCSI), il y a une couche de plus : les LUN iSCSI sont souvent des fichiers stockés sur le NAS lui-même. La démarche est la même, mais ce sont les disques du NAS qu'il faut nous confier. Voir aussi NAS Synology en panne : récupérer les données.
Machine virtuelle supprimée
Une VM effacée « du disque » depuis la console d'administration, un disque virtuel détaché puis supprimé, un volume logique Proxmox retiré avec la VM : les données ne sont pas effacées sur le moment, c'est leur emplacement qui est déclaré libre.
Les chances dépendent de trois choses :
Ce qui a été écrit depuis. Chaque nouvelle VM, chaque snapshot, chaque sauvegarde déposée sur le datastore peut réutiliser l'espace libéré. C'est le facteur numéro un : arrêtez toute écriture sur ce stockage dès que vous vous rendez compte de l'erreur
Le type de stockage. Sur des disques durs classiques, l'espace libéré garde ses données tant qu'il n'est pas réécrit. Sur des SSD ou une baie 100 % flash, les hyperviseurs récents savent signaler l'espace libéré au stockage (récupération automatique d'espace, UNMAP, option discard). C'est l'équivalent du TRIM d'un SSD de PC : les blocs rendus peuvent être vidés très vite, et la récupération devient alors beaucoup plus incertaine. Voir SSD formaté ou fichiers supprimés : ce que change le TRIM
L'allocation du disque virtuel. Un disque alloué d'un seul tenant (thick) occupe une zone continue, plus simple à retrouver. Un disque dynamique (thin) est dispersé en morceaux sur tout le datastore, et c'est la carte de ces morceaux qu'il faut reconstituer
Même quand le fichier du disque virtuel ne peut pas être reconstitué en entier, il reste souvent une voie : rechercher directement, dans l'espace brut du datastore, les structures du système de fichiers de la VM (celles du NTFS d'un Windows Server, par exemple). Elles permettent de retrouver les fichiers de la VM avec leurs noms et leurs dossiers, sans passer par le disque virtuel disparu.
Snapshot cassé ou chaîne de disques incohérente
Un snapshot n'est pas une sauvegarde : c'est un fichier de différences. À partir du moment où il est pris, la VM n'écrit plus dans son disque d'origine mais dans ce nouveau fichier (fichiers -000001.vmdk chez VMware, .avhdx chez Hyper-V, snapshots internes d'un .qcow2 ou de volumes LVM-thin et ZFS chez Proxmox). Chaque snapshot supplémentaire ajoute un maillon. Le disque « réel » de la VM, c'est la chaîne entière, dans le bon ordre.
Les pannes typiques :
un snapshot oublié qui grossit pendant des mois jusqu'à remplir le datastore, ce qui arrête toutes les VM du stockage
une consolidation (ou fusion) qui échoue en cours de route, laissant la chaîne à moitié fusionnée
un fichier de différences supprimé pour gagner de la place, parce qu'il « ne servait à rien »
une chaîne dont les liens internes ne correspondent plus (fichier restauré d'une autre date, copie partielle), et une VM qui démarre sur un état vieux de plusieurs mois, ou qui refuse de démarrer
Tant que les fichiers de la chaîne existent encore, même abîmés, les données récentes sont en principe là. Ce qui les fait perdre, ce sont les gestes suivants :
1. Revenir au snapshot (revert) : la VM repart de l'état du snapshot et abandonne toutes les modifications faites depuis. Parfois des mois de comptabilité.
2. Supprimer les fichiers de différences à la main, ou « tout supprimer » dans le gestionnaire de snapshots sans savoir si la fusion va aboutir sur un stockage plein.
3. Relancer la consolidation en boucle sur un datastore saturé ou un disque qui faiblit.
4. Démarrer la VM sur le disque de base seul, en rattachant manuellement l'ancien fichier : le système de la VM démarre sur des données périmées et commence à écrire dedans.
Au laboratoire, la chaîne est reconstruite virtuellement, maillon par maillon, sur des copies : on vérifie l'ordre et la cohérence de chaque fichier de différences avant de présenter le résultat comme un seul disque.
Disque virtuel VHDX ou VMDK corrompu
Après un plantage de l'hôte, une coupure de courant ou un stockage qui a renvoyé des erreurs de lecture, l'hyperviseur peut déclarer un disque virtuel corrompu ou illisible. Plusieurs cas se cachent derrière ce message :
l'en-tête ou la table interne du fichier est abîmé (un VHDX dynamique, par exemple, garde sa propre table d'allocation et un journal) : le contenu de la VM est intact, c'est le fichier qui ne sait plus décrire où il range ses blocs
le fichier est incomplet parce que le système de fichiers de l'hôte a perdu une partie de sa carte
le système de fichiers de la VM est lui-même endommagé, et le disque virtuel n'y est pour rien
Chaque cas se traite à un niveau différent, et c'est tout l'intérêt de travailler couche par couche plutôt que de lancer une réparation globale.
Surtout, ne lancez pas chkdsk (ou fsck) à l'intérieur de la VM pour « réparer » : il écrit dans le disque virtuel, lui-même posé sur un stockage peut-être défaillant, et empile une corruption sur une autre. Voir pourquoi chkdsk peut détruire vos données.
Proxmox : volumes LVM-thin et pools ZFS
Sur une installation Proxmox standard, les disques des VM ne sont souvent pas des fichiers mais des volumes logiques dans un pool LVM-thin, ou des volumes dans un pool ZFS. Deux pannes reviennent :
les métadonnées du pool LVM-thin sont abîmées (souvent après que le pool s'est rempli à 100 %) : tous les volumes de VM deviennent inaccessibles d'un coup, alors que les données sont toujours sur les disques
le pool ZFS refuse de s'importer après une coupure ou la perte d'un disque
Les outils en ligne de commande proposent alors des réparations ou des imports « forcés », dont certains abandonnent les dernières transactions ou réécrivent les métadonnées. À ne pas tenter sans avoir d'abord une copie de chaque disque.
Rançongiciel sur l'hyperviseur
Certains rançongiciels visent directement les hôtes de virtualisation et chiffrent les disques virtuels. Sur des fichiers de plusieurs centaines de Go, beaucoup ne chiffrent qu'une partie du fichier pour aller vite. Une partie du contenu de la VM reste alors en clair et peut être exploitée. Le résultat est très variable d'un cas à l'autre, mais avant de réinstaller l'hôte ou de formater le datastore, faites évaluer les fichiers chiffrés : ne les effacez pas.
1. Arrêtez les écritures sur le stockage concerné. Éteignez les VM qui y tournent encore, suspendez les sauvegardes planifiées et les tâches de réplication, ne créez rien dessus.
2. N'acceptez aucune proposition de l'hyperviseur qui touche au volume : formatage, nouvelle signature, réparation, réinitialisation du pool.
3. Notez l'environnement : hyperviseur et version (ESXi 7 ou 8, Windows Server avec Hyper-V, Proxmox VE...), type de stockage (disques locaux en RAID, NAS, baie SAN), disques durs ou SSD, VM concernées et leur taille, présence de snapshots.
4. Racontez ce qui a déjà été tenté : consolidation, retour au snapshot, suppression de fichiers, reconstruction du RAID. Cela nous dit ce qui a été écrit, et où chercher.
5. Listez les priorités : quelle VM d'abord, et dans cette VM quels dossiers ou quelle base (comptabilité, ERP, messagerie). Sur une infrastructure de plusieurs To, commencer par l'essentiel change tout.
6. Envoyez tous les disques du stockage, y compris ceux déclarés défaillants et ceux de remplacement, chacun repéré avec son numéro de baie. Méthode détaillée dans envoyer les disques d'un NAS ou d'un RAID : la règle des baies. Si la panne a commencé par un RAID dégradé, lisez aussi RAID 5 dégradé : que faire.
Si l'hyperviseur tourne encore et que seule une VM pose problème, vous pouvez aussi copier les fichiers de la VM (tous les fichiers de son dossier, snapshots compris) vers un autre support, sans les modifier, et nous confier cette copie. Mais si le datastore est instable, ne multipliez pas les lectures : envoyez les disques.
1. Copie de chaque disque. Chaque disque est lu séparément sur un équipement de laboratoire ; un disque en panne matérielle est réparé ou stabilisé avant d'être copié. Les originaux ne sont plus jamais remis dans un serveur.
2. Reconstruction virtuelle, couche par couche, en lecture seule. À partir des copies : le RAID est réassemblé, puis le système de fichiers du datastore relu, puis chaque disque virtuel (avec sa chaîne de snapshots) ouvert comme un disque à part entière, et enfin le système de fichiers de la VM. Chaque couche sert à vérifier la précédente : si le RAID est mal reconstruit, le datastore ne s'ouvre pas proprement ; si la chaîne de snapshots est dans le mauvais ordre, le système de fichiers de la VM le trahit aussitôt.
3. Restitution sous la forme utile. Selon le besoin : les fichiers de la VM (documents, bases de données exportées), ou le disque virtuel complet, remis au bon format pour être réimporté dans l'hyperviseur et redémarré. Dans les deux cas, vous vérifiez le résultat sur la liste avant de payer : voir vérifier la liste des fichiers récupérés avant paiement.
Pour les délais et les chances de réussite, voir taux de réussite et délais d'une récupération de données, et pour le budget combien coûte une récupération de données.
Pour une entreprise, chaque jour sans son serveur de virtualisation compte. Voici les ordres de grandeur, à partir de la réception des disques :
L'option prioritaire (+50 %) place votre dossier en tête de file dès sa réception. Elle supprime l'attente, pas le temps technique : copier un disque fatigué sans l'achever ne se fait pas plus vite. Nous ne garantissons donc pas de délai avant d'avoir vu les disques.
* Salle blanche, échange de têtes : forfait ferme de diagnostic approfondi en salle blanche (disque donneur compris), non remboursable, puis récupération des données à partir de 490 € TTC, uniquement en cas de succès.
Option prioritaire : +50 %. Le diagnostic et le devis sont gratuits et sans engagement. Pas de données, pas de frais sur la récupération elle-même. Barème complet : nos tarifs.
Nous recevons des disques de serveurs et d'hôtes de virtualisation d'entreprises de toute la France.
Un disque interne voyage dans un sachet antistatique, bien calé dans un carton rigide, jamais dans une enveloppe à bulles
Disques d'un serveur, d'un NAS ou d'une baie SAN : chacun étiqueté avec son numéro de baie, et tous les disques de la grappe dans le même colis
Joignez une note avec vos coordonnées, l'hyperviseur et sa version, ce qui s'est passé, ce qui a été tenté, et ce qui est prioritaire
Envoi avec suivi, sans indiquer le contenu sur le colis
J'ai supprimé une VM par erreur il y a deux jours. Le serveur a continué de tourner. C'est perdu ?
Pas forcément. Tout dépend de ce qui a été écrit depuis sur le même datastore (autres VM, snapshots, sauvegardes) et du type de stockage (sur SSD avec récupération automatique d'espace, les chances baissent vite). Arrêtez dès maintenant toute écriture sur ce stockage : chaque heure compte.
Je peux ouvrir le fichier VMDK ou VHDX avec un logiciel de récupération sur mon PC ?
Si vous avez une copie saine et complète du fichier, et que vous travaillez sur une copie de cette copie, c'est envisageable pour un cas simple. Mais si le fichier est incomplet, s'il dépend d'une chaîne de snapshots, ou s'il est encore sur le datastore en panne, vous risquez surtout de conclure à tort que tout est perdu, ou d'écrire au mauvais endroit.
L'hyperviseur me propose de consolider les snapshots. J'accepte ?
Sur un stockage sain et avec assez d'espace libre, c'est l'opération normale. Sur un datastore plein, un disque en alerte, ou une chaîne déjà signalée comme incohérente, une consolidation qui échoue à mi-parcours peut laisser les disques dans un état très difficile. Sans sauvegarde, faites d'abord copier les fichiers de la VM.
Nos VM étaient sauvegardées, mais la sauvegarde est sur le même serveur (ou le même NAS). Elle compte ?
Oui, envoyez-la aussi, en le signalant. Même incomplète ou ancienne, elle peut servir de référence pour reconstruire une chaîne de snapshots ou une VM supprimée. Mais pour l'avenir, une sauvegarde posée sur le même stockage que les VM tombe en même temps qu'elles.
Faut-il vous envoyer le serveur entier ?
En général, non : les disques suffisent dans la grande majorité des cas, étiquetés par baie. Notez simplement le modèle du serveur et de la carte RAID. Si le stockage est chiffré par le contrôleur ou par l'hyperviseur, dites-le d'emblée : nous vous dirons alors ce qu'il faut fournir en plus (clés, contrôleur).
Nous avons un cluster avec une baie SAN partagée entre plusieurs hôtes. Même démarche ?
Même principe (arrêter les écritures, ne rien reformater, tout noter), mais une baie SAN a sa propre couche de gestion des disques. Appelez-nous avant de démonter quoi que ce soit : l'ordre des disques et la configuration de la baie sont à relever avant tout.
Une VM est un conteneur dans un conteneur : disques, RAID, système de fichiers de l'hôte, disque virtuel, système de fichiers de la VM. Chaque couche doit être rouverte dans l'ordre
Un datastore inaccessible ne veut pas dire des VM perdues : dans la plupart des cas, les disques virtuels sont intacts
⚠️ N'acceptez jamais de formater, de resigner ou de « réparer » le volume proposé par l'hyperviseur
⚠️ Ne revenez pas à un snapshot, ne supprimez pas de fichiers de différences, ne lancez pas chkdsk dans la VM. Ces gestes écrivent ou abandonnent des données récentes
VM supprimée : stoppez toute écriture sur le datastore immédiatement. Sur SSD, le temps joue contre vous
Envoyez tous les disques, repérés par baie, avec la description de l'environnement et de ce qui a été tenté
Pour nous confier les disques de votre serveur de virtualisation : estimation gratuite pour un RAID ou un serveur, ou contactez-nous si l'entreprise est à l'arrêt et que vous voulez faire le point par téléphone au 09 71 32 65 95.
Toutes les pannes que nous traitons et le barème : récupération de données sur RAID.
Le serveur hôte redémarre et le datastore n'apparaît plus. Ou une machine virtuelle a été supprimée « du disque » par erreur. Ou encore un snapshot oublié depuis des mois a rempli le stockage, la consolidation a échoué, et la VM refuse de démarrer. Dans tous les cas, c'est rarement un seul poste qui s'arrête : c'est le serveur de fichiers, la comptabilité, la base métier, parfois toute l'informatique de l'entreprise, rangée dans quelques gros fichiers.
Le réflexe est de lancer un logiciel de récupération. Il tourne des heures et ne trouve rien d'utile, ou une montagne de fichiers sans nom. Ce n'est pas parce que les données ont disparu : c'est parce qu'une machine virtuelle est un conteneur rangé dans un conteneur, lui-même rangé dans un autre. Voici comment c'est construit, ce qui se récupère selon la panne, et les gestes qui font perdre ce qui était encore récupérable.
En bref
Arrêtez toute écriture sur le stockage concerné : éteignez les VM qui y tournent encore, suspendez sauvegardes et réplications N'acceptez aucune proposition de l'hyperviseur qui touche au volume : formatage, nouvelle signature, réparation, réinitialisation du pool Un datastore inaccessible ne veut pas dire des VM perdues : dans la plupart des cas, les disques virtuels sont intacts VM supprimée : sur SSD ou baie flash, la récupération automatique d'espace peut vider les blocs libérés très vite. Chaque heure compte Snapshot cassé : ne revenez pas au snapshot, ne supprimez pas de fichiers de différences, ne lancez pas chkdsk dans la VM Tarifs de 90 € à 790 € TTC et plus pour un disque, 190 € de reconstruction pour un datastore RAID ou NAS. Diagnostic gratuit, pas de données, pas de frais (hors forfait salle blanche)
🔴 Datastore ou machine virtuelle en panne ? BSC DataRecovery - 09 71 32 65 95.
Diagnostic gratuit et sans engagement.
Obtenir une estimation gratuite →
Diagnostic gratuit et sans engagement.
Obtenir une estimation gratuite →
Une VM, c'est des poupées russes
Une machine virtuelle croit avoir un vrai disque dur. En réalité, ce disque est un fichier (ou un volume logique) posé sur le stockage de l'hôte. Pour atteindre un document Word rangé dans la VM, il faut traverser plusieurs couches, dans l'ordre :
1. Les disques physiques du serveur ou de la baie de stockage.
2. Le RAID qui les assemble en un seul volume (contrôleur matériel, RAID logiciel, NAS).
3. Le système de fichiers de l'hôte, celui du datastore : VMFS chez VMware ESXi, NTFS ou ReFS chez Hyper-V, et chez Proxmox selon l'installation un groupe de volumes LVM-thin, un pool ZFS ou un simple répertoire.
4. Le disque virtuel de la VM : fichiers .vmdk chez VMware, .vhdx chez Hyper-V, fichiers .qcow2 ou .raw, ou volumes logiques chez Proxmox. S'il y a des snapshots, ce n'est pas un fichier mais une chaîne de fichiers qui dépendent les uns des autres.
5. La table de partitions et le système de fichiers de la VM (NTFS pour un Windows Server, ext4 ou XFS pour un Linux).
6. Vos fichiers, enfin.
Une panne peut toucher n'importe laquelle de ces couches, et chacune doit être rouverte correctement pour que la suivante soit lisible. C'est ce qui rend ces dossiers techniques, mais aussi ce qui les rend souvent très favorables : une couche abîmée n'efface pas les autres.
Pourquoi les logiciels classiques ne voient rien
Un logiciel de récupération grand public sait lire une couche : il cherche des partitions et des fichiers sur un disque. Face à une infrastructure virtuelle, il bute sur trois obstacles.
Lancé sur un seul disque d'un RAID, il ne voit que des tranches de fichiers entrecoupées de parité. Aucun disque virtuel n'est lisible tant que la grappe n'est pas réassemblée Le système de fichiers de l'hôte n'est pas toujours reconnu. VMFS, LVM-thin ou ZFS ne sont pas des formats de PC de bureau : beaucoup d'outils ne les ouvrent tout simplement pas, ou mal Un disque virtuel est un fichier géant et sans signature exploitable. La recherche « par signature » retrouve des photos ou des PDF grâce à leur en-tête. Un disque virtuel de 500 Go ou 2 To n'est pas un fichier qu'on repère ainsi, surtout s'il était en allocation dynamique (thin provisioning) et donc éparpillé sur le datastore au fil de sa croissance. Le logiciel ressort, au mieux, des milliers de fichiers anonymes trouvés à l'intérieur, sans leur nom ni leur dossierIl y a pire : lancer ce logiciel depuis l'hôte, sur le datastore en panne, ou y enregistrer le résultat, écrit précisément là où se trouvent les données à sauver. Voir les limites des logiciels de récupération gratuits.
Ce qui se récupère, selon la panne
Datastore inaccessible ou disparu
C'est le cas le plus fréquent, et le plus favorable. Le datastore ne remonte plus après une coupure de courant, un contrôleur RAID mort, une grappe dégradée qui a perdu un second disque, ou une corruption des métadonnées du système de fichiers de l'hôte. L'hyperviseur annonce un volume introuvable, non monté, ou un disque « vierge ».
Dans l'immense majorité de ces cas, les disques virtuels sont intacts : c'est l'accès qui est cassé, pas le contenu. Une fois le RAID reconstruit et le système de fichiers de l'hôte relu, les VM ressortent complètes.
Le danger vient de l'hyperviseur lui-même. Quand il découvre un volume qu'il ne reconnaît plus, il propose volontiers de l'ajouter comme nouveau stockage, avec une option de formatage, ou de lui attribuer une nouvelle signature. Formater efface l'index du datastore. Changer la signature modifie les métadonnées d'un volume qu'on n'a pas encore sauvé. Dans le doute, n'acceptez rien : notez le message exact, faites une capture d'écran, et arrêtez-vous là.
Si le datastore est hébergé sur un NAS (partage NFS ou volume iSCSI), il y a une couche de plus : les LUN iSCSI sont souvent des fichiers stockés sur le NAS lui-même. La démarche est la même, mais ce sont les disques du NAS qu'il faut nous confier. Voir aussi NAS Synology en panne : récupérer les données.
Machine virtuelle supprimée
Une VM effacée « du disque » depuis la console d'administration, un disque virtuel détaché puis supprimé, un volume logique Proxmox retiré avec la VM : les données ne sont pas effacées sur le moment, c'est leur emplacement qui est déclaré libre.
Les chances dépendent de trois choses :
Ce qui a été écrit depuis. Chaque nouvelle VM, chaque snapshot, chaque sauvegarde déposée sur le datastore peut réutiliser l'espace libéré. C'est le facteur numéro un : arrêtez toute écriture sur ce stockage dès que vous vous rendez compte de l'erreur Le type de stockage. Sur des disques durs classiques, l'espace libéré garde ses données tant qu'il n'est pas réécrit. Sur des SSD ou une baie 100 % flash, les hyperviseurs récents savent signaler l'espace libéré au stockage (récupération automatique d'espace, UNMAP, option discard). C'est l'équivalent du TRIM d'un SSD de PC : les blocs rendus peuvent être vidés très vite, et la récupération devient alors beaucoup plus incertaine. Voir SSD formaté ou fichiers supprimés : ce que change le TRIM L'allocation du disque virtuel. Un disque alloué d'un seul tenant (thick) occupe une zone continue, plus simple à retrouver. Un disque dynamique (thin) est dispersé en morceaux sur tout le datastore, et c'est la carte de ces morceaux qu'il faut reconstituerMême quand le fichier du disque virtuel ne peut pas être reconstitué en entier, il reste souvent une voie : rechercher directement, dans l'espace brut du datastore, les structures du système de fichiers de la VM (celles du NTFS d'un Windows Server, par exemple). Elles permettent de retrouver les fichiers de la VM avec leurs noms et leurs dossiers, sans passer par le disque virtuel disparu.
Snapshot cassé ou chaîne de disques incohérente
Un snapshot n'est pas une sauvegarde : c'est un fichier de différences. À partir du moment où il est pris, la VM n'écrit plus dans son disque d'origine mais dans ce nouveau fichier (fichiers -000001.vmdk chez VMware, .avhdx chez Hyper-V, snapshots internes d'un .qcow2 ou de volumes LVM-thin et ZFS chez Proxmox). Chaque snapshot supplémentaire ajoute un maillon. Le disque « réel » de la VM, c'est la chaîne entière, dans le bon ordre.
Les pannes typiques :
un snapshot oublié qui grossit pendant des mois jusqu'à remplir le datastore, ce qui arrête toutes les VM du stockage une consolidation (ou fusion) qui échoue en cours de route, laissant la chaîne à moitié fusionnée un fichier de différences supprimé pour gagner de la place, parce qu'il « ne servait à rien » une chaîne dont les liens internes ne correspondent plus (fichier restauré d'une autre date, copie partielle), et une VM qui démarre sur un état vieux de plusieurs mois, ou qui refuse de démarrerTant que les fichiers de la chaîne existent encore, même abîmés, les données récentes sont en principe là. Ce qui les fait perdre, ce sont les gestes suivants :
1. Revenir au snapshot (revert) : la VM repart de l'état du snapshot et abandonne toutes les modifications faites depuis. Parfois des mois de comptabilité.
2. Supprimer les fichiers de différences à la main, ou « tout supprimer » dans le gestionnaire de snapshots sans savoir si la fusion va aboutir sur un stockage plein.
3. Relancer la consolidation en boucle sur un datastore saturé ou un disque qui faiblit.
4. Démarrer la VM sur le disque de base seul, en rattachant manuellement l'ancien fichier : le système de la VM démarre sur des données périmées et commence à écrire dedans.
Au laboratoire, la chaîne est reconstruite virtuellement, maillon par maillon, sur des copies : on vérifie l'ordre et la cohérence de chaque fichier de différences avant de présenter le résultat comme un seul disque.
Disque virtuel VHDX ou VMDK corrompu
Après un plantage de l'hôte, une coupure de courant ou un stockage qui a renvoyé des erreurs de lecture, l'hyperviseur peut déclarer un disque virtuel corrompu ou illisible. Plusieurs cas se cachent derrière ce message :
l'en-tête ou la table interne du fichier est abîmé (un VHDX dynamique, par exemple, garde sa propre table d'allocation et un journal) : le contenu de la VM est intact, c'est le fichier qui ne sait plus décrire où il range ses blocs le fichier est incomplet parce que le système de fichiers de l'hôte a perdu une partie de sa carte le système de fichiers de la VM est lui-même endommagé, et le disque virtuel n'y est pour rienChaque cas se traite à un niveau différent, et c'est tout l'intérêt de travailler couche par couche plutôt que de lancer une réparation globale.
Surtout, ne lancez pas chkdsk (ou fsck) à l'intérieur de la VM pour « réparer » : il écrit dans le disque virtuel, lui-même posé sur un stockage peut-être défaillant, et empile une corruption sur une autre. Voir pourquoi chkdsk peut détruire vos données.
Proxmox : volumes LVM-thin et pools ZFS
Sur une installation Proxmox standard, les disques des VM ne sont souvent pas des fichiers mais des volumes logiques dans un pool LVM-thin, ou des volumes dans un pool ZFS. Deux pannes reviennent :
les métadonnées du pool LVM-thin sont abîmées (souvent après que le pool s'est rempli à 100 %) : tous les volumes de VM deviennent inaccessibles d'un coup, alors que les données sont toujours sur les disques le pool ZFS refuse de s'importer après une coupure ou la perte d'un disqueLes outils en ligne de commande proposent alors des réparations ou des imports « forcés », dont certains abandonnent les dernières transactions ou réécrivent les métadonnées. À ne pas tenter sans avoir d'abord une copie de chaque disque.
Rançongiciel sur l'hyperviseur
Certains rançongiciels visent directement les hôtes de virtualisation et chiffrent les disques virtuels. Sur des fichiers de plusieurs centaines de Go, beaucoup ne chiffrent qu'une partie du fichier pour aller vite. Une partie du contenu de la VM reste alors en clair et peut être exploitée. Le résultat est très variable d'un cas à l'autre, mais avant de réinstaller l'hôte ou de formater le datastore, faites évaluer les fichiers chiffrés : ne les effacez pas.
Ce qu'il faut faire, dans l'ordre
1. Arrêtez les écritures sur le stockage concerné. Éteignez les VM qui y tournent encore, suspendez les sauvegardes planifiées et les tâches de réplication, ne créez rien dessus.
2. N'acceptez aucune proposition de l'hyperviseur qui touche au volume : formatage, nouvelle signature, réparation, réinitialisation du pool.
3. Notez l'environnement : hyperviseur et version (ESXi 7 ou 8, Windows Server avec Hyper-V, Proxmox VE...), type de stockage (disques locaux en RAID, NAS, baie SAN), disques durs ou SSD, VM concernées et leur taille, présence de snapshots.
4. Racontez ce qui a déjà été tenté : consolidation, retour au snapshot, suppression de fichiers, reconstruction du RAID. Cela nous dit ce qui a été écrit, et où chercher.
5. Listez les priorités : quelle VM d'abord, et dans cette VM quels dossiers ou quelle base (comptabilité, ERP, messagerie). Sur une infrastructure de plusieurs To, commencer par l'essentiel change tout.
6. Envoyez tous les disques du stockage, y compris ceux déclarés défaillants et ceux de remplacement, chacun repéré avec son numéro de baie. Méthode détaillée dans envoyer les disques d'un NAS ou d'un RAID : la règle des baies. Si la panne a commencé par un RAID dégradé, lisez aussi RAID 5 dégradé : que faire.
Si l'hyperviseur tourne encore et que seule une VM pose problème, vous pouvez aussi copier les fichiers de la VM (tous les fichiers de son dossier, snapshots compris) vers un autre support, sans les modifier, et nous confier cette copie. Mais si le datastore est instable, ne multipliez pas les lectures : envoyez les disques.
Ce qui se passe au laboratoire
1. Copie de chaque disque. Chaque disque est lu séparément sur un équipement de laboratoire ; un disque en panne matérielle est réparé ou stabilisé avant d'être copié. Les originaux ne sont plus jamais remis dans un serveur.
2. Reconstruction virtuelle, couche par couche, en lecture seule. À partir des copies : le RAID est réassemblé, puis le système de fichiers du datastore relu, puis chaque disque virtuel (avec sa chaîne de snapshots) ouvert comme un disque à part entière, et enfin le système de fichiers de la VM. Chaque couche sert à vérifier la précédente : si le RAID est mal reconstruit, le datastore ne s'ouvre pas proprement ; si la chaîne de snapshots est dans le mauvais ordre, le système de fichiers de la VM le trahit aussitôt.
3. Restitution sous la forme utile. Selon le besoin : les fichiers de la VM (documents, bases de données exportées), ou le disque virtuel complet, remis au bon format pour être réimporté dans l'hyperviseur et redémarré. Dans les deux cas, vous vérifiez le résultat sur la liste avant de payer : voir vérifier la liste des fichiers récupérés avant paiement.
Pour les délais et les chances de réussite, voir taux de réussite et délais d'une récupération de données, et pour le budget combien coûte une récupération de données.
Délais
Pour une entreprise, chaque jour sans son serveur de virtualisation compte. Voici les ordres de grandeur, à partir de la réception des disques :
| Situation | Délai indicatif |
|---|---|
| Diagnostic et devis | 24 à 48 h |
| VM supprimée, snapshot à reconstruire (disques sains) | 1 à 3 jours |
| Disque avec secteurs défectueux | 3 à 10 jours |
| Datastore RAID, NAS ou pool ZFS/LVM-thin (selon le nombre et l'état des disques) | 1 à 3 semaines |
| Disque à ouvrir en salle blanche | 1 à 4 semaines |
Combien ça coûte
| Extraction : serveur hors service, disque sain | 90 € |
| Panne logique : VM supprimée, snapshot ou volume à reconstruire | 190 € |
| Panne physique sans ouverture : secteurs défectueux, électronique | 390 € |
| Panne mécanique : salle blanche, échange de têtes | à partir de 790 € * |
| SSD en panne physique | 690 € |
| Datastore RAID, NAS ou pool (ZFS/LVM-thin), disques sains : copie de chaque disque et reconstruction du volume | 190 € |
| Par disque en panne physique, en plus de la reconstruction | 390 € |
| Par disque en panne mécanique, en plus de la reconstruction | à partir de 790 € * |
Option prioritaire : +50 %. Le diagnostic et le devis sont gratuits et sans engagement. Pas de données, pas de frais sur la récupération elle-même. Barème complet : nos tarifs.
Envoyer les disques depuis toute la France
Nous recevons des disques de serveurs et d'hôtes de virtualisation d'entreprises de toute la France.
Un disque interne voyage dans un sachet antistatique, bien calé dans un carton rigide, jamais dans une enveloppe à bulles Disques d'un serveur, d'un NAS ou d'une baie SAN : chacun étiqueté avec son numéro de baie, et tous les disques de la grappe dans le même colis Joignez une note avec vos coordonnées, l'hyperviseur et sa version, ce qui s'est passé, ce qui a été tenté, et ce qui est prioritaire Envoi avec suivi, sans indiquer le contenu sur le colisQuestions fréquentes
J'ai supprimé une VM par erreur il y a deux jours. Le serveur a continué de tourner. C'est perdu ?
Pas forcément. Tout dépend de ce qui a été écrit depuis sur le même datastore (autres VM, snapshots, sauvegardes) et du type de stockage (sur SSD avec récupération automatique d'espace, les chances baissent vite). Arrêtez dès maintenant toute écriture sur ce stockage : chaque heure compte.
Je peux ouvrir le fichier VMDK ou VHDX avec un logiciel de récupération sur mon PC ?
Si vous avez une copie saine et complète du fichier, et que vous travaillez sur une copie de cette copie, c'est envisageable pour un cas simple. Mais si le fichier est incomplet, s'il dépend d'une chaîne de snapshots, ou s'il est encore sur le datastore en panne, vous risquez surtout de conclure à tort que tout est perdu, ou d'écrire au mauvais endroit.
L'hyperviseur me propose de consolider les snapshots. J'accepte ?
Sur un stockage sain et avec assez d'espace libre, c'est l'opération normale. Sur un datastore plein, un disque en alerte, ou une chaîne déjà signalée comme incohérente, une consolidation qui échoue à mi-parcours peut laisser les disques dans un état très difficile. Sans sauvegarde, faites d'abord copier les fichiers de la VM.
Nos VM étaient sauvegardées, mais la sauvegarde est sur le même serveur (ou le même NAS). Elle compte ?
Oui, envoyez-la aussi, en le signalant. Même incomplète ou ancienne, elle peut servir de référence pour reconstruire une chaîne de snapshots ou une VM supprimée. Mais pour l'avenir, une sauvegarde posée sur le même stockage que les VM tombe en même temps qu'elles.
Faut-il vous envoyer le serveur entier ?
En général, non : les disques suffisent dans la grande majorité des cas, étiquetés par baie. Notez simplement le modèle du serveur et de la carte RAID. Si le stockage est chiffré par le contrôleur ou par l'hyperviseur, dites-le d'emblée : nous vous dirons alors ce qu'il faut fournir en plus (clés, contrôleur).
Nous avons un cluster avec une baie SAN partagée entre plusieurs hôtes. Même démarche ?
Même principe (arrêter les écritures, ne rien reformater, tout noter), mais une baie SAN a sa propre couche de gestion des disques. Appelez-nous avant de démonter quoi que ce soit : l'ordre des disques et la configuration de la baie sont à relever avant tout.
À retenir
Une VM est un conteneur dans un conteneur : disques, RAID, système de fichiers de l'hôte, disque virtuel, système de fichiers de la VM. Chaque couche doit être rouverte dans l'ordre Un datastore inaccessible ne veut pas dire des VM perdues : dans la plupart des cas, les disques virtuels sont intacts ⚠️ N'acceptez jamais de formater, de resigner ou de « réparer » le volume proposé par l'hyperviseur ⚠️ Ne revenez pas à un snapshot, ne supprimez pas de fichiers de différences, ne lancez pas chkdsk dans la VM. Ces gestes écrivent ou abandonnent des données récentes VM supprimée : stoppez toute écriture sur le datastore immédiatement. Sur SSD, le temps joue contre vous Envoyez tous les disques, repérés par baie, avec la description de l'environnement et de ce qui a été tentéPour nous confier les disques de votre serveur de virtualisation : estimation gratuite pour un RAID ou un serveur, ou contactez-nous si l'entreprise est à l'arrêt et que vous voulez faire le point par téléphone au 09 71 32 65 95.
Toutes les pannes que nous traitons et le barème : récupération de données sur RAID.
Pendant et après la récupération, dans le groupe BSC.
💻 Des postes pour continuer à travailler pendant que le serveur est à l'arrêt, sur quelques jours ou quelques semaines : BSC Location loue des ordinateurs fixes et portables en courte et longue durée.
🛠️ Remettre l'hôte en service sur des disques neufs, réimporter les VM récupérées et mettre en place une sauvegarde sur un support séparé : BSC Informatique fournit le matériel et intervient pour les professionnels depuis son atelier de Hyères.
Un snapshot n'est pas une sauvegarde, un RAID non plus, et une sauvegarde rangée sur le même datastore que les VM disparaît avec lui. Voir qu'est-ce qu'une sauvegarde et pourquoi c'est important.
Sources : cas de serveurs de virtualisation et de grappes RAID traités à l'atelier ; documentation technique de laboratoire sur la reconstruction de RAID, de datastores VMFS, de volumes LVM et de LUN iSCSI ; documentation publique des formats de disque virtuel (VMDK, VHDX, qcow2) et des mécanismes de snapshot et de récupération d'espace des hyperviseurs.💻 Des postes pour continuer à travailler pendant que le serveur est à l'arrêt, sur quelques jours ou quelques semaines : BSC Location loue des ordinateurs fixes et portables en courte et longue durée.
🛠️ Remettre l'hôte en service sur des disques neufs, réimporter les VM récupérées et mettre en place une sauvegarde sur un support séparé : BSC Informatique fournit le matériel et intervient pour les professionnels depuis son atelier de Hyères.
Un snapshot n'est pas une sauvegarde, un RAID non plus, et une sauvegarde rangée sur le même datastore que les VM disparaît avec lui. Voir qu'est-ce qu'une sauvegarde et pourquoi c'est important.