Atruna: Piezīme ir paredzēta izklaides nolūkiem. Noderīgās informācijas īpatnējais blīvums tajā ir zems. Tas bija rakstīts "priekš sevis".
Lirisks ievads
Failu izgāztuve mūsu organizācijā darbojas virtuālajā mašīnā VMware ESXi 6, kurā darbojas sistēma Windows Server 2016. Un šī nav tikai atkritumu izgāztuve. Šis ir failu apmaiņas serveris starp strukturālajām nodaļām: ir sadarbība, projekta dokumentācija un mapes no tīkla skeneriem. Kopumā visa ražošanas dzīve ir šeit.
Un šis visa ražošanas mūža konteiners sāka karāties. Turklāt viesis varēja mierīgi pakārties, neietekmējot citus. Viņš varēja nojaukt visu saimnieku un attiecīgi visas pārējās viesu mašīnas. Es varētu pakārt sevi un pakārt vSphere klientu pakalpojumus: tas ir, pārējo viesu procesi ir dzīvi, mašīnas darbojas pareizi un reaģē, bet nav failu mazgātāja un vSphere klients nepieķeras saimniekam. Kopumā nevienu sistēmu nevarēja identificēt. Zemas slodzes laikā dienas laikā var rasties sasalšana. Viņi to varēja darīt naktī bez slodzes. Varētu naktī diferenciālās dublēšanas un vidējās slodzes laikā. Varētu nedēļas nogalēs pilnas dublēšanas un lielas slodzes laikā. Un bija acīmredzama situācijas pasliktināšanās. Sākumā tas bija reizi gadā, pēc tam reizi pusgadā. Manas pacietības beigās - divas reizes nedēļā.
Man bija atmiņas problēma. Bet viņi neļāva man apturēt atkritumu kaudzi pat nedēļas nogalēs un palaist Memtest. Mēs gaidījām maija brīvdienas. Maija brīvdienās palaistīju Memtest un... nekādas kļūdas netika atrastas.
Es biju pārsteigts un nolēmu doties atvaļinājumā. Kamēr es biju atvaļinājumā, atkritumu izgāztuvē nebija nevienas piekārtas. Un, kad es pirmdien pirmo dienu atgriezos darbā, bija atkritumu kaudze. Es izturēju pilnu dublēšanu un pakārtu uzreiz pēc tā pabeigšanas. Tik sirsnīga sagaidīšana no atvaļinājuma lika man pieņemt lēmumu fiziski vilkt diskus ar viesu mašīnu uz citu saimnieku.
Un, lai gan jau sen zināms, ka pirmajā dienā pēc atvaļinājuma neko nopietnu nevar darīt, lai gan gatavojos nestrādāt visu ceļu uz darbu, mans sašutums par kārtējo sastingumu izsita gan garastāvokli, gan garastāvokli. zvērests no manas galvas...
Fiziskie diski ir pārvietoti uz citu resursdatoru. Karstais savienojums. Cilnes krātuves iestatījumos Diski parādās diski. Uz cilnes Datu krātuves Šajos diskos nav atmiņas. atsvaidzināt - neparādās. Nu, protams, pirmais impulss - Pievienot krātuvi. Pievienošanas vednis izskaidro, ko tas atbalsta. Protams, tas atbalsta arī VMFS. Es par to nešaubījos. Īss vedņa ziņojumu apskats katrā darbībā: Nākamais, Nākamais, Nākamais, Pabeigt. Acs pat nepietuvojās, lai notvertu mazo dzelteno apli ar izsaukuma zīmi viena meistara pakāpiena loga apakšā.
Vedņa beigās sarakstā parādījās jaunais Datastore... un kopā ar to Datastores no atlikušajiem fiziskajiem diskiem.
Es pāreju uz navigāciju pa tikko pievienoto datu krātuvi, un tas ir... tukšs. Protams, es atkal kritu izbrīnā. Pulkstens ir 8 no rīta, pirmās 15 minūtes darbā pēc atvaļinājuma, es vēl neesmu pat cukuru kafijā samaisījusi. Un šeit tas ir. Pirmā doma bija tāda, ka es izvilku nepareizo disku no “native” resursdatora. Es paskatījos, vai “vietējā” saimniekdatorā ir vajadzīgā datu krātuve: nē, tā nebija. Otrā doma bija: "Bet!" Es neesmu pārliecināts, bet man šķiet, ka trešā, ceturtā un vismaz piektā doma bija viena un tā pati.
Lai kliedētu šaubas, es ātri instalēju testēšanai jaunu ESXi, paņēmu kreiso disku un, jau to lasot, izgāju cauri vedņa soļiem. Jā. Kad pievienojat datu krātuvi, izmantojot vedni, visi diskā esošie dati tiek zaudēti bez iespējas atsaukt darbību un atjaunot datus. Vēlāk vienā no forumiem izlasīju kāda meistara vērtējumu par šo dizainu: sūdīgi sūdi. Un es tiešām piekritu.
Sākot ar sesto, domas ritēja konstruktīvākā virzienā. LABI. Pat 3Tb diska inicializācija aizņem dažas sekundes. Tātad šis ir augsta līmeņa formatējums. Tas nozīmē, ka nodalījuma tabula tika vienkārši pārrakstīta. Tātad dati joprojām ir. Tātad, tagad mēs meklēsim kādu neformātu un voila.
Ielādēju mašīnu no Strelec sāknēšanas attēla... Un uzzinu, ka partition atkopšanas programmas zina visu, izņemot VMFS. Piemēram, viņi zina Synology nodalījuma izkārtojumu, bet ne VMFS.
Meklēšana programmās nav pārliecinoša: labākajā gadījumā GetDataBack un R.Saver atrod NTFS nodalījumus ar reāllaika direktoriju struktūru un reāllaika failu nosaukumiem. Bet tas man neder. Man vajag divus vmdk failus: ar sistēmas disku un miskastes faila disku.
Un tad es saprotu, ka tagad es instalēšu Windows un izlaidīšu no faila dublējuma. Un tajā pašā laikā es atceros, ka man tur bija DFS sakne. Un arī piekļuves tiesību sistēma nodaļu mapēm, kuras darbības joma un sekas ir absolūti savvaļas. Nav variants. Vienīgā laikā pieņemamā iespēja ir atjaunot sistēmas un diska stāvokli ar datiem un visām tiesībām.
Atkal Google, forumi, KB'shki un atkal Jaroslavnas raudāšana: VMware ESXi nenodrošina datu atkopšanas mehānismu. Visiem diskusiju pavedieniem ir divas galotnes: kāds tika atkopts, izmantojot dārgo DiskInternals VMFS Recovery, vai kādam palīdzēja programmatūras speciālists, aktīvi reklamējot savus pakalpojumus. vmfs-tools и dd. DiskInternals VMFS atkopšanas licences iegāde par USD 700 nav iespējama. Tāpat nav risinājums ļaut nepiederošam cilvēkam no “potenciālā ienaidnieka teritorijas” piekļūt korporatīvajiem datiem. Bet tika pameklēts googlē, ka VMFS nodalījumus var lasīt arī UFS Explorer.
DiskInternals VMFS atkopšana
Izmēģinājuma versija tika lejupielādēta un instalēta. Programma veiksmīgi redzēja tukšo VMFS nodalījumu:
režīms Atsaukt dzēšanu (ātrā skenēšana) Atradu arī nobružātu Datastore ar virtuālo mašīnu mapēm ar diskiem iekšā:
Priekšskatījums parādīja, ka faili ir dzīvi:
Sadalījuma uzstādīšana sistēmā bija veiksmīga, taču nezināma iemesla dēļ visās trīs mapēs bija viena un tā pati virtuālā mašīna. Protams, saskaņā ar likumu zemiskums nav tas, kas tiek prasīts.
Trīs kauna rindasMēģinājums bezkaunīgi bloķēt programmatūru beidzās ar neveiksmi. Bet UFS Explorer tika bloķēta.
Man ir ārkārtīgi negatīva attieksme pret programmatūras zādzībām. Es nekādā gadījumā neaicinu izmantot līdzekļus, lai apietu aizsardzību pret nelicencētu lietošanu.
Es biju katastrofālā situācijā un nemaz nebiju lepns par pasākumiem, pie kuriem biju ķērusies.
UFS Explorer
Diska skenēšana parādīja 7 mezglu klātbūtni. Mezglu skaits “pārsteidzoši” sakrita ar *-flat.vmdk failu skaitu, ko atklāja VMFS Recovery:
Failu izmēru un mezglu izmēru salīdzinājums arī parādīja atbilstību līdz baitam. Tajā pašā laikā tika atjaunoti *-flat.vmdk failu nosaukumi un attiecīgi to piederība virtuālajām mašīnām.
Kopumā vmdk diski no ESXi viedokļa sastāv no diviem failiem: datu faila (<mašīnas nosaukums>-flat.vmdk) un “fiziskā” diska izkārtojuma faila (<mašīnas nosaukums>.vmdk). Ja augšupielādējat *-flat.vmdk failu datu krātuvē no vietējās mašīnas, ESXi to neatpazīs kā derīgu diska failu. VMware zināšanu bāzē ir raksts par to, kā manuāli izveidot diska deskriptora failu: , bet man tas nebija jādara, es vienkārši nokopēju atbilstošo failu saturu no DiskInternals VMFS Recovery faila satura priekšskatījuma apgabala:
Pēc 4 stundām pēc 2,5 TB mezgla izkraušanas no UFS Explorer un 20 stundām ilgas ielādes hipervizora datu krātuvē, avarējušie diska faili tika savienoti ar jaunizveidoto virtuālo mašīnu. Diski pacēla. Datu zudumi netika novēroti.
Avots: www.habr.com