Ansvarsfraskrivelse: Notatet er til underholdningsformål. Den spesifikke tettheten av nyttig informasjon i den er lav. Det ble skrevet "for meg selv".
Lyrisk introduksjon
Fildumpen i organisasjonen vår kjører på en VMware ESXi 6 virtuell maskin som kjører Windows Server 2016. Og dette er ikke bare en søppelplass. Dette er en filutvekslingsserver mellom strukturelle divisjoner: det er samarbeid, prosjektdokumentasjon og mapper fra nettverksskannere. Generelt er alt produksjonsliv her.
Og denne beholderen av alt produksjonsliv begynte å henge. Dessuten kunne gjesten stille henge seg selv uten å påvirke de andre. Han kunne ta ned hele verten og følgelig alle de andre gjestemaskinene. Jeg kunne henge meg selv og henge vSphere-klienttjenestene: det vil si at prosessene til de andre gjestene er i live, maskinene fungerer som de skal og reagerer, men det er ingen filvasker og vSphere-klienten klamrer seg ikke til verten. Generelt kunne ikke noe system identifiseres. Frys kan forekomme i løpet av dagen ved lav belastning. De kunne gjøre det om natten uten belastning. Kan om natten under differensiell backup og gjennomsnittlig belastning. Kunne i helgene under full backup og høy belastning. Og det var en klar forringelse av situasjonen. Først var det en gang i året, deretter en gang i halvåret. På slutten av min tålmodighet - to ganger i uken.
Jeg hadde et minneproblem. Men de lot meg ikke stoppe søppelhaugen selv i helgene og kjøre Memtest. Vi ventet på maiferien. I løpet av maiferien kjørte jeg Memtest og... ingen feil ble funnet.
Jeg ble overrasket og bestemte meg for å reise på ferie. Mens jeg var på ferie, var det ikke en eneste hangup på søppelplassen. Og da jeg gikk tilbake på jobb den første dagen på mandag, var det en søppelhaug. Jeg tålte en full backup og hang rett etter at den var fullført. En slik varm velkomst fra ferie presset meg til beslutningen om å fysisk dra diskene med gjestemaskinen til en annen vert.
Og selv om det lenge har vært kjent at du ikke kan gjøre noe seriøst den første dagen etter en ferie, selv om jeg forberedte meg på ikke å jobbe hele veien til jobb, slo min indignasjon over enda en fryser både humøret og løfter ut av hodet mitt...
Fysiske disker har blitt flyttet til en annen vert. Varm tilkobling. I lagringsinnstillingene på fanen Stasjoner disker vises. På fanen Datalagre Det er ingen lagringsplass på disse diskene. Forfriske - vises ikke. Vel, selvfølgelig, den første impulsen - Legg til lagring. Legg til veiviseren forklarer hva den støtter. Den støtter selvfølgelig også VMFS. Jeg tvilte ikke på det. En rask titt på veiviserens meldinger ved hvert trinn: Neste, Neste, Neste, Fullfør. Øyet var ikke engang i nærheten av å fange den lille gule sirkelen med et utropstegn nederst i vinduet til en av mesterens trinn.
På slutten av veiviseren dukket det ferske datalageret opp i listen... og sammen med det datalagrene fra de gjenværende fysiske diskene.
Jeg går videre til å navigere gjennom den nylig lagt til Datastore, og den er... tom. Selvfølgelig falt jeg tilbake i forundring. Klokken er 8, de første 15 minuttene på jobb etter ferie, jeg har ikke engang rørt sukkeret i kaffen enda. Og her er det. Den første tanken var at jeg trakk feil disk fra den "native" verten. Jeg så for å se om den nødvendige Datastore var til stede i den "native" verten: nei, den var ikke til stede. Den andre tanken var: "Fan!" Jeg er ikke sikker, men det ser ut til at den tredje, fjerde og minst femte tanken var den samme.
For å fjerne tvil installerte jeg raskt en ny ESXi for testing, tok den venstre disken og gikk gjennom trinnene til veiviseren, allerede når jeg leste den. Ja. Når du legger til et datalager ved hjelp av veiviseren, går alle data på disken tapt uten muligheten til å rulle tilbake operasjonen og gjenopprette dataene. Senere leste jeg på et av forumene en vurdering av dette designet av en mester: shitsome crap. Og jeg var virkelig enig.
Fra og med den sjette strømmet tankene i en mer konstruktiv retning. OK. Initialisering tar noen sekunder selv for en 3Tb-disk. Så dette er formatering på høyt nivå. Dette betyr at partisjonstabellen ganske enkelt ble skrevet om. Så dataene er der fortsatt. Så, nå skal vi se etter noe uformat og voila.
Jeg starter maskinen fra Strelec-oppstartsbildet... Og jeg finner ut at partisjonsgjenopprettingsprogrammer vet alt bortsett fra VMFS. For eksempel kjenner de partisjonsoppsettet til Synology, men ikke VMFS.
Å søke gjennom programmer er ikke betryggende: i beste fall finner GetDataBack og R.Saver NTFS-partisjoner med en levende katalogstruktur og levende filnavn. Men dette passer ikke meg. Jeg trenger to vmdk-filer: med systemdisken og søppelfildisken.
Og så forstår jeg at det ser ut som jeg nå skal installere Windows og rulle ut fra en filsikkerhetskopi. Og samtidig husker jeg at jeg hadde en DFS-rot der. Og også et system med tilgangsrettigheter til avdelingsmapper som er helt vilt i omfang og forgreninger. Ikke et alternativ. Det eneste tidsakseptable alternativet er å gjenopprette tilstanden til systemet og disken med data og alle rettigheter.
Igjen Google, forum, KB'shki og igjen Yaroslavnas gråt: VMware ESXi gir ikke en datagjenopprettingsmekanisme. Alle diskusjonstråder har to avslutninger: noen ble gjenopprettet ved å bruke den dyre DiskInternals VMFS Recovery, eller noen ble hjulpet av en programvarespesialist som aktivt promoterte tjenestene hans vmfs-verktøy и dd. Alternativet for å kjøpe en DiskInternals VMFS Recovery-lisens for $700 er ikke et alternativ. Å la en utenforstående fra «en potensiell fiendes territorium» få tilgang til bedriftsdata er heller ikke et alternativ. Men det ble googlet at VMFS-partisjoner også kan leses av UFS Explorer.
DiskInternals VMFS-gjenoppretting
Prøveversjonen ble lastet ned og installert. Programmet så den tomme VMFS-partisjonen:
I modus Angre sletting (rask skanning) Jeg fant også et lurvete datalager med mapper med virtuelle maskiner med disker inni:
Forhåndsvisningen viste at filene er i live:
Montering av partisjonen i systemet var vellykket, men av en eller annen ukjent grunn inneholdt alle tre mappene den samme virtuelle maskinen. I følge loven er selvfølgelig ikke ondskap det som kreves.
Tre linjer med skamForsøket på å skamløst låse programvaren endte i feil. Men UFS Explorer låste seg.
Jeg har en ekstremt negativ holdning til programvaretyveri. Jeg oppfordrer på ingen måte til bruk av midler for å omgå beskyttelse mot ulisensiert bruk.
Jeg var i en katastrofal situasjon og var slett ikke stolt over tiltakene jeg hadde tatt i bruk.
UFS Explorer
En diskskanning viste tilstedeværelsen av 7 noder. Antall noder falt "overraskende" sammen med antallet *-flat.vmdk-filer som ble oppdaget av VMFS Recovery:
En sammenligning av filstørrelser og nodestørrelser viste også samsvar ned til byte. Samtidig ble navnene på *-flat.vmdk-filer og følgelig deres tilhørighet til virtuelle maskiner gjenopprettet.
Generelt sett består vmdk-disker fra ESXi-synspunkt av to filer: en datafil (<maskinnavn>-flat.vmdk) og en "fysisk" diskoppsettfil (<maskinnavn>.vmdk). Hvis du laster opp en *-flat.vmdk-fil til Datastore fra en lokal maskin, vil ikke ESXi gjenkjenne den som en gyldig diskfil. VMware Knowledge Base har en artikkel om hvordan du manuelt oppretter en diskbeskrivelsesfil: , men jeg trengte ikke å gjøre dette, jeg kopierte ganske enkelt innholdet i de tilsvarende filene fra forhåndsvisningsområdet for filinnhold i DiskInternals VMFS Recovery:
Etter 4 timers lossing av en 2,5 TB node fra UFS Explorer og 20 timers lasting inn i hypervisorens Datastore, ble de krasjete diskfilene koblet til den nyopprettede virtuelle maskinen. Diskene tok seg opp. Det ble ikke observert tap av data.
Kilde: www.habr.com