Une machine virtuelle a été supprimée. Peut-on encore la récupérer ?

Souvent, oui, tant que l'espace libéré n'a pas été écrasé. Arrêtez immédiatement d'écrire sur le datastore, ne créez pas de nouvelles machines virtuelles et demandez une analyse.

Notre chaîne de snapshots est endommagée et la VM ne démarre plus. Que faire ?

Ne consolidez et ne supprimez aucun snapshot. Reconstruire la chaîne peut ramener le dernier état, mais uniquement tant que tous les maillons sont encore là.

Le volume utilise la déduplication et les fichiers ne s'ouvrent plus. Sont-ils perdus ?

Généralement pas. Le contenu se trouve dans le chunk store ; ce sont souvent les références vers celui-ci qui sont endommagées. Ne lancez pas de nettoyage ni d'autres tâches de maintenance, car elles peuvent supprimer définitivement des chunks.

Pouvez-vous récupérer une base de données Exchange ou SQL qui se trouvait dans une machine virtuelle ?

Oui. Nous traitons les couches jusqu'à la base de données et vérifions qu'elle s'ouvre à nouveau. Ne lancez pas d'outils de réparation sur la base au préalable ; ils peuvent supprimer définitivement des pages endommagées.

Quelle est la différence avec vos trois processus pour les grands volumes ?

Les trois processus concernent la taille : ils permettent de traiter des volumes de centaines de téraoctets. La récupération multicouche concerne la structure : plusieurs couches empilées. Dans les grands environnements, les deux se présentent souvent ensemble.

Sous quelle forme récupérons-nous les données ?

À vous de choisir : sous forme de fichiers séparés, de disque virtuel à rattacher à votre hyperviseur, ou de base de données à remonter.

Pouvez-vous restaurer des sauvegardes Veeam endommagées ?

Souvent, oui. Si les fichiers de sauvegarde se trouvent sur un stockage défectueux, nous récupérons d'abord ce stockage. Si les fichiers de sauvegarde eux-mêmes sont endommagés, nous exploitons la redondance qu'ils contiennent et, si nécessaire, nous travaillons en concertation avec Veeam. Indiquez la version et, pour les sauvegardes chiffrées, le mot de passe.

Récupération multicouche (multi-layer recovery) : virtualisation, déduplication et bases de données • Datarecuperatie

Qu'est-ce qu'une installation multicouche ?

Dans un environnement serveur moderne, chaque couche est un conteneur pour la suivante : le RAID fournit un volume, le volume reçoit un partitionnement et un système de fichiers, ce système de fichiers contient des disques virtuels, ces disques virtuels contiennent à nouveau un système de fichiers, et on y trouve les fichiers d'une application, comme une base de données Exchange ou SQL.

Chaque couche interprète les octets de la couche inférieure. Si une couche est endommagée, tout ce qui se trouve au-dessus devient illisible, même si les données elles-mêmes sont encore entièrement présentes. Il s'agit alors de reconstruire la couche endommagée pour que les couches supérieures redeviennent cohérentes.

Une couche endommagée signifie rarement que les données au-dessus sont perdues. Le plus souvent, c'est la clé pour les lire qui manque, pas le contenu.

Les couches, de bas en haut

Couche	Exemples	Ce qui tourne souvent mal
Stockage et RAID	Disques, contrôleur RAID, NAS, SAN	Disques défectueux, configuration RAID perdue
Partitionnement	MBR, GPT, LVM, Storage Spaces	Table de partitions écrasée, disque initialisé par erreur
Système de fichiers (native file system)	NTFS, ReFS, ext4, XFS, ZFS, Btrfs, VMFS	Métadonnées endommagées, formatage, vérification ratée
Déduplication (deduplication)	Déduplication Windows Server, ZFS dedup, appliances de sauvegarde	Chunk store ou index endommagé
Virtualisation	VMware vSphere, Hyper-V, Proxmox et KVM	Machine virtuelle supprimée, snapshots détachés
Disque virtuel (virtual disk image)	VMDK, VHDX, qcow2, raw	Dispersé sur le datastore, en-tête ou table de blocs endommagé
Système de fichiers invité (guest file system)	NTFS, ext4, XFS dans la machine virtuelle	Les mêmes problèmes que tout système de fichiers
Application	Exchange (ESE), SQL Server, Oracle, archives de courrier	Pages endommagées, fichiers journaux manquants
Sauvegarde	Veeam® (.vbk, .vib, .vrb) et autres logiciels de sauvegarde	Chaîne de sauvegarde endommagée, fichiers de sauvegarde sur un stockage défectueux

Technique : comment les disques virtuels suivent leurs blocs

Un disque virtuel qui n'est pas entièrement alloué à l'avance (thin provisioned, sparse) conserve une table indiquant où chaque bloc du disque virtuel se trouve dans le fichier : le grain directory et les grain tables pour VMDK, la Block Allocation Table (BAT) pour VHDX, les tables L1 et L2 pour qcow2.

Les snapshots et disques différentiels (fichiers delta VMware, .avhdx Hyper-V) forment une chaîne : chaque fichier ne contient que les blocs modifiés et renvoie à son parent. Si un maillon ou la référence vers celui-ci est endommagé, la chaîne doit être reconstruite pour obtenir l'état actuel du disque.

Le principe : les autres couches disent ce qui manque

Chaque couche contient, volontairement ou non, des informations sur les couches qui l'entourent. Nous les utilisons dans trois directions :

