{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Capacity Tier (alebo ako ho naz\u00fdvame u n\u00e1s vo vime \u2014 kaptir) sa objavil u\u017e za \u010dias Veeam Backup and Replication 9.5 Update 4 pod menom Archive Tier. My\u0161lienka, ktor\u00e1 za n\u00edm stoj\u00ed, je umo\u017eni\u0165 presun podpory, ktor\u00e9 vypadli z takzvan\u00e9ho opera\u010dn\u00e9ho okna obnovy, do objektov\u00fdch \u00falo\u017e\u00edsk. To pom\u00e1halo uvo\u013eni\u0165 miesto na disku t\u00fdm pou\u017e\u00edvate\u013eom, ktor\u00ed ho mali m\u00e1lo. T\u00e1to mo\u017enos\u0165 sa naz\u00fdva Move Mode.<\/p>\n<p>Na vykonanie tohto jednoduch\u00e9ho (ako sa zd\u00e1) \u00fakonu sta\u010dilo splni\u0165 dve podmienky: v\u0161etky body pres\u00favan\u00e9ho z\u00e1lohovania museli by\u0165 mimo vy\u0161\u0161ie uveden\u00e9ho opera\u010dn\u00e9ho okna obnovy, ktor\u00e9 je zadan\u00e9 v\u00fdslovne v UI. A druh\u00e1: re\u0165azec mus\u00ed by\u0165 v takzvanom \u201epe\u010datnom stave\u201c (sealed backup chain alebo Inactive Backup Chain). To znamen\u00e1, \u017ee v priebehu \u010dasu v tejto re\u0165azi nedoch\u00e1dza k zmen\u00e1m.<\/p>\n<p>Ale vo VBR v10 sa koncept doplnil o nov\u00e9 funkcie \u2014 objavil sa Copy Mode, Sealed Mode a vec so zlo\u017eit\u00fdm n\u00e1zvom Immutability.<\/p>\n<p>O t\u00fdchto fascinuj\u00facich veciach budeme dnes hovori\u0165. Najprv o tom, ako to fungovalo vo VBR9.5u4, a potom o zmen\u00e1ch v desiatej verzii.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA nech ma zbavia kritici \u010dist\u00e9ho jazyka, ale pr\u00edli\u0161 ve\u013ea term\u00ednov nemo\u017eno prelo\u017ei\u0165.<br \/>\nTak\u017ee tu bude mno\u017estvo anglicizmov.<br \/>\nA ve\u013ea gifiek. <br \/>\nA obr\u00e1zkov.<\/p>\n<ul>\n<li>Bez ak\u00fdchko\u013evek \u013eutovan\u00ed. Autor \u010dl\u00e1nku.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Ako bolo<\/h1>\n<p>\nTak\u017ee za\u010dnime anal\u00fdzou opera\u010dn\u00e9ho okna obnovy a sealed backup (alebo ako sa naz\u00fdvaj\u00fa v dokument\u00e1cii Inactive Backup Chain). Bez ich porozumenia nem\u00f4\u017eeme vysvetli\u0165 \u010falej.<\/p>\n<p>Ako vid\u00edme na obr\u00e1zku, m\u00e1me nejak\u00fd z\u00e1lohovac\u00ed re\u0165azec s blokmi \u00fadajov, ktor\u00fd sa nach\u00e1dza na Performance tier SOBR reposit\u00e1ra, ku ktor\u00e9mu je pripojen\u00fd Capacity Tier. Na\u0161e okno opera\u010dnej z\u00e1lohy trv\u00e1 tri dni.<\/p>\n<p>V s\u00falade s t\u00fdm, v\u00edkendov\u00fd .vbk uzatv\u00e1ra predch\u00e1dzaj\u00faci re\u0165azec, ktor\u00e9ho okno je nastaven\u00e9 na tri dni. A tak m\u00f4\u017eeme bez ob\u00e1v za\u010da\u0165 pres\u00fava\u0165 do kapacity tier v\u0161etko, \u010do je star\u0161ie ako tieto tri dni.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAle \u010do presne sa rozumelo pod sealed re\u0165azcom a \u010do sa mohlo posla\u0165 do kapacity tier v update 4?<\/p>\n<p>Pre Forward Incremental je znakom pe\u010datenia re\u0165azca vytvorenie novej plnej z\u00e1lohy. A nez\u00e1le\u017e\u00ed na tom, ako sa t\u00e1to pln\u00e1 z\u00e1loha vytv\u00e1ra: ber\u00fa sa do \u00favahy syntetick\u00e9 a akt\u00edvne pln\u00e9 z\u00e1lohy.<\/p>\n<p>V pr\u00edpade Reverse s\u00fa to v\u0161etky s\u00fabory, ktor\u00e9 sa nedost\u00e1vaj\u00fa do opera\u010dn\u00e9ho okna. <\/p>\n<p>V pr\u00edpade Forward increment s rollbackmi ide o v\u0161etky rollbacky a .vbk, ak na performance extent existuje \u010fal\u0161\u00ed .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeraz sa pozrime na mo\u017enos\u0165 pr\u00e1ce s re\u0165azcami Backup Copy. Tu sa odosielali len tie, ktor\u00e9 spadali pod GFS retention. Preto\u017ee v\u0161etko, \u010do sa nach\u00e1dza v nov\u0161\u00edch re\u0165azcoch backup copy, m\u00f4\u017ee by\u0165 r\u00f4znym sp\u00f4sobom upraven\u00e9.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeraz nahliadnime pod kapotu. Tam prebieha proces naz\u00fdvan\u00fd dehydrat\u00e1cia \u2014 ponechanie pr\u00e1zdnych backupn\u00fdch s\u00faborov na extent a pres\u00favanie blokov z t\u00fdchto s\u00faborov do kapacity tier. Na optimaliz\u00e1ciu tohto procesu sa pou\u017e\u00edva takzvan\u00fd index dehydrat\u00e1cie, ktor\u00fd umo\u017e\u0148uje nekop\u00edrova\u0165 bloky, ktor\u00e9 u\u017e boli skop\u00edrovan\u00e9 do kapacity tier. <\/p>\n<p>Pozrime sa, ako to vyzer\u00e1 na pr\u00edklade: predpokladajme, \u017ee m\u00e1me .vbk, ktor\u00fd vy\u0161iel z opera\u010dn\u00e9ho okna a patr\u00ed uzamknut\u00e9mu re\u0165azcu. To znamen\u00e1, \u017ee m\u00e1me \u00fapln\u00e9 pr\u00e1vo presun\u00fa\u0165 ho do kapacity tier. V momente presunu sa vytvor\u00ed s\u00fabor metad\u00e1t v kapacite tier a bloky pres\u00favan\u00e9ho s\u00faboru. V s\u00fabore metad\u00e1t na \u00farovni odkazov je pop\u00edsan\u00e9, z ak\u00fdch blokov sa n\u00e1\u0161 s\u00fabor sklad\u00e1. V pr\u00edpade na obr\u00e1zku n\u00e1\u0161 prv\u00fd s\u00fabor pozost\u00e1va z blokov a, b, c a v metad\u00e1tach s\u00fa umiestnen\u00e9 odkazy na tieto bloky. Ke\u010f sa objav\u00ed druh\u00fd .vbk s\u00fabor, pripraven\u00fd na presun a pozost\u00e1vaj\u00faci z blokov a, b a d, analyzujeme index dehydrat\u00e1cie a ch\u00e1peme, \u017ee pres\u00fava\u0165 treba len blok d. A jeho s\u00fabor metad\u00e1t bude obsahova\u0165 odkazy na dva predch\u00e1dzaj\u00face bloky a jeden nov\u00fd.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZodpovedaj\u00faco, proces sp\u00e4tn\u00e9ho naplnenia t\u00fdchto pr\u00e1zdnych miest d\u00e1tami sa naz\u00fdva rehydrat\u00e1cia. Tu sa u\u017e pou\u017e\u00edva svoj index rehydrat\u00e1cie, ktor\u00fd sa opiera o najstar\u0161\u00ed .vbk s\u00fabor na lok\u00e1lnom performance extent. To znamen\u00e1, \u017ee ak chce pou\u017e\u00edvate\u013e vr\u00e1ti\u0165 s\u00fabor z kapacity tier, najprv vytvor\u00edme index blokov najstar\u0161ieho kompletn\u00e9ho backupu a pres\u00favame z kapacity tier len ch\u00fdbaj\u00face bloky. V pr\u00edpade, ktor\u00fd je zn\u00e1zornen\u00fd na obr\u00e1zku, aby sme rehydratovali FullBackup1.vbk pod\u013ea indexu rehydrat\u00e1cie, ch\u00fdba n\u00e1m len blok C, ktor\u00fd si berieme z kapacity tier. Ak ako kapacitu tier vystupuje cloudov\u00fd objektov\u00fd storage, umo\u017e\u0148uje to u\u0161etri\u0165 obrovsk\u00e9 peniaze.<\/p>\n<p>M\u00f4\u017ee sa zda\u0165, \u017ee t\u00e1to technol\u00f3gia je identick\u00e1 s tou, ktor\u00e1 sa pou\u017e\u00edva v WAN akceler\u00e1toroch, ale to je len zdanie. V akceler\u00e1toroch je deduplik\u00e1cia glob\u00e1lna, zatia\u013e \u010do tu sa pou\u017e\u00edva lok\u00e1lna v r\u00e1mci ka\u017ed\u00e9ho s\u00faboru pod\u013ea ur\u010dit\u00e9ho offsetu. To je sp\u00f4soben\u00e9 rozdielom v rie\u0161en\u00fdch \u00faloh\u00e1ch: tu mus\u00edme kop\u00edrova\u0165 ve\u013ek\u00e9 s\u00fabory pln\u00fdch z\u00e1loh a pod\u013ea na\u0161ich \u0161t\u00fadi\u00ed, aj ke\u010f medzi nimi prejde dlh\u00fd \u010das, tak\u00fdto algoritmus deduplik\u00e1cie poskytuje lep\u0161ie v\u00fdsledky.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAle viac indexov bohu indexov! Existuje e\u0161te aj index na obnovenie \u00fadajov! Ke\u010f spust\u00edme obnovenie stroja umiestnen\u00e9ho v kapacitnom tire, \u010d\u00edtame iba unik\u00e1tne bloky \u00fadajov, ktor\u00e9 nie s\u00fa v v\u00fdkonovom tire.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Ako sa ukazuje<\/h1>\n<p>\nNa tomto sa s \u00favodnou \u010das\u0165ou v\u0161etko kon\u010d\u00ed. Je pomerne podrobn\u00e1, ale, ako bolo uveden\u00e9 vy\u0161\u0161ie, bez t\u00fdchto podrobnost\u00ed nie je mo\u017en\u00e9 vysvetli\u0165, ako funguj\u00fa nov\u00e9 funkcie. Preto sa bez zbyto\u010dn\u00fdch predslovov presu\u0148me k prvej.<\/p>\n<h3>Re\u017eim kop\u00edrovania<\/h3>\n<p>\nZ ve\u013ekej \u010dasti je zalo\u017een\u00fd na existuj\u00facich technol\u00f3giach, av\u0161ak nesie so sebou \u00faplne odli\u0161n\u00fa logiku pou\u017e\u00edvania.\u00a0<\/p>\n<p>Cie\u013eom tohto re\u017eimu je zabezpe\u010di\u0165, aby v\u0161etky \u00fadaje umiestnen\u00e9 na lok\u00e1lnom extentu mali k\u00f3piu v kapacitnom tire.<\/p>\n<p>Ak porovn\u00e1me re\u017eimy Move a Copy, vyjde to takto:<\/p>\n<ul>\n<li>Pres\u00fava\u0165 mo\u017eno iba uzavret\u00e9 re\u0165azce. V pr\u00edpade re\u017eimu kop\u00edrovania sa odvezie \u00faplne v\u0161etko, nez\u00e1visle od toho, \u010do sa deje v z\u00e1lo\u017enej \u00falohe.<\/li>\n<li>Presunutie nastane, ke\u010f s\u00fabory prekro\u010dia hranice okna operat\u00edvnej z\u00e1lohy, zatia\u013e \u010do kop\u00edrovanie sa aktivuje okam\u017eite, hne\u010f ako sa objav\u00ed z\u00e1lo\u017en\u00fd s\u00fabor.<\/li>\n<li>Sledovanie nov\u00fdch \u00fadajov na kop\u00edrovanie prebieha neust\u00e1le, zatia\u013e \u010do pres\u00favanie sa sp\u00fa\u0161\u0165alo raz za 4 hodiny.<\/li>\n<\/ul>\n<p>\nPri zva\u017eovan\u00ed nov\u00e9ho re\u017eimu navrhujem \u00eds\u0165 od jednoduch\u00fdch pr\u00edkladov k zlo\u017eit\u00fdm.<\/p>\n<p>V najz\u00e1kladnej\u0161om pr\u00edpade sa jednoducho objavuj\u00fa nov\u00e9 s\u00fabory s inkrementmi a my ich jednoducho kop\u00edrujeme do kapacitn\u00e9ho tire. Bez oh\u013eadu na to, ak\u00fd re\u017eim sa pou\u017e\u00edva v z\u00e1lo\u017enej \u00falohe, bez oh\u013eadu na to, \u010di patr\u00ed k uzavretej \u010dasti re\u0165azca alebo nie, bez oh\u013eadu na to, \u010di vypr\u0161alo na\u0161e operat\u00edvne okno. Jednoducho sme vzali a skop\u00edrovali.<\/p>\n<p>Proces, ktor\u00fd za t\u00fdm stoj\u00ed, je st\u00e1le dehydrat\u00e1cia, ako bolo op\u00edsan\u00e9 vy\u0161\u0161ie. V re\u017eime kop\u00edrovania sa tie\u017e sleduje, aby sme nekop\u00edrovali bloky, ktor\u00e9 u\u017e s\u00fa na na\u0161om \u00falo\u017eisku. Jedin\u00fd rozdiel je v tom, \u017ee ak v re\u017eime presunu nahr\u00e1dzame skuto\u010dn\u00e9 s\u00fabory s\u00fabormi n\u00e1hradami, tu ich nijako nemen\u00edme a nech\u00e1vame v\u0161etko tak, ako je. Inak je to rovnak\u00fd index dehydrat\u00e1cie, ktor\u00fd sa starostlivo sna\u017e\u00ed \u0161etri\u0165 va\u0161e peniaze a \u010das.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVyz\u00fdva ot\u00e1zku \u2014 ak sa pozrieme na UI, tak tam je mo\u017enos\u0165 vybra\u0165 obe mo\u017enosti naraz. Ako bude fungova\u0165 tak\u00fd kombinovan\u00fd re\u017eim?<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPo\u010fme sa na to pozrie\u0165.<\/p>\n<p>Za\u010diatok je \u0161tandardn\u00fd: vytvor\u00ed sa z\u00e1lohovac\u00ed s\u00fabor a okam\u017eite sa skop\u00edruje. K nemu sa vytvor\u00ed inkrement a tie\u017e sa skop\u00edruje. Takto sa to deje, k\u00fdm si uvedom\u00edme, \u017ee s\u00fabory vy\u0161li z n\u00e1\u0161ho opera\u010dn\u00e9ho okna a objavila sa uzavret\u00e1 re\u0165az. V tomto momente vykon\u00e1vame oper\u00e1ciu dehydrat\u00e1cie a nahr\u00e1dzame tieto s\u00fabory n\u00e1hradami. Samozrejme, znova na kapacite tier ni\u010d nekop\u00edrujeme.<\/p>\n<p>Za cel\u00fa t\u00fato fascinuj\u00facu logiku zodpoved\u00e1 iba jedno za\u0161krtnutie v rozhran\u00ed: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>A na\u010do n\u00e1m je tento Copy re\u017eim? <\/h3>\n<p>\nE\u0161te lep\u0161ie je preformulova\u0165 ot\u00e1zku takto \u2014 pred ak\u00fdmi rizikami sa chr\u00e1nime jeho pomocou? Ak\u00fd probl\u00e9m n\u00e1m pom\u00e1ha vyrie\u0161i\u0165?<\/p>\n<p>Odpove\u010f je zjavn\u00e1: samozrejme, je to obnova d\u00e1t. Ak m\u00e1me na objektovom \u00falo\u017eisku \u00fapln\u00fa k\u00f3piu lok\u00e1lnych d\u00e1t, tak je jedno, \u010do sa stane s na\u0161ou produkciou, v\u017edy m\u00f4\u017eeme obnovi\u0165 d\u00e1ta zo s\u00faborov umiestnen\u00fdch v podmienenom Amazone.<\/p>\n<p>Preto si prejdime mo\u017en\u00e9 scen\u00e1re, od najjednoduch\u0161ieho po zlo\u017eitej\u0161\u00ed.<\/p>\n<p>Najjednoduch\u0161ia pohroma, ktor\u00e1 n\u00e1m m\u00f4\u017ee spadn\u00fa\u0165 na hlavu \u2014 je nedostupnos\u0165 jedn\u00e9ho zo s\u00faborov v z\u00e1lohovacej re\u0165azi.<\/p>\n<p>Smutnej\u0161\u00ed pr\u00edbeh \u2014 m\u00e1me rozbit\u00fd jeden z extentov n\u00e1\u0161ho SOBR repozit\u00e1ra.<\/p>\n<p>E\u0161te hor\u0161ie je, ke\u010f je cel\u00fd SOBR repozit\u00e1r nedostupn\u00fd, ale funguje kapacita tier.<br \/>\nA je to \u00faplne zl\u00e9 \u2014 ke\u010f zomrie z\u00e1lohovac\u00ed server a va\u0161a prv\u00e1 t\u00fa\u017eba je pok\u00fasi\u0165 sa dobehn\u00fa\u0165 kanadsk\u00fa hranicu za desa\u0165 min\u00fat.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA teraz si rozoberme ka\u017ed\u00fa situ\u00e1ciu osobitne.<\/p>\n<p>Ke\u010f strat\u00edme jeden (a aj nieko\u013eko) z\u00e1lo\u017en\u00fdch s\u00faborov, sta\u010d\u00ed spusti\u0165 proces preskenuj\u00faci repozit\u00e1r a straten\u00fd s\u00fabor bude nahraden\u00fd pr\u00e1zdnym s\u00faborom. A pomocou procesu rehydrat\u00e1cie (o ktorom sme hovorili na za\u010diatku \u010dl\u00e1nku) si pou\u017e\u00edvate\u013e m\u00f4\u017ee stiahnu\u0165 d\u00e1ta z kapacitn\u00e9ho \u00falo\u017eiska do miestneho \u00falo\u017eiska.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeraz je situ\u00e1cia zlo\u017eitej\u0161ia. Predpokladajme, \u017ee na\u0161u SOBR tvoria dva extenzory, ktor\u00e9 pracuj\u00fa v re\u017eime v\u00fdkonu, a teda na\u0161e .vbk a .vib s\u00fa rozlo\u017een\u00e9 po nich dos\u0165 nerovnomerne. A v nejakom okamihu jeden z extenzorov prestane fungova\u0165 a pou\u017e\u00edvate\u013e potrebuje urgentne obnovi\u0165 stroj, ktor\u00e9ho \u010das\u0165 d\u00e1t le\u017e\u00ed pr\u00e1ve na tomto extenzore. <\/p>\n<p>Pou\u017e\u00edvate\u013e spust\u00ed sprievodcu obnovou, vyberie bod, na ktor\u00fd chce obnovi\u0165, a sprievodca po\u010das pr\u00e1ce zist\u00ed, \u017ee v\u0161etky potrebn\u00e9 d\u00e1ta na obnovu nem\u00e1 lok\u00e1lne, a preto ich treba stiahnu\u0165 z kapacitn\u00e9ho \u00falo\u017eiska. Pri tom bloky, ktor\u00e9 zostali na miestnom \u00falo\u017eisku, sa s\u0165ahova\u0165 z cloudu nebud\u00fa. Nech \u017eije restore index (\u00e1no, o \u0148om sme tie\u017e hovorili na za\u010diatku \u010dl\u00e1nku).<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodtyp tohto pr\u00edpadu je, ke\u010f je cel\u00fd SOBR repozit\u00e1r nedostupn\u00fd. V takom pr\u00edpade nem\u00e1me \u010do kop\u00edrova\u0165 z miestnych \u00falo\u017e\u00edsk, a v\u0161etky bloky sa stiahnu z cloudu.<\/p>\n<p>A najzauj\u00edmavej\u0161ia situ\u00e1cia je, ke\u010f zomrie z\u00e1lohovac\u00ed server. Tu s\u00fa dve mo\u017enosti: admin bol \u0161ikovn\u00fd a robil konfigura\u010dn\u00e9 z\u00e1lohy, a admin s\u00e1m sebe zl\u00fd Buratino a nerobil konfigura\u010dn\u00fa z\u00e1lohu.<\/p>\n<p>V prvom pr\u00edpade mu bude sta\u010di\u0165 jednoducho niekde spusti\u0165 \u010dist\u00fa in\u0161tal\u00e1ciu VBR a obnovi\u0165 jeho datab\u00e1zu zo z\u00e1lohy \u0161tandardn\u00fdmi prostriedkami. Na konci tohto procesu sa v\u0161etko vr\u00e1ti do norm\u00e1lu. Alebo sa obnov\u00ed pod\u013ea jedn\u00e9ho z vy\u0161\u0161ie uveden\u00fdch scen\u00e1rov.<\/p>\n<p>Ak v\u0161ak administr\u00e1tor alebo s\u00e1m sebe nepriate\u013e, alebo aj z\u00e1loha konfigur\u00e1cie postihla m\u00fdtick\u00e1 ne\u00fasp\u011bch, ani v takomto pr\u00edpade ho nenech\u00e1me napospas osudu. Pre tento pr\u00edpad sme zaviedli nov\u00fa proced\u00faru, ktor\u00e1 sa vol\u00e1 Import Object Storage. Umo\u017e\u0148uje ob\u00eds\u0165 proces manu\u00e1lneho obnovenia SOBR \u00falo\u017eiska a jeho pripojenia k kapacite, a namiesto toho jednoducho prida\u0165 objektov\u00e9 \u00falo\u017eisko do rozhrania Vima a spusti\u0165 proced\u00faru Import Storage Repository. Jedin\u00e9, \u010do m\u00f4\u017ee st\u00e1\u0165 medzi vami a va\u0161imi z\u00e1lohami, je po\u017eiadavka zada\u0165 heslo, ak boli va\u0161e z\u00e1lohy \u0161ifrovan\u00e9.<\/p>\n<p>Na tomto sme o m\u00f3de Copy Mode a prech\u00e1dzame k<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nHlavn\u00e1 my\u0161lienka je tak\u00e1, \u017ee na vybranom rozsahu SOBR \u00falo\u017eiska sa nem\u00f4\u017eu objavova\u0165 nov\u00e9 z\u00e1lohy. Do verzie 10 sme mali iba Maintenance Mode, ktor\u00fd \u00faplne zakazoval ak\u00fako\u013evek \u010dinnos\u0165 s \u00falo\u017eiskom. Ak\u00fdsi hardcore re\u017eim vypnutia \u00falo\u017eiska, kde bola dostupn\u00e1 len tla\u010didlo Evacuate, ktor\u00e1 raz prev\u00e1\u017eala z\u00e1lohy na in\u00fd rozsah.<\/p>\n<p>A Sealed Mode je ak\u00e1si \u201ejemn\u00e1\u201c alternat\u00edva: zakazujeme vytv\u00e1ranie nov\u00fdch z\u00e1loh a postupne odstra\u0148ujeme star\u00e9 pod\u013ea zvolen\u00e9ho reten\u010dn\u00e9ho obdobia, ale po\u010das procesu nestr\u00e1came mo\u017enos\u0165 obnovova\u0165 sa z uchov\u00e1van\u00fdch bodov. Ve\u013emi u\u017eito\u010dn\u00e1 vec, ke\u010f sa n\u00e1m bu\u010f kon\u010d\u00ed \u017eivotnos\u0165 zariadenia a je potrebn\u00e9 ho vymeni\u0165, alebo ho jednoducho treba uvo\u013eni\u0165 pre nie\u010do d\u00f4le\u017eitej\u0161ie, a niet kam v\u0161etko raz prenies\u0165. Alebo ho nemo\u017eno odstr\u00e1ni\u0165. <\/p>\n<p>Princ\u00edp \u010dinnosti je teda pomerne jednoduch\u00fd: je potrebn\u00e9 zak\u00e1za\u0165 v\u0161etky oper\u00e1cie z\u00e1pisu (objavovanie nov\u00fdch d\u00e1t), pri\u010dom si ponech\u00e1vanie \u010d\u00edtania (obnovenia) a mazania (reten\u010dn\u00e9ho obdobia).<\/p>\n<p>Obe re\u017eimy je mo\u017en\u00e9 pou\u017e\u00edva\u0165 s\u00fa\u010dasne, ale treba ma\u0165 na pam\u00e4ti, \u017ee \u00fadr\u017eba m\u00e1 vy\u0161\u0161iu prioritu.<\/p>\n<p>Ako pr\u00edklad si vezmime SOBR, ktor\u00fd sa sklad\u00e1 z dvoch rozsahov. Predpokladajme, \u017ee prv\u00e9 \u0161tyri dni sme vytv\u00e1rali z\u00e1lohy v re\u017eime Forward Forever Incremental, a potom sme rozsah uzavreli. To vedie k tomu, \u017ee iniciujeme vytvorenie nov\u00e9ho akt\u00edvneho pln\u00e9ho na druhom dostupnom rozsahu. Ak je n\u00e1\u0161 reten\u010dn\u00fd \u010das \u0161tyri, potom ke\u010f cel\u00fd re\u0165azec umiestnen\u00fd na uzavretom rozsahu presiahne jeho hranice, m\u00f4\u017ee by\u0165 s \u010dist\u00fdm svedom\u00edm odstr\u00e1nen\u00fd.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nExistuj\u00fa situ\u00e1cie, ke\u010f sa odstr\u00e1nenie uskuto\u010dn\u00ed sk\u00f4r. Napr\u00edklad, ide o Forward incremental s periodick\u00fdmi full backupmi. Ak sa po\u010das prv\u00fdch dvoch dn\u00ed vytvorili full backupy a vo \u0161tvrtok sa rozhodneme uzavrie\u0165 repozit\u00e1r, tak v piatok, ke\u010f sa vytvor\u00ed nov\u00fd full backup, s\u00fabor z pondelka bude odstr\u00e1nen\u00fd, preto\u017ee k tomuto bodu nie s\u00fa \u017eiadne z\u00e1vislosti. A samotn\u00fd bod nie je z\u00e1visl\u00fd na nikom. Potom \u010dak\u00e1me, k\u00fdm sa vytvor\u00ed \u0161tyri body na dostupnom extente a odstr\u00e1nime zost\u00e1vaj\u00face tri, ktor\u00e9 nem\u00f4\u017eu by\u0165 odstr\u00e1nen\u00e9 nez\u00e1visle jedno od druh\u00e9ho.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS Reverse Incremental je to jednoduch\u0161ie. V \u0148om najstar\u0161ie body nie s\u00fa na ni\u010d z\u00e1visl\u00e9 a m\u00f4\u017eu by\u0165 v pokoji odstr\u00e1nen\u00e9. Preto, akon\u00e1hle je vytvoren\u00fd nov\u00fd .vbk na novom extente, star\u00e9 .vrb bud\u00fa postupne odstra\u0148ovan\u00e9.<\/p>\n<p>Mimochodom, pre\u010do ka\u017ed\u00fd raz vytv\u00e1rame nov\u00fd .vbk: ak by sa nevytv\u00e1ral, ale pokra\u010dovalo by sa v starej re\u0165azci inkrementov, star\u00fd .vbk by visel nekone\u010dne dlho v akomko\u013evek re\u017eime, \u010do by br\u00e1nilo jeho odstr\u00e1neniu. Preto sa rozhodlo, \u017ee akon\u00e1hle je extente uzavret\u00e9, vytv\u00e1rame full backup na vo\u013enom extente.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZlo\u017eitej\u0161ie je to s capacity tier. <\/p>\n<p>Sk\u00f4r skontrolujme copy mode. Predpokladajme, \u017ee sme \u0161tyri dni akt\u00edvne vytv\u00e1rali backupy a potom bol capacity tier uzavret\u00fd. Ni\u010d neodstra\u0148ujeme, ale trpezlivo dr\u017e\u00edme retention, po \u010dom odstr\u00e1nime \u00fadaje z capacity tier.<\/p>\n<p>Pribli\u017ene to ist\u00e9 sa deje pri move mode \u2014 \u010dakan\u00edm na retention, odstr\u00e1nime star\u00e9 v lok\u00e1lnom \u00falo\u017eisku a \u00fadaje ulo\u017een\u00e9 v object storage.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZauj\u00edmav\u00fd pr\u00edklad s Forever forward incremental. Nastav\u00edme retention na tri body a za\u010dneme v pondelok robi\u0165 backupy, ktor\u00e9 sa spo\u013eahlivo kop\u00edruj\u00fa do cloudu. Po uzavret\u00ed \u00falo\u017eiska sa backupy na\u010falej vytv\u00e1raj\u00fa, dodr\u017eiavaj\u00fac tri body, ale \u00fadaje ulo\u017een\u00e9 v capacity tier zost\u00e1vaj\u00fa z\u00e1visl\u00e9 a nem\u00f4\u017eu by\u0165 odstr\u00e1nen\u00e9. Preto \u010dak\u00e1me na \u0161tvrtok, ke\u010f n\u00e1\u0161 .vbk prekro\u010d\u00ed r\u00e1mce retention, a a\u017e potom pokojne odstr\u00e1nime cel\u00fa ulo\u017een\u00fa re\u0165az.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA mal\u00e1 pozn\u00e1mka: v\u0161etky pr\u00edklady s\u00fa uk\u00e1zan\u00e9 s jedn\u00fdm strojom. Ak m\u00e1te vo backup-e viacero, retention sa bude l\u00ed\u0161i\u0165 v z\u00e1vislosti od toho, \u010di bol vykonan\u00fd Active Full alebo nie.<\/p>\n<p>Na tom, v podstate, je v\u0161etko. Tak\u017ee prejdeme k najhardcore funkcii \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nAko pri predch\u00e1dzaj\u00facich bodoch, prv\u00e9, o \u010dom hovor\u00edme, je probl\u00e9m, ktor\u00fd t\u00e1to funkcia rie\u0161i. Akon\u00e1hle uvo\u013en\u00edme na\u0161e z\u00e1lohy na uchov\u00e1vanie, vznik\u00e1 siln\u00e1 chu\u0165 zabezpe\u010di\u0165 ich ochranu, teda fyzicky zabr\u00e1ni\u0165 ich odstr\u00e1neniu a ak\u00fdmko\u013evek \u00faprav\u00e1m po\u010das stanoven\u00e9ho retentionu. To zah\u0155\u0148a aj spr\u00e1vcov, aj pod ich root \u00fa\u010dtami. To umo\u017e\u0148uje chr\u00e1ni\u0165 ich pred n\u00e1hodn\u00fdm alebo \u00famyseln\u00fdm po\u0161koden\u00edm. T\u00ed, ktor\u00ed pracuj\u00fa s AWS, mohli narazi\u0165 na podobn\u00fa funkciu nazvan\u00fa Object Lock.<\/p>\n<p>Teraz sa pozrime na re\u017eim v obecn\u00fdch slov\u00e1ch a potom sa preh\u013abime do detailov. V na\u0161om pr\u00edklade bude Immutability zapnut\u00e9 pre n\u00e1\u0161 kapacitu s retentionom \u0161tyri dni. A v z\u00e1lohe je zapnut\u00fd re\u017eim Copy.<\/p>\n<p>Immutability nijako neinteraguje s celkov\u00fdm retentionom. Napr\u00edklad, neprid\u00e1va dodato\u010dn\u00e9 body alebo nie\u010do tak\u00e9. Po\u010das \u0161tyroch dn\u00ed nem\u00f4\u017ee osoba odstr\u00e1ni\u0165 s\u00fabory z\u00e1loh. Ak sa v pondelok vykon\u00e1 z\u00e1loha, s\u00fabor sa d\u00e1 odstr\u00e1ni\u0165 a\u017e v piatok.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV\u0161etky predt\u00fdm vysvetlen\u00e9 koncepty dehydrat\u00e1cie, indexov a metad\u00e1t funguj\u00fa presne tak ist\u00fdm sp\u00f4sobom. Ale s jednou podmienkou \u2014 blok sa vystavuje nielen pre d\u00e1ta, ale aj pre metad\u00e1ta. To sa rob\u00ed pre pr\u00edpad, \u017ee z\u00e1ludn\u00fd \u00fato\u010dn\u00edk sa rozhodne vymaza\u0165 na\u0161u datab\u00e1zu metad\u00e1t, a aby bloky s d\u00e1tami sa nezmenili na bezcenn\u00fa bin\u00e1rnu ka\u0161u.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA teraz nastal skvel\u00fd moment na vysvetlenie na\u0161ej technol\u00f3gie generovania blokov. Alebo block generation. Na to si predstav\u00edme situ\u00e1ciu, ktor\u00e1 k jej vzniku viedla.<\/p>\n<p>Zoberme si \u010dasov\u00fa os s \u0161iestimi d\u0148ami a zdola budeme zaznamen\u00e1va\u0165 \u010das o\u010dak\u00e1van\u00e9ho vypr\u0161ania immutability. V prv\u00fd de\u0148 vytvor\u00edme s\u00fabor, ktor\u00fd pozost\u00e1va z bloku a a jeho metad\u00e1t. Ak je immutability nastaven\u00e9 na tri dni, logicky by sa dalo predpoklada\u0165, \u017ee \u0161tvrt\u00fd de\u0148 bud\u00fa d\u00e1ta odomknut\u00e9 a odstr\u00e1nen\u00e9. Na druh\u00fd de\u0148 prid\u00e1me nov\u00fd file2, pozost\u00e1vaj\u00faci z bloku b s rovnak\u00fdmi nastaveniami. Blok a by mal by\u0165 st\u00e1le odstr\u00e1nen\u00fd na \u0161tvrt\u00fd de\u0148. Ale na tret\u00ed de\u0148 sa stane nie\u010do hrozn\u00e9 \u2014 vytvor\u00ed sa s\u00fabor File3, ktor\u00fd obsahuje nov\u00fd blok d a odkaz na star\u00fd blok a. To znamen\u00e1, \u017ee pre blok a by mal by\u0165 jeho flag immutability resetovan\u00fd na nov\u00fd \u010dasov\u00fd r\u00e1mec, ktor\u00fd sa pos\u00fava na \u0161iesty de\u0148. A tu nast\u00e1va probl\u00e9m \u2014 v re\u00e1lnych z\u00e1lohe t\u00fdchto blokov vznik\u00e1 obrovsk\u00e9 mno\u017estvo. A aby sme im pred\u013a\u017eili obdobie immutability, mus\u00edme zaka\u017ed\u00fdm uskuto\u010dni\u0165 obrovsk\u00e9 mno\u017estvo po\u017eiadaviek. A v skuto\u010dnosti by to bol takmer nekone\u010dn\u00fd denn\u00fd proces, preto\u017ee s ve\u013ekou pravdepodobnos\u0165ou pri ka\u017edom kop\u00edrovan\u00ed budeme nach\u00e1dza\u0165 ve\u013ek\u00e9 bal\u00edky deduplikovan\u00fdch blokov. A \u010do znamen\u00e1 ve\u013ek\u00e9 mno\u017estvo po\u017eiadaviek od poskytovate\u013eov object storage? Presne! Obrovsk\u00fd \u00fa\u010det na konci mesiaca.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA aby sme ne\u00fa\u010dtovali za slobodn\u00e9 peniaze svojim ob\u013e\u00faben\u00fdm klientom, bol vymyslen\u00fd mechanizmus block generation. Toto je dodato\u010dn\u00e9 obdobie, ktor\u00e9 prid\u00e1vame k stanoven\u00e9mu obdobiu immutability. V ni\u017e\u0161ie uvedenom pr\u00edklade toto obdobie trv\u00e1 dva dni. Ale to je len na pr\u00edklad. V skuto\u010dnosti tam pou\u017e\u00edvaj\u00fa svoju vlastn\u00fa formulu, ktor\u00e1 d\u00e1va pribli\u017ene desa\u0165 \u010fal\u0161\u00edch dn\u00ed pri mesa\u010dnom locku. <\/p>\n<p>Pokra\u010dujme s rovnakou situ\u00e1ciou, ale u\u017e s generovan\u00edm blokov. V prv\u00fd de\u0148 vytv\u00e1rame file1 z bloku a a metad\u00e1t. S\u010d\u00edtame obdobie gener\u00e1ci\u00ed a immutability \u2014 to znamen\u00e1, \u017ee mo\u017enos\u0165 odstr\u00e1ni\u0165 s\u00fabor bude na \u0161iesty de\u0148. Ak v druh\u00fd de\u0148 vytvor\u00edme File2, ktor\u00fd bude obsahova\u0165 blok b a odkaz na blok a, predpokladan\u00fd d\u00e1tum odstr\u00e1nenia sa nezmen\u00ed. Ten ost\u00e1va na \u0161iesty de\u0148. Sna\u017e\u00edme sa t\u00fdmto sp\u00f4sobom \u0161etri\u0165 peniaze na po\u010dte po\u017eiadaviek. Jedin\u00e1 situ\u00e1cia, kedy m\u00f4\u017ee by\u0165 term\u00edn posunut\u00fd, je, ak vypr\u0161alo obdobie gener\u00e1cie. Teda, ak na tret\u00ed de\u0148 nov\u00fd File3 bude obsahova\u0165 odkaz na blok a, tak sa prid\u00e1 gener\u00e1cia 2, preto\u017ee Gen1 u\u017e vypr\u0161alo. O\u010dak\u00e1van\u00fd d\u00e1tum odstr\u00e1nenia bloku a sa presunie na \u00f4smy de\u0148. To n\u00e1m umo\u017e\u0148uje dramaticky zn\u00ed\u017ei\u0165 po\u010det po\u017eiadaviek na pred\u013a\u017eenie \u017eivotnosti deduplikovan\u00fdch blokov, \u010do \u0161etr\u00ed ve\u013ea pe\u0148az\u00ed klientom.<\/p>\n<p><img decoding=\"async\" alt=\"\u010co sa zmenilo v Capacity Tier, ke\u010f Veeam pre\u0161iel na v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSamotn\u00e1 technol\u00f3gia je dostupn\u00e1 pou\u017e\u00edvate\u013eom S3 a S3-kompatibiln\u00e9ho hardv\u00e9ru, ktor\u00e9ho v\u00fdrobcovia zaru\u010duj\u00fa, \u017ee ich implement\u00e1cia sa nel\u00ed\u0161i od amazonovej. Odtia\u013e pramen\u00ed odpove\u010f na legit\u00edmnu ot\u00e1zku, pre\u010do nie je podporovan\u00fd Azure \u2014 maj\u00fa podobn\u00fa funkciu, ale funguje na \u00farovni kontajnerov, nie jednotliv\u00fdch objektov. Mimochodom, v samotnom Amazone existuje objekt lock v dvoch re\u017eimoch: compliance a governance. V druhom pr\u00edpade zost\u00e1va mo\u017enos\u0165, aby najv\u00e4\u010d\u0161\u00ed admin nad adminmi a root nad rootmi, napriek objekt locku, predsa len odstr\u00e1nil d\u00e1ta. V pr\u00edpade compliance je v\u0161etko pripevnen\u00e9 klincami a z\u00e1lohy nem\u00f4\u017ee odstr\u00e1ni\u0165 nikto. Ani admini z Amazonu (pod\u013ea ich ofici\u00e1lnych vyhl\u00e1sen\u00ed). My podporujeme pr\u00e1ve tento re\u017eim.<\/p>\n<p>\nA tradi\u010dne, trochu u\u017eito\u010dn\u00fdch odkazov:<\/p>\n<ul>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generovanie blokov<\/a><\/noindex> vo v\u0161etk\u00fdch podrobnostiach.<\/li>\n<li>V\u0161etky inform\u00e1cie o <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> v najlep\u0161ej podobe<\/li>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Kapacitn\u00e1 vrstva<\/a><\/noindex> v detailoch<\/li>\n<\/ul>\n<p>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u010co sa zmenilo v kapacitnom tieri, ke\u010f sa Veeam stal v10 | ProHoster","description":"Kapacitn\u00fd tier (alebo ako ho u n\u00e1s internne vol\u00e1me \u2014 kaptier) sa objavil u\u017e v \u010dase Veeam Backup and Replication 9.5 Update 4 pod n\u00e1zvom Archive Tier.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:49:54","updated":"2022-09-29 08:38:47","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}