Në Ne informuam ju për veçoritë e reja në përditësimin e janarit Update 4 për Veeam Backup & Replication 9.5 (VBR), ku qëllimisht nuk përmendëm backup-et në kasetat magnetike. Një histori mbi këtë fushë meriton një artikull të veçantë, pasi kishte vërtet shumë veçori të reja.
â DjemtĂ« nga QA, do shkruani njĂ« artikull?
â Pse jo!
Diskët kasetë në shekullin XXI
Ruajtja e të dhënave në kasetat magnetike (kasetat, "diskët kasetë", siç i quajmë ne në R&D) nuk kufizohet në kompjuterin e kaluar ZX-Spectrum, një lojë për të cilin mund të ngarkohej në memorien operative 48 kb nga për disa minuta. Gjatë një çereku shekulli, shpejtësitë dhe kapacitetet e kasetave janë rritur me 6-7 renditje. Ky nuk është një krahasim krejt objektiv, dhe sipas standard nuk po ndjek ritmin. Megjithatë, teknologjitë moderne lejojnë që në një kasetë kilometrike të ruhet 12 terabajt të dhënash (deri në 30 terabajt në modin e kompresimit), kështu që disku i kushton 160 dollarë e lë pas konkurrencën në kosto për ruajtjen afatgjatë të sasisë së madhe të të dhënave, edhe duke marrë parasysh investimet në pajisjet për regjistrimin/leximin e tyre. Të dhënat në këto kaseta ruhen me besueshmëri për 15-30 vjet.
Po e shoh nga njĂ« kĂ«ndvĂ«shtrim tjetĂ«r. KohĂ«t e fundit, kanĂ« arritur njĂ« nivel tĂ« ri. Ata mund tĂ« presin nĂ« heshtje nĂ« infrastrukturĂ«n e njĂ« kompanie tĂ« madhe pĂ«r javĂ« dhe muaj, dhe me shfaqjen e njĂ« dobĂ«sie tĂ« re zero â tĂ« shkatĂ«rrojnĂ« (jo pa ndihmĂ«n e njeriut, sepse janĂ« pĂ«rpara para tĂ« mĂ«dha) jo vetĂ«m tĂ« dhĂ«nat, por edhe tĂ« gjitha kopjet rezervĂ«, deri ku mund tĂ« arrijnĂ«. KĂ«shtu , kur kompanitĂ« u detyruan tĂ« paguajnĂ« hakerĂ«t. TĂ« ashtuquajturat air gap, domethĂ«nĂ«, kopjet e rezervĂ«s qĂ« janĂ« fizikisht tĂ« izoluara nga infrastruktura, janĂ« bĂ«rĂ«, nĂ« thelb, shpĂ«timi i vetĂ«m tĂ« besueshĂ«m nga kĂ«to histori. Kasetat magnetike kĂ«tu janĂ« njĂ« nga zgjidhjet qĂ« nuk dalin nga moda.
Por njĂ« specifikim dhe risitĂ« teknologjike tĂ« prodhuesve kryesorĂ« (IBM, HPE, Oracle, Dell) nuk mjaftojnĂ« pĂ«r mbrojtjen e besueshme tĂ« tĂ« dhĂ«nave, nevojitet njĂ« softuer i mirĂ«. NĂ« Veeam, kemi njĂ« ekip tĂ« tĂ«rĂ« qĂ« merret me backup-et nĂ« kaseta, rreth 10 persona analizojnĂ«, planifikojnĂ«, kĂ«rkojnĂ«, zhvillojnĂ« dhe testojnĂ« çdo ditĂ«. Rezultatet e kĂ«saj pune mund t'i keni parĂ« nĂ« artikujt tanĂ« tĂ« mĂ«parshĂ«m (, ). ĂfarĂ« Ă«shtĂ« bĂ«rĂ« gjatĂ« vitit tĂ« fundit?
Fjalor
Po vjen njĂ« zgjedhje midis lirisĂ« ndaj gjuhĂ«s amtare dhe burokracive qĂ« e komplikojnĂ« lexueshmĂ«rinĂ«. UnĂ« preferoj tĂ« parĂ«n, kĂ«shtu qĂ« paraprakisht kĂ«rkoj falje, nĂ«se ndonjĂ« fjalĂ« xhargoni nga lista mĂ« poshtĂ« do t'i cĂ«nojĂ« sytĂ« dikujt. KĂ«tu do tâi kujtoj shkurtimisht se çfarĂ« do tĂ« thotĂ« secili term.
E gjithĂ« kjo pjesĂ« mund tĂ« kalojĂ« pĂ«r specialistĂ«t e VBRJob â punĂ« â njĂ« operacion backup-i. Faktikisht, e gjithĂ« VBR ndihmohet nga jobs. PĂ«rveç backup-it dhe replikimit, kjo mund tĂ« jetĂ« edhe kopjimi nĂ« kasetat magnetike (backup to tape job, job kasete). Dua tĂ« sqaroj se rikuperimi nga njĂ« kopje rezervĂ« (restor) Ă«shtĂ« gjithashtu njĂ« job, por nĂ« kĂ«tĂ« artikull ky term do tĂ« pĂ«rkthehet si backup.
Storage â storazh â njĂ« emĂ«r qĂ« ka lindur historikisht. KĂ«to janĂ« skedarĂ«t nĂ« repozitorit (repository â depo), qĂ« pĂ«rmbajnĂ« kopje rezervĂ« â operacione homomorfe tĂ« plota dhe inkrementalet. NĂ« njĂ« storage mund tĂ« ketĂ« ose njĂ« makinĂ« virtuale ose disa.
Chain â zinxhir â njĂ« sĂ«rĂ« storazhesh tĂ« lidhura me njĂ«ra-tjetrĂ«n. PĂ«r rikuperimin e tĂ« dhĂ«nave nga n-i inkremental duhet tĂ« keni tĂ« gjitha tĂ« mĂ«parshme nga (n-1) deri nĂ« atĂ« tĂ« parĂ« dhe storazhi i plotĂ« i referuar nga e para inkrementale.
Source, Target â source, target. Source Ă«shtĂ« entiteti fillestar qĂ« pĂ«rpunon job-in. NĂ« rastin e backup-eve/replikave, kjo zakonisht Ă«shtĂ« njĂ« makinĂ« virtuale nĂ« hipervizor. NĂ« rastin e job-it tĂ« kasetave, source Ă«shtĂ« vetĂ« job-i i backup-it (apo skedarĂ«t nĂ« rastin e job-it file to tape). Target pĂ«r job-in e backup-it Ă«shtĂ« repository ku ruhen backup-et. PĂ«r job-in e kasetave, kjo Ă«shtĂ« media pool.
Media pool â â njĂ« pool informacioni, nĂ« rastin tonĂ« â kasetat. NjĂ« konteiner logjik, i krijuar nga pĂ«rdoruesi dhe qĂ« pĂ«rmban kaseta nga njĂ« ose disa biblioteka. Pra, job-i i kasetave gjithmonĂ« ka njĂ« media pool si target, domethĂ«nĂ« tĂ« dhĂ«nat nuk shkruhen nĂ« ndonjĂ« kasetĂ« specifike dhe as nĂ« ndonjĂ« kasetĂ« tĂ« çfarĂ«do nĂ« bibliotekĂ«, por nĂ« njĂ« grup tĂ« caktuar prej tyre. Media pool ka njĂ« konfigurim tĂ« kohĂ«s sĂ« ruajtjes tĂ« tĂ« dhĂ«nave, pas sĂ« cilĂ«s kaseta mund tĂ« ri-regjistrohet. PĂ«rdoruesi mund tĂ« krijojĂ« media pools standarde dhe . Ădo njĂ«ri nga kĂ«to lloje tani mund tĂ« jetĂ« gjithashtu WORM dhe jo-WORM, pĂ«r kĂ«tĂ« mĂ« poshtĂ«.
Media set â â njĂ« grup kasetash nĂ« mediat pool, mbi tĂ« cilat shkruhen vazhdimisht backupet/fajllat. PĂ«r pool-et GFS, mediat setet kanĂ« gjithashtu lidhje me intervalin (p.sh., vjetor â yearly), kasetat rotullohen vetĂ«m brenda intervalit tĂ« tyre.
â elementet e bibliotekĂ«s sĂ« kasetave. Dreyti lexon dhe rrotullon kasetĂ«n, cjeinder Ă«shtĂ« njĂ« robot qĂ« lĂ«viz kasetat midis slotit tĂ« ruajtjes, slotit tĂ« shkarkimit dhe dreytit. Ka edhe dreyt standalone (standalone â nĂ« kĂ«mbĂ«), roli i cjeinder kĂ«tu e kryen njeriu. NjĂ« dreyt kĂ«rkon instalimin e saktĂ« tĂ« drejtuarit tĂ« prodhuesit nĂ« makinĂ«n Windows, ku Ă«shtĂ« e lidhur biblioteka; me cjeinder mund tĂ« punojmĂ« edhe pa drejtuar, pĂ«rmes native SCSI.
Tenant to tape. MbrojtĂ«s Ă«shtĂ« ofruesi â mbrohen klientĂ«t
Të gjitha aspekte të shfaqen. Karakteristika më e madhe e azhurnimit tonë, e destinuar për , që përdorin VBR në infrastrukturën e tyre. Zhvillimi filloi dy vjet më parë. Së shpejti kuptuam se do të ishte e vështirë të përballeshim me një detyrë kaq të madhe për lëshimin e afërt, morët një pushim të vogël dhe në fund lëshuam karakteristikën në 9.5 Update 4.
NĂ«se flasim shkurt, tani ofruesit kanĂ« mundĂ«sinĂ« tĂ« kopjojnĂ« backupet e klientĂ«ve tĂ« tyre nĂ« kaseta pĂ«rmes njĂ« punĂ« tĂ« tape-nĂ« GFS-pool. Kjo u jep ofruesve â dhe kĂ«ta janĂ« njerĂ«z shumĂ« tĂ« rĂ«ndĂ«sishĂ«m pĂ«r ne dhe departamentin tonĂ« tregtar â dy mundĂ«si:
- tĂ« mbrojnĂ« klientĂ«t e tyre (tenantĂ«, tenant â qiramarrĂ«s) nga humbja e tĂ« dhĂ«nave pĂ«r shkak tĂ« fshirjes sĂ« rastĂ«sishme ose problemeve infrastrukturore ("flood in server room");
- të ofrojnë tenantëve një shërbim shtesë për rikuperimin e të dhënave nga një backup i vjetër, i cili tashmë është fshirë nga depozita e rezerve në oborrin e re, por në kaseta ka mbetur akoma.
Nga perspektiva marketingu, funksionaliteti Ă«shtĂ« shumĂ« "i shijshĂ«m", nga ana jonĂ« â po aq komplekse nĂ« zbatim.
Zhvillimi
Problemi kryesor i lindur ishte kriptimi i tĂ« dhĂ«nave. Shumica e backup-eve nĂ« re janĂ« tĂ« enkriptuara, statistikat tregojnĂ« pĂ«r â e numrit total. PĂ«r ne, ky numĂ«r ishte njĂ« surprizĂ«, supozonim se shumĂ«, por jo â duket se shumĂ« klientĂ« kanĂ« besim tĂ« pakushtuar nĂ« ofruesit e tyre.
Paradigma është e thjeshtë: ofruesi nuk duhet të jetë në gjendje të dekriptojë të dhënat e tenantëve të tij. Megjithatë, në kuadër të karakteristikës së re, kërkohet nga ana e ofruesit të hapë ruajtjet me backupet. Kjo është e nevojshme për të transferuar blloqet e të dhënave, për shembull, për krijimin e . E rëndësishme është se kjo duhet të bëhet në mënyrë të pavarur nga tenantët, kur çelësat e nevojshëm nuk transferohen në anën e ofruesit gjatë ekzekutimit të punës.
Zgjidhja e kĂ«tij problemi, e cila po ashtu Ă«shtĂ« e angazhuar nĂ« njĂ« karakteristikĂ« tjetĂ«r thelbĂ«sore tĂ« azhurnimit â â qĂ«ndron nĂ« shtimin e njĂ« çelĂ«si tĂ« ri tĂ« kriptimit. ĂelĂ«si arkivor (Archive key) ruhet nĂ« bazĂ«n e tĂ« dhĂ«nave tĂ« ofruesit nĂ« formĂ« tĂ« enkriptuar. NĂ« njĂ« skemĂ« tĂ« mençur nĂ« anĂ«n e ofruesit, me tĂ« ndihmohet tĂ« hapet ruajtja, tĂ« transferohen dhe pĂ«rsĂ«riten blloqet e tĂ« dhĂ«nave midis ruajtjeve (sepse secila ka çelĂ«sin e vet), por nuk mund tĂ« dekriptohen vetĂ« tĂ« dhĂ«nat.
Skema me mençuri (versioni funksional)
Do të shtoj se të gjithë inxhinierët në R&D e duan shumë kriptimin në produktin tonë, megjithatë, askush nuk e di në të gjitha detajet se si funksionon. (Këtu kishte një shaka "dhe pse në të vërtetë funksionon", por kjo nuk u kalua nga redaktorët.)
Testimi
Mbi karakteristikĂ«n u regjistruan qindra bugs. Zonat mĂ« tĂ« komplikuara â kriptimi, ndĂ«rfaqja e pĂ«rdoruesit, problemet gjatĂ« rikuperimit.
Nga perspektiva e testimit, vĂ«shtirĂ«sia pĂ«rbĂ«nte variabiliteti i madh, "kombinatorika" e llojeve dhe format e punĂ«ve tĂ« tenantĂ«ve dhe depozitave â po flas pĂ«r burimin, si dhe destinacionin gjatĂ« rikuperimit tĂ« backup-eve nĂ« infrastrukturĂ«. TĂ« gjitha kĂ«to lidhen me logjikĂ«n nĂ« kuadĂ«r tĂ« (pĂ«rfshirĂ« tĂ« rejat â paralelizmi dhe grupet mediat ditore, pĂ«r kĂ«tĂ« mĂ« poshtĂ«), si dhe nĂ« pĂ«rgjithĂ«si pĂ«r specifikĂ«n e re tĂ« cloud pĂ«r kasetat. Mos harroni tĂ« pĂ«rzgjidhni shume me kriptimin. NĂ«se vazhdojmĂ« metaforĂ«n, ne kemi ngrĂ«nĂ« shumĂ« mirĂ« kĂ«tĂ« tĂ« nxjerrĂ« - por pĂ«rpiqemi ta shijojmĂ« nga tĂ« gjitha anĂ«t.
Fragmenti i planit të testimit
Si rezultat
Përshkrimi i detajuar mund të gjendet në (deri tani në anglisht): , . Do të ndalem në çështjet kryesore.
Backup
Ofruesi shton tenantët në punën e tape me GFS-pool si destinacion. Me një licencë cloud, në hapin e dytë të wizard është në dispozit seçtyne Tenantët. Mund të shtoni të gjithë tenantët menjëherë ose një për një, ose të zgjidhni vetëm një kuotë (por jo subkuotë) të një tenant të veçantë. Nuk mund të përzihen backup-et e tenantëve dhe ato lokale normale në një punë.
Rregullimet e tjera janë pothuajse plotësisht identike me punën normale në GFS-pool.
Restaurimi i të dhënave është i mundshëm si në anën e ofruesit, ashtu edhe në anën e vetë klientit.
Rivendosja në anën e ofruesit
Kjo realizohet përmes një asistenti të ri. Këtu mund të përcaktohet një punë e veçantë, duke rikthyer të gjithë zinxhirin që ka qenë në depo në një ditë të caktuar.
Ka tre mundësi për restaurim:
- Në lokacionin origjinal. Në këtë rast, backup-i origjinal, nëse ekziston, hiqet; punët e klientit rinisën automatikisht në zinxhirin e rikuperuar. Supozohet se një restaurim i tillë do të jetë në përgjithësi i padukshëm për klientin, vetëm për një kohë të shkurtër do të jetë i çaktivizuar nga depoja në cloud.
- Në një kuotë/repot të re. Ofruesi mund, për shembull, të krijojë një llogari për këtë qëllim, e cila më vonë do të fshihet. Backup-i shfaqet në infrastrukturën e klientit pas sinkronizimit me bazën e ofruesit.
- Thjesht në një disk të serverit Linux ose Windows, i regjistruar në infrastrukturën e ofruesit. Më pas, ky zinxhir mund të ruhet në një flash drive dhe të dërgohet te klienti.
Rivendosja në anën e klientit
Kjo mundësi nënkupton praninë e klientit të një infrastrukture tape dhe një sasi të madhe të dhënash për restaurim. Kaseta me backup-et e regjistruara mund të dërgohet fizikisht nga ofruesi te klienti përmes shërbimit të dorëzimit, ai e katalogizon atë në pajisjet e tij, e dekripton kasetën dhe backup-et dhe punon me kopjet rezervë siç do ta kishte bërë vetë.
Përmirësime masive të grupit GFS
-pools media u shfaqën në VBR dy vjet më parë, në versionin 9.5. Në përditësimin e fundit, si për shkak të shfaqjes së veçorisë Tenant to tape, ashtu edhe në kërkesat e përdoruesve, ne e përmirësuam këtë funksionalitet.
Sete mediale ditore
Ka një set të ri ditor (daily) set medial. Tani në grupin GFS mund të ruhen backup-et për çdo ditë, dhe jo vetëm të plota, por edhe inkrementale. Të fundit zënë substancialisht më pak hapësirë, dhe kjo u bë në emër të kursimit të kasetave. Supozohet se këto kaseta rotullohen vazhdimisht në bibliotekë, nuk dërgohen për ruajtje të largët. Në këtë rast, për restaurimin nga një pikë inkrementale do të nevojiteshin kaseta nga një nga setet mediale më të larta (javore, mujore, tremujore ose vjetore). Aktivizimi i një seti mediali ditor pa aktivizimin e atij javor nuk është i mundur, për të siguruar që në shumicën e rasteve, për rimarrjen nga një kopje inkrementale do të nevojiteshin pikërisht kasetat javore. Ato ose gjithmonë ndodhen në bibliotekë, ose ruhen në një depo jo aq të largët.
Logjika e punĂ«s sĂ« punĂ«s sĂ« bandes nĂ« grupin GFS , shkrimtarĂ«t teknikĂ« nuk do ta mohojnĂ«. NĂ« dy fjalĂ«, duke pĂ«rjashtuar detajet, nĂ« setet mediale javore dhe mĂ« tĂ« larta kopjohen vetĂ«m backup-et e plota (pĂ«rfshirĂ« backup-et plotĂ«sisht virtuale), njĂ« pĂ«r çdo datĂ«, ndĂ«rsa nĂ« atĂ« ditor â tĂ« gjitha backup-et qĂ« janĂ« nĂ« depo pĂ«r ditĂ«n aktuale, sepse puna e backup-it mund tĂ« fillojĂ« mĂ« shpesh se njĂ« herĂ« nĂ« ditĂ«.
Paralelizmi, koha e fillimit dhe pritja në grupet GFS
Tani Ă«shtĂ« e mundur tĂ« shkruajĂ« nĂ« mĂ«nyrĂ« paralele disa zinxhirĂ« ose punĂ« nĂ« disa disqe tĂ« bibliotekĂ«s edhe nĂ« grupet GFS (mĂ« parĂ« â vetĂ«m nĂ« ato normale). Aktivizohet nĂ« hapin MundĂ«sitĂ« tĂ« grupit media.
Shënim i rëndësishëm: një skedar i njëjtë gjithmonë shkruhet në një rrjedhë, prandaj në rastin e disa makinave virtuale të mëdha rekomandohet të aktivizohet , në mënyrë që backup-i të përbëhet nga disa zinxhirë.
PĂ«rveç kĂ«saj, tani Ă«shtĂ« e mundur tĂ« zgjidhet koha e fillimit tĂ« vetĂ« punĂ«s GFS. ShumĂ« pĂ«rdorues nuk e pĂ«lqenin nisjen nĂ« mesnatĂ« dhe pritjen pas njĂ« ditĂ« tĂ« tĂ«rĂ«, derisa punimi burimor tĂ« pĂ«rfundojĂ«. Tani ky kohĂ« mund tĂ« vendoset, pĂ«r shembull, nĂ« mbrĂ«mje tĂ« vonĂ«, kur tashmĂ« ka diçka pĂ«r tĂ« kopjuar nĂ« kasetĂ«. MĂ« shumĂ«, sipas kĂ«rkesave tĂ« pĂ«rdoruesve, kemi nxjerrĂ« nĂ« cilĂ«simet e avancuara njĂ« opsion, qĂ« mĂ« parĂ« mund tĂ« aktivizohej vetĂ«m me njĂ« çelĂ«s regjistri. Mjafton tĂ« zgjidhni Procesoni pikĂ«n mĂ« tĂ« fundit tĂ« rikuperimit pĂ«rpara se tĂ« prisni â dhe nĂ« kasetĂ« kopjohet ajo qĂ« Ă«shtĂ« nĂ« depo nĂ« momentin e fillimit tĂ« punĂ«s sĂ« bandes (pika nga dita e djeshme, pĂ«r shembull), nuk ka asnjĂ« pritje.
Përmirësimi i punës me bibliotekat e shumta
Flitet për situatën kur në një grup medial janë shtuar më shumë se një bibliotekë. Kjo u mbështet edhe më përpara, por herë pas here vinin klientë me ankesa për sjellje jo të parashikueshme.
Ishte
Për shembull, një punë e nisur filloi duke përdorur dy disqe në bibliotekën e parë, por cilësimet e paralelizmit lejojnë të përdoren menjëherë 4 disqe. A duhet të kalojë kjo punë në bibliotekën e dytë të grupit të mediave dhe ta përdorë atë gjithashtu, apo do të ishte tepricë burimesh?
NjĂ« rast tjetĂ«r. ĂshtĂ« zgjedhur opsioni pĂ«r t'u kalitur nĂ« kushtin "nuk ka kaseta tĂ« disponueshme", nĂ« bibliotekĂ«n e parĂ« ka vetĂ«m njĂ« kasetĂ«, por e gjithĂ« informacioni potencialisht pĂ«rmbushet aty. MegjithatĂ«, cilĂ«simet lejojnĂ« shkrim paralel nĂ« dy kaseta. A duhet tĂ« aktivizohet biblioteka e dytĂ« nĂ« kĂ«tĂ« rast?
Ne vendosëm ta organizojmë këtë fushë, duke dhënë mundësinë për të cilësuar sjelljen në mënyrë të qartë.
Nisi
kanĂ« rol â aktiv dhe pasiv. Dhe grupi i mediave vetĂ« ka dy moda: tĂ« qĂ«ndrueshĂ«m, ose ndihmĂ«s (failover) dhe shkrim paralel (paralleling). Tani, nĂ« varĂ«si tĂ« kĂ«rkesave, grupi i mediave mund tĂ« konfigurohet ndryshe.
- NĂ«se keni disa biblioteka tĂ« barabarta dhe Ă«shtĂ« e nevojshme tĂ« rregullohet shkrimi nĂ« to â aktivizoni modin e shkrimit paralel, pĂ«r kĂ«tĂ« tĂ« gjitha bibliotekat duhet tĂ« kenĂ« rol aktiv. NĂ« kĂ«tĂ« rast, kasetat dhe disqet e reja do tĂ« aktivizohen menjĂ«herĂ«, nĂ« momentin qĂ« ka nevojĂ«, pavarĂ«sisht se nĂ« cilĂ«n bibliotekĂ« ndodhen. Prioriteti ndodhet gjithmonĂ« â sĂ« pari do tĂ« pĂ«rpiqemi tĂ« gjejmĂ« burimet nĂ« bibliotekĂ«n qĂ« ndodhet mĂ« lart nĂ« listĂ«.
- Nëse ka vetëm një bibliotekë kryesore dhe një disqet e vjetër ose të vetme si rezervë, aktivizoni modin e ndihmës, duke vendosur bibliotekën kryesore në fillim të listës dhe zgjedhur rol pasiv për pajisjet rezervë. Kalimi në një pajisje të tillë do të ndodhë vetëm kur është vërtet e nevojshme, për të siguruar që puna të funksionojë në ndonjë mënyrë. Kjo situatë do të trajtohet si një incident dhe do të dërgohet një njoftim në email.
Ekziston njĂ« situatĂ« mĂ« komplekse qĂ« pĂ«r momentin nuk e mbĂ«shtesim â disa biblioteka aktive me pajisje pasive. RrugĂ«zimi do tĂ« tregojĂ« nĂ«se ka nevojĂ« pĂ«r kĂ«so konfigurimesh dhe nĂ«se duhet "pĂ«rdorur" funksionalitetin nĂ« tĂ« ardhmen. PraktikĂ« standarde.
Mbështetje WORM
WORM â Write Once Read Many â kaseta qĂ« nuk mund tĂ« fshihen ose rinovohen , mund tĂ« shtohen vetĂ«m tĂ« dhĂ«na. PĂ«rdorimi i tyre Ă«shtĂ« i detyrueshĂ«m sipas rregullave tĂ« disa organizatave, pĂ«r shembull, qĂ« punojnĂ« nĂ« fushĂ«n e mjekĂ«sisĂ«. Problemi kryesor me kĂ«to kaseta mĂ« parĂ« ishte se VBR gjatĂ« ose regjistronte titullin, i cili mĂ« pas nuk mund tĂ« fshihej dhe punĂ«t e kasetave binin me gabim gjatĂ« njĂ« pĂ«rpjekjeje tĂ« tillĂ«.
Në 9.5 Update 4, mbështetje e plotë për këto kaseta është realizuar. Janë shtuar grupe mediatike WORM, të zakonshëm dhe GFS, në të cilat mund të vendosen vetëm kaseta të këtij lloji.
Kasetat e reja kanë një ikonë blu, "të ngrirë". Nga këndvështrimi i përdoruesit, puna me kasetat WORM nuk ndodhet ndryshe nga ajo me ato normale.
"Wormësia" e kasetave përcaktohet fillimisht sipas sufiksit , nëse barkodi mbi to është normal ose i palexueshëm, informata jepet nga disku gjatë insertimit të parë të kasetës. Nuk do të jetë e mundur të vendosen kasetat WORM në një grup të zakonshëm dhe të shkruhen mbi to. Nga të çuditshmet: përdoruesit kanë filluar të vendosin barkode WORM mbi kaseta normale dhe u janë dukur të habitur nga ndryshimet në infrastrukturën e tyre pas përditësimit.
Ăipi i kasetĂ«s
NjĂ«kohĂ«sisht me integrimin e kasetave qĂ« nuk mund tĂ« rinovohen, filluam tĂ« punojmĂ« me . Atributet standarde nĂ« çipin mĂ« parĂ« nuk ishin pĂ«rdorur nga ne, tani pĂ«r disa prej tyre shkruajmĂ« dhe lexojmĂ«, por nuk i perceptojmĂ« si burim kryesor tĂ« tĂ« dhĂ«nave. Orientimi kryesor mbetet â titulli i kasetĂ«s. Ky zgjidhje rezultoi e saktĂ«: pas njĂ« muaji nga lĂ«shimi shohim se "zoo" i harduerĂ«ve tĂ« pĂ«rdoruesve sjell surpriza nĂ« aspektin e punĂ«s me çipin.
Backup i volumit NDMP në kaseta
PĂ«rfundimisht â pĂ«r funksionalitetin mĂ« tĂ« kĂ«rkuar sipas numrit tĂ« komenteve nĂ« kĂ«tĂ« Update. Backup i volumit NDMP Ă«shtĂ« bĂ«rĂ« i disponueshĂ«m pĂ«r kasetat. Duhet , pas sĂ« cilĂ«s nĂ« punĂ«n e skedĂ«s sĂ« kasetave mund tĂ« zgjidhen volumet nga ky host. Ata transferohen nĂ« kaseta si skedarĂ« me njĂ« atribut special, nĂ« mĂ«nyrĂ« qĂ« tĂ« dallohet nga ato normale gjatĂ« katalogizimit.
NĂ« realizimin e parĂ«, ka disa kufizime: nuk mbĂ«shteten zgjerimet (extensions), pĂ«rveç kĂ«saj, Ă«shtĂ« i mundur backup dhe rikuperimi vetĂ«m i volumit tĂ« plotĂ«, jo tĂ« skedarĂ«ve individualĂ«. Backup funksionon pĂ«rmes (nĂ« rastin e NetApp â ), kĂ«tu ka disa veçori: numri maksimal i pikave inkrementale Ă«shtĂ« 9, pas tĂ« cilave detyrohet njĂ« kopje rezervĂ« e plotĂ«.
Si përfundim
Këto ishin vetëm risitë më të mëdha në fushën e kopjimeve rezervë mbi kasetë në VBR 9.5 Update 4. Ndryshimet e tjera do të renditen:
- mundësia për të përcaktuar rendin e burimeve dhe skedarëve në punët e kasetës;
- shtuar roli i Operatorit të Kasetës (përdoruesi mund të bëjë gjithçka, përveç rikuperimit nga kasetat - për këtë ka Operatorin e Rikuperimit);
- shtuar maskat e plota për përfshirje/përjashtim në punën e kasetës me skedarë (përveç NDMP);
- përmirësuar rikuperimi në punën e kasetës me skedarë (folderi rikuperohet me ato skedarë që ishin aty në momentin e kopjimit rezervë, jo me të gjithë ata që kanë qenë ndonjëherë gjatë gjithë historisë së kopjimeve rezervë - një veçori shumë e kërkuar, për të thënë të vërtetën);
- rritur shpejtësinë e rikuperimit të një numri shumë të madh skedarësh nga kasetat;
- përmirësuar algoritmi i zgjedhjes së kasetës së ardhshme për shkrim, në veçanti, duke konsideruar sasinë e të dhënave të shkruara/lexuara gjatë gjithë jetës së saj, marrim më të rejnë;
- përmirësuar stabilitetin e produktit.
Linqe të dobishme
Për ndryshim, do të sjell disa lidhje edhe në burimet në gjuhën ruse:
- Dhe kthyer nĂ« vendin e saj tĂ« zakonshĂ«m, video pĂ«rmbledhĂ«se «Si funksionon» (me tĂ« vĂ«rtetĂ«, pĂ«r momentin nĂ« anglisht) â mund ta shikoni . Rreth kasetave flitet nĂ« slajdet 95 â 102.
Burimi: habr.com
