Avertissement: La note est à des fins de divertissement. La densité spécifique des informations utiles qu'il contient est faible. Il a été écrit « pour moi ».
Introduction lyrique
Le vidage de fichiers dans notre organisation s'exécute sur une machine virtuelle VMware ESXi 6 exécutant Windows Server 2016. Et il ne s'agit pas simplement d'un vidage de mémoire. Il s'agit d'un serveur d'échange de fichiers entre les divisions structurelles : il y a la collaboration, la documentation du projet et les dossiers des scanners réseau. En général, toute la vie de production est ici.
Et ce conteneur de toute la vie de production a commencé à pendre. De plus, l'invité pouvait se pendre tranquillement sans affecter les autres. Il pourrait supprimer l'intégralité de l'hôte et, par conséquent, toutes les autres machines invitées. Je pourrais me pendre et suspendre les services client vSphere : c'est-à-dire que les processus des autres invités sont vivants, les machines fonctionnent correctement et répondent, mais il n'y a pas de laveur de fichiers et vSphere Client ne s'accroche pas à l'hôte. En général, aucun système n'a pu être identifié. Des gels pourraient survenir pendant la journée lors d’une faible charge. Ils pouvaient le faire la nuit sans charge. Pourrait la nuit pendant la sauvegarde différentielle et la charge moyenne. Peut-être le week-end lors de sauvegardes complètes et de charges élevées. Et il y a eu une nette dégradation de la situation. Au début, c'était une fois par an, puis une fois tous les six mois. À bout de patience - deux fois par semaine.
J'ai eu un problème de mémoire. Mais ils ne m'ont pas laissé arrêter le tas d'ordures, même le week-end, et exécuter Memtest. Nous attendions les vacances de mai. Pendant les vacances de mai, j'ai lancé Memtest et... aucune erreur n'a été trouvée.
J'ai été étonné et j'ai décidé de partir en vacances. Pendant mes vacances, il n’y a pas eu un seul accroc à la décharge. Et quand je suis retourné au travail le premier jour de lundi, il y avait un tas d'ordures. J'ai subi une sauvegarde complète et je me suis arrêté juste après sa fin. Un accueil si chaleureux après les vacances m'a poussé à prendre la décision de faire glisser physiquement les disques contenant la machine invitée vers un autre hôte.
Et, même si l'on sait depuis longtemps qu'on ne peut rien faire de sérieux le premier jour après les vacances, même si je me préparais à ne pas travailler jusqu'au travail, mon indignation face à un énième gel a ébranlé à la fois mon humeur et mon des vœux qui me sortent de la tête...
Les disques physiques ont été déplacés vers un autre hôte. Connexion chaude. Dans les paramètres de stockage sur l'onglet Variateurs des disques apparaissent. Sur l'onglet Banques de données Il n'y a pas de stockage sur ces disques. Refresh - n'apparait pas. Eh bien, bien sûr, la première impulsion - Ajouter Stockage. L'assistant d'ajout explique ce qu'il prend en charge. Bien entendu, il prend également en charge VMFS. Je n'en doutais pas. Un aperçu rapide des messages de l'assistant à chaque étape : Suivant, Suivant, Suivant, Terminer. L’œil n’était même pas près d’apercevoir le petit cercle jaune avec un point d’exclamation au bas de la fenêtre d’un des marches du maître.
À la fin de l'assistant, le nouveau Datastore est apparu dans la liste... et avec lui les Datastores des disques physiques restants.
Je passe à la navigation dans la banque de données nouvellement ajoutée, et elle est... vide. Bien sûr, je suis retombé dans l’étonnement. Il est 8 heures du matin, les 15 premières minutes de travail après les vacances, je n'ai même pas encore remué le sucre de mon café. Et le voici. La première pensée a été que j'avais extrait le mauvais disque de l'hôte « natif ». J'ai regardé si le Datastore requis était présent dans l'hôte « natif » : non, il n'était pas présent. La deuxième pensée a été : « putain ! Je n’en suis pas sûr, mais il me semble que la troisième, la quatrième et au moins la cinquième pensée étaient les mêmes.
Pour dissiper les doutes, j'ai rapidement installé un nouvel ESXi pour le tester, j'ai pris le disque de gauche et, après l'avoir déjà lu, j'ai suivi les étapes de l'assistant. Oui. Lorsque vous ajoutez une banque de données à l'aide de l'assistant, toutes les données du disque sont perdues sans possibilité d'annuler l'opération et de restaurer les données. Plus tard, j'ai lu sur l'un des forums une évaluation de cette conception par un maître : de la merde. Et j'étais vraiment d'accord.
À partir du sixième, les pensées ont afflué dans une direction plus constructive. D'ACCORD. L'initialisation prend quelques secondes, même pour un disque de 3 To. Il s'agit donc d'un formatage de haut niveau. Cela signifie que la table de partition a simplement été réécrite. Les données sont donc toujours là. Alors maintenant, nous allons chercher du formatage et le tour est joué.
Je démarre la machine à partir de l'image de démarrage Strelec... Et je découvre que les programmes de récupération de partition savent tout sauf VMFS. Par exemple, ils connaissent la disposition des partitions de Synology, mais pas de VMFS.
La recherche dans les programmes n'est pas rassurante : au mieux, GetDataBack et R.Saver trouvent des partitions NTFS avec une structure de répertoires et des noms de fichiers dynamiques. Mais cela ne me convient pas. J'ai besoin de deux fichiers vmdk : avec le disque système et le disque de fichiers poubelle.
Et puis je comprends qu'il semble que je vais maintenant installer Windows et déployer à partir d'une sauvegarde de fichier. Et en même temps, je me souviens que j'y avais une racine DFS. Et aussi un système de droits d'accès aux dossiers des services d'une portée et de ramifications absolument folles. Pas une option. La seule option acceptable dans le temps est de restaurer l'état du système et du disque avec les données et tous les droits.
Encore une fois Google, les forums, KB'shki et encore les cris de Yaroslavna : VMware ESXi ne fournit pas de mécanisme de récupération de données. Tous les fils de discussion ont deux fins : quelqu'un a été récupéré à l'aide du coûteux DiskInternals VMFS Recovery, ou quelqu'un a été aidé par un spécialiste en logiciel faisant activement la promotion de ses services. outils vmfs и dd. L'option d'acheter une licence DiskInternals VMFS Recovery pour 700 $ n'est pas une option. Permettre à un étranger venant du « territoire d’un ennemi potentiel » d’accéder aux données de l’entreprise n’est pas non plus une option. Mais il a été recherché sur Google que les partitions VMFS peuvent également être lues par UFS Explorer.
Récupération VMFS DiskInternals
La version d'essai a été téléchargée et installée. Le programme a réussi à voir la partition VMFS vide :
Dans le mode Annuler la suppression (analyse rapide) J'ai également trouvé un Datastore minable avec des dossiers de machines virtuelles contenant des disques :
L'aperçu a montré que les fichiers sont vivants :
Le montage de la partition dans le système a réussi, mais pour une raison inconnue, les trois dossiers contenaient la même machine virtuelle. Bien entendu, selon la loi, la méchanceté n’est pas requise.
Trois lignes de honteLa tentative de verrouiller sans vergogne le logiciel s’est soldée par un échec. Mais UFS Explorer s'est verrouillé.
J'ai une attitude extrêmement négative envers le vol de logiciels. En aucun cas je n’encourage l’utilisation de moyens permettant de contourner la protection contre une utilisation sans licence.
J'étais dans une situation catastrophique et je n'étais pas du tout fier des mesures auxquelles j'avais eu recours.
Explorateur UFS
Une analyse du disque a montré la présence de 7 nœuds. Le nombre de nœuds a coïncidé « étonnamment » avec le nombre de fichiers *-flat.vmdk détectés par VMFS Recovery :
Une comparaison des tailles de fichiers et des tailles de nœuds a également montré une correspondance jusqu'à l'octet. Dans le même temps, les noms des fichiers *-flat.vmdk et, par conséquent, leur appartenance aux machines virtuelles ont été restaurés.
En général, les disques vmdk du point de vue ESXi se composent de deux fichiers : un fichier de données (<nom de la machine>-flat.vmdk) et un fichier de configuration de disque « physique » (<nom de la machine>.vmdk). Si vous téléchargez un fichier *-flat.vmdk vers la banque de données à partir d'une machine locale, ESXi ne le reconnaîtra pas comme un fichier disque valide. La base de connaissances VMware contient un article expliquant comment créer manuellement un fichier de descripteur de disque : , mais je n'ai pas eu à le faire, j'ai simplement copié le contenu des fichiers correspondants à partir de la zone d'aperçu du contenu des fichiers dans DiskInternals VMFS Recovery :
Après 4 heures de déchargement d'un nœud de 2,5 To depuis UFS Explorer et 20 heures de chargement dans le Datastore de l'hyperviseur, les fichiers du disque en panne ont été connectés à la machine virtuelle nouvellement créée. Les disques ramassés. Aucune perte de données n'a été constatée.
Source: habr.com