Disclaimer: Sedlen er til underholdningsformål. Den specifikke tæthed af nyttig information i den er lav. Det var skrevet "til mig selv".
Lyrisk introduktion
Fildumpet i vores organisation kører på en VMware ESXi 6 virtuel maskine, der kører Windows Server 2016. Og dette er ikke kun et skrald. Dette er en filudvekslingsserver mellem strukturelle divisioner: Der er samarbejde, projektdokumentation og mapper fra netværksscannere. Generelt er hele produktionslivet her.
Og denne beholder af alt produktionsliv begyndte at hænge. Desuden kunne gæsten stille og roligt hænge sig uden at påvirke de andre. Han kunne tage hele værten ned og dermed alle de andre gæstemaskiner. Jeg kunne hænge mig selv og hænge vSphere-klienttjenesterne: det vil sige, de andre gæsters processer er i live, maskinerne fungerer korrekt og reagerer, men der er ingen filvasker, og vSphere-klienten klamrer sig ikke til værten. Generelt kunne intet system identificeres. Frost kan forekomme i løbet af dagen under en lav belastning. De kunne gøre det om natten uden belastning. Kunne om natten under differentiel backup og gennemsnitlig belastning. Kunne i weekenden under fuld backup og høj belastning. Og der var en klar forringelse af situationen. Først var det en gang om året, derefter en gang hvert halve år. På slutningen af min tålmodighed - to gange om ugen.
Jeg havde et hukommelsesproblem. Men de lod mig ikke stoppe skraldebunken selv i weekenden og køre Memtest. Vi ventede på majferien. I løbet af majferien 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 et eneste læg på affaldspladsen. Og da jeg gik tilbage på arbejde den første dag i mandags, var der en skraldebunke. Jeg udholdt en fuld backup og hængte lige efter den var færdig. Sådan en varm velkomst fra ferie skubbede mig til beslutningen om fysisk at trække diskene med gæstemaskinen til en anden vært.
Og selvom det længe har været kendt, at man ikke kan gøre noget seriøst den første dag efter en ferie, selvom jeg forberedte mig på ikke at arbejde hele vejen til arbejde, så slog min indignation over endnu en frysning både mit humør og mit humør. løfter ud af mit hoved...
Fysiske diske er blevet flyttet til en anden vært. Varm forbindelse. I lagerindstillingerne på fanen Drev og diske vises. På fanen Databutikker Der er ingen lagerplads på disse diske. Opfrisk - vises ikke. Nå, selvfølgelig, den første impuls - Tilføj Opbevaring. Tilføj guiden forklarer, hvad den understøtter. Det understøtter selvfølgelig også VMFS. Jeg tvivlede ikke på det. Et hurtigt kig på guidens beskeder ved hvert trin: Næste, Næste, Næste, Udfør. Øjet var ikke engang tæt på at fange den lille gule cirkel med et udråbstegn i bunden af vinduet på et af mesterens trin.
I slutningen af guiden dukkede det nye datalager op på listen... og sammen med det datalagrene fra de resterende fysiske diske.
Jeg går videre til at navigere gennem den nyligt tilføjede Datastore, og den er... tom. Selvfølgelig faldt jeg tilbage i forbløffelse. Klokken er 8, de første 15 minutter på arbejde efter ferien, jeg har ikke engang rørt sukkeret i min kaffe endnu. Og her er det. Den første tanke var, at jeg trak den forkerte disk fra den "native" vært. Jeg så for at se, om den nødvendige Datastore var til stede i den "native" vært: nej, den var ikke til stede. Den anden tanke var: "fuck!" Jeg er ikke sikker, men det forekommer mig, at den tredje, fjerde og mindst femte tanke var den samme.
For at fjerne tvivl installerede jeg hurtigt en ny ESXi til test, tog den venstre disk og, da jeg allerede læste den, gik jeg gennem guidens trin. Ja. Når du tilføjer et datalager ved hjælp af guiden, går alle data på disken tabt uden mulighed for at rulle handlingen tilbage og gendanne dataene. Senere læste jeg på et af foraene en vurdering af dette design af en mester: lort. Og jeg var virkelig enig.
Fra den sjette strømmede tankerne i en mere konstruktiv retning. OKAY. Initialisering tager et spørgsmål om sekunder, selv for en 3Tb disk. Så dette er formatering på højt niveau. Det betyder, at partitionstabellen simpelthen blev omskrevet. Så dataene er der stadig. Så nu leder vi efter noget uformat og voila.
Jeg starter maskinen fra Strelec-startbilledet... Og jeg finder ud af, at partitionsgendannelsesprogrammer ved alt undtagen VMFS. For eksempel kender de partitionslayoutet for Synology, men ikke VMFS.
At søge gennem programmer er ikke betryggende: i bedste fald finder GetDataBack og R.Saver NTFS-partitioner med en levende mappestruktur og levende filnavne. Men det her passer mig ikke. Jeg har brug for to vmdk-filer: med systemdisken og trash-fildisken.
Og så forstår jeg, at det ser ud til, at jeg nu vil installere Windows og rulle ud fra en fil backup. Og samtidig husker jeg, at jeg havde en DFS-rod der. Og også et system med adgangsrettigheder til afdelingsmapper, der er helt vildt i omfang og forgreninger. Ikke en mulighed. Den eneste tidsacceptable mulighed er at gendanne systemets og diskens tilstand med data og alle rettigheder.
Igen Google, fora, KB'shki og igen Yaroslavnas gråd: VMware ESXi giver ikke en datagendannelsesmekanisme. Alle diskussionstråde har to slutninger: nogen blev gendannet ved hjælp af den dyre DiskInternals VMFS Recovery, eller nogen blev hjulpet af en softwarespecialist, der aktivt promoverede hans tjenester vmfs-værktøjer и dd. Muligheden for at købe en DiskInternals VMFS Recovery-licens for $700 er ikke en mulighed. At give en outsider fra "en potentiel fjendes territorium" adgang til virksomhedsdata er heller ikke en mulighed. Men det blev googlet, at VMFS-partitioner også kan læses af UFS Explorer.
DiskInternals VMFS-gendannelse
Prøveversionen blev downloadet og installeret. Programmet så med succes den tomme VMFS-partition:
tilstanden Fortryd sletning (hurtig scanning) Jeg fandt også en lurvet Datastore med mapper med virtuelle maskiner med diske indeni:
Forhåndsvisningen viste, at filerne er i live:
Montering af partitionen i systemet lykkedes, men af en eller anden ukendt årsag indeholdt alle tre mapper den samme virtuelle maskine. Ifølge loven er ondskab naturligvis ikke det, der kræves.
Tre streger af skamForsøget på skamløst at låse softwaren endte i fiasko. Men UFS Explorer låste op.
Jeg har en ekstrem negativ holdning til softwaretyveri. Jeg opfordrer på ingen måde til brug af midler til at omgå beskyttelse mod ulicenseret brug.
Jeg var i en katastrofal situation og var slet ikke stolt af de foranstaltninger, jeg havde grebet til.
UFS Explorer
En diskscanning viste tilstedeværelsen af 7 noder. Antallet af noder faldt "overraskende" sammen med antallet af *-flat.vmdk filer, der blev registreret af VMFS Recovery:
En sammenligning af filstørrelser og nodestørrelser viste også et match ned til byten. Samtidig blev navnene på *-flat.vmdk-filer og dermed deres tilhørsforhold til virtuelle maskiner gendannet.
Generelt består vmdk-diske fra ESXi-synspunktet af to filer: en datafil (<maskinnavn>-flat.vmdk) og en "fysisk" disklayoutfil (<maskinnavn>.vmdk). Hvis du uploader en *-flat.vmdk fil til Datastore fra en lokal maskine, vil ESXi ikke genkende den som en gyldig diskfil. VMware Knowledge Base har en artikel om, hvordan man manuelt opretter en diskbeskrivelsesfil: , men jeg behøvede ikke at gøre dette, jeg kopierede simpelthen indholdet af de tilsvarende filer fra forhåndsvisningsområdet for filindhold i DiskInternals VMFS Recovery:
Efter 4 timers aflæsning af en 2,5 TB node fra UFS Explorer og 20 timers indlæsning i hypervisorens Datastore, blev de nedbrudte diskfiler forbundet med den nyoprettede virtuelle maskine. Diskene blev samlet op. Der blev ikke observeret noget datatab.
Kilde: www.habr.com