Vrywaring: Die nota is vir vermaaklikheidsdoeleindes. Die spesifieke digtheid van nuttige inligting daarin is laag. Dit is geskryf "vir myself."
Liriese inleiding
Die lêerstorting in ons organisasie loop op 'n VMware ESXi 6 virtuele masjien met Windows Server 2016. En dit is nie net 'n vullishoop nie. Dit is 'n lêeruitruilbediener tussen strukturele afdelings: daar is samewerking, projekdokumentasie en vouers van netwerkskandeerders. Oor die algemeen is alle produksielewe hier.
En hierdie houer van alle produksielewe het begin hang. Boonop kon die gas homself rustig ophang sonder om die ander te beïnvloed. Hy kon die hele gasheer en dienooreenkomstig al die ander gasmasjiene afneem. Ek kon myself ophang en die vSphere-kliëntdienste ophang: dit wil sê, die prosesse van die ander gaste is lewendig, die masjiene werk behoorlik en reageer, maar daar is geen lêerwasser nie en die vSphere Client klou nie aan die gasheer nie. Oor die algemeen kon geen stelsel geïdentifiseer word nie. Vries kan gedurende die dag voorkom tydens 'n lae vrag. Hulle kon dit in die nag doen tydens geen vrag nie. Kan snags tydens differensiële rugsteun en gemiddelde las. Kan oor naweke tydens volle rugsteun en hoë vrag. En daar was 'n duidelike agteruitgang van die situasie. Eers was dit een keer per jaar, toe een keer elke ses maande. Aan die einde van my geduld – twee keer per week.
Ek het 'n geheueprobleem gehad. Maar hulle het nie toegelaat dat ek selfs oor naweke die rommelhoop stop en Memtest bestuur nie. Ons het gewag vir die Mei-vakansie. Gedurende die Mei-vakansie het ek Memtest gehardloop en... geen foute is gevind nie.
Ek was verstom en het besluit om met vakansie te gaan. Terwyl ek met vakansie was, was daar nie 'n enkele hangup by die vullishoop nie. En toe ek Maandag vir die eerste dag teruggaan werk toe, was daar 'n rommelhoop. Ek het 'n volledige rugsteun verduur en gehang net nadat dit voltooi is. So 'n hartlike ontvangs van vakansie het my gedryf tot die besluit om die skywe met die gasmasjien fisies na 'n ander gasheer te sleep.
En alhoewel dit lankal bekend is dat jy niks ernstigs kan doen op die eerste dag na 'n vakansie nie, alhoewel ek myself voorberei het om nie al die pad werk toe te werk nie, het my verontwaardiging oor nog 'n vriespunt beide my bui en my geloftes uit my kop uit...
Fisiese skywe is na 'n ander gasheer geskuif. Warm verbinding. In die berging instellings op die blad Drives skywe verskyn. Op die blad Datawinkels Daar is geen berging op hierdie skywe nie. Verfris - verskyn nie. Wel, natuurlik, die eerste impuls - Voeg berging by. Die Add Wizard verduidelik wat dit ondersteun. Dit ondersteun natuurlik ook VMFS. Ek het nie daaraan getwyfel nie. 'n Vinnige blik op die towenaar se boodskappe by elke stap: Volgende, Volgende, Volgende, Voltooi. Die oog het nie eers naby daaraan gekom om die klein geel sirkel met 'n uitroepteken onder in die venster van een van die meester se trappe te vang nie.
Aan die einde van die towenaar het die vars Datastore in die lys verskyn ... en daarmee saam die Datastore van die oorblywende fisiese skywe.
Ek gaan voort om deur die nuut bygevoegde Datastore te navigeer, en dit is ... leeg. Natuurlik het ek weer in verbasing geval. Dit is 8:15, die eerste XNUMX minute by die werk na vakansie, ek het nog nie eers die suiker in my koffie geroer nie. En hier is dit. Die eerste gedagte was dat ek die verkeerde skyf van die "inheemse" gasheer getrek het. Ek het gekyk of die vereiste Datastore teenwoordig was in die "inheemse" gasheer: nee, dit was nie teenwoordig nie. Die tweede gedagte was: "fok!" Ek is nie seker nie, maar dit lyk vir my of die derde, vierde en ten minste vyfde gedagte dieselfde was.
Om twyfel uit die weg te ruim, het ek vinnig 'n vars ESXi geïnstalleer om te toets, die linkerskyf geneem en, al gelees, deur die stappe van die towenaar gestap. Ja. Wanneer jy 'n Datastore met behulp van die towenaar byvoeg, gaan alle data op die skyf verlore sonder die vermoë om die bewerking terug te draai en die data te herstel. Later het ek op een van die forums 'n beoordeling van hierdie ontwerp deur 'n meester gelees: shitsome crap. En ek het regtig saamgestem.
Vanaf die sesde het gedagtes in 'n meer konstruktiewe rigting gevloei. OK. Inisialisering neem 'n kwessie van sekondes, selfs vir 'n 3Tb-skyf. Dit is dus hoëvlakformatering. Dit beteken dat die partisietabel eenvoudig herskryf is. Die data is dus steeds daar. So, nou sal ons soek na 'n paar onformaat en voila.
Ek selflaai die masjien vanaf die Strelec selflaai beeld ... En ek vind uit dat partisie herstel programme alles weet behalwe VMFS. Hulle ken byvoorbeeld die partisie-uitleg van Synology, maar nie VMFS nie.
Om deur programme te soek is nie gerusstellend nie: op sy beste vind GetDataBack en R.Saver NTFS-partisies met 'n lewendige gidsstruktuur en lewendige lêername. Maar dit pas my nie. Ek benodig twee vmdk-lêers: met die stelselskyf en die asbliklêerskyf.
En dan verstaan ek dat dit lyk of ek nou Windows sal installeer en uitrol vanaf 'n lêerrugsteun. En terselfdertyd onthou ek dat ek 'n DFS-wortel daar gehad het. En ook 'n stelsel van toegangsregte tot afdelingsvouers wat absoluut wild is in omvang en gevolge. Nie 'n opsie nie. Die enigste tyd-aanvaarbare opsie is om die toestand van die stelsel en skyf met data en alle regte te herstel.
Weereens Google, forums, KB'shki en weer Yaroslavna se huil: VMware ESXi bied nie 'n dataherwinningsmeganisme nie. Alle besprekingsdrade het twee eindes: iemand is herwin met die duur DiskInternals VMFS Recovery, of iemand is gehelp deur 'n sagtewarespesialis wat sy dienste aktief bevorder vmfs-gereedskap и dd. Die opsie om 'n DiskInternals VMFS Recovery-lisensie vir $700 te koop, is nie 'n opsie nie. Om 'n buitestander van die "gebied van 'n potensiële vyand" toe te laat om toegang tot korporatiewe data te verkry, is ook nie 'n opsie nie. Maar daar is gegoogle dat VMFS partisies ook deur UFS Explorer gelees kan word.
DiskInternals VMFS-herstel
Die proefweergawe is afgelaai en geïnstalleer. Die program het die leë VMFS-partisie suksesvol gesien:
die modus Herstel uitvee (vinnige skandering) Ek het ook 'n skamele Datastore gevind met dopgehou van virtuele masjiene met skywe binne:
Die voorskou het getoon dat die lêers lewendig is:
Die installering van die partisie in die stelsel was suksesvol, maar om een of ander onbekende rede het al drie dopgehou dieselfde virtuele masjien bevat. Natuurlik, volgens die wet, is gemeenheid nie wat vereis word nie.
Drie lyne van skaamteDie poging om die sagteware skaamteloos te sluit, het op mislukking geëindig. Maar UFS Explorer het toegesluit.
Ek het 'n uiters negatiewe houding teenoor sagteware diefstal. Ek moedig op geen manier die gebruik van middele aan om beskerming teen ongelisensieerde gebruik te omseil nie.
Ek was in 'n rampspoedige situasie en was glad nie trots op die maatreëls waartoe ek my gewend het nie.
UV-verkenner
'n Skyfskandering het die teenwoordigheid van 7 nodusse getoon. Die aantal nodusse het “verbasend genoeg” saamgeval met die aantal *-flat.vmdk-lêers wat deur VMFS Recovery opgespoor is:
'n Vergelyking van lêergroottes en nodusgroottes het ook 'n passing tot by die greep getoon. Terselfdertyd is die name van *-flat.vmdk-lêers en dienooreenkomstig hul behoort aan virtuele masjiene herstel.
Oor die algemeen bestaan vmdk-skywe vanuit die ESXi-oogpunt uit twee lêers: 'n datalêer (<masjiennaam>-flat.vmdk) en 'n "fisiese" skyfuitleglêer (<masjiennaam>.vmdk). As jy 'n *-flat.vmdk lêer oplaai na die Datastore vanaf 'n plaaslike masjien, sal ESXi dit nie as 'n geldige skyflêer herken nie. Die VMware Knowledge Base het 'n artikel oor hoe om 'n skyfbeskrywinglêer met die hand te skep: , maar ek hoef dit nie te doen nie, ek het eenvoudig die inhoud van die ooreenstemmende lêers van die lêerinhoudvoorskouarea in DiskInternals VMFS Recovery gekopieer:
Na 4 uur se aflaai van 'n 2,5 TB-knooppunt vanaf UV Explorer en 20 uur se laai in die hypervisor se Datastore, is die vasgestorte skyflêers aan die nuutgeskepte virtuele masjien gekoppel. Die skywe het opgetel. Geen dataverlies is waargeneem nie.
Bron: will.com