Disclaimer: Muistio on tarkoitettu viihdetarkoituksiin. Hyödyllisen tiedon ominaistiheys siinä on pieni. Se oli kirjoitettu "itselleni".
Lyyrinen johdanto
Organisaatiomme tiedostovedos toimii VMware ESXi 6 -virtuaalikoneessa, jossa on Windows Server 2016. Eikä tämä ole vain kaatopaikka. Tämä on tiedostonvaihtopalvelin rakenteellisten osastojen välillä: siellä on yhteistyötä, projektidokumentaatiota ja kansioita verkkoskannereilta. Yleensä koko tuotanto on täällä.
Ja tämä koko tuotantoajan säiliö alkoi roikkua. Lisäksi vieras saattoi hirttää itsensä hiljaa vaikuttamatta muihin. Hän saattoi tuhota koko isännän ja vastaavasti kaikki muut vieraskoneet. Voisin ripustaa itseni ja ripustaa vSphere-asiakaspalvelut: eli muiden vieraiden prosessit ovat elossa, koneet toimivat kunnolla ja vastaavat, mutta tiedostojen pesuria ei ole ja vSphere Client ei tartu isäntään. Yleensä järjestelmää ei voitu tunnistaa. Jäätymistä voi esiintyä päivän aikana alhaisen kuormituksen aikana. He voisivat tehdä sen yöllä ilman kuormaa. Voisi yöllä differentiaalivarmistuksen ja keskimääräisen kuormituksen aikana. Voisi viikonloppuisin täyden varmuuskopioinnin ja suuren kuormituksen aikana. Ja tilanne oli selvä huononeminen. Aluksi kerran vuodessa, sitten kerran puolen vuoden välein. Kärsivällisyyteni lopussa - kahdesti viikossa.
Minulla oli muistiongelma. Mutta he eivät antaneet minun pysäyttää roskakasaa edes viikonloppuisin ja suorittaa Memtestiä. Odotimme toukokuun vappua. Toukokuun lomien aikana suoritin Memtestin ja... virheitä ei löytynyt.
Olin hämmästynyt ja päätin lähteä lomalle. Kun olin lomalla, kaatopaikalla ei ollut yhtään jumitusta. Ja kun palasin töihin ensimmäisenä maanantaina, siellä oli roskakasa. Kestin täyden varmuuskopioinnin ja lopetin puhelun heti sen valmistuttua. Tällainen lämmin vastaanotto lomalta sai minut päätökseen vetää levyt fyysisesti vieraskoneen kanssa toiseen isäntään.
Ja vaikka on jo pitkään tiedetty, että ensimmäisenä päivänä loman jälkeisenä päivänä ei voi tehdä mitään vakavaa, vaikka valmistauduin olemaan tekemättä töitä koko matkan töihin, närkästymiseni uudesta jäätymisestä löi sekä mielialani että lupaukset päässäni...
Fyysiset levyt on siirretty toiseen isäntään. Kuuma yhteys. Välilehden tallennusasetuksissa asemat levyt tulevat näkyviin. Välilehdellä Tietovarastot Näillä levyillä ei ole tallennustilaa. virkistää - eivät näy. No, tietysti ensimmäinen impulssi - Lisää tallennustilaa. Ohjattu lisäystoiminto selittää, mitä se tukee. Tietysti se tukee myös VMFS:ää. En epäillyt sitä. Pikakatsaus ohjatun toiminnon viesteihin kussakin vaiheessa: Seuraava, Seuraava, Seuraava, Valmis. Silmä ei edes päässyt kiinni pieneen keltaiseen ympyrään, jossa oli huutomerkki yhden mestarin portaiden ikkunan alaosassa.
Ohjatun toiminnon lopussa luettelossa ilmestyi tuore Datastore... ja sen mukana tietovarastot jäljellä olevilta fyysisiltä levyiltä.
Siirryn selailemaan juuri lisättyä Datastorea, ja se on... tyhjä. Tietysti hämmästyin takaisin. Kello on kahdeksan, ensimmäiset 8 minuuttia töissä loman jälkeen, en ole vielä edes sekoittanut sokeria kahvissani. Ja tässä se on. Ensimmäinen ajatus oli, että vedin väärän levyn "alkuperäisestä" isännästä. Katsoin, oliko vaadittu tietovarasto "alkuperäisessä" isännässä: ei, sitä ei ollut. Toinen ajatus oli: "Vittu!" En ole varma, mutta minusta näyttää siltä, että kolmas, neljäs ja ainakin viides ajatus oli sama.
Hälventämään epäilyjä, asensin nopeasti uuden ESXin testausta varten, otin vasemman levyn ja jo luin sitä, kävelin ohjatun toiminnon vaiheiden läpi. Joo. Kun lisäät tietovaraston ohjatun toiminnon avulla, kaikki levyllä olevat tiedot menetetään ilman mahdollisuutta peruuttaa toimintoa ja palauttaa tietoja. Myöhemmin luin yhdeltä foorumilta mestarin arvion tästä mallista: paskaa paskaa. Ja olin todella samaa mieltä.
Kuudennesta alkaen ajatukset virtasivat rakentavampaan suuntaan. OK. Alustus kestää muutamassa sekunnissa jopa 3 Tb:n levyllä. Tämä on siis korkean tason muotoilu. Tämä tarkoittaa, että osiotaulukko yksinkertaisesti kirjoitettiin uudelleen. Data on siis edelleen olemassa. Joten nyt etsitään unformaattia ja voila.
Käynnistän koneen Strelecin käynnistysvedosta... Ja huomaan, että osion palautusohjelmat tietävät kaiken paitsi VMFS:n. He esimerkiksi tietävät Synologyn osioasettelun, mutta eivät VMFS:n.
Ohjelmien kautta etsiminen ei ole vakuuttavaa: parhaimmillaan GetDataBack ja R.Saver löytävät NTFS-osioita, joissa on elävä hakemistorakenne ja elävät tiedostonimet. Mutta tämä ei sovi minulle. Tarvitsen kaksi vmdk-tiedostoa: järjestelmälevyn ja roskakoritiedostolevyn.
Ja sitten ymmärrän, että näyttää siltä, että aion nyt asentaa Windowsin ja ottaa sen käyttöön tiedostojen varmuuskopiosta. Ja samalla muistan, että minulla oli DFS-juuri siellä. Ja myös osastokansioiden käyttöoikeusjärjestelmä, joka on täysin villi laajuudeltaan ja seurauksiltaan. Ei vaihtoehto. Ainoa ajallisesti hyväksyttävä vaihtoehto on palauttaa järjestelmän ja levyn tila tiedoilla ja kaikilla oikeuksilla.
Taas Google, foorumit, KB'shki ja taas Jaroslavnan itku: VMware ESXi ei tarjoa tietojen palautusmekanismia. Kaikilla keskustelusäikeillä on kaksi loppua: joku palautettiin kalliilla DiskInternals VMFS Recovery -ohjelmistolla tai jotakuta auttoi ohjelmistoasiantuntija, joka mainosti aktiivisesti hänen palveluitaan. vmfs-työkalut и dd. DiskInternals VMFS Recovery -lisenssin ostaminen 700 dollarilla ei ole vaihtoehto. Myöskään "potentiaalisen vihollisen alueelta" tulevan ulkopuolisen pääsy yrityksen tietoihin ei ole vaihtoehto. Mutta googletettiin, että VMFS-osioita voi lukea myös UFS Explorerilla.
DiskInternals VMFS -palautus
Kokeiluversio ladattiin ja asennettiin. Ohjelma näki onnistuneesti tyhjän VMFS-osion:
tila Peruuta (nopea skannaus) Löysin myös nuhjuisen Datastoren, jossa on virtuaalikoneiden kansioita ja levyjä:
Esikatselu osoitti, että tiedostot ovat elossa:
Osion liittäminen järjestelmään onnistui, mutta jostain tuntemattomasta syystä kaikki kolme kansiota sisälsivät saman virtuaalikoneen. Tietenkin lain mukaan ilkeyttä ei vaadita.
Kolme riviä häpeääYritys lukita ohjelmisto häpeämättömästi päättyi epäonnistumiseen. Mutta UFS Explorer lukittui.
Suhtaudun erittäin kielteisesti ohjelmistovarkauksiin. En missään tapauksessa rohkaise käyttämään keinoja, joilla vältetään suoja luvatonta käyttöä vastaan.
Olin katastrofaalisessa tilanteessa, enkä ollut ollenkaan ylpeä toimenpiteistä, joihin olin turvautunut.
UFS Explorer
Levyskannaus osoitti 7 solmun olemassaolon. Solmujen määrä "yllättäen" osui yhteen VMFS Recoveryn havaitsemien *-flat.vmdk-tiedostojen määrän kanssa:
Tiedostokokojen ja solmujen koon vertailu osoitti myös vastaavuuden tavua myöten. Samalla palautettiin *-flat.vmdk-tiedostojen nimet ja vastaavasti niiden kuuluminen virtuaalikoneen.
Yleisesti ottaen vmdk-levyt ESXi:n näkökulmasta koostuvat kahdesta tiedostosta: datatiedostosta (<koneen nimi>-flat.vmdk) ja "fyysisestä" levyasettelutiedostosta (<koneen nimi>.vmdk). Jos lataat *-flat.vmdk-tiedoston tietosäilöön paikalliselta koneelta, ESXi ei tunnista sitä kelvolliseksi levytiedostoksi. VMware Knowledge Base -tietokannassa on artikkeli levykuvaustiedoston luomisesta manuaalisesti: , mutta minun ei tarvinnut tehdä tätä, vaan kopioin vastaavien tiedostojen sisällön tiedoston sisällön esikatselualueelta DiskInternals VMFS Recoveryssa:
Kun 4 Tt:n solmu oli purettu 2,5 tuntia UFS Explorerista ja 20 tuntia hypervisorin tietosäilöön, kaatuneet levytiedostot yhdistettiin äskettäin luotuun virtuaalikoneeseen. Levyt nousivat. Tietojen menetystä ei havaittu.
Lähde: will.com