Ansvarsfraskrivelse: Notatet har underholdende karakter. Den informative tæthed er lav. Den blev skrevet "til mig selv".
Lyrisk indledning
Vores organisations filskrald kører på en virtuel maskine VMware ESXi 6 under Windows Server 2016. Og det er ikke bare skrald. Det er en filudvekslingsserver mellem afdelingerne: her er der samarbejde, projekt dokumentation og mapper fra netværksscannere. Kort sagt, her foregår hele den produktive live.
Og nu er dette opbevaringssted for hele den produktive liv begyndt at hænge. Faktisk kunne gæsten stille hænge selv uden at påvirke de andre. Den kunne hænge efter sig og lamme hele værten og dermed alle de andre gæstemaskiner. Den kunne hænge selv og lamme vSphere-klienttjenesterne: det vil sige, de andre gæsters processer er i live, maskinerne fungerer og reagerer, men filskraldet reagerer ikke og vSphere-klienten kan ikke forbinde til værten. Kort sagt, der kunne ikke identificeres nogen systematisk årsag. Hængningerne kunne ske om dagen under lav belastning. De kunne ske om natten under nul belastning. De kunne ske om natten under differential backup og medium belastning. De kunne ske i weekenden under fuld backup og høj belastning. Og der blev observeret en klar forværring af situationen. Først skete det en gang om året, så hver sjette måned. Mod slutningen af mit tålamod – to gange om ugen.
Jeg lagde skylden på RAM. Men jeg kunne ikke stoppe skraldet, selv i weekenden, og køre Memtest. Vi ventede på majferierne. I majferierne kørte jeg Memtest og... der blev ikke fundet fejl.
Jeg blev overrasket og besluttede at tage på ferie. Mens jeg var på ferie, var der ikke én eneste hængning i skraldet. Men da jeg mandag kom tilbage på arbejde – hængte skraldet. Det klarede den fulde backup og lige efter færdiggørelsen hængte det. Denne varme velkomst fra ferien fik mig til at beslutte at flytte diske fra gæstemaskinen til en anden vært.
Og selvom det er velkendt, at man ikke skal gøre noget alvorligt den første dag efter ferien, selvom jeg hele turen til arbejde forsøgte at indstille mig på ikke at arbejde, gjorde min forargelse over endnu en hængning, at jeg glemte både indstillingen og løfterne...
De fysiske diske blev flyttet til en anden vært. Hot-plug forbindelsen blev etableret. I opbevaringsindstillingerne under fanen Drives diskene vises. I fanen Datastores findes der ikke noget lager på disse diske. Opdater — viser sig ikke. Og selvfølgelig er den første reaktion — Tilføj lager. Guiden tilføjelse fortæller, hvad den understøtter. Selvfølgelig understøtter den også VMFS. Det tvivlede jeg ikke på. Et hurtigt kig på guiden ved hvert trin: Næste, Næste, Næste, Udfør. Blikket fangede ikke engang det lille gule cirkel med udråbstegn i bunden af vinduet på et af trinene i guiden.
Efter guiden dukkede det friske Datastore op i listen... og sammen med det også Datastores fra de andre fysiske diske.
Jeg går videre til navigationen af det nytilføjede Datastore, og det er... tomt. Selvfølgelig blev jeg igen overvældet. Klokken er 8 om morgenen, de første 15 minutter på arbejde efter ferien, jeg har ikke engang omrørt sukkeret i kaffen endnu. Og så sker der dette. Den første tanke var — ikke den rigtige disk fra den "oprindelige" vært jeg trak. Tjekkede om det ønskede Datastore var til stede på den "oprindelige" vært: nej, det var ikke til stede. Den anden tanke var: "f***!". Jeg er ikke sikker, men det føles som om den tredje, fjerde og mindst femte tanke var næsten den samme.
For at afklare tvivlene installerer jeg hurtigt en ny ESXi som test, tager en vild disk og læser mens jeg går igennem trinene i guiden. Ja. Ved tilføjelsen af Datastore gennem guiden mister man alle data på disken uden mulighed for at annullere operationen og gendanne data. Senere læste jeg på et forum en vurdering af dette designs guiden: shitsome crap. Og jeg var helt enig.
Fra den sjette — begyndte tankerne at flyde i mere konstruktiv retning. Okay. Initialiseringen tager kun få sekunder selv for en 3Tb-disk. Det er høj-niveau formatering. Så dataene er stadig der. Lad os se efter en formateringsgenoprettelse, og voila.
Jeg booter maskinen fra boot-image Strelec... Og finder ud af, at gendannelsesprogrammerne for partitioner kender alt undtagen VMFS. De kender for eksempel Synology partitionering, men ikke VMFS.
Gennemgangen af programmerne er ikke opmuntrende: i bedste fald finder GetDataBack og R.Saver NTFS-partitioner med en aktiv katalogstruktur og aktive filnavne. Men det tilfredsstiller mig ikke. Jeg har brug for to vmdk-filer: en med systemdisken og en med affaldsfildisken.
Og her indser jeg, at jeg tilsyneladende nu skal installere Windows og genskabe fra en filbackup. Samtidig husker jeg, at jeg havde en DFS-rod dér. Og der var også et fuldstændig vildt system af adgangsrettigheder til mapperne i afdelingerne. Det er ikke en mulighed. Den eneste tidsacceptabel løsning er at genskabe systemets tilstand og disken med data og alle rettigheder.
Igen googling, fora, KB’er og igen klager: VMware ESXi tilbyder ikke en mekanisme til datagendannelse. Alle diskussionstråde har to udfald: nogen har genskabt ved hjælp af det dyre DiskInternals VMFS Recovery, eller nogen fik hjælp fra en specialist, der aktivt promoverer sine tjenester. vmfs-tools og dd. Muligheden for at købe en licens til DiskInternals VMFS Recovery til $700 – det er ikke en mulighed. At lade en person fra 'potentiale modstander' adgang til virksomhedens data – det er heller ikke en mulighed. Til gengæld blev det givet videre, at VMFS-partitioner også kan læses af UFS Explorer.
DiskInternals VMFS Recovery
Den trial-version blev downloadet og installeret. Programmet så med succes den tomme VMFS-partition:
I tilstand Undelete (Fast Scan) fandt også det slide Datastore med mapper virtual machines med diske indeni:
Forhåndsvisningen viste, at filerne var intakte:
Monteringen af partitionen i systemet var vellykket, men af en eller anden uforklarlig grund var der den samme virtuelle maskine i alle tre mapper. Selvfølgelig, som skæbnen ville have det – ikke den, der var nødvendig.
Tre linjer skamDet forsøgte hadefulde forsøg på at piratkopiere softwaren endte i fiasko. Men UFS Explorer blev piratkopieret.
Jeg er meget imod softwaretyveri. Jeg opfordrer på ingen måde til brugen af midler til at omgå beskyttelse mod ikke-licenseret brug.
Jeg befandt mig i en katastrofal situation og var bestemt ikke stolt af de tiltag, jeg havde taget.
UFS Explorer
Diskscanningen viste tilstedeværelsen af 7 noder. Antallet af noder stemte 'forbløffende' overens med antallet af *-flat.vmdk filer, der blev opdaget af VMFS Recovery:
Sammenligningen af filstørrelser og størrelsen på noderne viste også overensstemmelse ned til byte. Samtidig blev navnene på *-flat.vmdk filer også genskabt, og derved deres tilhørsforhold til de virtuelle maskiner.
Generelt set består vmdk-diskene i forhold til ESXi af to filer: en fil med data (-flat.vmdk) og en fil med "fysisk" diskopdeling (.vmdk). Hvis du uploader *-flat.vmdk-filen fra den lokale maskine til Datastore, vil ESXi ikke genkende det som en gyldig diskfil. I VMware's vidensbase findes der en artikel om, hvordan du manuelt opretter en diskdescriptorfil: , men jeg behøvede ikke at gøre dette, jeg kopierede blot indholdet fra de tilsvarende filer fra forhåndsvisningsområdet af filen i DiskInternals VMFS Recovery:
Efter 4 timers udtrækning af 2,5TB noden fra UFS Explorer og 20 timers upload til hypervisorens Datastore blev de beskadigede diskfiler tilsluttet en nyoprettet virtuel maskine. Diskene blev genkendt. Der blev ikke registreret datatab.
Kilde: habr.com
