Le serveur applicatif ne répond plus, l’hyperviseur affiche la machine virtuelle en erreur, et impossible de la redémarrer. Quand on regarde de plus près, c’est la base SQL Server qui fait tourner l’ERP, le CRM ou l’application métier qui a purement et simplement disparu. Ce scénario, de plus en plus fréquent dans les entreprises qui hébergent leurs bases MSSQL sur des infrastructures virtualisées, déroute même les administrateurs système les plus expérimentés : les outils habituels ne répondent pas, et la base semble s’être volatilisée alors que rien n’indique de panne matérielle classique.
Pourquoi une base MSSQL peut disparaître avec une VM corrompue
Une base de données SQL Server tourne presque toujours sur une machine virtuelle, que ce soit sous VMware, Hyper-V ou Proxmox. Cette VM repose elle-même sur un disque virtuel (un fichier VMDK ou VHDX selon l’hyperviseur), et ce disque virtuel est stocké sur une infrastructure physique : un NAS, une baie SAN ou un serveur en local. Trois couches s’empilent donc entre votre base de données et le matériel réel, et chacune d’elles peut être le point de départ d’une corruption.
Quand le stockage physique se corrompt ou se sature brutalement (un NAS qui atteint 100 % de sa capacité, un contrôleur RAID défaillant, une écriture interrompue en pleine réplication), ce n’est pas uniquement le fichier de la base qui est touché. C’est le système de fichiers de la VM elle-même, le plus souvent NTFS, qui peut être endommagé dans sa structure.
Le rôle central de la MFT
Sur un volume NTFS, la Master File Table (MFT) est la structure qui indexe l’intégralité des fichiers présents : leur emplacement, leur taille, leurs attributs. Sans MFT exploitable, le système d’exploitation ne sait plus où se trouvent les fichiers, même si les données sont toujours physiquement présentes sur le disque. Concrètement, cela signifie qu’aucun accès standard aux fichiers .mdf et .ldf de votre base n’est possible : Windows ne les voit tout simplement plus, et SQL Server ne peut évidemment pas monter une base dont il ne trouve pas les fichiers.
Pourquoi les réflexes SQL classiques ne suffisent pas ici
Un DBA confronté à ce type d’incident se retrouve souvent démuni, et c’est légitime : les outils sur lesquels il s’appuie au quotidien n’ont tout simplement pas prise sur ce genre de panne. Le réflexe naturel est de lancer DBCC CHECKDB pour diagnostiquer une corruption interne à la base, ou de restaurer la dernière sauvegarde disponible. Ces deux approches partent d’un postulat qui ne tient pas dans ce cas précis : elles supposent que la base est accessible, mais « corrompue au sens SQL », c’est-à-dire que ses fichiers existent et sont lisibles, mais que leur contenu pose problème.
Or ici, le problème se situe une couche en dessous : ce n’est pas la base qui est corrompue, c’est le système de fichiers qui la contient qui a disparu. Aucun outil de réparation SQL, aussi performant soit-il, ne peut agir sur des fichiers auxquels le système d’exploitation lui-même n’a plus accès. Tenter de restaurer une sauvegarde sur un volume qui ne répond plus, ou lancer une réparation applicative sur une base fantôme, ne fait que faire perdre un temps précieux sans résoudre le problème réel.
Ce qu’il faut faire, et surtout ne pas faire, dans l’immédiat
Face à ce genre d’incident, les premières minutes comptent, mais pas dans le sens où on l’imagine généralement. Il ne s’agit pas d’agir vite pour « réparer », il s’agit avant tout de ne rien faire qui puisse aggraver la situation.
- Arrêtez immédiatement l’hôte de virtualisation concerné. Continuer à écrire sur le stockage, y compris via des mécanismes automatiques comme le TRIM ou l’UNMAP sur les disques SSD, risque d’effacer définitivement des données encore présentes mais que le système ne sait plus indexer.
- Ne lancez pas de réparation NTFS générique de type chkdsk sur le volume concerné. Exactement comme un rebuild RAID lancé trop tôt, une réparation automatique de ce type peut réécrire des structures et détruire les dernières traces exploitables des données.
- Ne tentez pas de remonter le disque virtuel en écriture « pour voir si ça repart ». Chaque tentative de ce genre réduit les chances d’une récupération complète par la suite.
- Sollicitez une évaluation professionnelle avant toute nouvelle manipulation. La plupart des laboratoires de récupération de données, dont Chronodisk, proposent un diagnostic initial gratuit pour évaluer précisément l’état du volume avant d’engager quoi que ce soit.
Ces réflexes s’appliquent que votre infrastructure repose sur un volume RAID classique ou sur une machine virtuelle : dans les deux cas, la priorité absolue est de préserver l’état actuel du support, même dégradé, plutôt que de multiplier les tentatives qui compliquent le travail de reconstruction.
En quoi consiste une récupération professionnelle dans ce contexte
Sans structure NTFS ou MFT exploitable, il n’existe pas de « restore » simple. La récupération passe par une reconstruction manuelle au niveau bas du disque : il faut identifier, bloc par bloc, les zones qui appartiennent aux fichiers de la base à partir de signatures et de motifs internes propres au format MDF et LDF de SQL Server, puis reconstituer une structure de table exploitable à partir de ces fragments retrouvés.
Ce travail n’a rien de comparable avec une restauration de sauvegarde classique. Il demande une compréhension fine à la fois du format interne des bases SQL Server et de la mécanique des systèmes de fichiers virtualisés, ce qui explique pourquoi ce type de dossier ne se résout ni avec les outils SQL standards, ni en quelques heures. C’est un travail d’ingénierie inverse minutieux, qui doit composer avec l’état réel du support et la quantité de données encore récupérables.
Chronodisk intervient sur ce type de corruption, qu’elle touche des volumes RAID physiques ou des machines virtuelles sous VMware, Hyper-V ou Proxmox. Lorsqu’aucune défaillance matérielle physique n’est associée à l’incident (pas de disque qui ne s’allume plus, pas de bruit anormal signalant une panne mécanique), l’intervention peut souvent se faire à distance, ce qui permet de gagner un temps précieux par rapport à un transfert physique du matériel. Dans tous les cas, un diagnostic préalable permet de déterminer si la MFT est partiellement récupérable, si une reconstruction par signatures est nécessaire, et quel volume de données peut raisonnablement être restauré.
Si votre base SQL Server est devenue inaccessible suite à la corruption d’une VM, la première chose à faire est de résister à la tentation de « essayer encore une fois ». Chaque manipulation non maîtrisée réduit les chances de récupération. Un diagnostic professionnel permet d’y voir clair rapidement, sans risquer d’aggraver une situation déjà compliquée.