Disclaimer: Dit aantekening heeft een vermakelijk karakter. De informatie-dichtheid is laag. Het was geschreven "voor mezelf".
Lyrische inleiding
De bestandcontainer in onze organisatie draait op een virtuele machine VMware ESXi 6 onder Windows Server 2016. En dit is niet zomaar een container. Dit is een server voor bestandsoverdracht tussen de afdelingen: hier vindt gezamenlijke samenwerking plaats, projectdocumentatie, en mappen van netwerkscanners. Kortom, hier bevindt zich het hele productieproces.
En dit vat van het hele productieproces begon vast te lopen. Bovendien kon een gast stilletjes vastlopen zonder de anderen te beĆÆnvloeden. Hij kon het hele host vastzetten en, bijgevolg, alle andere gastmachines. Hij kon zichzelf vastzetten en de klantenservices van vSphere platleggen: dat wil zeggen, de processen van de andere gasten waren levend, de machines werkten correct en reageerden, maar de bestandscontainer niet en de vSphere Client kon de host niet bereiken. Kortom, er was geen systeem te detecteren. Vastlopers konden zich overdag voordoen tijdens een lage belasting. Ze konden 's nachts optreden bij nul belasting. Ze konden 's nachts optreden tijdens een incrementele back-up en gemiddelde belasting. Ze konden in het weekend tijdens een volledige back-up en hoge belasting voorkomen. En er was een duidelijke verslechtering van de situatie zichtbaar. In het begin was het eens per jaar, daarna eens per half jaar. Tegen het einde van mijn geduld - tweemaal per week.
Ik gaf de schuld aan het RAM-geheugen. Maar ik kon de container zelfs in het weekend niet stopzetten en Memtest draaien. We wachtten op de meivakanties. Tijdens de meivakanties heb ik Memtest gedraaid en... er werden geen fouten gevonden.
Ik viel in verbazing en besloot op vakantie te gaan. Terwijl ik op vakantie was, was er geen enkele vastloper bij de container. En toen ik op maandag weer aan het werk ging - stond de container vast. Hij overleefde de volledige back-up en net na het beƫindigen ervan viel hij stil. Zo'n warme terugkeer van vakantie duwde me naar de beslissing om de schijven van de gastmachine fysiek naar een andere host te verplaatsen.
En, hoewel het al lang bekend is dat je op de eerste dag na je vakantie niets ernstigs moet doen, hoewel ik mezelf elke reis naar het werk had ingesteld om niet te werken, maakte mijn verontwaardiging over de volgende vastloper me het hoofd en de instelling en de beloften vergeten...
De fysieke schijven werden in een andere host geplaatst. Hot swap. In de opslaginstellingen op het tabblad Schijven de schijven verschijnen. Op het tabblad Datastores zijn er geen opslagplaatsen op deze schijven. Vernieuwen ā verschijnen niet. En natuurlijk is mijn eerste reactie ā Voeg opslag toe. De wizard voor het toevoegen vertelt dat hij dit ondersteunt. Natuurlijk ondersteunt hij VMFS. Daar had ik geen twijfels over. Een vluchtige blik op de berichten van de wizard bij elke stap: Volgende, Volgende, Voltooien. Mijn blik is zelfs niet op de kleine gele cirkel met een uitroepteken onderaan een van de stappen van de wizard gevallen.
Na de wizard verscheen de nieuwe Datastore in de lijst... samen met Datastores van de andere fysieke schijven.
Ik ga navigeren door de pas toegevoegde Datastore, en die is... leeg. Uiteraard viel ik opnieuw in verbazing. Het is 8 uur 's morgens, de eerste 15 minuten op het werk na mijn vakantie, ik heb zelfs de suiker in mijn koffie nog niet geroerd. En dan dit. Mijn eerste gedachte was ā ik heb de verkeerde schijf van de "hoofd" host getrokken. Gecontroleerd of de gewenste Datastore aanwezig is op de "hoofd" host: nee, die is er niet. De tweede gedachte was: "verdorie!". Ik ben niet zeker, maar ik denk dat de derde, vierde en minstens de vijfde gedachte ook zo waren.
Om mijn twijfels te verhelpen, heb ik snel een nieuwe ESXi getest, een random schijf genomen en, terwijl ik las, door de stappen van de wizard gegaan. Ja. Bij het toevoegen van een Datastore via de wizard verliezen alle gegevens op de schijf zonder mogelijkheid om de operatie terug te draaien en gegevens te herstellen. Later las ik op een van de forums de beoordeling van dit ontwerp van de wizard: shitsome crap. En ik kon het niet meer eens zijn.
Vanaf de zesde ā begonnen de gedachten meer constructief te stromen. Goed. De initialisatie duurt enkele seconden, zelfs voor een 3Tb-schijf. Dat betekent dat het om hoog-niveau formatteren gaat. Dat betekent dat alleen de partitie-tabel is overschreven. Dat betekent dat de gegevens er nog steeds zijn. Dus nu gaan we een unformat-tool zoeken en voila.
Ik boot de machine met het opstartimage van Strelec... En ontdek dat recovery-programma's alles weten, behalve VMFS. Ze kennen bijvoorbeeld de partitie-indeling van Synology, maar VMFS ā niet.
De zoektocht naar programma's is niet bemoedigend: in de beste gevallen vinden GetDataBack en R.Saver NTFS-partities met een levendige mappenstructuur en levende bestandsnamen. Maar dat voldoet me niet. Ik heb twee vmdk-bestanden nodig: met de schijf van het systeem en de schijf van de afvalbestanden.
En dat is wanneer ik besef dat ik waarschijnlijk Windows ga installeren en mijn bestanden ga herstellen vanaf een back-up. Tegelijkertijd herinner ik me dat ik daar een DFS-wortel had. En er is ook een volkomen verbazend uitgebreide en afwijkende systeem van toegangsrechten voor de mappen van de afdelingen. Geen optie. De enige tijdsefficiƫnte optie is het herstel van de systeemstatus en de schijf met gegevens en alle rechten.
Weer googelen, forums, KB-artikelen en wederom de klachten van een Jozefina: VMware ESXi biedt geen mechanisme voor gegevensherstel. Alle discussiedraden hebben twee eindes: iemand herstelde met behulp van de dure DiskInternals VMFS Recovery of iemand kreeg hulp van een specialist die zijn diensten actief promootte. vmfs-tools en dd. De optie om een licentie van DiskInternals VMFS Recovery voor $700 aan te schaffen, is geen optie. Toegang voor een derde partij van 'het grondgebied van een potentiƫle vijand' tot bedrijfsgegevens is eveneens geen optie. Maar het is gevonden dat UFS Explorer ook VMFS-partities kan lezen.
DiskInternals VMFS Recovery
Een trialversie werd gedownload en geĆÆnstalleerd. Het programma zag succesvol de lege VMFS-partitie:
In modus Undelete (Snelle scan) vond ook de beschadigde datastore met mappen virtuele machines met schijven erin:
De preview toonde aan dat de bestanden levend waren:
Het monteren van de partitie in het systeem was succesvol, maar om onduidelijke redenen had elke map dezelfde virtuele machine. Natuurlijk, volgens de wet van Murphy ā niet de gewenste.
Drie zinnen van schaamteDe poging om de software schaamteloos te pirateren eindigde in een fiasco. Maar UFS Explorer werd wel succesvol gepirateerd.
Ik ben extreem negatief over software-diefstal. Ik roep absoluut niet op tot het gebruiken van middelen om de bescherming tegen ongeautoriseerd gebruik te omzeilen.
Ik bevond me in een catastrofale positie en was totaal niet trots op de maatregelen die ik had genomen.
UFS Explorer
De scan van de schijf toonde de aanwezigheid van 7 knooppunten. Het aantal knooppunten kwam 'wonderbaarlijk' overeen met het aantal *-flat.vmdk-bestanden dat door VMFS Recovery was gevonden:
De vergelijking van bestandsgroottes en knooppuntgroottes toonde ook overeenkomsten tot op de byte. Tegelijkertijd werden de namen van de *-flat.vmdk-bestanden hersteld en dus ook de toewijzing aan de virtuele machines.
Eigenlijk bestaan vmdk-schijven vanuit het perspectief van ESXi uit twee bestanden: dit is het gegevensbestand (<machine naam>-flat.vmdk) en het bestand voor de 'fysieke' indeling van de schijf (<machine naam>.vmdk). Als je het *-flat.vmdk-bestand vanaf een lokale machine in de Datastore uploadt, herkent ESXi het niet als een geldig schijfbestand. In de VMware-kennisbank is er een artikel over hoe je handmatig een schijfdescriptorbestand kunt maken: , maar ik hoefde dit niet te doen, ik heb gewoon de inhoud van de bijbehorende bestanden gekopieerd uit het voorbeeldgedeelte van het bestand in DiskInternals VMFS Recovery:
Na 4 uur het exporteren van 2,5TB van de node uit UFS Explorer en 20 uur het uploaden naar de Datastore werden de beschadigde schijfbestanden verbonden met de pas aangemaakte virtuele machine. De schijven werden herkend. Er zijn geen gegevensverlies opgemerkt.
Bron: habr.com
