Disclaimer: Het briefje is bedoeld voor amusementsdoeleinden. De specifieke dichtheid van nuttige informatie daarin is laag. Het is geschreven ‘voor mezelf’.
Lyrische inleiding
De bestandsdump in onze organisatie draait op een virtuele VMware ESXi 6-machine met Windows Server 2016. En dit is niet zomaar een vuilnisbelt. Dit is een server voor bestandsuitwisseling tussen structurele afdelingen: er is samenwerking, projectdocumentatie en mappen van netwerkscanners. Over het algemeen is het hele productieleven hier.
En deze container met al het productieleven begon te hangen. Bovendien kon de gast zichzelf stilletjes ophangen zonder de anderen te beïnvloeden. Hij zou de hele host kunnen uitschakelen, en dus ook alle andere gastmachines. Ik zou mezelf kunnen ophangen en de vSphere-clientservices kunnen ophangen: dat wil zeggen, de processen van de andere gasten leven, de machines werken naar behoren en reageren, maar er is geen bestandswasmachine en de vSphere Client houdt zich niet vast aan de host. Over het algemeen kon geen enkel systeem worden geïdentificeerd. Bij lage belasting kunnen er overdag bevriezingen optreden. Ze zouden het 's nachts kunnen doen als er geen belasting is. Kan 's nachts tijdens differentiële back-up en gemiddelde belasting. Kan in het weekend tijdens volledige back-ups en hoge belasting. En er was sprake van een duidelijke verslechtering van de situatie. In eerste instantie was dat één keer per jaar, daarna één keer per zes maanden. Aan het einde van mijn geduld - twee keer per week.
Ik had een geheugenprobleem. Maar ze lieten me niet toe om zelfs in het weekend de vuilnisbelt tegen te houden en Memtest uit te voeren. We waren aan het wachten op de meivakantie. Tijdens de meivakantie heb ik Memtest gedraaid en... er zijn geen fouten gevonden.
Ik was verbaasd en besloot op vakantie te gaan. Terwijl ik op vakantie was, was er geen enkele ophanging op de vuilstortplaats. En toen ik maandag voor de eerste dag weer aan het werk ging, lag er een vuilnisbelt. Ik heb een volledige back-up doorstaan en bleef meteen hangen nadat deze was voltooid. Zo'n warm welkom na mijn vakantie bracht mij tot de beslissing om de schijven met de gastmachine fysiek naar een andere host te slepen.
En hoewel het al lang bekend is dat je op de eerste dag na een vakantie niets ernstigs kunt doen, hoewel ik mezelf erop voorbereidde om niet helemaal naar mijn werk te werken, deed mijn verontwaardiging over de zoveelste bevriezing zowel mijn humeur als mijn geloften uit mijn hoofd...
Fysieke schijven zijn verplaatst naar een andere host. Warme verbinding. In de opslaginstellingen op het tabblad Schijven schijven verschijnen. Op het tabblad Gegevensopslag Er is geen opslagruimte op deze schijven. verversen - niet verschijnen. Nou ja, natuurlijk, de eerste impuls... Voeg Storage. De wizard Toevoegen legt uit wat deze ondersteunt. Uiteraard ondersteunt het ook VMFS. Ik twijfelde er niet aan. Een snelle blik op de berichten van de wizard bij elke stap: Volgende, Volgende, Volgende, Voltooien. Het oog kwam niet eens in de buurt van de kleine gele cirkel met een uitroepteken onderaan het raam van een van de traptreden van de meester.
Aan het einde van de wizard verscheen de nieuwe Datastore in de lijst... en daarmee de Datastores van de resterende fysieke schijven.
Ik ga verder met navigeren door de nieuw toegevoegde Datastore, en deze is... leeg. Natuurlijk viel ik weer in verbazing. Het is 8 uur 's ochtends, de eerste 15 minuten op het werk na de vakantie, ik heb nog niet eens de suiker in mijn koffie geroerd. En hier is het. De eerste gedachte was dat ik de verkeerde schijf van de “native” host had gehaald. Ik heb gekeken of de benodigde Datastore aanwezig was in de “native” host: nee, die was niet aanwezig. De tweede gedachte was: “fuck!” Ik weet het niet zeker, maar het lijkt mij dat de derde, vierde en op zijn minst vijfde gedachte hetzelfde waren.
Om twijfels weg te nemen, installeerde ik snel een nieuwe ESXi om te testen, pakte de linkerschijf en liep, al aan het lezen, door de stappen van de wizard. Ja. Wanneer u een Datastore toevoegt met behulp van de wizard, gaan alle gegevens op de schijf verloren zonder dat u de bewerking kunt terugdraaien en de gegevens kunt herstellen. Later las ik op een van de forums een beoordeling van dit ontwerp door een meester: rotzooi. En ik was het er echt mee eens.
Vanaf de zesde stroomden de gedachten in een meer constructieve richting. OK. Initialisatie duurt een kwestie van seconden, zelfs voor een schijf van 3 Tb. Dit is dus opmaak op hoog niveau. Dit betekent dat de partitietabel eenvoudigweg werd herschreven. De gegevens zijn er dus nog steeds. Dus nu gaan we op zoek naar wat unformat en voila.
Ik start de machine op vanaf de Streelec-opstartimage... En ik ontdek dat partitieherstelprogramma's alles weten behalve VMFS. Ze kennen bijvoorbeeld de partitie-indeling van Synology, maar niet VMFS.
Zoeken door programma's is niet geruststellend: in het beste geval vinden GetDataBack en R.Saver NTFS-partities met een live directorystructuur en live bestandsnamen. Maar dit past niet bij mij. Ik heb twee vmdk-bestanden nodig: met de systeemschijf en de prullenbakbestandschijf.
En dan begrijp ik dat het erop lijkt dat ik nu Windows ga installeren en uitrollen vanaf een bestandsback-up. En tegelijkertijd herinner ik me dat ik daar een DFS-root had. En ook een systeem van toegangsrechten tot afdelingsmappen dat absoluut wild is qua omvang en gevolgen. Geen optie. De enige tijd-acceptabele optie is het herstellen van de status van het systeem en de schijf met gegevens en alle rechten.
Opnieuw Google, forums, KB'shki en opnieuw roept Yaroslavna: VMware ESXi biedt geen mechanisme voor gegevensherstel. Alle discussiethreads hebben twee uiteinden: iemand is hersteld met behulp van het dure DiskInternals VMFS Recovery, of iemand is geholpen door een softwarespecialist die zijn diensten actief promoot vmfs-tools и dd. De optie om een DiskInternals VMFS Recovery-licentie voor $700 aan te schaffen is geen optie. Een buitenstaander uit het ‘territorium van een potentiële vijand’ toegang geven tot bedrijfsgegevens is eveneens geen optie. Maar er werd gegoogled dat VMFS-partities ook door UFS Explorer kunnen worden gelezen.
DiskInternals VMFS-herstel
De proefversie is gedownload en geïnstalleerd. Het programma zag met succes de lege VMFS-partitie:
de mode Verwijdering ongedaan maken (snelle scan) Ik vond ook een armoedige Datastore met mappen met virtuele machines met schijven erin:
Uit het voorbeeld bleek dat de bestanden leven:
Het koppelen van de partitie in het systeem was succesvol, maar om een onbekende reden bevatten alle drie de mappen dezelfde virtuele machine. Volgens de wet is gemeenheid uiteraard niet vereist.
Drie lijnen van schaamteDe poging om de software schaamteloos te vergrendelen liep op een mislukking uit. Maar UFS Explorer zat vast.
Ik heb een uiterst negatieve houding tegenover softwarediefstal. Ik moedig op geen enkele manier het gebruik aan van middelen om de bescherming tegen ongeoorloofd gebruik te omzeilen.
Ik bevond mij in een catastrofale situatie en was helemaal niet trots op de maatregelen waartoe ik mijn toevlucht had genomen.
UFS-verkenner
Een schijfscan toonde de aanwezigheid van 7 knooppunten aan. Het aantal knooppunten viel “verrassend genoeg” samen met het aantal *-flat.vmdk-bestanden gedetecteerd door VMFS Recovery:
Een vergelijking van bestandsgroottes en knooppuntgroottes toonde ook een overeenkomst tot op de byte aan. Tegelijkertijd werden de namen van *-flat.vmdk-bestanden en dienovereenkomstig hun eigendommen bij virtuele machines hersteld.
Over het algemeen bestaan vmdk-schijven vanuit het ESXi-oogpunt uit twee bestanden: een gegevensbestand (<machinenaam>-flat.vmdk) en een “fysiek” schijfindelingsbestand (<machinenaam>.vmdk). Als u een *-flat.vmdk-bestand uploadt naar de Datastore vanaf een lokale machine, zal ESXi dit niet herkennen als een geldig schijfbestand. De VMware Knowledge Base bevat een artikel over hoe u handmatig een schijfdescriptorbestand kunt maken: , maar ik hoefde dit niet te doen, ik heb eenvoudigweg de inhoud van de overeenkomstige bestanden gekopieerd uit het voorbeeldgebied voor de bestandsinhoud in DiskInternals VMFS Recovery:
Na 4 uur laden van een knooppunt van 2,5 TB uit UFS Explorer en 20 uur laden in de Datastore van de hypervisor, werden de gecrashte schijfbestanden verbonden met de nieuw gemaakte virtuele machine. De schijven zijn opgenomen. Er werd geen gegevensverlies waargenomen.
Bron: www.habr.com