{"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\/ro\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Tier-ul de Capacitate (sau cum \u00eei spunem noi intern \u2014 captir) a ap\u0103rut \u00eenc\u0103 din vremurile Veeam Backup and Replication 9.5 Update 4 sub numele de Archive Tier. Ideea din spatele acestuia este de a permite mutarea backup-urilor care au ie\u0219it din a\u0219a-numitul fereastr\u0103 de restaurare opera\u021bional\u0103, pe stoc\u0103ri obiectuale. Acest lucru a ajutat la eliberarea spa\u021biului pe disc pentru utilizatorii care aveau limita de stocare. Aceast\u0103 op\u021biune se nume\u0219te Mod de Mutare.<\/p>\n<p>Pentru a realiza aceast\u0103 ac\u021biune simpl\u0103 (a\u0219a cum pare) erau suficiente dou\u0103 condi\u021bii: toate punctele din backup-ul mutat trebuie s\u0103 fie \u00een afara ferestrei de restaurare opera\u021bional\u0103 men\u021bionate anterior, care este definit\u0103 explicit \u00een UI. \u0218i a doua: lan\u021bul trebuie s\u0103 fie \u00een a\u0219a-numitul \u201aformat sigilat\u2019 (sealed backup chain sau Inactive Backup Chain). Aceasta \u00eenseamn\u0103 c\u0103, \u00een timp, \u00een acest lan\u021b nu se produc modific\u0103ri.<\/p>\n<p>Dar \u00een VBR v10, conceptul a fost completat cu noi func\u021bionalit\u0103\u021bi \u2014 a ap\u0103rut Mod de Copiere, Mod Sigilat \u0219i o op\u021biune cu un nume greu de pronun\u021bat \u2014 Imutabilitate.<\/p>\n<p>Ast\u0103zi ne vom axa asupra acestor lucruri fascinante. Mai \u00eent\u00e2i vom discuta despre cum func\u021biona \u00een VBR9.5u4, iar apoi despre schimb\u0103rile din versiunea zece.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u0218i, v\u0103 rog s\u0103 m\u0103 ierta\u021bi, ap\u0103r\u0103torii limbii curate, dar prea mul\u021bi termeni sunt imposibil de tradus.<br \/>\nA\u0219a c\u0103 aici vor fi mul\u021bi anglicisme.<br \/>\n\u0218i multe GIF-uri. <br \/>\n\u0218i poze.<\/p>\n<ul>\n<li>F\u0103r\u0103 niciun regret. Autorul articolului.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Cum a fost<\/h1>\n<p>\nA\u0219adar, s\u0103 \u00eencepem cu analiza ferestrei de restaurare opera\u021bional\u0103 \u0219i a backup-ului sigilat (sau cum sunt acestea numite \u00een documenta\u021bie Inactive Backup Chain). F\u0103r\u0103 \u00een\u021belegerea lor, nu putem continua explica\u021biile.<\/p>\n<p>Dup\u0103 cum vedem \u00een imagine, avem un anumit lan\u021b de backup cu blocuri de date, care este situat \u00een repositoriul Performance tier SOBR, la care este conectat Tier-ul de Capacitate. Fereastra noastr\u0103 de backup opera\u021bional este de trei zile.<\/p>\n<p>Prin urmare, backup-ul .vbk creat luni sigileaz\u0103 lan\u021bul anterior, al c\u0103rui fereastr\u0103 este stabilit\u0103 pe trei zile. A\u0219adar, putem \u00eencepe s\u0103 mut\u0103m \u00een Capacity Tier tot ce este mai vechi de aceste trei zile.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDar ce \u00eenseamn\u0103 exact lan\u021bul sigilat \u0219i ce putea fi trimis \u00een Capacity Tier \u00een update 4?<\/p>\n<p>Pentru Forward Incremental, semnul sigil\u0103rii lan\u021bului este crearea unei noi backup-uri complete. Indiferent de modul \u00een care este ob\u021binut\u0103 aceast\u0103 backup complet\u0103: sunt considerate at\u00e2t backup-urile sintetice complete, c\u00e2t \u0219i cele active.<\/p>\n<p>\u00cen cazul Reverse, toate fi\u0219ierele care nu se \u00eencadreaz\u0103 \u00een fereastra opera\u021bional\u0103 sunt incluse. <\/p>\n<p>\u00cen cazul Forward increment cu rollbacks, toate rollback-urile \u0219i .vbk sunt p\u0103strate, dac\u0103 exist\u0103 un alt .vbk pe extinderea de performan\u021b\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAcum s\u0103 analiz\u0103m varianta de lucru cu lan\u021burile de Backup Copy. Aici au fost luate \u00een considerare doar cele incluse \u00een reten\u021bia GFS. Pentru c\u0103 tot ceea ce se afl\u0103 \u00een lan\u021burile mai recente de backup copy poate fi modificat \u00een diverse moduri.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAcum s\u0103 arunc\u0103m o privire sub capot\u0103. Acolo are loc un proces numit dehidratare \u2014 l\u0103sarea fi\u0219ierelor de backup goale pe extindere \u0219i mutarea blocurilor din aceste fi\u0219iere \u00een tirul de capacitate. Pentru a optimiza acest proces, se folose\u0219te a\u0219a-numitul index de dehidratare, care permite evitarea copierii blocurilor care au fost deja copiate \u00een tirul de capacitate. <\/p>\n<p>S\u0103 vedem cum arat\u0103 acest lucru pe un exemplu: s\u0103 presupunem c\u0103 avem un .vbk care a ie\u0219it din fereastra opera\u021bional\u0103 \u0219i apar\u021bine unui lan\u021b sigilat. Asta \u00eenseamn\u0103 c\u0103 avem dreptul complet s\u0103-l mut\u0103m \u00een tirul de capacitate. \u00cen momentul mut\u0103rii, se creeaz\u0103 un fi\u0219ier de metadate \u00een tirul de capacitate \u0219i blocurile fi\u0219ierului mutat. \u00cen fi\u0219ierul de metadate, la nivel de referin\u021be, este descris din ce blocuri este format fi\u0219ierul nostru. \u00cen cazul din imagine, primul nostru fi\u0219ier const\u0103 din blocurile a, b, c, iar \u00een metadate sunt plasate referin\u021bele c\u0103tre aceste blocuri. C\u00e2nd avem un al doilea fi\u0219ier .vbk, preg\u0103tit pentru mutare \u0219i format din blocurile a, b \u0219i d, analiz\u00e2nd indexul de dehidratare, \u00een\u021belegem c\u0103 trebuie s\u0103 mut\u0103m doar blocul d. Fi\u0219ierul s\u0103u de metadate va con\u021bine referin\u021be c\u0103tre cele dou\u0103 blocuri anterioare \u0219i unul nou.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrin urmare, procesul de umplere invers\u0103 a acestor loca\u0219uri goale cu date se nume\u0219te rehidratare. Aici se folose\u0219te deja propriul index de rehidratare, bazat pe cel mai vechi fi\u0219ier .vbk de pe extinderea de performan\u021b\u0103 local\u0103. Deci, dac\u0103 utilizatorul dore\u0219te s\u0103 restituie un fi\u0219ier din tirul de capacitate, mai \u00eent\u00e2i cre\u0103m indexul blocurilor celui mai vechi backup complet \u0219i mut\u0103m din tirul de capacitate doar blocurile lips\u0103. \u00cen cazul prezentat \u00een imagine, pentru a rehidrata FullBackup1.vbk conform indexului de rehidratare, ne lipse\u0219te doar blocul C, pe care \u00eel lu\u0103m din tirul de capacitate. Dac\u0103 tirul de capacitate este un obiect de stocare \u00een cloud, acest lucru permite economisirea unor sume considerabile de bani.<\/p>\n<p>Aici poate p\u0103rea c\u0103 aceast\u0103 tehnologie este similar\u0103 cu cea utilizat\u0103 \u00een Acelera\u021bii WAN, dar aceasta este doar o impresie. \u00cen acceleratoare, deduplicarea este global\u0103, \u00een timp ce aici se folose\u0219te deduplicarea local\u0103 \u00een cadrul fiec\u0103rui fi\u0219ier, pe un anumit offset. Acest lucru se datoreaz\u0103 diferen\u021bei de sarcini rezolvate: trebuie s\u0103 copiem fi\u0219iere mari de backup complet \u0219i, conform cercet\u0103rilor noastre, chiar dac\u0103 \u00eentre acestea trece o perioad\u0103 mare de timp, un astfel de algoritm de deduplicare ofer\u0103 cele mai bune rezultate.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDar mai multe indexuri lui Dumnezeu indexuri! Exist\u0103 \u0219i un index pentru recuperarea datelor! C\u00e2nd lans\u0103m recuperarea unei ma\u0219ini situate \u00een capacitatea tir, vom citi doar blocurile unice de date, care nu se afl\u0103 \u00een tirul de performan\u021b\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>A\u0219a a devenit<\/h1>\n<p>\nAcesta a fost tot cu introducerea. Este destul de detaliat\u0103, dar, a\u0219a cum s-a spus mai sus, f\u0103r\u0103 aceste detalii nu se poate explica cum func\u021bioneaz\u0103 noile func\u021bii. A\u0219adar, f\u0103r\u0103 alte introduceri, trecem la prima.<\/p>\n<h3>Modul de copiere<\/h3>\n<p>\nSe bazeaz\u0103 \u00een mare parte pe tehnologiile existente, dar aduce o logic\u0103 complet diferit\u0103 de utilizare.\u00a0<\/p>\n<p>Scopul acestui mod este de a garanta c\u0103 toate datele aflate pe extensia local\u0103 au o copie \u00een capacitatea tir.<\/p>\n<p>Dac\u0103 compar\u0103m brutal modurile Move \u0219i Copy, va fi a\u0219a:<\/p>\n<ul>\n<li>Se pot muta doar lan\u021buri sigilate. \u00cen cazul modului Copy, se transport\u0103 absolut tot, indiferent de ceea ce se \u00eent\u00e2mpl\u0103 \u00een jobul de backup.<\/li>\n<li>Mutarea se activeaz\u0103 atunci c\u00e2nd fi\u0219ierele ies din fereastra de operare a backupului, iar copierea se activeaz\u0103 imediat ce apare fi\u0219ierul de backup.<\/li>\n<li>Monitorizarea noilor date pentru copiere se face constant, iar pentru mutare se activa odat\u0103 la 4 ore.<\/li>\n<\/ul>\n<p>\n\u00cen examinarea noului mod, propunem s\u0103 trecem de la exemple simple la cele complexe.<\/p>\n<p>\u00cen cel mai banal caz, avem pur \u0219i simplu fi\u0219iere noi cu incremente, \u0219i le copiem pur \u0219i simplu \u00een tirul de capacitate. Indiferent de modul utilizat \u00een jobul de backup, indiferent dac\u0103 apar\u021bine p\u0103r\u021bii sigilate a lan\u021bului sau nu, indiferent dac\u0103 fereastra noastr\u0103 opera\u021bional\u0103 a expirat. Pur \u0219i simplu le-am luat \u0219i le-am copiat.<\/p>\n<p>Procesul din spate r\u0103m\u00e2ne tot dehidrarea, a\u0219a cum a fost descris mai sus. \u00cen modul copia, de asemenea, se asigur\u0103 c\u0103 nu copiem blocuri care sunt deja \u00een stocarea noastr\u0103. Singura diferen\u021b\u0103 este c\u0103, \u00een modul mutare, am \u00eenlocuit fi\u0219ierele reale cu fi\u0219iere golite, iar aici nu le atingem \u0219i l\u0103s\u0103m totul a\u0219a cum este. \u00cen rest, este exact acela\u0219i index de dehidrare, care se str\u0103duie\u0219te s\u0103 economiseasc\u0103 banii \u0219i timpul dumneavoastr\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe pune \u00eentrebarea \u2014 dac\u0103 ne uit\u0103m \u00een UI, exist\u0103 op\u021biunea de a alege ambele op\u021biuni simultan. Cum va func\u021biona acest mod combinat?<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u0103 analiz\u0103m.<\/p>\n<p>\u00cenceputul este standard: se creeaz\u0103 un fi\u0219ier de backup \u0219i se copiaz\u0103 imediat. Se creeaz\u0103 un increment \u0219i, de asemenea, se copiaz\u0103. Acest lucru se \u00eent\u00e2mpl\u0103 p\u00e2n\u0103 \u00een momentul \u00een care \u00een\u021belegem c\u0103 fi\u0219ierele au ie\u0219it din fereastra noastr\u0103 opera\u021bional\u0103 \u0219i a ap\u0103rut un lan\u021b sigilat. \u00cen acest moment, efectu\u0103m opera\u021bia de dehidrare \u0219i \u00eenlocuim aceste fi\u0219iere cu altele goale. Bine\u00een\u021beles, nu mai copiem nimic din nou pe capacitatea tir.<\/p>\n<p>Toat\u0103 aceast\u0103 logic\u0103 interesant\u0103 este responsabil\u0103 doar o bif\u0103 \u00een interfa\u021b\u0103: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Dar de ce avem acest mod Copy? <\/h3>\n<p>\nEste chiar mai bine s\u0103 reformul\u0103m \u00eentrebarea astfel \u2014 de la ce riscuri ne protej\u0103m cu ajutorul s\u0103u? Ce problem\u0103 ne ajut\u0103 s\u0103 rezolv\u0103m?<\/p>\n<p>R\u0103spunsul este evident: desigur, este vorba despre recuperarea datelor. Dac\u0103 avem pe stocarea obiectelor o copie complet\u0103 a datelor locale, atunci nu conteaz\u0103 ce se \u00eent\u00e2mpl\u0103 cu produc\u021bia noastr\u0103, putem oric\u00e2nd s\u0103 recuper\u0103m datele din fi\u0219ierele aflate \u00een Amazonul nostru ipotetic.<\/p>\n<p>A\u0219a c\u0103 haide\u021bi s\u0103 discut\u0103m despre posibilele scenarii, de la cel mai simplu la cel mai complex.<\/p>\n<p>Cea mai simpl\u0103 problem\u0103 care poate c\u0103dea asupra capului nostru este inadmisibilitatea unuia dintre fi\u0219ierele din lan\u021bul de backup.<\/p>\n<p>O poveste \u0219i mai trist\u0103 \u2014 ne-a fost stricat unul dintre extensiile depozitului nostru SOBR.<\/p>\n<p>\u0218i devine \u0219i mai r\u0103u atunci c\u00e2nd \u00eentregul depozit SOBR devine inaccesibil, dar func\u021bioneaz\u0103 capacitatea tir.<br \/>\n\u0218i totul devine cu adev\u0103rat grav \u2014 atunci c\u00e2nd serverul de backup moare \u0219i prima ta dorin\u021b\u0103 este s\u0103 \u00eencerci s\u0103 ajungi la grani\u021ba canadian\u0103 \u00een zece minute.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAcum s\u0103 analiz\u0103m fiecare situa\u021bie \u00een parte.<\/p>\n<p>C\u00e2nd am pierdut un (chiar dac\u0103 mai multe) fi\u0219iere de backup, va fi suficient s\u0103 lans\u0103m procesul de re-scanare a repository-ului, iar fi\u0219ierul pierdut va fi \u00eenlocuit cu un fi\u0219ier gol. Iar prin procesul de rehidratare (despre care am vorbit la \u00eenceputul articolului), utilizatorul va putea desc\u0103rca datele din capacity tier \u00een stocarea local\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAcum situa\u021bia devine mai complicat\u0103. S\u0103 presupunem c\u0103 SOBR-ul nostru const\u0103 din dou\u0103 extenturi, func\u021bion\u00e2nd \u00een modul Performance, ceea ce \u00eenseamn\u0103 c\u0103 fi\u0219ierele noastre .vbk \u0219i .vib sunt distribuite pe acestea \u00eentr-un mod destul de inegal. \u0218i la un moment dat, unul dintre extenturi devine inaccesibil, iar utilizatorul trebuie s\u0103 recupereze urgent ma\u0219ina, o parte din datele c\u0103reia se afl\u0103 tocmai pe acest extent. <\/p>\n<p>Utilizatorul ini\u021biaz\u0103 wizard-ul de recuperare, selecteaz\u0103 punctul la care dore\u0219te s\u0103 recupereze, iar wizard-ul, pe parcursul procesului, \u00ee\u0219i d\u0103 seama c\u0103 nu are toate datele necesare pentru recuperare local \u0219i, prin urmare, trebuie s\u0103 le descarce din capacity tier. \u00cen acest timp, blocurile care au r\u0103mas \u00een stocarea local\u0103 nu vor fi desc\u0103rcate din cloud. Slav\u0103 indexului de restaurare (da, a fost men\u021bionat \u0219i acesta la \u00eenceputul articolului).<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO variant\u0103 a acestui caz este c\u0103 \u00eentreg repository-ul SOBR a devenit inaccesibil. \u00cen acest caz, nu avem nimic de copiat din stoc\u0103rile locale, iar toate blocurile sunt desc\u0103rcate din cloud.<\/p>\n<p>\u0218i cea mai interesant\u0103 situa\u021bie \u2014 serverul de backup a murit. Aici sunt dou\u0103 variante: administratorul e de\u0219tept \u0219i a realizat backup-uri ale configura\u021biei, sau administratorul este un r\u0103uf\u0103c\u0103tor care nu a realizat niciun backup de configura\u021bie.<\/p>\n<p>\u00cen primul caz, va fi suficient s\u0103 implementeze undeva o instalare curat\u0103 a VBR-ului \u0219i s\u0103-\u0219i restaureze baza din backup prin metode standard. La finalul acestui proces, totul va reveni la normal. Sau va fi restaurat conform unuia dintre scenariile de mai sus.<\/p>\n<p>Dar dac\u0103 administratorul este inamicul s\u0103u sau dac\u0103 copia de rezerv\u0103 a configura\u021biei a avut parte de e\u0219ecuri legendare, chiar \u0219i aici nu-l vom l\u0103sa pe mila sor\u021bii. Pentru acest caz, am introdus o nou\u0103 procedur\u0103 numit\u0103 Import Object Storage. Aceasta permite s\u0103 s\u0103rim peste procesul de recreare manual\u0103 a repositoarelor SOBR \u0219i de ata\u0219are a capacit\u0103\u021bii acestora cu un nou scan, ad\u0103ug\u00e2nd pur \u0219i simplu storage-ul de obiecte \u00een interfa\u021ba vima \u0219i lans\u00e2nd procedura Import Storage Repository. Singurul lucru care poate sta \u00een calea ta \u0219i a copiilor tale de rezerv\u0103 este o solicitare de a introduce parola, \u00een cazul \u00een care copierea ta de rezerv\u0103 a fost criptat\u0103.<\/p>\n<p>Aici se finalizeaz\u0103 discu\u021bia despre Modului Copy, iar acum trecem la<\/p>\n<h3>Mod \u00eenchis<\/h3>\n<p>\nConceptul de baz\u0103 este c\u0103 nu pot ap\u0103rea copii de rezerv\u0103 noi pe extensia selectat\u0103 a repositoarelor SOBR. P\u00e2n\u0103 la v10, aveam doar Modul de \u00eentre\u021binere, c\u00e2nd era complet interzis\u0103 orice activitate cu repositoarele. Acesta era un mod sever de oprire a stoc\u0103rii din func\u021biune, \u00een care era disponibil doar butonul Evacuate, care muta temporar copiile de rezerv\u0103 pe o alt\u0103 extensie.<\/p>\n<p>Modul \u00eenchis reprezint\u0103 o variant\u0103 \u201emoale\u201d: interzicem crearea de copii de rezerv\u0103 noi \u0219i elimin\u0103m treptat copiile vechi conform reten\u021biei selectate, dar \u00een acest proces nu pierdem capacitatea de a ne restaura din punctele de stocare existente. Este o caracteristic\u0103 foarte util\u0103 atunci c\u00e2nd se apropie termenul de via\u021b\u0103 al echipamentului \u0219i trebuie s\u0103 fie \u00eenlocuit, sau trebuie pur \u0219i simplu s\u0103 eliber\u0103m spa\u021biu pentru ceva mai important, dar nu avem unde s\u0103 transfer\u0103m totul deodat\u0103. Sau nu se poate \u0219terge. <\/p>\n<p>Prin urmare, principiul de func\u021bionare este destul de simplu: trebuie s\u0103 interzicem toate opera\u021biile de scriere (apari\u021bia de date noi), l\u0103s\u00e2nd opera\u021biile de citire (restaur\u0103ri) \u0219i \u0219tergete (reten\u021bie).<\/p>\n<p>Ambele moduri pot fi utilizate simultan, dar trebuie s\u0103 \u021bine\u021bi cont c\u0103 Modul de \u00eentre\u021binere are prioritate mai mare.<\/p>\n<p>Ca exemplu, s\u0103 lu\u0103m \u00een considerare un SOBR compus din dou\u0103 extensii. S\u0103 presupunem c\u0103, \u00een primele patru zile, copiile de rezerv\u0103 au fost create \u00een modul Forward Forever Incremental, iar apoi sigil\u0103m extensia. Aceasta duce la ini\u021bierea cre\u0103rii unui nou activ full pe a doua extensie disponibil\u0103. Dac\u0103 reten\u021bia noastr\u0103 este de patru, atunci c\u00e2nd \u00eentreaga chain\u0103 situat\u0103 pe extensia sigilat\u0103 dep\u0103\u0219e\u0219te aceast\u0103 limit\u0103, aceasta poate fi \u0219tears\u0103 f\u0103r\u0103 probleme.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nExist\u0103 situa\u021bii \u00een care \u0219tergerea are loc mai devreme. De exemplu, este cazul Forward incremental cu copii complete periodice. Dac\u0103 \u00een primele dou\u0103 zile s-au creat copii complete, iar joi decidem s\u0103 pecetluim depozitul, atunci vinerea, c\u00e2nd se va crea o nou\u0103 copie complet\u0103, fi\u0219ierul de luni va fi \u0219ters deoarece p\u00e2n\u0103 la acest punct nu exist\u0103 dependen\u021be. \u0218i acest punct nu depinde de nimeni. Dup\u0103 aceea, a\u0219tept\u0103m s\u0103 fie create patru puncte pe extinderea disponibil\u0103 \u0219i \u0219tergem cele trei r\u0103mase, care nu pot fi \u0219terse independent una de cealalt\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLucrurile stau mai simplu cu Reverse Incremental. Aici, cele mai vechi puncte nu depind de nimeni \u0219i pot fi \u0219terse f\u0103r\u0103 probleme. A\u0219adar, de \u00eendat\u0103 ce se creeaz\u0103 un nou .vbk pe o nou\u0103 extindere, vechile .vrb vor fi \u0219terse treptat.<\/p>\n<p>Apropo, de ce cre\u0103m de fiecare dat\u0103 un nou .vbk: dac\u0103 nu l-am crea \u0219i am continua vechea serie de incrementaluri, vechiul .vbk s-ar bloca pe o perioad\u0103 nedefinit\u0103 \u00een orice mod, \u00eempiedic\u00e2nd \u0219tergerea sa. A\u0219adar, s-a decis c\u0103 de \u00eendat\u0103 ce extinderea este pecetluit\u0103, cre\u0103m o copie complet\u0103 pe o extindere liber\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLucrurile sunt mai complicate cu capacitatea tier. <\/p>\n<p>Mai \u00eent\u00e2i, s\u0103 lu\u0103m \u00een considerare modul copy. S\u0103 presupunem c\u0103 am avut patru zile \u00een care s-au creat activ copii de rezerv\u0103, iar apoi capacitatea tier a fost pecetluit\u0103. Nu \u0219tergem nimic, ci a\u0219tept\u0103m calm perioada de reten\u021bie, dup\u0103 care \u0219tergem datele din capacitatea tier.<\/p>\n<p>Aproape acela\u0219i lucru se \u00eent\u00e2mpl\u0103 \u00een modul move \u2014 a\u0219tept\u0103m perioada de reten\u021bie, \u0219tergem vechile date din stocarea local\u0103, \u0219tergem ce se afl\u0103 \u00een obiect storage.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn exemplu interesant cu Forever forward incremental. Stabilim o reten\u021bie de trei puncte \u0219i \u00eencepem cu luni s\u0103 facem copii de rezerv\u0103, care se copiaz\u0103 corect \u00een cloud. Dup\u0103 pecetluirea stoc\u0103rii, copiile de rezerv\u0103 continu\u0103 s\u0103 fie create, men\u021bin\u00e2nd cele trei puncte, dar datele stocate \u00een capacitatea tier r\u0103m\u00e2n dependente \u0219i nu pot fi \u0219terse. A\u0219adar, a\u0219tept\u0103m joi, c\u00e2nd .vbk-ul nostru dep\u0103\u0219e\u0219te perioada de reten\u021bie, \u0219i abia atunci \u0219tergem cu lini\u0219te \u00eentreaga serie de date salvate.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u0218i o mic\u0103 precizare: toate exemplele de aici sunt prezentate cu o singur\u0103 ma\u0219in\u0103. Dac\u0103 ave\u021bi mai multe \u00een backup, atunci perioada de reten\u021bie va diferi \u00een func\u021bie de faptul c\u0103 a fost efectuat un Active Full sau nu.<\/p>\n<p>Asta ar fi tot. A\u0219adar, s\u0103 trecem la cea mai hardcore func\u021bie \u2014 <\/p>\n<h3>Imutabilitate <\/h3>\n<p>\nCa \u0219i \u00een punctele anterioare, primul lucru despre care vorbim este problema pe care o rezolv\u0103 aceast\u0103 func\u021bie. Atunci c\u00e2nd export\u0103m undeva backup-urile noastre pentru stocare, apare o dorin\u021b\u0103 acut\u0103 de a garanta p\u0103strarea acestora, adic\u0103 de a interzice fizic \u0219tergerea \u0219i orice modificare pe durata reten\u021biei stabilite. Inclusiv de c\u0103tre administratori, inclusiv sub conturile lor de root. Acest lucru protejeaz\u0103 backup-urile de deteriorarea accidental\u0103 sau inten\u021bionat\u0103. Cei care lucreaz\u0103 cu AWS ar putea \u00eent\u00e2lni o astfel de func\u021bie sub numele de Object Lock.<\/p>\n<p>Acum s\u0103 discut\u0103m modul \u00een termeni generali, apoi ne vom aprofunda \u00een detalii. \u00cen exemplul nostru, Immutability va fi activat pentru capacitatea noastr\u0103 cu o reten\u021bie de patru zile. Iar \u00een backup este activat modul Copy.<\/p>\n<p>Immutability nu interac\u021bioneaz\u0103 deloc cu reten\u021bia general\u0103. De exemplu, nu adaug\u0103 puncte suplimentare sau ceva asem\u0103n\u0103tor. Pur \u0219i simplu, \u00een decurs de patru zile, o persoan\u0103 nu poate \u0219terge fi\u0219ierele backup-urilor. Dac\u0103 \u00een ziua de luni se face un backup, atunci fi\u0219ierul s\u0103u poate fi \u0219ters doar vineri.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nToate conceptele explicate anterior despre dehidratare, indec\u0219i \u0219i metadate continu\u0103 s\u0103 func\u021bioneze exact la fel. Dar cu o condi\u021bie \u2014 blocul este stabilit nu doar pentru date, ci \u0219i pentru metadate. Acest lucru este f\u0103cut pentru cazul \u00een care un atacator viclean decide s\u0103 \u0219tearg\u0103 baza noastr\u0103 de metadate, astfel \u00eenc\u00e2t blocurile de date s\u0103 nu devin\u0103 o mas\u0103 binar\u0103 inutil\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u0218i acum a sosit momentul excelent pentru a explica tehnologia noastr\u0103 de generare a blocurilor. Sau block generation. Pentru aceasta, s\u0103 analiz\u0103m situa\u021bia care a dus la apari\u021bia acesteia.<\/p>\n<p>S\u0103 lu\u0103m o scar\u0103 temporal\u0103 de \u0219ase zile \u0219i vom marca \u00een partea de jos timpul estimat al expir\u0103rii immutabilit\u0103\u021bii. Cre\u0103m, \u00een prima zi, un fi\u0219ier format din blocul a \u0219i metadatele sale. Dac\u0103 immutabilitatea este setat\u0103 la trei zile, este logic s\u0103 presupunem c\u0103 \u00een a patra zi datele vor fi deblocate \u0219i \u0219terse. \u00cen a doua zi, ad\u0103ug\u0103m un nou fi\u0219ier file2, format din blocul b cu acelea\u0219i set\u0103ri. Blocul a ar trebui s\u0103 fie \u00een continuare \u0219ters \u00een a patra zi. Dar \u00een a treia zi se \u00eent\u00e2mpl\u0103 ceva groaznic \u2014 se creeaz\u0103 fi\u0219ierul File3, format dintr-un nou bloc d \u0219i referin\u021ba la vechiul bloc a. Asta \u00eenseamn\u0103 c\u0103 pentru blocul a, steagul de immutabilitate ar trebui resetat la un nou termen, care se mut\u0103 \u00een a \u0219asea zi. \u0218i aici apare problema \u2014 \u00een backup-urile reale ale acestor blocuri, se produce un num\u0103r imens. \u0218i pentru a extinde perioada de immutabilitate, trebuie s\u0103 facem constant un num\u0103r foarte mare de cereri. \u0218i, de fapt, acest proces va fi aproape nesf\u00e2r\u0219it zilnic, deoarece este foarte probabil ca la fiecare copiere s\u0103 g\u0103sim gr\u0103mezi mari de blocuri deduplicat. \u0218i ce \u00eenseamn\u0103 un num\u0103r mare de cereri pentru furnizorii de stocare de obiecte? Exact! O factur\u0103 enorm\u0103 la sf\u00e2r\u0219itul lunii.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u0218i pentru a nu expune clien\u021bii no\u0219tri dragi la costuri considerabile f\u0103r\u0103 motiv, a fost inventat mecanismul de generare a blocurilor. Acesta este un interval suplimentar pe care \u00eel ad\u0103ug\u0103m la perioada stabilit\u0103 de immutabilitate. \u00cen exemplul de mai jos, aceast\u0103 perioad\u0103 este de dou\u0103 zile. Dar aceasta este doar pentru exemplificare. \u00cen realitate, o formul\u0103 proprie este utilizat\u0103, care ofer\u0103 aproximativ zece zile suplimentare pentru un blocaj lunar. <\/p>\n<p>S\u0103 continu\u0103m s\u0103 discut\u0103m aceea\u0219i situa\u021bie, dar deja cu generarea de blocuri. Cre\u0103m \u00een prima zi file1 din blocul a \u0219i metadatele. Adun\u0103m perioada de genera\u021bie \u0219i imutabilitate \u2013 \u00eenseamn\u0103 c\u0103 posibilitatea de a \u0219terge fi\u0219ierul va fi \u00een a \u0219asea zi. Dac\u0103 \u00een a doua zi cre\u0103m File2, compus din bloc b \u0219i un link la blocul a, atunci data estimat\u0103 a \u0219tergerii nu se schimb\u0103. R\u0103m\u00e2ne la a \u0219asea zi, exact ca la \u00eenceput. \u00cencerc\u0103m astfel s\u0103 economisim bani pe num\u0103rul de solicit\u0103ri. Singura situa\u021bie \u00een care termenul poate fi mutat este dac\u0103 perioada de genera\u021bie a expirat. A\u0219adar, dac\u0103 \u00een a treia zi noul File3 va con\u021bine un link c\u0103tre blocul a, atunci se va ad\u0103uga genera\u021bia 2 deoarece Gen1 a expirat deja. Data estimat\u0103 a \u0219tergerii blocului a se va muta \u00een a opta zi. Aceasta ne permite s\u0103 reducem dramatic num\u0103rul de solicit\u0103ri pentru prelungirea timpului de via\u021b\u0103 al blocurilor deduplicated, ceea ce economise\u0219te o sum\u0103 considerabil\u0103 de bani clien\u021bilor.<\/p>\n<p><img decoding=\"async\" alt=\"Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTehnologia \u00een sine este disponibil\u0103 utilizatorilor S3 \u0219i hardware-ului compatibil S3, ale c\u0103ror produc\u0103tori garanteaz\u0103 c\u0103 implementarea lor nu difer\u0103 de cea amazonian\u0103. De aici r\u0103spunsul la \u00eentrebarea legitim\u0103 de ce nu este sus\u021binut Azure \u2013 au o caracteristic\u0103 similar\u0103, dar aceasta func\u021bioneaz\u0103 la nivelul containerelor, nu al obiectelor individuale. Apropo, \u00een Amazonul \u00eensu\u0219i, Object Lock exist\u0103 \u00een dou\u0103 moduri: compliance \u0219i governance. \u00cen al doilea caz, r\u0103m\u00e2ne posibilitatea ca cel mai mare administrator dintre administratori, \u0219i root-ul \u00eentre root-uri, \u00een ciuda Object Lock, totu\u0219i s\u0103 \u0219tearg\u0103 datele. \u00cen cazul compliance, totul este b\u0103tut \u00een cuie, iar backup-urile nu pot fi \u0219terse de nimeni. Chiar \u0219i de c\u0103tre administratorii Amazon (conform declara\u021biilor lor oficiale). Noi sus\u021binem exact acest mod.<\/p>\n<p>\n\u0218i, \u00een mod tradi\u021bional, c\u00e2teva linkuri utile:<\/p>\n<ul>\n<li>Despre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generarea de blocuri<\/a><\/noindex> \u00een toate detaliile.<\/li>\n<li>Toate informa\u021biile despre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> \u00een cea mai bun\u0103 form\u0103<\/li>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> \u00een detalii<\/li>\n<\/ul>\n<p>Sursa: <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.2.1 - 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\/ro\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47Ce s-a schimbat \u00een Capacity Tier, c\u00e2nd Veeam a devenit v10 | ProHoster","description":"Capacity Tier (sau cum \u00eel numim noi intern \u2013 captier) a ap\u0103rut \u00eenc\u0103 din vremurile Veeam Backup and Replication 9.5 Update 4 sub numele Archive Tier.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}