Disclaimer: De notysje is foar ferdivedaasjedoelen. De spesifike tichtens fan nuttige ynformaasje dêryn is leech. It waard skreaun "foar mysels."
Lyryske ynlieding
De triem dump yn ús organisaasje rint op in VMware ESXi 6 firtuele masine mei Windows Server 2016. En dit is net allinnich in jiskefet. Dit is in triem útwikseling tsjinner tusken strukturele divyzjes: der is gearwurking, projekt dokumintaasje, en mappen fan netwurk scanners. Yn 't algemien is alle produksjelibben hjir.
En dizze kontener fan alle produksjelibben begon te hingjen. Boppedat koe de gast himsels rêstich ophingje sûnder de oaren te beynfloedzjen. Hy koe de hiele host delhelje en dus alle oare gastmasines. Ik koe hingje mysels en hingje de vSphere client tsjinsten: dat is, de prosessen fan de oare gasten binne yn libben, de masines wurkje goed en reagearje, mar der is gjin triem waskmasine en de vSphere Client net fêsthâlde oan de host. Yn 't algemien koe gjin systeem identifisearre wurde. Friezen kinne oerdeis foarkomme by in lege lading. Se koene it nachts by gjin lading dwaan. Koe nachts by differinsjaal backup en gemiddelde lading. Koe yn it wykein by folsleine backups en hege lading. En d'r wie in dúdlike degradaasje fan 'e situaasje. Earst wie it ien kear yn it jier, dan ien kear yn de seis moanne. Oan 'e ein fan myn geduld - twa kear yn'e wike.
Ik hie in ûnthâld probleem. Mar se lieten my net stopje de jiskefet heap sels yn it wykein en rinne Memtest. Wy wachtsje op de maaiefakânsje. Yn de maaiefakânsje ha ik Memtest rûn en... gjin flaters fûn.
Ik wie fernuvere en besleat om op fakânsje te gean. Wylst ik op fakânsje wie, wie der net ien ophongen op it jiskefet. En doe't ik moandei foar de earste dei wer oan it wurk gie, wie der in jiskefet. Ik fernearde in folsleine reservekopy en hong direkt neidat it wie klear. Sa'n waarm wolkom út fakânsje skood my ta it beslút om fysyk sleep de skiven mei de gast masine nei in oare host.
En hoewol't it al lang bekend is dat jo op 'e earste dei nei in fakânsje neat serieus dwaan kinne, hoewol ik my tariede om net hielendal nei it wurk te wurkjen, sloech myn argewaasje by noch in oare frieze sawol myn stimming as myn geloften út myn holle ...
Fysike skiven binne ferpleatst nei in oare host. Hot ferbining. Yn de opslach ynstellings op de ljepper Driven skiven ferskine. Op de ljepper Datastores D'r is gjin opslach op dizze skiven. refresh - net ferskine. No, fansels, de earste ympuls - Add Storage. De Add Wizard ferklearret wat it stipet. Fansels stipet it ek VMFS. Ik twifele der net oan. In rappe blik op de berjochten fan 'e wizard by elke stap: Folgjende, Folgjende, Folgjende, Finish. It each kaam net iens ticht by it fangen fan de lytse giele sirkel mei in útropteken ûnderoan it rút fan ien fan de master syn stappen.
Oan 'e ein fan' e wizard ferskynde de frisse Datastore yn 'e list ... en tegearre mei it de Datastores fan 'e oerbleaune fysike skiven.
Ik gean nei it navigearjen troch de nij tafoege Datastore, en it is ... leech. Fansels rekke ik wer yn fernuvering. It is 8 oere, de earste 15 minuten op it wurk nei de fakânsje, ik haw noch net iens de sûker yn myn kofje roer. En hjir is it. De earste gedachte wie dat ik luts de ferkearde skiif út de "native" host. Ik seach om te sjen oft de fereaske Datastore oanwêzich wie yn 'e "native" host: nee, it wie net oanwêzich. De twadde gedachte wie: "fuck!" Ik bin der net wis fan, mar it liket my ta dat de tredde, fjirde en op syn minst fyfde gedachte itselde wie.
Om dispel twifels, Ik ynstallearre fluch in frisse ESXi foar testen, naam de linker skiif en, al lêzen it, rûn troch de stappen fan de wizard. Ja. As jo in Datastore tafoegje mei de wizard, binne alle gegevens op 'e skiif ferlern sûnder de mooglikheid om de operaasje werom te rôljen en de gegevens te herstellen. Letter lês ik op ien fan 'e foarums in beoardieling fan dit ûntwerp troch in master: shitsome crap. En ik wie it echt iens.
Begjinnend fan de sechsde, tinzen streamden yn in mear konstruktive rjochting. OK. Inisjalisaasje nimt in kwestje fan sekonden sels foar in 3Tb skiif. Dat dit is opmaak op hege nivo. Dit betsjut dat de partition tabel gewoan oerskreaun waard. Dus de gegevens binne der noch. Dat, no sille wy sykje nei wat unformat en voila.
Ik boot de masine út de Strelec boot ôfbylding ... En ik fyn út dat partition recovery programma witte alles útsein VMFS. Bygelyks, se kenne de partition yndieling fan Synology, mar net VMFS.
Sykje troch programma's is net gerêststellend: op syn bêst fine GetDataBack en R.Saver NTFS-partysjes mei in live mapstruktuer en live bestânsnammen. Mar dit past my net. Ik haw twa vmdk-bestannen nedich: mei de systeemskiif en de jiskefetbestânskiif.
En dan begryp ik dat it liket dat ik no Windows sil ynstallearje en útrolje fan in bestânreservekopy. En tagelyk wit ik dat ik dêr in DFS-root hie. En ek in systeem fan tagongsrjochten foar ôfdielingsmappen dat absolút wyld is yn omfang en fertakkingen. Gjin opsje. De ienige tiid-akseptabele opsje is om de steat fan it systeem en skiif te herstellen mei gegevens en alle rjochten.
Wer Google, foarums, KB'shki en wer Yaroslavna's skriemen: VMware ESXi jout gjin gegevensherstelmeganisme. Alle diskusje-threads hawwe twa eintsjes: immen waard weromfûn mei de djoere DiskInternals VMFS Recovery, of immen waard holpen troch in softwarespesjalist dy't syn tsjinsten aktyf befoardere vmfs-ark и dd. De opsje fan it keapjen fan in DiskInternals VMFS Recovery-lisinsje foar $ 700 is gjin opsje. It tastean fan in bûtensteander út it "gebiet fan in potinsjele fijân" tagong ta bedriuwsgegevens is ek gjin opsje. Mar it waard googled dat VMFS-partysjes ek lêze kinne troch UFS Explorer.
DiskInternals VMFS Recovery
De proefferzje waard ynladen en ynstalleare. It programma seach mei súkses de lege VMFS-partysje:
Yn 'e modus Undelete (Fast Scan) Ik fûn ek in shabby Datastore mei mappen fan firtuele masines mei skiven yn:
It foarbyld liet sjen dat de bestannen libje:
It montearjen fan de partysje yn it systeem wie suksesfol, mar om ien of oare ûnbekende reden befette alle trije mappen deselde firtuele masine. Fansels, neffens de wet, is gemienens net wat nedich is.
Trije rigels fan skamteIt besykjen om de software skamteleas te beskoatteljen einige yn mislearring. Mar UFS Explorer opsletten.
Ik haw in ekstreem negative hâlding foar softwarestellerij. Op gjin inkelde manier moedigje ik it gebrûk fan middels oan om beskerming tsjin net lisinsearre gebrûk te omgean.
Ik siet yn in katastrophale sitewaasje en wie hielendal net grutsk op de maatregels dy't ik tanommen hie.
UFS Explorer
In skiif scan liet de oanwêzigens fan 7 knopen sjen. It oantal knooppunten foel "ferrassend" oerien mei it oantal *-flat.vmdk-bestannen ûntdutsen troch VMFS Recovery:
In ferliking fan triemgrutte en knooppuntgrutte liet ek in oerienkomst sjen nei de byte. Tagelyk waarden de nammen fan *-flat.vmdk-bestannen en, sadwaande, har hearren ta firtuele masines werombrocht.
Yn it algemien, vmdk skiven út de ESXi eachpunt bestiet út twa triemmen: in gegevens triem (< masine namme> -flat.vmdk) en in "fysike" skiif layout triem (< masine namme> .vmdk). As jo oplade in * -flat.vmdk triem oan de Datastore fan in lokale masine, sil ESXi net werkenne it as in jildich skiif triem. De VMware Knowledge Base hat in artikel oer hoe't jo in skiifbeskriuwingsbestân mei de hân meitsje kinne: , mar ik hoegde dit net te dwaan, ik haw gewoan de ynhâld fan 'e oerienkommende bestannen kopieare fan it foarbyldgebiet fan bestânynhâld yn DiskInternals VMFS Recovery:
Nei 4 oeren fan it lossen fan in 2,5 TB-knooppunt fan UFS Explorer en 20 oeren fan laden yn 'e Hypervisor's Datastore, waarden de ferûngelokke skiifbestannen ferbûn mei de nij oanmakke firtuele masine. De skiven pakten op. Gjin gegevensferlies waard waarnommen.
Boarne: www.habr.com