Varning: Anteckningen är för underhållningsändamål. Den specifika tätheten av användbar information i den är låg. Det skrevs "för mig själv".
Lyrisk introduktion
Fildumpen i vår organisation körs på en VMware ESXi 6 virtuell maskin som kör Windows Server 2016. Och detta är inte bara en soptipp. Detta är en filutbytesserver mellan strukturella divisioner: det finns samarbete, projektdokumentation och mappar från nätverksskannrar. I allmänhet är allt produktionsliv här.
Och denna behållare av allt produktionsliv började hänga. Dessutom kunde gästen tyst hänga sig själv utan att påverka de andra. Han kunde ta ner hela värden och följaktligen alla andra gästmaskiner. Jag skulle kunna hänga mig och hänga vSphere-klienttjänsterna: det vill säga att de andra gästernas processer lever, maskinerna fungerar korrekt och svarar, men det finns ingen filtvättare och vSphere-klienten klamrar sig inte fast vid värden. I allmänhet kunde inget system identifieras. Frysningar kan förekomma under dagen vid låg belastning. De kunde göra det på natten under ingen belastning. Kan på natten under differentiell backup och genomsnittlig belastning. Kunde på helger under full backup och hög belastning. Och det var en tydlig försämring av situationen. Först var det en gång om året, sedan en gång i halvåret. På slutet av mitt tålamod - två gånger i veckan.
Jag hade ett minnesproblem. Men de lät mig inte stoppa sophögen ens på helgerna och köra Memtest. Vi väntade på majlovet. Under majlovet körde jag Memtest och... inga fel hittades.
Jag blev förvånad och bestämde mig för att åka på semester. Medan jag var på semester var det inte ett enda stopp på soptippen. Och när jag gick tillbaka till jobbet för första dagen i måndags låg det en sophög. Jag uthärdade en fullständig backup och hängde direkt efter att den var klar. Ett sådant varmt välkomnande från semestern drev mig till beslutet att fysiskt dra diskarna med gästmaskinen till en annan värd.
Och även om det länge har varit känt att man inte kan göra något seriöst den första dagen efter en semester, även om jag förberedde mig på att inte jobba hela vägen till jobbet, slog min indignation över ännu en frysning både mitt humör och min löften ur mitt huvud...
Fysiska diskar har flyttats till en annan värd. Varm anslutning. I lagringsinställningarna på fliken Enheter skivor visas. På fliken Databutiker Det finns ingen lagring på dessa diskar. refresh - dyker inte upp. Jo, naturligtvis, den första impulsen - Lägg Förvaring. Add Wizard förklarar vad den stöder. Naturligtvis stöder den också VMFS. Jag tvivlade inte på det. En snabb titt på guidens meddelanden vid varje steg: Nästa, Nästa, Nästa, Slutför. Ögat var inte ens i närheten av att fånga den lilla gula cirkeln med ett utropstecken längst ner i fönstret i ett av mästarens steg.
I slutet av guiden dök det nya datalagret upp i listan... och tillsammans med det datalagret från de återstående fysiska diskarna.
Jag går vidare till att navigera genom den nyligen tillagda Datastore, och den är... tom. Naturligtvis föll jag tillbaka i förvåning. Klockan är 8, de första 15 minuterna på jobbet efter semestern, jag har inte ens rört ut sockret i mitt kaffe än. Och här är den. Den första tanken var att jag drog fel disk från den "infödda" värden. Jag tittade för att se om den nödvändiga Datastore fanns i den "native" värden: nej, den fanns inte. Den andra tanken var: "fan!" Jag är inte säker, men det verkar som om den tredje, fjärde och åtminstone femte tanken var densamma.
För att skingra tvivel installerade jag snabbt en ny ESXi för testning, tog den vänstra skivan och när jag redan läste den gick jag igenom stegen i guiden. Ja. När du lägger till ett datalager med hjälp av guiden försvinner all data på disken utan möjlighet att återställa åtgärden och återställa data. Senare läste jag på ett av forumen en bedömning av denna design av en mästare: skitbra. Och jag höll verkligen med.
Från och med den sjätte flödade tankarna i en mer konstruktiv riktning. OK. Initiering tar bara några sekunder även för en 3Tb disk. Så det här är formatering på hög nivå. Det betyder att partitionstabellen helt enkelt skrevs om. Så data finns kvar. Så nu ska vi leta efter lite oformat och voila.
Jag startar maskinen från Strelec-startavbildningen... Och jag får reda på att partitionsåterställningsprogram kan allt utom VMFS. Till exempel känner de till partitionslayouten för Synology, men inte VMFS.
Att söka igenom program är inte betryggande: i bästa fall hittar GetDataBack och R.Saver NTFS-partitioner med en levande katalogstruktur och levande filnamn. Men det här passar mig inte. Jag behöver två vmdk-filer: med systemdisken och papperskorgen.
Och då förstår jag att det ser ut som att jag nu ska installera Windows och rulla ut från en filsäkerhetskopiering. Och samtidigt minns jag att jag hade en DFS-rot där. Och även ett system med åtkomsträttigheter till avdelningsmappar som är helt vilda i omfattning och förgreningar. Inte ett alternativ. Det enda tidsacceptabla alternativet är att återställa systemets och diskens tillstånd med data och alla rättigheter.
Återigen Google, forum, KB'shki och igen Yaroslavnas gråt: VMware ESXi tillhandahåller ingen dataåterställningsmekanism. Alla diskussionstrådar har två slut: någon återställdes med den dyra DiskInternals VMFS Recovery, eller någon fick hjälp av en mjukvaruspecialist som aktivt marknadsförde sina tjänster vmfs-verktyg и dd. Alternativet att köpa en DiskInternals VMFS Recovery-licens för $700 är inte ett alternativ. Att tillåta en utomstående från "en potentiell fiendes territorium" att få tillgång till företagsdata är inte heller ett alternativ. Men det googlades om att VMFS-partitioner även kan läsas av UFS Explorer.
DiskInternals VMFS-återställning
Testversionen laddades ner och installerades. Programmet såg framgångsrikt den tomma VMFS-partitionen:
läget Återställ (snabbsökning) Jag hittade också en taskig Datastore med mappar med virtuella maskiner med diskar inuti:
Förhandsgranskningen visade att filerna är levande:
Monteringen av partitionen i systemet lyckades, men av någon okänd anledning innehöll alla tre mappar samma virtuella maskin. Enligt lagen är elakhet naturligtvis inte vad som krävs.
Tre rader av skamFörsöket att skamlöst låsa programvaran slutade i ett misslyckande. Men UFS Explorer låste sig.
Jag har en extremt negativ inställning till programstöld. Jag uppmuntrar inte på något sätt att använda medel för att kringgå skydd mot olicensierad användning.
Jag var i en katastrofal situation och var inte alls stolt över de åtgärder jag hade tillgripit.
UFS Explorer
En diskskanning visade närvaron av 7 noder. Antalet noder sammanföll "överraskande nog" med antalet *-flat.vmdk-filer som upptäckts av VMFS Recovery:
En jämförelse av filstorlekar och nodstorlekar visade också en matchning ner till byten. Samtidigt återställdes namnen på *-flat.vmdk-filerna och följaktligen deras tillhörighet till virtuella maskiner.
I allmänhet består vmdk-diskar från ESXi-synpunkt av två filer: en datafil (<maskinnamn>-flat.vmdk) och en "fysisk" disklayoutfil (<maskinnamn>.vmdk). Om du laddar upp en *-flat.vmdk-fil till Datastore från en lokal dator kommer ESXi inte att känna igen den som en giltig diskfil. VMware Knowledge Base har en artikel om hur man manuellt skapar en diskbeskrivningsfil: , men jag behövde inte göra detta, jag kopierade helt enkelt innehållet i motsvarande filer från förhandsgranskningsområdet för filinnehåll i DiskInternals VMFS Recovery:
Efter 4 timmars urladdning av en 2,5 TB nod från UFS Explorer och 20 timmars laddning i hypervisorns Datastore, kopplades de kraschade diskfilerna till den nyskapade virtuella maskinen. Skivorna plockade upp. Ingen dataförlust observerades.
Källa: will.com