Disclaimer: Notisen har ett underhÄllande syfte. Dens specifika informationsdensitet Àr lÄg. Den skrevs «för mig sjÀlv».
Lyriskt förord
FilskrÀpet i vÄr organisation körs pÄ en virtuell maskin VMware ESXi 6 under Windows Server 2016. Och det Àr inte bara skrÀp. Det Àr en filutbytesserver mellan avdelningarna: hÀr finns bÄde samarbete, projektledning och mappar med nÀtverksskaner. Med andra ord, hÀr finns hela produktionslivet.
Och denna behĂ„llare för allt produktionsliv började hĂ€nga sig. Och gĂ€sten kunde hĂ€nga sig tyst, utan att pĂ„verka de andra. Den kunde hĂ€nga sig och dra med sig hela vĂ€rden, och dĂ€rmed alla andra gĂ€ster. Den kunde hĂ€nga sig sjĂ€lv och lĂ„sa klienttjĂ€nsterna i vSphere: det vill sĂ€ga processerna för de andra gĂ€sterna var vid liv, maskinerna fungerade bra och svarade, men filskrĂ€pet fungerade inte och vSphere-klienten kunde inte ansluta till vĂ€rden. Med andra ord, ingen systematisk identifiering kunde Ă„stadkommas. HĂ€ngningar kunde intrĂ€ffa dagtid under lĂ„g belastning. De kunde intrĂ€ffa pĂ„ natten under ingen belastning. De kunde intrĂ€ffa pĂ„ natten under differentierad sĂ€kerhetskopiering och medelbelastning. De kunde intrĂ€ffa under helgerna under full sĂ€kerhetskopiering och hög belastning. Och en uppenbar försĂ€mring av situationen observerades. Först var det en gĂ„ng om Ă„ret, sedan en gĂ„ng var sjĂ€tte mĂ„nad. I slutet av mitt tĂ„lamod â tvĂ„ gĂ„nger i veckan.
Jag misstÀnkte RAM-minnet. Men jag fick inte stoppa skrÀpet ens under helgerna och köra Memtest. Vi vÀntade pÄ majhelgerna. Under majhelgerna körde jag Memtest och⊠inga fel hittades.
Jag blev förundrad och beslutade mig för att ta semester. Medan jag var pÄ semester hÀnde det inte att skrÀpet hÀngde sig. Och nÀr jag kom tillbaka till jobbet pÄ mÄndagen hÀngde skrÀpet. Den klarade av en full sÀkerhetskopiering och precis efter det hÀngde den sig. En sÄ varm Äterkomst frÄn semestern fick mig att bestÀmma mig för att fysiskt flytta diskarna för den virtuella maskinen till en annan vÀrd.
Och Àven om det lÀnge har varit kÀnt att man inte ska göra nÄgot allvarligt första dagen efter semestern, och Àven om jag under hela vÀgen till jobbet förberedde mig pÄ att inte arbeta, slog mitt förargande över Ànnu en hÀngning bort bÄde fokus och löften.
De fysiska enheterna har flyttats till en annan vĂ€rd. Hot-swap-anslutning. I lagringsinstĂ€llningarna under fliken Enheter syns enheterna. Under fliken Datastores i dessa enheter finns det inga. Uppdatera â dyker inte upp. SĂ„ klart var den första impulsen â LĂ€gg till lagring. Guiden för att lĂ€gga till berĂ€ttar att den stöder. SjĂ€lvklart stöder den ocksĂ„ VMFS. Jag hade inga tvivel. En hastig översyn av meddelandena i guiden steg för steg: NĂ€sta, NĂ€sta, NĂ€sta, Avsluta. Blicken fastnade inte ens vid den lilla gula cirkeln med utropstecknet lĂ€ngst ner i fönstret vid ett av stegen i guiden.
Vid slutet av guiden dök den nya Datastore upp pÄ listan⊠tillsammans med Datastores frÄn de andra fysiska enheterna.
Jag gĂ„r vidare för att navigera i den nyligen tillagda Datastoren, och den Ă€r⊠tom. SjĂ€lvklart förvĂ„nade jag mig igen. Klockan Ă€r 8 pĂ„ morgonen, de första 15 minuterna pĂ„ jobbet efter semestern, jag har knappt rört om sockret i mitt kaffe. Och sĂ„ hĂ€nder detta. Den första tanken var â det var inte den enheten frĂ„n "ursprunglig" vĂ€rd som jag tog. Jag kollade om den sökta Datastoren fanns pĂ„ "ursprunglig" vĂ€rd: nej, den finns inte. Den andra tanken var: "fan!". Jag Ă€r inte sĂ€ker, men jag tror att den tredje, fjĂ€rde och minst femte tanken var densamma.
För att avvÀrja tvivel installerade jag snabbt en ny ESXi för test, tog en frÀmmande enhet och gick igenom guiden steg för steg. Jaha. NÀr Datastore lÀggs till via guiden sker förlust av all data pÄ enheten utan möjlighet till ÄterstÀllning av operationen och datan. Senare lÀste jag pÄ ett forum en bedömning av sÄdant guiddesign: skitdÄligt. Och jag höll verkligen med.
FrĂ„n och med den sjĂ€tte â flöt tankarna i en mer konstruktiv riktning. Okej. Initieringen tar nĂ„gra sekunder Ă€ven för en 3TB-enhet. Det betyder att det Ă€r en högre nivĂ„ av formatering. AlltsĂ„ blev bara partitionstabellen överskriven. Det betyder att datan fortfarande finns dĂ€r. Det betyder att vi nu ska leta efter nĂ„got unformat och voila.
Jag startar maskinen frĂ„n en Strelec startimage⊠Och jag finner att program för Ă„terstĂ€llning av partitioner kĂ€nner till allt utom VMFS. Till exempel kĂ€nner de till partitionslayouten för Synology, men VMFS â nej.
Uppskattningen av programmen Àr nedslÄende: i bÀsta fall hittar GetDataBack och R.Saver NTFS-partitioner med levande katalogstrukturer och levande filnamn. Men det nöjer mig inte. Jag behöver tvÄ vmdk-filer: en med systemdisken och en med skrÀpfilerna.
Och hÀr inser jag att jag verkar behöva installera Windows och ÄterstÀlla frÄn en filbackup. Samtidigt kommer jag ihÄg att jag hade en DFS-root dÀr. Dessutom finns det ett helt vansinnigt komplext system för ÄtkomstrÀttigheter till mapparna i avdelningen. Inte ett alternativ. Det enda tidsmÀssigt acceptabla alternativet Àr att ÄterstÀlla systemets och diskens tillstÄnd med alla data och rÀttigheter.
à terigen googling, forum, KB-artiklar och Äterigen grÄter jag ut över att VMware ESXi inte har nÄgon mekanism för datarÀddning. Alla diskussionstrÄdar har tvÄ slut: antingen har nÄgon ÄterstÀllt med hjÀlp av det dyra DiskInternals VMFS Recovery, eller sÄ har nÄgon fÄtt hjÀlp av en specialist som aktivt marknadsför sina tjÀnster. vmfs-tools och dd. Alternativet att köpa en licens för DiskInternals VMFS Recovery för 700 USD Àr inte aktuellt. Att tillÄta en utomstÄende person frÄn "potentiell fiendens territorium" att fÄ tillgÄng till företagsdata Àr heller inte ett alternativ. Men det blev ocksÄ klart att UFS Explorer kan lÀsa VMFS-partitioner.
DiskInternals VMFS Recovery
Den trial-versionen laddades ner och installerades. Programmet upptÀckte framgÄngsrikt den tomma VMFS-partitionen:
I lÀget Undelete (Fast Scan) hittade ocksÄ den förlorade Datastore med mappar virtuella maskiner med diskar inuti:
Förhandsgranskningen visade att filerna levde:
Monteringen av partitionen i systemet var framgÄngsrik, men av okÀnda skÀl fanns det exakt samma virtuella maskin i alla tre mappar. Naturligtvis, enligt lagarna om otur, inte den som behövdes.
Tre rader av skamDet misslyckade försöket att omoraliskt piratkopiera mjukvaran slutade i fiasko. Men UFS Explorer svartscheckades.
Jag har en starkt negativ instÀllning till mjukvarupiratkopiering. Jag uppmanar absolut inte till anvÀndning av metoder för att kringgÄ skydd mot olagligt bruk.
Jag befann mig i en katastrofal situation och var överhuvudtaget inte stolt över de ÄtgÀrder jag vidtog.
UFS Explorer
Diskskanningen visade att det fanns 7 noder. Antalet noder stÀmde "otroligt nog" överens med antalet *-flat.vmdk-filer upptÀckta av VMFS Recovery:
JÀmförelsen av filstorlekar och nodernas storlekar visade ocksÄ överensstÀmmelse ner till byte. Samtidigt ÄterstÀlldes namnen pÄ *-flat.vmdk-filerna och dÀrmed deras koppling till virtuella maskiner.
Generellt sett bestÄr vmdk-diskar i ESXi av tvÄ filer: en datafil (<namn pÄ maskin>-flat.vmdk) och en fil med den "fysiska" diskens indelning (<namn pÄ maskin>.vmdk). Om du laddar upp *-flat.vmdk-filen frÄn den lokala maskinen till Datastore, kommer ESXi inte att kÀnna igen den som en giltig diskfil. Det finns en artikel i VMware:s kunskapsdatabas om hur man manuellt skapar en diskbeskrivningsfil: , men jag behövde inte göra det, jag kopierade helt enkelt innehÄllet frÄn motsvarande filer frÄn förhandsgranskningsomrÄdet i DiskInternals VMFS Recovery:
Efter 4 timmars export av en 2,5TB nod frÄn UFS Explorer och 20 timmars uppladdning till Datastore kopplades de kraschade diskfilerna till en ny skapad virtuell maskin. Diskarna anslöts. Ingen datarförlust noterades.
KĂ€lla: habr.com
