Malgarantio: La noto estas por distraj celoj. La specifa denseco de utilaj informoj en ĝi estas malalta. Ĝi estis skribita "por mi mem".
Lirika enkonduko
La dosiera rubejo en nia organizo funkcias per virtuala maŝino VMware ESXi 6, kiu funkcias Windows Server 2016. Kaj ĉi tio ne estas nur rubujo. Ĉi tio estas dosier-interŝanĝa servilo inter strukturaj dividoj: ekzistas kunlaboro, projektdokumentado kaj dosierujoj de retaj skaniloj. Ĝenerale, ĉiu produktadvivo estas ĉi tie.
Kaj ĉi tiu ujo de ĉiu produktadvivo komencis pendi. Krome, la gasto povis trankvile pendigi sin sen tuŝi la aliajn. Li povus malkonstrui la tutan gastiganton kaj, sekve, ĉiujn aliajn gastmaŝinojn. Mi povus pendigi min kaj pendigi la klientajn servojn de vSphere: tio estas, la procezoj de la aliaj gastoj vivas, la maŝinoj funkcias ĝuste kaj respondas, sed ne ekzistas dosierlavilo kaj la kliento de vSphere ne alkroĉiĝas al la gastiganto. Ĝenerale, neniu sistemo povus esti identigita. Frostiĝoj povus okazi dum la tago dum malalta ŝarĝo. Ili povis fari ĝin nokte dum senŝarĝo. Povus nokte dum diferenciala sekurkopio kaj averaĝa ŝarĝo. Povus dum semajnfinoj dum plenaj sekurkopioj kaj alta ŝarĝo. Kaj estis klara degenero de la situacio. Komence ĝi estis unufoje jare, poste unufoje ĉiujn ses monatojn. Je la fino de mia pacienco — dufoje semajne.
Mi havis problemon pri memoro. Sed ili ne lasis min haltigi la rubamason eĉ dum semajnfinoj kaj ruli Memtest. Ni atendis la majajn feriojn. Dum la majaj ferioj, mi kuris Memtest kaj... neniuj eraroj estis trovitaj.
Mi miris kaj decidis ferii. Dum mi feriis, ne estis eĉ unu interrompo ĉe la rubejo. Kaj kiam mi reiris al laboro por la unua tago lunde, estis rubamaso. Mi eltenis plenan sekurkopion kaj pendis tuj post kiam ĝi estis kompletigita. Tia varma bonvenigo de feriado puŝis min al la decido fizike treni la diskojn kun la gastmaŝino al alia gastiganto.
Kaj, kvankam oni jam delonge scias, ke oni ne povas fari ion seriozan en la unua tago post feriado, kvankam mi preparis min por ne labori ĝis la laboro, mia indigno pri ankoraŭ alia frosto frapis kaj mian humoron kaj mian promesoj el mia kapo...
Fizikaj diskoj estis movitaj al alia gastiganto. Varma konekto. En la stokado agordoj sur la langeto diskoj diskoj aperas. Sur la langeto Datumvendejoj Ne estas stokado sur ĉi tiuj diskoj. refreŝigi - ne aperas. Nu, kompreneble, la unua impulso - Aldonu Stokadon. La Aldoni Sorĉisto klarigas kion ĝi subtenas. Kompreneble ĝi ankaŭ subtenas VMFS. Mi ne dubis pri tio. Rapida rigardo al la mesaĝoj de la sorĉisto ĉe ĉiu paŝo: Poste, Sekva, Sekva, Finu. La okulo eĉ ne alproksimiĝis al kapti la malgrandan flavan cirklon kun ekkria signo ĉe la fundo de la fenestro de unu el la ŝtupoj de la mastro.
Ĉe la fino de la sorĉisto, la freŝa Datastore aperis en la listo... kaj kune kun ĝi la Datastores el la ceteraj fizikaj diskoj.
Mi pluiras al navigado tra la lastatempe aldonita Datastore, kaj ĝi estas... malplena. Kompreneble, mi refalis en miron. Estas la 8-a matene, la unuaj 15 minutoj ĉe la laboro post feriado, mi ankoraŭ ne movis la sukeron en mia kafo. Kaj jen ĝi. La unua penso estis, ke mi eltiris la malĝustan diskon de la "denaska" gastiganto. Mi rigardis por vidi ĉu la bezonata Datastore ĉeestas en la "denaska" gastiganto: ne, ĝi ne ĉeestis. La dua penso estis: "fiku!" Mi ne certas, sed ŝajnas al mi, ke la tria, kvara kaj almenaŭ kvina penso estis la sama.
Por forigi dubojn, mi rapide instalis freŝan ESXi por testado, prenis la maldekstran diskon kaj, jam leginte ĝin, trairis la paŝojn de la sorĉisto. Jes. Kiam vi aldonas Datumvendejon uzante la sorĉiston, ĉiuj datumoj sur la disko estas perditaj sen la kapablo refari la operacion kaj restarigi la datumojn. Poste mi legis en unu el la forumoj takson de tiu ĉi dezajno fare de majstro: aĉa aĉaĵo. Kaj mi vere konsentis.
Komencante de la sesa, pensoj fluis en pli konstruiva direkto. BONE. Iniciatigo prenas demandon de sekundoj eĉ por 3Tb disko. Do ĉi tio estas altnivela formatado. Ĉi tio signifas, ke la sekciotabelo estis simple reverkita. Do la datumoj ankoraŭ estas tie. Do, nun ni serĉos iom da senformato kaj voila.
Mi ekŝargas la maŝinon el la Strelec-ŝargbildo... Kaj mi ekscias, ke la programoj de reakiro de diskpartoj scias ĉion krom VMFS. Ekzemple, ili konas la sekcion de Synology, sed ne VMFS.
Serĉi tra programoj ne trankviligas: en la plej bona kazo, GetDataBack kaj R.Saver trovas NTFS-diskojn kun viva dosierujo-strukturo kaj vivaj dosiernomoj. Sed ĉi tio ne konvenas al mi. Mi bezonas du vmdk-dosierojn: kun la sistema disko kaj la rubdosiero-disko.
Kaj tiam mi komprenas, ke ŝajnas, ke mi nun instalos Vindozon kaj eliros el dosiera sekurkopio. Kaj samtempe mi memoras, ke mi havis DFS-radikon tie. Kaj ankaŭ sistemo de alirrajtoj al fakaj dosierujoj, kiu estas absolute sovaĝa laŭ amplekso kaj konsekvencoj. Ne eblo. La sola tempo-akceptebla opcio estas restarigi la staton de la sistemo kaj disko kun datumoj kaj ĉiuj rajtoj.
Denove Guglo, forumoj, KB'shki kaj denove la kriado de Jaroslavna: VMware ESXi ne provizas mekanismon de reakiro de datumoj. Ĉiuj diskutfadenoj havas du finaĵojn: iu estis reakirita uzante la multekostan DiskInternals VMFS Recovery, aŭ iu estis helpita de programaro-specialisto aktive promocianta siajn servojn. vmfs-iloj и dd. La opcio aĉeti DiskInternals VMFS Recovery-licencon por $ 700 ne estas opcio. Permesi al eksterulo de la "teritorio de ebla malamiko" aliri kompaniajn datumojn ankaŭ ne estas eblo. Sed oni guglos, ke VMFS-diskoj ankaŭ povas esti legitaj de UFS-Esploristo.
DiskInternals VMFS-Reakiro
La provversio estis elŝutita kaj instalita. La programo sukcese vidis la malplenan VMFS-sekcion:
En reĝimo Malforigi (Rapida Skanado) Mi ankaŭ trovis malbonan Datumvendejon kun dosierujoj de virtualaj maŝinoj kun diskoj interne:
La antaŭvido montris, ke la dosieroj vivas:
Munti la sekcion en la sistemon sukcesis, sed pro iu nekonata kialo, ĉiuj tri dosierujoj enhavis la saman virtualan maŝinon. Kompreneble, laŭ la leĝo, malnobleco ne estas tio, kio estas postulata.
Tri linioj de hontoLa provo senhonte ŝlosi la programaron finiĝis en fiasko. Sed UFS Explorer ŝlosis.
Mi havas ekstreme negativan sintenon al softvarŝtelo. Neniel mi instigas la uzadon de rimedoj por preteriri protekton kontraŭ senlicenca uzo.
Mi troviĝis en katastrofa situacio kaj tute ne fieris pri la rimedoj, al kiuj mi uzis.
UFS-Esploristo
Diska skanado montris la ĉeeston de 7 nodoj. La nombro da nodoj "surprize" koincidis kun la nombro da *-flat.vmdk dosieroj detektitaj de VMFS Recovery:
Komparo de dosiergrandecoj kaj nodaj grandecoj ankaŭ montris kongruon ĝis la bajto. Samtempe, la nomoj de *-flat.vmdk dosieroj kaj, sekve, ilia aparteno al virtualaj maŝinoj estis restarigitaj.
Ĝenerale, vmdk-diskoj el la vidpunkto de ESXi konsistas el du dosieroj: datumdosiero (<machine name>-flat.vmdk) kaj "fizika" disk-aranĝdosiero (<machine name>.vmdk). Se vi alŝutas *-flat.vmdk dosieron al la Datumvendejo de loka maŝino, ESXi ne rekonos ĝin kiel validan diskdosieron. La VMware Knowledge Base havas artikolon pri kiel permane krei diskan priskriban dosieron: , sed mi ne devis fari tion, mi simple kopiis la enhavon de la respondaj dosieroj el la dosiera enhavo antaŭrigarda areo en DiskInternals VMFS Recovery:
Post 4 horoj da malŝarĝo de 2,5 TB-nodo de UFS-Esploristo kaj 20 horoj da ŝarĝo en la Datumvendejon de la hiperviziero, la kraŝintaj diskdosieroj estis konektitaj al la lastatempe kreita virtuala maŝino. La diskoj reprenis. Neniu datumperdo estis observita.
fonto: www.habr.com