Dėmesio: Pastaba skirta pramogai. Savitas naudingos informacijos tankis jame mažas. Buvo parašyta „dėl savęs“.
Lyrinė įžanga
Failų sąvartynas mūsų organizacijoje veikia VMware ESXi 6 virtualioje mašinoje, kurioje veikia Windows Server 2016. Ir tai ne tik šiukšlynas. Tai failų mainų serveris tarp struktūrinių padalinių: yra bendradarbiavimas, projektinė dokumentacija ir aplankai iš tinklo skaitytuvų. Apskritai čia yra visas gamybos laikas.
Ir šis viso gamybos gyvavimo konteineris pradėjo kabėti. Be to, svečias galėjo ramiai pasikabinti, nepakenkdamas kitiems. Jis galėjo nuimti visą šeimininką ir atitinkamai visas kitas svečių mašinas. Galėčiau pasikabinti ir pakabinti vSphere kliento paslaugas: tai yra, kitų svečių procesai gyvi, mašinos veikia tinkamai ir reaguoja, bet nėra failų ploviklio ir vSphere Client neprisikabina prie pagrindinio kompiuterio. Apskritai nebuvo galima nustatyti jokios sistemos. Mažos apkrovos metu dienos metu gali užšalti. Jie galėjo tai padaryti naktį, be apkrovos. Galimas naktį diferencialo atsarginės kopijos ir vidutinės apkrovos metu. Galima savaitgaliais, kai daromos visos atsarginės kopijos ir didelė apkrova. Ir buvo akivaizdus padėties pablogėjimas. Iš pradžių tai buvo kartą per metus, vėliau kartą per šešis mėnesius. Mano kantrybės pabaigoje – du kartus per savaitę.
Turėjau atminties problemų. Bet jie neleido man sustabdyti šiukšlių krūvos net savaitgaliais ir paleisti „Memtest“. Laukėme gegužės švenčių. Per gegužės šventes paleidau Memtestą ir... jokių klaidų nerasta.
Nustebau ir nusprendžiau eiti atostogų. Kol atostogavau, šiukšlyne nebuvo nei vieno pakabinimo. O kai pirmadienį grįžau į darbą pirmą dieną, buvo šiukšlių krūva. Ištvėriau visą atsarginę kopiją ir pakabinau iškart po to, kai ji buvo baigta. Toks šiltas sutikimas iš atostogų paskatino mane apsispręsti fiziškai nutempti diskus su svečių mašina į kitą šeimininką.
Ir nors jau seniai žinoma, kad pirmą dieną po atostogų nieko rimto daryti negalima, nors ruošiausi nedirbti iki pat darbo, pasipiktinimas dėl eilinio sustingimo išmušė ir nuotaiką, ir priesaika iš galvos...
Fiziniai diskai buvo perkelti į kitą pagrindinį kompiuterį. Karštas ryšys. Skirtuko saugojimo nustatymuose Diskai atsiranda diskai. Skirtuke Duomenų saugyklos Šiuose diskuose nėra saugyklos. atnaujinti - nepasirodo. Na, žinoma, pirmasis impulsas - Pridėti saugyklą. Pridėti vedlys paaiškina, ką jis palaiko. Žinoma, jis taip pat palaiko VMFS. Neabejojau. Greitai peržiūrėkite vedlio pranešimus kiekviename žingsnyje: Kitas, Kitas, Kitas, Baigti. Akis net nepriartėjo prie mažo geltono apskritimo su šauktuku vieno iš šeimininko laiptelių lango apačioje.
Vedlio pabaigoje sąraše pasirodė nauja duomenų saugykla... ir kartu su juo duomenų saugyklos iš likusių fizinių diskų.
Pradedu naršyti po naujai pridėtą duomenų saugyklą, ir ji... tuščia. Žinoma, vėl puolu į nuostabą. Jau 8 valanda, pirmos 15 minučių darbe po atostogų, aš dar net nesumaišiau cukraus kavoje. Ir štai. Pirma mintis buvo ta, kad ištraukiau netinkamą diską iš „vietinio“ pagrindinio kompiuterio. Pažiūrėjau, ar reikiama duomenų saugykla yra „gimtojoje“ priegloboje: ne, jos nebuvo. Antroji mintis buvo: „šik! Nesu tikras, bet man atrodo, kad trečia, ketvirta ir bent penkta mintis buvo ta pati.
Kad išsklaidyčiau abejones, greitai įdiegiau naują ESXi testavimui, paėmiau kairįjį diską ir, jau skaitydamas jį, ėjau vedlio žingsniais. Taip. Kai pridedate duomenų saugyklą naudodami vedlį, visi diske esantys duomenys prarandami be galimybės atšaukti operaciją ir atkurti duomenų. Vėliau viename forumų perskaičiau meistro šio dizaino įvertinimą: šlykštus šūdas. Ir aš tikrai sutikau.
Pradedant nuo šešto, mintys krypo konstruktyvesne linkme. GERAI. Net 3Tb disko inicijavimas trunka kelias sekundes. Taigi tai yra aukšto lygio formatavimas. Tai reiškia, kad skaidinių lentelė buvo tiesiog perrašyta. Taigi duomenys vis dar yra. Taigi, dabar ieškosime neformato ir voila.
Įkraunu mašiną iš Strelec įkrovos atvaizdo... Ir sužinau, kad skaidinio atkūrimo programos žino viską, išskyrus VMFS. Pavyzdžiui, jie žino „Synology“ skaidinio išdėstymą, bet ne VMFS.
Ieškoti per programas neduoda ramybės: geriausiu atveju GetDataBack ir R.Saver randa NTFS skaidinius su gyva katalogų struktūra ir tiesioginiais failų pavadinimais. Bet tai man netinka. Man reikia dviejų vmdk failų: su sistemos disku ir šiukšliadėžės failo disku.
Ir tada suprantu, kad atrodo, kad dabar įdiegsiu „Windows“ ir išleisiu iš failo atsarginės kopijos. Ir tuo pačiu prisimenu, kad ten turėjau DFS šaknį. Taip pat prieigos teisių prie skyrių aplankų sistema, kurios apimtis ir pasekmės yra visiškai laukinės. Ne pasirinkimas. Vienintelė priimtina galimybė yra atkurti sistemos ir disko būseną su duomenimis ir visomis teisėmis.
Vėl Google, forumai, KB'shki ir vėl Jaroslavnos verksmas: VMware ESXi nepateikia duomenų atkūrimo mechanizmo. Visos diskusijų gijos turi dvi pabaigas: kažkas buvo atkurtas naudojant brangią DiskInternals VMFS Recovery arba kažkam padėjo programinės įrangos specialistas, aktyviai reklamuojantis savo paslaugas. vmfs-tools и dd. Įsigyti DiskInternals VMFS Recovery licenciją už 700 USD nėra galimybė. Leisti pašaliniams iš „potencialaus priešo teritorijos“ pasiekti įmonės duomenis taip pat nėra išeitis. Bet buvo paieškota google, kad VMFS skaidinius gali skaityti ir UFS Explorer.
DiskInternals VMFS atkūrimas
Bandomoji versija buvo atsisiųsta ir įdiegta. Programa sėkmingai pamatė tuščią VMFS skaidinį:
Režime Atšaukti trynimą (greitasis nuskaitymas) Taip pat radau apleistą duomenų saugyklą su virtualių mašinų aplankais su diskais:
Peržiūra parodė, kad failai yra gyvi:
Skirsnio įdiegimas sistemoje buvo sėkmingas, tačiau dėl nežinomos priežasties visuose trijuose aplankuose buvo ta pati virtuali mašina. Žinoma, pagal įstatymą niekšybė nėra tai, ko reikalaujama.
Trys gėdos eilutėsBandymas begėdiškai užrakinti programinę įrangą baigėsi nesėkmingai. Bet UFS Explorer užrakintas.
Labai neigiamai žiūriu į programinės įrangos vagystes. Jokiu būdu neskatinu naudoti priemones, skirtas apeiti apsaugą nuo nelicencijuoto naudojimo.
Atsidūriau katastrofiškoje situacijoje ir visai nesididžiavau priemonėmis, kurių ėmiausi.
NSO naršyklė
Disko nuskaitymas parodė, kad yra 7 mazgai. Mazgų skaičius „stebėtinai“ sutapo su *-flat.vmdk failų skaičiumi, aptiktų VMFS Recovery:
Failų dydžių ir mazgų dydžių palyginimas taip pat parodė atitiktį iki baito. Tuo pačiu buvo atkurti *-flat.vmdk failų pavadinimai ir atitinkamai jų priklausymas virtualioms mašinoms.
Apskritai, ESXi požiūriu vmdk diskai susideda iš dviejų failų: duomenų failo (<mašinos pavadinimas>-flat.vmdk) ir „fizinio“ disko išdėstymo failo (<mašinos pavadinimas>.vmdk). Jei įkelsite *-flat.vmdk failą į duomenų saugyklą iš vietinio kompiuterio, ESXi neatpažins jo kaip tinkamo disko failo. VMware žinių bazėje yra straipsnis apie tai, kaip rankiniu būdu sukurti disko deskriptoriaus failą: , bet man to daryti nereikėjo, tiesiog nukopijavau atitinkamų failų turinį iš „DiskInternals VMFS Recovery“ failo turinio peržiūros srities:
Po 4 valandų iškėlus 2,5 TB mazgą iš UFS Explorer ir 20 valandų įkėlus į hipervizoriaus duomenų saugyklą, sugedę disko failai buvo prijungti prie naujai sukurtos virtualios mašinos. Diskai pakėlė. Duomenų praradimo nepastebėta.
Šaltinis: www.habr.com