Une machine virtuelle n'est pas rangée dans une partition comme un système classique : c'est un gros fichier posé sur un disque, presque toujours un serveur en RAID. Quand l'hyperviseur crashe, que le RAID tombe ou que ce fichier se corrompt, on ne perd pas forcément les données, mais on doit reconstruire deux couches l'une après l'autre : d'abord retrouver le fichier de la machine virtuelle, puis remonter le système à l'intérieur. Le bon réflexe est le même que pour tout serveur : tout éteindre, ne rien recréer, et confier les disques à un laboratoire.

La suite explique ce qu'est vraiment la virtualisation, comment un environnement virtualisé tombe en panne, et pourquoi certaines tentatives de réparation condamnent définitivement les données.

La virtualisation en clair

Virtualiser, c'est faire tourner une machine complète, avec son propre système d'exploitation, à l'intérieur d'une autre. Cette machine virtuelle ne fait pas partie du partitionnement du disque : elle est stockée dans un gros fichier, ce qui lui permet d'être déplacée d'un serveur à un autre comme un simple document.

Il existe deux manières de virtualiser, et la distinction compte. La première est la virtualisation dite desktop, avec un logiciel comme VMware Workstation ou Oracle VirtualBox, installé à l'intérieur d'un système d'exploitation existant, par exemple Windows. Ce logiciel fait tourner un second système dans une fenêtre. On empile alors les couches : la machine virtuelle communique avec le logiciel de virtualisation, qui parle à Windows, qui accède enfin au matériel réel, la carte mère, la carte réseau, et le reste. C'est pratique pour tester ou faire cohabiter deux systèmes sur un poste, mais ce n'est pas ce qu'on utilise en production.

Pour un serveur d'entreprise, on emploie un hyperviseur : VMware ESXi, Microsoft Hyper-V ou Proxmox, ce dernier existant aussi en version communautaire, open source et gratuite. Ici, il n'y a pas de gros système d'exploitation par-dessus lequel on installerait un logiciel. L'hyperviseur est lui-même un petit logiciel léger, posé directement sur la machine, et c'est sur lui que l'on installe de vraies machines virtuelles, sous Windows, Linux, macOS ou des systèmes plus légers.

L'intérêt est économique et pratique. Une machine physique puissante n'est presque jamais sollicitée à fond en permanence. Plutôt que de laisser cette puissance dormir, on fait tourner deux, trois ou quatre serveurs virtualisés sur une seule machine, qui se partagent ses ressources. Mieux, on peut attribuer à chaque VM un nombre de processeurs et une quantité de mémoire, puis les augmenter à la demande si un serveur monte en charge. Cette souplesse fait le succès de la virtualisation, et c'est aussi ce qui concentre beaucoup de données critiques sur une seule machine.

Virtualisation desktop et hyperviseur : la différence

Critère	Virtualisation desktop	Hyperviseur (serveur)
Exemples	VMware Workstation, Oracle VirtualBox	VMware ESXi, Microsoft Hyper-V, Proxmox
Installation	Dans un système existant (Windows)	Directement sur la machine
Couches empilées	VM, logiciel, Windows, matériel	VM, hyperviseur, matériel
Usage type	Tester, faire cohabiter deux systèmes	Serveurs de production
Stockage	Un fichier sur le disque du poste	Un fichier sur un datastore, presque toujours en RAID

Comment un environnement virtualisé tombe en panne

Puisque tout repose sur une même machine physique et une pile logicielle, les points de rupture sont multiples. Voici ceux que nous voyons.

Panne	Conséquence
Hyperviseur qui crashe	Plus d'accès aux fichiers de machines virtuelles
RAID du serveur qui tombe	Le stockage des VM devient inaccessible
Datastore corrompu	L'espace qui héberge les VM n'est plus lisible
Fichier VMDK ou VHDX corrompu	Comme une panne de la partition de la VM
Partition interne à la VM endommagée	La VM ne démarre plus

L'hyperviseur peut crasher et refuser de redémarrer : on perd alors l'accès aux fichiers qui contiennent les différentes machines virtuelles. Le RAID du serveur peut tomber, et comme les serveurs de virtualisation tournent presque toujours sur un RAID, c'est un classique. Le datastore, cet espace qui héberge les VM et décrit leur organisation, peut se corrompre. Le fichier de la machine virtuelle lui-même, un VMDK chez VMware, un VHDX chez Hyper-V, peut être endommagé, ce qui revient à une panne de la partition de la VM. Enfin, la panne peut se situer à l'intérieur même de la machine virtuelle, dans son système de fichiers, l'empêchant de démarrer.

Dans la pratique, les deux cas les plus fréquents sont le RAID qui tombe et l'hyperviseur défectueux. Le reste vient s'y ajouter ou en découler.

Le piège du snapshot

Une confusion très répandue coûte cher : beaucoup considèrent un snapshot comme une sauvegarde. C'est faux, et dangereux.

Un snapshot n'est qu'un instantané différentiel : il enregistre les changements survenus depuis un point donné, et il dépend entièrement du disque parent sur lequel il s'appuie. Si ce disque parent est perdu ou corrompu, ou si la chaîne de snapshots est cassée, le snapshot seul ne vaut plus rien. Pire, une longue chaîne de snapshots jamais consolidés fragilise l'ensemble et complique toute récupération. Un snapshot dépanne pour revenir en arrière rapidement, mais il ne remplace en aucun cas une vraie sauvegarde indépendante.

La double couche : retrouver le fichier, puis son contenu

C'est ce qui distingue la récupération d'un serveur virtualisé de celle d'un disque ordinaire : il y a deux couches à remonter, l'une après l'autre.

