CAS CLIENT : Récupération d'une infrastructure de virtualisation critique
XCP-ng · VMware ESXi / VMFS6 · iSCSI · ddrescue · Forensic stockage · ~30 VM de production
Contexte anonymisé : environnement de virtualisation en production (~30 machines virtuelles, aucune sauvegarde disponible) devenu inaccessible suite à une erreur de configuration lors du rattachement d'un nouveau datastore iSCSI.
Diagnostic
- Un LUN unique a été utilisé simultanément comme datastore VMware/ESXi existant et comme cible d'un nouveau SR de stockage XCP-ng.
- Le nouveau système de stockage a écrit sa propre structure (en-tête LVM + un disque virtuel de 80 Go) sur le LUN pendant qu'un transfert de VM était en cours.
- Conséquence : le superblock VMFS a été écrasé, rendant le datastore invisible et illisible pour ESXi.
- Confirmation via les outils en ligne de commande ESXi que le datastore avait disparu, et vérification qu'aucun snapshot ni sauvegarde n'existait pour restaurer l'état antérieur.
Actions menées
- Sécurisation immédiate : annulation du transfert en cours, déconnexion du SR fautif pour stopper toute écriture supplémentaire, passage du LUN en lecture seule côté baie de stockage.
- Imagerie bit-à-bit d'un volume de 8 To avec ddrescue depuis une machine Linux, copie réalisée sans aucune erreur de secteur (confirmant une corruption logique et non physique).
- Optimisation du pipeline de traitement : après un premier essai trop lent (I/O aléatoires sur partage réseau), mise en place d'un volume iSCSI dédié et d'une liaison directe 10 Gbps, ramenant le temps de traitement d'environ 43h estimées à 13-14h réelles.
- Recherche forensic : tests successifs de plusieurs outils spécialisés uniquement sur la copie (jamais sur l'original), jusqu'à l'identification d'une structure VMFS6 complète par un outil dédié à ce format.
- Export et reconstruction : extraction de 100% des données identifiées (~2,5 To), création d'un nouveau datastore propre, réenregistrement et validation des VM avant remise en production.
Résultat
Intégralité des ~30 VM de production récupérées sans perte de données, malgré l'absence de toute sauvegarde préalable. Reprise de service validée machine par machine.
Enseignements retenus
- Un LUN ne doit jamais être partagé entre deux systèmes de stockage différents sans démarcation stricte.
- Toujours vérifier l'identité exacte d'un LUN/target (IQN, IP, taille) avant d'y créer une nouvelle ressource.
- Travailler exclusivement sur des copies a permis de tester plusieurs outils sans risque d'aggraver la situation.
Contexte anonymisé : environnement de virtualisation en production (~30 machines virtuelles, aucune sauvegarde disponible) devenu inaccessible suite à une erreur de configuration lors du rattachement d'un nouveau datastore iSCSI.
Diagnostic
- Un LUN unique a été utilisé simultanément comme datastore VMware/ESXi existant et comme cible d'un nouveau SR de stockage XCP-ng.
- Le nouveau système de stockage a écrit sa propre structure (en-tête LVM + un disque virtuel de 80 Go) sur le LUN pendant qu'un transfert de VM était en cours.
- Conséquence : le superblock VMFS a été écrasé, rendant le datastore invisible et illisible pour ESXi.
- Confirmation via les outils en ligne de commande ESXi que le datastore avait disparu, et vérification qu'aucun snapshot ni sauvegarde n'existait pour restaurer l'état antérieur.
Actions menées
- Sécurisation immédiate : annulation du transfert en cours, déconnexion du SR fautif pour stopper toute écriture supplémentaire, passage du LUN en lecture seule côté baie de stockage.
- Imagerie bit-à-bit d'un volume de 8 To avec ddrescue depuis une machine Linux, copie réalisée sans aucune erreur de secteur (confirmant une corruption logique et non physique).
- Optimisation du pipeline de traitement : après un premier essai trop lent (I/O aléatoires sur partage réseau), mise en place d'un volume iSCSI dédié et d'une liaison directe 10 Gbps, ramenant le temps de traitement d'environ 43h estimées à 13-14h réelles.
- Recherche forensic : tests successifs de plusieurs outils spécialisés uniquement sur la copie (jamais sur l'original), jusqu'à l'identification d'une structure VMFS6 complète par un outil dédié à ce format.
- Export et reconstruction : extraction de 100% des données identifiées (~2,5 To), création d'un nouveau datastore propre, réenregistrement et validation des VM avant remise en production.
Résultat
Intégralité des ~30 VM de production récupérées sans perte de données, malgré l'absence de toute sauvegarde préalable. Reprise de service validée machine par machine.
Enseignements retenus
- Un LUN ne doit jamais être partagé entre deux systèmes de stockage différents sans démarcation stricte.
- Toujours vérifier l'identité exacte d'un LUN/target (IQN, IP, taille) avant d'y créer une nouvelle ressource.
- Travailler exclusivement sur des copies a permis de tester plusieurs outils sans risque d'aggraver la situation.