Du haut vers le bas. Le contenu d'une couche supérieure révèle comment une couche inférieure était construite. Un fichier de la machine virtuelle qui s'étend sur deux fragments du disque virtuel confirme que ces fragments se suivent ; c'est ainsi qu'un disque virtuel dispersé peut être remis dans le bon ordre, même si sa table de blocs a disparu. Et le système de fichiers d'une partition indique sa propre taille, ce qui montre où se trouvait la partition, même si la table de partitions a été écrasée.
Du bas vers le haut. Une couche inférieure intacte délimite la recherche dans la couche supérieure. Si le système de fichiers du datastore sait encore quels blocs appartiennent à quel disque virtuel, nous ne cherchons les structures d'un système de fichiers invité endommagé que dans ces blocs, et dans le bon ordre.
Au sein de la couche. De nombreux formats se composent de blocs ou de pages de taille fixe avec leur propre signature ou somme de contrôle (checksum). Une page de base de données SQL Server indique par exemple son propre numéro de page. Des morceaux séparés peuvent ainsi être reconnus, vérifiés et remis en ordre.

Technique : exemples de copies de secours et de signatures

GPT conserve une copie de secours de l'en-tête et de la table de partitions à la fin du disque. NTFS conserve une copie du secteur de démarrage à la fin du volume, ainsi qu'une copie partielle de la MFT (MFTMirr). ext4 et XFS conservent des copies de leur superblock réparties sur le volume.

SQL Server travaille avec des pages de 8 Ko, avec le numéro de fichier et de page dans l'en-tête. Exchange (ESE) utilise depuis Exchange 2010 des pages de 32 Ko, chacune avec sa propre somme de contrôle. Ces signatures permettent de retrouver des pages parmi d'autres données.

La déduplication : une couche qui fragmente tout

La déduplication (deduplication) ne stocke chaque élément de données unique (chunk) qu'une seule fois. Un fichier n'est alors plus une suite continue de blocs, mais une liste de références vers des chunks dans un stockage commun (chunk store). Avec la déduplication Windows Server, les fichiers restent visibles sous forme de références (reparse points), tandis que leur contenu se trouve dans le chunk store.

Si l'index ou le chunk store est endommagé, les fichiers semblent toujours présents mais ne s'ouvrent pas. Pourtant, le chunk store contient l'intégralité du contenu. La couche supérieure, par exemple un disque virtuel à la structure reconnaissable, aide alors à remettre les chunks dans le bon ordre.

Les sauvegardes comme couche supplémentaire

Souvent, la sauvegarde elle-même est la dernière couche qui compte : les fichiers de sauvegarde de Veeam®, Backup Exec, Macrium Reflect ou d'autres logiciels se trouvent sur un NAS, un RAID ou un volume dédupliqué tombé en panne. Nous récupérons alors d'abord le stockage, ensuite les fichiers de sauvegarde, puis les données qu'ils contiennent, même si les fichiers de sauvegarde eux-mêmes sont endommagés.

Tout sur la récupération de sauvegardes inaccessibles →

Scénarios de la pratique

Machine virtuelle supprimée

Une machine virtuelle a été supprimée d'un datastore VMFS. L'espace est libéré, mais les blocs du disque virtuel sont souvent encore là ; la structure du système de fichiers invité permet de les retrouver et de les assembler.

Chaîne de snapshots rompue

Un environnement Hyper-V ou VMware avec des snapshots dont un maillon est endommagé. La machine virtuelle ne démarre plus ; reconstruire la chaîne ramène le dernier état.

Serveur Exchange virtualisé

RAID, VMFS, VMDK, NTFS et une base de données Exchange empilés. Une seule couche endommagée suffit à rendre les boîtes aux lettres inaccessibles ; les autres couches aident à la réparer, jusqu'à ce que la base soit à nouveau lisible.

Pourquoi les logiciels standard bloquent ici

Les logiciels de récupération ordinaires travaillent une couche à la fois et supposent que les couches inférieures sont en ordre : un outil de système de fichiers attend une partition correcte, un outil VMDK un datastore lisible, un outil de base de données un disque virtuel intact. Dans une installation multicouche endommagée à plus d'un niveau, cette hypothèse ne tient plus.

C'est pourquoi nous examinons toute la pile à la fois, et déterminons pour chaque couche quelles informations des autres couches sont nécessaires pour la reconstruire.

Ce qu'il vaut mieux faire

À faire

Arrêtez les machines virtuelles et tout ce qui écrit sur le stockage concerné.
Conservez la configuration : paramètres des VM (.vmx ou configuration Hyper-V), un aperçu des datastores et des snapshots.
Notez toute la pile : RAID, volumes, déduplication, virtualisation, applications.
Conservez les journaux de l'hyperviseur, du stockage et de l'application.

À éviter

Ne consolidez pas et ne supprimez pas de snapshots.
Ne recréez pas et ne formatez pas de datastore ou de volume.
Ne lancez pas de tâches de maintenance de la déduplication, comme le nettoyage (garbage collection).
Ne lancez pas d'outils de réparation dans la machine virtuelle ou sur la base de données, comme chkdsk ou eseutil /p.

Déroulement d'un dossier

Analyse par couche. Nous cartographions toute la pile et déterminons quelles couches sont endommagées.
Copies. Nous faisons une copie complète de chaque disque ; les disques physiquement endommagés sont d'abord réparés dans notre laboratoire Class 1.
Reconstruction. Nous commençons par la couche endommagée la plus basse et utilisons les informations des autres couches pour la reconstruire, couche par couche, jusqu'à l'application.
Contrôle au niveau de l'application. Une base de données doit non seulement être récupérée, mais aussi s'ouvrir. Nous vérifions le résultat au niveau où vous l'utilisez.
Livraison. Sous forme de fichiers, de disque virtuel que vous pouvez rattacher, ou de base de données. Vous voyez le résultat avant de payer.

Pour les très grands volumes, nous combinons cela avec notre approche en trois processus.

En savoir plus sur la récupération de grands volumes →

Récupération multicouche (multi-layer recovery)