Analyse
Comprendre le disque virtuel dans un cluster
Un disque virtuel en cluster n’est pas un fichier indépendant que l’on peut copier au hasard. Il appartient à une chaîne qui associe un descripteur, des données, d’éventuels fichiers différentiels, un espace de stockage virtualisé, le système de fichiers de l’invité et le stockage partagé. Une machine virtuelle (VM) peut aussi utiliser un instantané (snapshot), c’est-à-dire un état enregistré dont le fichier différentiel reste rattaché à un disque parent. Le cluster ajoute des hôtes, des verrous, des chemins et des mécanismes de bascule qui peuvent tous influencer le symptôme.
Une machine virtuelle lente ne prouve pas que son disque est corrompu. La cause peut se situer dans l’invité, l’hyperviseur, le réseau de stockage, un contrôleur, un ensemble RAID ou un groupe de stockage. À l’inverse, un disque virtuel peut sembler présent et de taille plausible alors que son fichier différentiel actif dépend d’un disque parent absent.
Le quorum et l’état « sain » du cluster concernent la coordination des nœuds, pas l’intégrité de chaque donnée. Un cluster peut rester disponible tout en servant une version logique endommagée, ou isoler correctement un hôte alors que le stockage commun demeure instable. Ces verdicts doivent être lus séparément.
Cartographier avant de réparer
| Couche | Objet à préserver | Symptôme possible |
|---|---|---|
| Invité | Le système de fichiers, la base et les journaux | Des erreurs, un volume en lecture seule ou un service arrêté |
| Disque virtuel | Les fichiers VMDK et VHDX, le descripteur et les fichiers différentiels | Une chaîne invalide ou un démarrage impossible |
| Hyperviseur | La configuration, les verrous et les tâches | Un instantané bloqué ou une migration échouée |
| Stockage virtualisé | Les métadonnées, la capacité et les chemins | Une latence, une déconnexion ou un montage partiel |
| Stockage physique | L’ensemble RAID, le NAS, le réseau SAN et les disques | Des erreurs d’entrée-sortie touchant plusieurs machines |
Sur un NAS d’entreprise, un disque virtuel dépend directement du stockage partagé. Dans un cluster, les signaux doivent en plus être corrélés entre les systèmes invités, les hôtes, les chemins et l’espace de stockage avant la panne franche.
Analyse
Repérer les signes avant la panne
Le signal le plus utile n’est pas une alerte isolée, mais une corrélation. Si plusieurs machines situées sur le même espace de stockage ralentissent au même moment, la couche partagée devient suspecte. Si une seule application se dégrade sans erreur d’entrée-sortie, la cause peut rester dans l’invité.
Signes à rapprocher dans le temps
- Une hausse durable de la latence et des files d’attente ;
- Des erreurs d’entrée-sortie sur plusieurs systèmes invités ;
- Des chemins de stockage perdus puis retrouvés ;
- Des instantanés ou des sauvegardes qui dépassent leur fenêtre ;
- Un espace de stockage saturé ou passé en lecture seule ;
- Des verrous persistants après une tâche interrompue ;
- Une migration à chaud échouée ;
- Des redémarrages ou des bascules répétées des mêmes machines.
Les journaux de l’invité, de l’hyperviseur, du cluster, du réseau et de la baie doivent être copiés avant leur rotation. Les horloges et les fuseaux sont vérifiés afin de reconstituer une séquence commune. Une capture d’écran sans fichier de journal ne suffit pas lorsque les événements se répondent sur plusieurs couches.
| Observation | Hypothèse à vérifier | Conclusion prématurée à éviter |
|---|---|---|
| Un instantané bloqué | L’espace disponible, un verrou, le disque parent ou un stockage lent | « L’instantané est seulement trop volumineux » |
| La latence de plusieurs machines virtuelles | Le stockage virtualisé, le réseau ou la baie partagée | « Toutes les machines virtuelles sont corrompues » |
| Une machine virtuelle ne démarre plus | La chaîne virtuelle ou le système invité | « Le fichier principal est perdu » |
| Un chemin revenu en ligne | Une instabilité transitoire de la couche | « Le stockage est redevenu sain » |
Un retour à la normale n’efface pas l’alerte. Une latence intermittente ou un chemin revenu en ligne peut annoncer une fenêtre de lecture limitée ; il faut conserver les traces et vérifier les sauvegardes avant une nouvelle tâche lourde.
Analyse
Éviter les reconstructions et les migrations à chaud
Sous pression, la consolidation des instantanés, l’extension de l’espace de stockage ou la migration d’une machine virtuelle semblent libérer de l’espace et remettre le service en mouvement. Ces opérations lisent et écrivent beaucoup. Sur une couche instable, elles peuvent créer une nouvelle version partielle et rendre l’état initial plus difficile à reconstituer.
Figer la chaîne complète
Avant toute action corrective, il faut inventorier :
- Les fichiers de configuration et les descripteurs ;
- Les disques de base et les fichiers différentiels dans leur ordre ;
- La tâche active ou interrompue ;
- L’emplacement de l’espace de stockage et les hôtes connectés ;
- Les sauvegardes et les réplications disponibles ;
- Les données et la période prioritaires.
Un instantané reste dépendant du disque de base, de ses fichiers différentiels, de l’espace de stockage et des métadonnées de l’hyperviseur : il ne constitue pas une sauvegarde indépendante. Sa suppression peut déclencher une consolidation qui réécrit la chaîne. Déplacer seulement le fichier le plus volumineux peut oublier des descripteurs ou des fichiers différentiels, et forcer un verrou sans identifier son propriétaire peut autoriser deux écritures concurrentes.
Seuil d’arrêt — Des erreurs d’entrée-sortie croissantes, des chemins instables, un stockage saturé et des instantanés incohérents imposent de suspendre les migrations, les consolidations, les sauvegardes et les réparations qui écrivent sur la chaîne source.
La continuité doit être relancée sur une copie saine ou une restauration isolée. Une copie partielle peut servir à un diagnostic si elle est datée et ne remplace pas l’original. Les administrateurs doivent noter chaque tentative plutôt que recréer plusieurs variantes sans provenance.
Analyse
Diagnostiquer les couches du stockage et de l’hyperviseur
Le diagnostic descend et remonte la chaîne. Il vérifie d’abord la stabilité du stockage physique et la possibilité d’acquérir les objets virtuels. Il reconstitue ensuite les relations entre les disques parents et les fichiers différentiels, puis le système de fichiers invité et enfin l’application.
Une hypothèse par couche
Une séquence défendable suit ces étapes :
- Acquérir ou copier les fichiers disponibles sans modifier la source ;
- Contrôler les tailles, les identifiants et les descripteurs ;
- Reconstruire la chaîne des instantanés sur une copie ;
- Présenter le disque virtuel en lecture contrôlée ;
- Vérifier les partitions et le système de fichiers invité ;
- Ouvrir les bases, les archives ou les services prioritaires dans un environnement isolé.
Quand le stockage utilise la déduplication, la compression ou une distribution propriétaire, copier les fichiers virtuels visibles depuis un hôte ne suffit pas toujours à préserver la couche basse. Le diagnostic doit établir à quel niveau une acquisition fidèle reste possible et quelles métadonnées du système de stockage sont indispensables.
La récupération d’un disque virtuel couvre le parcours de prise en charge. Les limites restent spécifiques : un fichier différentiel manquant, un descripteur incohérent, des blocs écrasés, un stockage partiellement acquis, un chiffrement inaccessible ou un ensemble RAID sous-jacent endommagé.
Datastrophe évalue le résultat à partir des données, pas à partir de l’écran de démarrage. Une base doit s’ouvrir avec ses journaux utiles ; un partage doit couvrir les périodes attendues ; une machine virtuelle doit être testée hors production. Aucune reconstruction ne recrée les blocs devenus absents après la suppression d’un instantané et la réécriture de sa chaîne.
Analyse
Préparer une récupération exploitable
Il contient :
Le dossier de diagnostic
- L’hyperviseur, sa version et le nombre d’hôtes ;
- Le format et l’emplacement de chaque disque virtuel ;
- La liste et l’ordre des instantanés ;
- L’espace de stockage, son protocole et le stockage sous-jacent ;
- Les alertes, les erreurs d’entrée-sortie et les tâches interrompues ;
- Les migrations, les consolidations et les restaurations tentées ;
- Les sauvegardes avec leur dernier test connu ;
- Les applications, les fichiers et les périodes prioritaires.
La validation finale distingue le disque acquis, la chaîne reconstruite, le système invité montable et les données métier contrôlées. Chaque fichier reçoit l’un des quatre statuts canoniques : contenu contrôlé et exploitable (recoverable_verified), contenu incomplet avec sa limite (partial), nom ou signature détecté sans preuve d’intégrité (detected_unverified) et contenu non exploitable (unrecoverable). Une machine virtuelle démarrée avec des fichiers manquants n’est pas présentée comme une récupération complète.
Le transport privé aller et retour du support est systématiquement pris en charge. Le transporteur déplace uniquement le colis scellé : il n’accède pas aux données et ne les traite jamais. Le diagnostic et le devis sont gratuits au laboratoire Datastrophe. Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée des fichiers recherchés.
Cette liste reprend les quatre statuts canoniques ci-dessus. Seuls les éléments recoverable_verified, dont le contenu est contrôlé et exploitable, sont présentés comme récupérables. Le client paie uniquement s’il accepte la liste contrôlée et le prix. La récupération finale, la préparation du résultat et la restitution interviennent après ce paiement.
Si aucune donnée exploitable vérifiée n’est trouvée, si la récupération finale échoue ou si le client refuse la liste ou le prix, aucun frais standard d’intervention, de transport aller, de transport retour, de douane ou de support standard de restitution n’est dû. La seule exception concerne une pièce rare et coûteuse : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée, et son coût reste non remboursable même si la récupération n’aboutit pas.
Analyse
Sources techniques primaires
Sources techniques primaires
- Examiner la relation parent-enfant des descripteurs VMDK : champs d’identification, ordre de la chaîne et relation entre un fichier parent et son enfant.
- Diagnostiquer les points de contrôle et les disques AVHDX : inventaire des chaînes Hyper-V, espace nécessaire à la fusion et traitement des fichiers différentiels orphelins.