La première consiste à retrouver le fichier de la machine virtuelle, le VMDK ou le VHDX, là où il se trouve, c'est-à-dire le plus souvent sur un RAID en panne. Il faut donc d'abord reconstruire le RAID pour accéder au datastore, puis en extraire les fichiers de virtualisation. La seconde couche consiste à ouvrir ce fichier et à remonter le système qu'il contient, avec son propre système de fichiers et ses données.

Le besoin du client oriente alors le travail. Certains veulent récupérer les fichiers virtuels eux-mêmes, pour les remonter tels quels sur un autre serveur. D'autres n'ont plus l'usage de la virtualisation : ils veulent migrer vers un Windows Server plus récent, et ce n'est pas le VMDK qui les intéresse, mais son contenu. Dans ce cas, nous exportons le fichier de VM, puis nous analysons son contenu pour restituer à part les fichiers, les bases de données ou les messageries qu'il renfermait.

Notre méthode ne varie pas. Comme pour toute récupération, nous commençons par figer l'état : aucune intervention directe sur les originaux, mais des copies bit à bit de sécurité, sur lesquelles seules nous travaillons ensuite. Nous reconstruisons le RAID à la volée à partir de ces copies, retrouvons les fichiers de virtualisation, les exportons, puis remontons leur contenu. Nous n'avons d'ailleurs pas besoin du serveur entier : tout se retravaille virtuellement, à partir des disques.

Les erreurs qui aggravent, et la prévention

Face à un environnement virtualisé en panne, l'acharnement est le pire ennemi. Recréer un datastore, générer de nouveaux snapshots, réinstaller l'hyperviseur sur les disques, ou lancer un rebuild RAID hasardeux : chacune de ces manipulations écrit sur le stockage et peut détruire définitivement des données encore récupérables. Plus on tente de réparer soi-même à l'aveugle, plus on réduit les chances. Le bon réflexe est d'arrêter le serveur et de confier les disques à un laboratoire avant toute autre tentative.

Côté prévention, la virtualisation ne dispense pas de sauvegarder, au contraire, puisqu'elle concentre plusieurs serveurs sur une seule machine. Certaines solutions, comme Proxmox, savent réaliser de véritables sauvegardes vers un NAS distant, ce qui est un vrai plus. Mais même un backup automatisé ne protège pas de tout, un ransomware pouvant par exemple atteindre les fichiers de VM comme le reste. Une machine virtuelle posée sur un RAID n'est pas une sauvegarde : il faut, là aussi, une copie indépendante conservée ailleurs.

Ce qu'il faut retenir

Une machine virtuelle est un fichier, généralement stocké sur un serveur en RAID, et sa récupération se joue sur deux niveaux : retrouver le fichier VMDK ou VHDX, puis remonter le système et les données qu'il contient. Les pannes les plus fréquentes viennent du RAID qui tombe ou de l'hyperviseur qui crashe, et un snapshot, souvent pris pour une sauvegarde, n'en est pas une.

En cas de problème, la règle est celle de tout incident sérieux sur un serveur : ne rien recréer, ne rien réinstaller, éteindre et confier les disques. Un laboratoire travaille sur des copies, reconstruit le RAID virtuellement, extrait les fichiers de VM et leur contenu, sans jamais toucher aux originaux. Et pour la suite, une vraie sauvegarde externe reste le seul filet qui tienne.

Foire aux questions

Une machine virtuelle, c'est quoi au juste ?

C'est un ordinateur complet, avec son propre système d'exploitation, qui tourne à l'intérieur d'une autre machine. Contrairement à un système classique, elle n'occupe pas une partition : elle est stockée dans un gros fichier (un VMDK chez VMware, un VHDX chez Hyper-V), ce qui permet de la déplacer d'un serveur à l'autre comme un document.

Un snapshot peut-il servir de sauvegarde ?

Non. Un snapshot est un instantané différentiel qui n'enregistre que les changements depuis un point donné et qui dépend entièrement du disque parent. Si le parent est perdu ou si la chaîne de snapshots est cassée, le snapshot seul ne vaut plus rien. Il dépanne pour revenir en arrière, mais ne remplace pas une sauvegarde indépendante.

Quelles sont les pannes les plus fréquentes sur un serveur virtualisé ?

Dans la pratique, deux dominent : le RAID du serveur qui tombe (les serveurs de virtualisation tournent presque toujours sur un RAID) et l'hyperviseur qui crashe et refuse de redémarrer. Viennent ensuite le datastore corrompu, le fichier VMDK ou VHDX endommagé, et la partition interne à la VM.

Peut-on récupérer les données sans le serveur physique ?

Oui. Il suffit des disques. Nous en réalisons des copies bit à bit, reconstruisons le RAID virtuellement à partir de ces copies, retrouvons les fichiers de virtualisation, puis remontons leur contenu. Tout se retravaille virtuellement, sans avoir besoin de la machine entière.

Que faire, et surtout ne pas faire, quand une VM ne démarre plus ?

Ne pas recréer de datastore, ne pas générer de nouveaux snapshots, ne pas réinstaller l'hyperviseur sur les disques et ne pas lancer de rebuild RAID hasardeux : chacune de ces manipulations écrit sur le stockage et peut détruire des données encore récupérables. Le bon réflexe est d'éteindre le serveur et de confier les disques à un laboratoire.

La virtualisation dispense-t-elle de faire des sauvegardes ?

Au contraire. Comme elle concentre plusieurs serveurs sur une seule machine, elle augmente le risque en cas de sinistre. Des solutions comme Proxmox savent sauvegarder vers un NAS distant, mais aucun backup ne protège de tout (un ransomware peut atteindre les fichiers de VM). Une VM posée sur un RAID n'est pas une sauvegarde : il faut une copie indépendante conservée ailleurs.