{"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\/pl\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Tier pojemno\u015bci (lub jak nazywamy to wewn\u0119trznie \u2014 kaptir) pojawi\u0142 si\u0119 jeszcze za czas\u00f3w Veeam Backup and Replication 9.5 Update 4 pod nazw\u0105 Archive Tier. Pomys\u0142 na niego polega\u0142 na umo\u017cliwieniu przenoszenia kopii zapasowych, kt\u00f3re wypad\u0142y z tak zwanego operational restore window, do obiektowych magazyn\u00f3w danych. Umo\u017cliwia\u0142o to zwolnienie przestrzeni dyskowej u\u017cytkownikom, kt\u00f3rzy mieli jej niewiele. Ta opcja nazywa\u0142a si\u0119 Move Mode.<\/p>\n<p>Aby wykona\u0107 to nieco skomplikowane (jak si\u0119 wydaje) dzia\u0142anie, wystarczy\u0142o spe\u0142ni\u0107 dwa warunki: wszystkie punkty z przenoszonej kopii zapasowej musia\u0142y znajdowa\u0107 si\u0119 poza wcze\u015bniej wspomnianym operational restore window, kt\u00f3re jest jednoznacznie okre\u015blone w UI. I drugie: \u0142a\u0144cuch musi by\u0107 w tak zwanym \u00abzapiecz\u0119towanym stanie\u00bb (sealed backup chain lub Inactive Backup Chain). Oznacza to, \u017ce w tym \u0142a\u0144cuchu w miar\u0119 up\u0142ywu czasu nie zachodz\u0105 \u017cadne zmiany.<\/p>\n<p>Jednak w VBR v10 koncepcja zosta\u0142a wzbogacona o nowe funkcje \u2014 pojawi\u0142y si\u0119 Copy Mode, Sealed Mode oraz rozwi\u0105zanie ze skomplikowan\u0105 nazw\u0105 Immutability.<\/p>\n<p>O tych fascynuj\u0105cych rzeczach porozmawiamy dzisiaj. Najpierw om\u00f3wimy, jak to dzia\u0142a\u0142o w VBR 9.5u4, a p\u00f3\u017aniej zmiany w dziesi\u0105tej wersji.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI niech mi wybacz\u0105 or\u0119downicy czystego j\u0119zyka, ale zbyt wiele termin\u00f3w nie da si\u0119 przet\u0142umaczy\u0107.<br \/>\nTak wi\u0119c tutaj b\u0119dzie mn\u00f3stwo anglicyzm\u00f3w.<br \/>\nI du\u017co gif\u00f3w. <br \/>\nI obrazk\u00f3w.<\/p>\n<ul>\n<li>Bez najmniejszych wyrzut\u00f3w sumienia. Autor artyku\u0142u.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Jak by\u0142o<\/h1>\n<p>\nC\u00f3\u017c, zaczynamy od om\u00f3wienia operational restore window i sealed backup (lub jak nazywaj\u0105 si\u0119 w dokumentacji Inactive Backup Chain). Bez ich zrozumienia dalsze wyja\u015bnienia nie b\u0119d\u0105 mo\u017cliwe.<\/p>\n<p>Jak widzimy na obrazku, mamy pewn\u0105 sekwencj\u0119 kopii zapasowych z blokami danych, kt\u00f3ra znajduje si\u0119 na performance tier repozytorium SOBR, do kt\u00f3rego pod\u0142\u0105czony jest Capacity Tier. Nasze okno operacyjne dla kopii zapasowej wynosi trzy dni.<\/p>\n<p>W zwi\u0105zku z tym, stworzony w poniedzia\u0142ek .vbk zapiecz\u0119towuje poprzedni\u0105 sekwencj\u0119, kt\u00f3rej okno wynosi trzy dni. Oznacza to, \u017ce z \u0142atwo\u015bci\u0105 mo\u017cna zacz\u0105\u0107 przenosi\u0107 do tieru pojemno\u015bci wszystko, co jest starsze ni\u017c te trzy dni.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAle co dok\u0142adnie oznacza\u0142o sealed chain i co mog\u0142o by\u0107 wys\u0142ane do capacity tier w update 4?<\/p>\n<p>Dla Forward Incremental znakiem zapiecz\u0119towania \u0142a\u0144cucha jest stworzenie nowej pe\u0142nej kopii zapasowej. I nie ma znaczenia, jak ta pe\u0142na kopia zosta\u0142a uzyskana: liczy si\u0119 zar\u00f3wno synthetic full, jak i active full backups.<\/p>\n<p>W przypadku Reverse wszystkie pliki, kt\u00f3re nie mieszcz\u0105 si\u0119 w operacyjnym oknie. <\/p>\n<p>W przypadku Forward increment z rollbackami, wszystkie rollbacki i .vbk, je\u015bli na perfromansie extencie znajduje si\u0119 jeszcze jeden .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrzyjrzyjmy si\u0119 teraz opcji pracy z \u0142a\u0144cuchami Backup Copy. Tutaj zbierane jest tylko to, co mie\u015bci si\u0119 w GFS retention. Poniewa\u017c wszystko, co znajduje si\u0119 w nowszych \u0142a\u0144cuchach backup copy, mo\u017ce zosta\u0107 w ten czy inny spos\u00f3b zmienione.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeraz zajrzyjmy pod mask\u0119. Zachodzi tam proces zwany dehydratacj\u0105 - pozostawienie pustych plik\u00f3w backupowych na extencie i przenoszenie blok\u00f3w z tych plik\u00f3w do pojemno\u015bci tir. Do optymalizacji tego procesu u\u017cywany jest tak zwany indeks dehydratacji, kt\u00f3ry pozwala nie kopiowa\u0107 blok\u00f3w, kt\u00f3re ju\u017c zosta\u0142y skopiowane do pojemno\u015bci tir. <\/p>\n<p>Zobaczmy, jak to wygl\u0105da na przyk\u0142adzie: za\u0142\u00f3\u017cmy, \u017ce mamy .vbk, kt\u00f3ry wyszed\u0142 z okna operacyjnego i nale\u017cy do zamkni\u0119tego \u0142a\u0144cucha. To oznacza, \u017ce mamy pe\u0142ne prawo przenie\u015b\u0107 go do pojemno\u015bci tir. W momencie przeprowadzki tworzony jest plik metadanych w pojemno\u015bci tir oraz bloki przenoszonego pliku. W pliku metadanych na poziomie odniesie\u0144 opisane jest, z jakich blok\u00f3w sk\u0142ada si\u0119 nasz plik. W przypadku na obrazku nasz pierwszy plik sk\u0142ada si\u0119 z blok\u00f3w a, b, c, a w metadanych umieszczone s\u0105 odniesienia do tych blok\u00f3w. Gdy pojawia si\u0119 drugi plik .vbk, gotowy do przeprowadzki i sk\u0142adaj\u0105cy si\u0119 z blok\u00f3w a, b i d, analizuj\u0105c indeks dehydratacji, rozumiemy, \u017ce nale\u017cy przenie\u015b\u0107 tylko blok d. A jego plik metadanych b\u0119dzie zawiera\u0142 odniesienia do dw\u00f3ch poprzednich blok\u00f3w i jednego nowego.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW zwi\u0105zku z tym, proces ponownego wype\u0142niania tych pustych blok\u00f3w danymi nazywa si\u0119 rehyratacj\u0105. U\u017cywany jest ju\u017c w\u0142asny indeks rehyratacji, opieraj\u0105cy si\u0119 na najstarszym pliku .vbk w lokalnym performance extencie. To znaczy, \u017ce je\u015bli u\u017cytkownik chce przywr\u00f3ci\u0107 plik z pojemno\u015bci tir, najpierw tworzymy indeks blok\u00f3w najstarszej pe\u0142nej kopii zapasowej i przenosimy z pojemno\u015bci tir tylko brakuj\u0105ce bloki. W przedstawionym przypadku, aby rehyratowa\u0107 FullBackup1.vbk zgodnie z indeksem rehyratacji, brakuje nam tylko bloku C, kt\u00f3ry zabieramy z pojemno\u015bci tir. Je\u015bli jako pojemno\u015b\u0107 tir wyst\u0119puje obiekt storage w chmurze, pozwala to zaoszcz\u0119dzi\u0107 ogromne pieni\u0105dze.<\/p>\n<p>Mo\u017cna odnie\u015b\u0107 wra\u017cenie, \u017ce ta technologia jest podobna do tej u\u017cywanej w akceleratorach WAN, ale to tylko pozory. W akceleratorach dokonuje si\u0119 globalnej deduplikacji, natomiast tutaj wykorzystywana jest lokalna w obr\u0119bie ka\u017cdego pliku w okre\u015blonym ofsecie. Dzieje si\u0119 tak z powodu r\u00f3\u017cnicy w rozwi\u0105zywanych zadaniach: musimy kopiowa\u0107 du\u017ce pliki pe\u0142nych kopii zapasowych, a z naszych bada\u0144 wynika, \u017ce nawet je\u015bli mi\u0119dzy nimi minie d\u0142u\u017cszy czas, taki algorytm deduplikacji daje lepsze rezultaty.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAle wi\u0119cej indeks\u00f3w bogu indeks\u00f3w! Jest jeszcze indeks do przywracania danych! Gdy uruchamiamy przywracanie maszyny znajduj\u0105cej si\u0119 w kapacito tir, odczytujemy tylko unikalne bloki danych, kt\u00f3rych nie ma w performance tir.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Jak to si\u0119 sta\u0142o<\/h1>\n<p>\nNa tym ko\u0144czymy nasz\u0105 wprowadzenie. Jest ono do\u015b\u0107 szczeg\u00f3\u0142owe, ale, jak wspomniano wcze\u015bniej, bez tych szczeg\u00f3\u0142\u00f3w nie mo\u017cna wyja\u015bni\u0107, jak dzia\u0142aj\u0105 nowe funkcje. Dlatego bez zb\u0119dnych wst\u0119p\u00f3w przechodzimy do pierwszego.<\/p>\n<h3>Tryb kopiowania<\/h3>\n<p>\nW du\u017cej mierze oparty na istniej\u0105cych technologiach, jednak niesie ze sob\u0105 zupe\u0142nie inn\u0105 logik\u0119 u\u017cytkowania.\u00a0<\/p>\n<p>Celem tego trybu jest zapewnienie, \u017ce wszystkie dane znajduj\u0105ce si\u0119 w lokalnym ekstensie maj\u0105 kopi\u0119 w kapacito tir.<\/p>\n<p>Por\u00f3wnuj\u0105c bezpo\u015brednio tryby Move i Copy, otrzymujemy nast\u0119puj\u0105ce wyniki:<\/p>\n<ul>\n<li>Mo\u017cna przesuwa\u0107 tylko zapiecz\u0119towany \u0142a\u0144cuch. W przypadku trybu kopiowania przewo\u017cone jest absolutnie wszystko, niezale\u017cnie od tego, co dzieje si\u0119 w zadaniu backupowym.<\/li>\n<li>Przesuni\u0119cie nast\u0119puje, gdy pliki opuszczaj\u0105 granice okna operacyjnego kopii zapasowej, natomiast kopiowanie uruchamia si\u0119 od razu, jak tylko pojawia si\u0119 plik kopii zapasowej.<\/li>\n<li>\u015aledzenie nowych danych do kopiowania odbywa si\u0119 na bie\u017c\u0105co, natomiast dla przesuni\u0119cia by\u0142o uruchamiane co 4 godziny.<\/li>\n<\/ul>\n<p>\nW omawianiu nowego trybu proponuj\u0119 przechodzi\u0107 od prostych przyk\u0142ad\u00f3w do bardziej z\u0142o\u017conych.<\/p>\n<p>W najprostszej sytuacji po prostu pojawiaj\u0105 si\u0119 nowe pliki z inkrementami, a my po prostu kopiujemy je do kapacito tir. Niezale\u017cnie od tego, jaki tryb jest u\u017cywany w zadaniu backupowym, niezale\u017cnie od tego, do kt\u00f3rej cz\u0119\u015bci \u0142a\u0144cucha nale\u017cy, niezale\u017cnie od tego, czy nasze okno operacyjne wygas\u0142o. Po prostu wzi\u0119li\u015bmy i skopiowali\u015bmy.<\/p>\n<p>Proces, kt\u00f3ry za tym stoi, to nadal odwodnienie w spos\u00f3b opisany powy\u017cej. W trybie kopiowania r\u00f3wnie\u017c \u015bledzi, aby\u015bmy nie kopiowali blok\u00f3w, kt\u00f3re ju\u017c znajduj\u0105 si\u0119 w naszym magazynie. Jedyna r\u00f3\u017cnica polega na tym, \u017ce w trybie przenoszenia zast\u0119powali\u015bmy rzeczywiste pliki plikami zast\u0119pczymi, a tutaj niczego nie dotykamy i zostawiamy wszystko jak jest. W pozosta\u0142ych kwestiach to dok\u0142adnie taki sam wska\u017anik odwodnienia, kt\u00f3ry stara si\u0119 oszcz\u0119dza\u0107 Twoje pieni\u0105dze i czas.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPojawia si\u0119 pytanie \u2014 je\u015bli spojrzymy na interfejs, to istnieje mo\u017cliwo\u015b\u0107 wyboru obu opcji jednocze\u015bnie. Jak b\u0119dzie dzia\u0142a\u0107 taki tryb po\u0142\u0105czenia?<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrzejd\u017amy do sedna.<\/p>\n<p>Standardowo: tworzony jest plik kopii zapasowej i od razu jest kopiowany. Tworzony jest do niego inkrement i r\u00f3wnie\u017c jest kopiowany. Tak dzieje si\u0119 do momentu, w kt\u00f3rym zdajemy sobie spraw\u0119, \u017ce pliki wysz\u0142y z naszego okna operacyjnego i pojawi\u0142 si\u0119 zapiecz\u0119towany \u0142a\u0144cuch. W tym momencie wykonujemy operacj\u0119 odwodnienia i zast\u0119pujemy te pliki plikami zast\u0119pczymi. Oczywi\u015bcie, ponownie nie kopiujemy do capacity tier.<\/p>\n<p>Za ca\u0142\u0105 t\u0119 pasjonuj\u0105c\u0105 logik\u0119 odpowiada zaledwie jedna opcja w interfejsie: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>A po co nam ten tryb Copy? <\/h3>\n<p>\nJeszcze lepiej przeformu\u0142owa\u0107 pytanie \u2014 przed jakimi ryzykami si\u0119 zabezpieczamy za jego pomoc\u0105? Jak\u0105 problematyk\u0119 on nam pomaga rozwi\u0105za\u0107?<\/p>\n<p>Odpowied\u017a jest oczywista: oczywi\u015bcie, \u017ce to odzyskiwanie danych. Je\u015bli mamy na obiektowym magazynie pe\u0142n\u0105 kopi\u0119 lokalnych danych, to niewa\u017cne, co si\u0119 stanie z naszym \u015brodowiskiem produkcyjnym, zawsze mo\u017cemy przywr\u00f3ci\u0107 dane z plik\u00f3w znajduj\u0105cych si\u0119 w warunkowym Amazonie.<\/p>\n<p>Dlatego przejd\u017amy przez mo\u017cliwe scenariusze, od najprostszych do bardziej skomplikowanych.<\/p>\n<p>Najprostsza katastrofa, kt\u00f3ra mo\u017ce nas spotka\u0107, to niedost\u0119pno\u015b\u0107 jednego z plik\u00f3w w \u0142a\u0144cuchu kopii zapasowych.<\/p>\n<p>Bardziej smutna historia \u2014 jeden z fragment\u00f3w naszego repozytorium SOBR uleg\u0142 awarii.<\/p>\n<p>Jeszcze gorzej, gdy ca\u0142e repozytorium SOBR sta\u0142o si\u0119 niedost\u0119pne, ale dzia\u0142a capacity tier.<br \/>\nA najgorzej \u2014 to gdy umiera serwer kopii zapasowej i twoim pierwszym pragnieniem jest spr\u00f3bowa\u0107 dotrze\u0107 do kanadyjskiej granicy w dziesi\u0119\u0107 minut.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA teraz przeanalizujmy ka\u017cd\u0105 sytuacj\u0119 osobno.<\/p>\n<p>Kiedy stracili\u015bmy jeden (a nawet kilka) plik\u00f3w kopii zapasowej, wystarczy uruchomi\u0107 proces skanowania repozytorium, a utracony plik zostanie zast\u0105piony plikiem pustym. A dzi\u0119ki procesowi rehydratacji (o kt\u00f3rym m\u00f3wiono na pocz\u0105tku artyku\u0142u) u\u017cytkownik b\u0119dzie m\u00f3g\u0142 pobra\u0107 dane z pojemnika do lokalnego przechowywania.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeraz sytuacja jest trudniejsza. Za\u0142\u00f3\u017cmy, \u017ce nasz SOBR sk\u0142ada si\u0119 z dw\u00f3ch ekstent\u00f3w dzia\u0142aj\u0105cych w trybie Performance, co oznacza, \u017ce nasze pliki .vbk i .vib s\u0105 rozmieszczone po nich do\u015b\u0107 nier\u00f3wnomiernie. I w pewnym momencie jeden z ekstent\u00f3w staje si\u0119 niedost\u0119pny, a u\u017cytkownik pilnie musi przywr\u00f3ci\u0107 maszyn\u0119, kt\u00f3rej cz\u0119\u015b\u0107 danych znajduje si\u0119 w\u0142a\u015bnie na tym ekstencie. <\/p>\n<p>U\u017cytkownik uruchamia kreator przywracania, wybiera punkt, do kt\u00f3rego chce przywr\u00f3ci\u0107, a kreator w trakcie pracy zdaje sobie spraw\u0119, \u017ce nie ma lokalnie wszystkich niezb\u0119dnych danych do przywr\u00f3cenia, dlatego nale\u017cy je pobra\u0107 z pojemnika. Przy tym bloki, kt\u00f3re pozosta\u0142y w lokalnym przechowywaniu, nie b\u0119d\u0105 pobierane z chmury. Dzi\u0119ki indeksowi restore (tak, o nim te\u017c m\u00f3wiono na pocz\u0105tku artyku\u0142u).<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodtyp tej sytuacji \u2014 ca\u0142y repozytorium SOBR sta\u0142o si\u0119 niedost\u0119pne. W takim przypadku nie mamy czego kopiowa\u0107 z lokalnych magazyn\u00f3w i wszystkie bloki s\u0105 pobierane z chmury.<\/p>\n<p>A najciekawsza sytuacja \u2014 serwer kopii zapasowych umar\u0142. S\u0105 dwie mo\u017cliwo\u015bci: admin jest m\u0105dry i robi\u0142 kopie zapasowe konfiguracji, albo admin sam sobie zgotowa\u0142 z\u0142o i nie robi\u0142 kopii zapasowej konfiguracji.<\/p>\n<p>W pierwszym przypadku wystarczy gdzie\u015b wdro\u017cy\u0107 czyst\u0105 instalacj\u0119 VBR i przywr\u00f3ci\u0107 jego baz\u0119 z kopii zapasowej standardowymi \u015brodkami. Na zako\u0144czenie tego procesu wszystko wr\u00f3ci do normy. Mo\u017cna r\u00f3wnie\u017c przywr\u00f3ci\u0107 wed\u0142ug jednego z powy\u017cszych scenariuszy.<\/p>\n<p>Jednak je\u015bli administrator jest sam sobie wrogiem lub backup konfiguracji r\u00f3wnie\u017c napotka\u0142 mityczn\u0105 niepowodzenie, to nawet tutaj nie zostawimy go na pastw\u0119 losu. W tym celu wprowadzili\u015bmy now\u0105 procedur\u0119, kt\u00f3ra nazywa si\u0119 Import Object Storage. Umo\u017cliwia ona pomini\u0119cie r\u0119cznego procesu przywracania repozytorium SOBR oraz do\u0142\u0105czenia do niego pojemno\u015bci t\u0105 z p\u00f3\u017aniejszym reskanowaniem, a po prostu doda\u0107 storage obiektowy w interfejsie wima i uruchomi\u0107 procedur\u0119 Import Storage Repository. Jedyn\u0105 rzecz\u0105, kt\u00f3ra mo\u017ce stan\u0105\u0107 na drodze mi\u0119dzy wami a waszymi backupami, jest pro\u015bba o wprowadzenie has\u0142a, je\u015bli wasze kopie zapasowe by\u0142y szyfrowane.<\/p>\n<p>Na tym ko\u0144czymy temat Trybu Kopiowania, a teraz przechodzimy do<\/p>\n<h3>Tryb Zwyci\u0119ski<\/h3>\n<p>\nG\u0142\u00f3wna idea polega na tym, \u017ce na wybranym rozszerzeniu repozytorium SOBR nie mog\u0105 pojawia\u0107 si\u0119 nowe kopie zapasowe. Do wersji v10 mieli\u015bmy tylko Tryb Utrzymania, kt\u00f3ry ca\u0142kowicie zabrania\u0142 jakiejkolwiek pracy z repozytorium. Taki hardkorowy tryb wy\u0142\u0105czenia przechowalni z pracy, gdzie dost\u0119pny by\u0142 tylko przycisk Ewakuacji, kt\u00f3ry jednorazowo przenosi\u0142 kopie zapasowe do innego rozszerzenia.<\/p>\n<p>A Tryb Zwyci\u0119ski to swego rodzaju \u201c\u0142agodna\u201d wersja: zabraniaj\u0105c tworzenia nowych kopii zapasowych i stopniowo usuwaj\u0105c stare zgodnie z wybran\u0105 retencj\u0105, ale w tym procesie nie tracimy mo\u017cliwo\u015bci przywracania z przechowywanych punkt\u00f3w. Bardzo przydatna rzecz, gdy ko\u0144czy si\u0119 czas \u017cycia sprz\u0119tu i trzeba go wymieni\u0107 lub po prostu zwolni\u0107 na co\u015b wa\u017cniejszego, a przenoszenie wszystkiego naraz jest niemo\u017cliwe lub nie mo\u017cna usun\u0105\u0107. <\/p>\n<p>W zwi\u0105zku z tym zasada dzia\u0142ania jest do\u015b\u0107 prosta: trzeba zabroni\u0107 wszystkich operacji zapisu (pojawianie si\u0119 nowych danych), pozostawiaj\u0105c odczyty (przywr\u00f3cenia) i usuwanie (retencj\u0119).<\/p>\n<p>Oba tryby mo\u017cna u\u017cywa\u0107 jednocze\u015bnie, tylko trzeba pami\u0119ta\u0107, \u017ce Tryb Utrzymania ma wy\u017cszy priorytet.<\/p>\n<p>Jako przyk\u0142ad rozwa\u017cmy SOBR sk\u0142adaj\u0105cy si\u0119 z dw\u00f3ch rozszerze\u0144. Za\u0142\u00f3\u017cmy, \u017ce przez pierwsze cztery dni tworzone by\u0142y kopie zapasowe w trybie Forward Forever Incremental, a potem zamykamy rozszerzenie. To prowadzi do tego, \u017ce inicjujemy stworzenie nowego aktywnego pe\u0142nego na drugim dost\u0119pnym rozszerzeniu. Je\u015bli nasza retencja wynosi cztery, to gdy ca\u0142y \u0142a\u0144cuch znajduj\u0105cy si\u0119 na zamkni\u0119tym rozszerzeniu przekroczy jego granice, mo\u017ce by\u0107 z czystym sumieniem usuni\u0119ty.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u0105 sytuacje, kiedy usuni\u0119cie nast\u0119puje wcze\u015bniej. Na przyk\u0142ad, podczas Forward incremental z okresowymi pe\u0142nymi kopami. Je\u015bli przez pierwsze dwa dni tworzyli\u015bmy pe\u0142ne kopie zapasowe, a w czwartek postanawiamy zablokowa\u0107 repozytorium, to w pi\u0105tek, kiedy powstanie nowa pe\u0142na kopia, plik z poniedzia\u0142ku zostanie usuni\u0119ty, poniewa\u017c do tego punktu nie ma zale\u017cno\u015bci. Sam punkt nie zale\u017cy od nikogo. Nast\u0119pnie czekamy, a\u017c zostan\u0105 utworzone cztery punkty na dost\u0119pnym zakresie i usuwamy pozosta\u0142e trzy, kt\u00f3re nie mog\u0105 by\u0107 usuni\u0119te niezale\u017cnie od siebie.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPro\u015bciej sprawa wygl\u0105da z Reverse Incremental. W nim najstarsze punkty nie zale\u017c\u0105 od niczego i mog\u0105 by\u0107 swobodnie usuni\u0119te. Dlatego, gdy tylko zostanie utworzony nowy plik .vbk na nowym zakresie, stare .vrb b\u0119d\u0105 usuwane po jednym.<\/p>\n<p>Nawiasem m\u00f3wi\u0105c, dlaczego za ka\u017cdym razem tworzymy nowy .vbk: gdyby\u015bmy go nie tworzyli, a kontynuowali star\u0105 seri\u0119 przyrost\u00f3w, stary .vbk zawiesi\u0142by si\u0119 na niesko\u0144czenie d\u0142ugi czas w ka\u017cdym trybie, uniemo\u017cliwiaj\u0105c jego usuni\u0119cie. Dlatego podj\u0119to decyzj\u0119, \u017ce gdy tylko zakres zostanie zablokowany, tworzymy pe\u0142n\u0105 kopi\u0119 zapasow\u0105 na wolnym zakresie.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSprawy s\u0105 bardziej skomplikowane z kapacity tier. <\/p>\n<p>Najpierw rozwa\u017cmy tryb copy. Za\u0142\u00f3\u017cmy, \u017ce przez cztery dni aktywnie tworzono kopie zapasowe, a nast\u0119pnie kapacity tier zosta\u0142 zablokowany. Nie usuwamy nic, tylko cierpliwie czekamy na retencj\u0119, a potem usuwamy dane z kapacity tiera.<\/p>\n<p>Podobnie sprawa wygl\u0105da w trybie move \u2014 czekamy na retencj\u0119, usuwamy stare w lokalnym magazynie, usuwamy to, co jest przechowywane w obiektowym sk\u0142adowisku.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCiekawy przyk\u0142ad z Forever forward incremental. Ustawiamy retencj\u0119 na trzy punkty i zaczynamy od poniedzia\u0142ku tworzy\u0107 kopie zapasowe, kt\u00f3re sumiennie kopiuj\u0105 si\u0119 do chmury. Po zablokowaniu magazynu, kopie zapasowe nadal si\u0119 tworz\u0105, utrzymuj\u0105c trzy punkty, ale dane przechowywane w kapacity tier pozostaj\u0105 zale\u017cne i nie mog\u0105 by\u0107 usuni\u0119te. Dlatego czekamy na czwartek, kiedy nasz .vbk wychodzi poza ramy retencji, i dopiero wtedy spokojnie usuwamy ca\u0142y zapisany \u0142a\u0144cuch.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI ma\u0142e zastrze\u017cenie: wszystkie przyk\u0142ady pokazane tutaj dotycz\u0105 jednej maszyny. Je\u015bli w kopii zapasowej jest ich kilka, to retencja b\u0119dzie r\u00f3\u017cna w zale\u017cno\u015bci od tego, czy zosta\u0142a wykonana Active Full, czy nie.<\/p>\n<p>Na tym w zasadzie wszystko. Przechodzimy do najtrudniejszej funkcji \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nJak w przypadku wcze\u015bniejszych punkt\u00f3w, na pocz\u0105tku om\u00f3wmy, jaki problem rozwi\u0105zuje ta funkcja. Gdy tylko przesy\u0142amy nasze kopie zapasowe gdzie\u015b na przechowanie, pojawia si\u0119 silna potrzeba zapewnienia ich bezpiecze\u0144stwa, czyli fizycznego zakazu ich usuwania oraz jakiejkolwiek modyfikacji w trakcie okre\u015blonego okresu retencji. W tym tak\u017ce przez administrator\u00f3w, r\u00f3wnie\u017c pod ich kontami roota. Pozwala to chroni\u0107 je przed przypadkowym lub zamierzonym uszkodzeniem. Osoby pracuj\u0105ce z AWS mog\u0142y spotka\u0107 si\u0119 z podobn\u0105 funkcj\u0105 pod nazw\u0105 Object Lock.<\/p>\n<p>Teraz om\u00f3wimy tryb w og\u00f3lnych s\u0142owach, a potem zag\u0142\u0119bimy si\u0119 w szczeg\u00f3\u0142y. W naszym przyk\u0142adzie Immutability b\u0119dzie w\u0142\u0105czony dla naszego pojemno\u015bci tira z retencj\u0105 wynosz\u0105c\u0105 cztery dni. A w kopii zapasowej w\u0142\u0105czono tryb Copy.<\/p>\n<p>Immutability nie wsp\u00f3\u0142dzia\u0142a w \u017caden spos\u00f3b z og\u00f3ln\u0105 retencj\u0105. Na przyk\u0142ad, nie dodaje dodatkowych punkt\u00f3w ani nic podobnego. Po prostu przez cztery dni cz\u0142owiek nie mo\u017ce usun\u0105\u0107 plik\u00f3w kopii zapasowych. Je\u017celi w poniedzia\u0142ek wykonamy kopi\u0119 zapasow\u0105, to usuni\u0119cie jej pliku b\u0119dzie mo\u017cliwe dopiero w pi\u0105tek.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWszystkie wcze\u015bniej om\u00f3wione koncepcje dehydratacji, indeks\u00f3w i metadanych nadal dzia\u0142aj\u0105 dok\u0142adnie tak samo. Ale z jednym zastrze\u017ceniem \u2014 blok wystawiany jest nie tylko dla danych, ale i dla metadanych. Zosta\u0142o to zrobione na wypadek, gdyby podst\u0119pny przest\u0119pca postanowi\u0142 usun\u0105\u0107 nasz\u0105 baz\u0119 metadanych, aby bloki z danymi nie zamieni\u0142y si\u0119 w bezu\u017cyteczn\u0105 binarn\u0105 papk\u0119.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI teraz nasta\u0142 doskona\u0142y moment na wyja\u015bnienie naszej technologii generowania blok\u00f3w. Albo block generation. W tym celu rozwa\u017cmy sytuacj\u0119, kt\u00f3ra doprowadzi\u0142a do jej powstania.<\/p>\n<p>We take a timeline of six days and mark the expected expiration time of immutability at the bottom. On the first day, we create a file consisting of data block a and its metadata. If immutability is set for three days, it is logical to assume that on the fourth day the data will be unlocked and deleted. On the second day, we will add a new file2 consisting of block b with the same settings. Block a should still be deleted on the fourth day. But on the third day, something terrible happens \u2014 a file File3 is created, consisting of a new block d and a reference to the old block a. This means that for block a its immutability flag must be reset for a new term, which is postponed to the sixth day. And here arises the problem \u2014 in real backups of such blocks, an enormous amount is generated. To extend their immutability period, it is necessary to make a huge number of requests each time. And in fact, this will be an almost endless daily process, as there is a high probability that we will find large batches of deduplicated blocks with each copy. And what does a large number of requests mean for object storage providers? Right! A huge bill at the end of the month.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo avoid charging my valued clients an excessive amount for no reason, a mechanism called block generation was devised. This is an additional period that we add to the specified immutability period. In the example below, this period equals two days. But this is just for illustration. In reality, a specific formula is used that provides approximately ten additional days for a monthly lock. <\/p>\n<p>Przyjrzymy si\u0119 tej samej sytuacji, ale z generowaniem blok\u00f3w. Tworzymy w pierwszy dzie\u0144 file1 z bloku a i metadanych. Sumujemy okresy generacji i immutability \u2014 oznacza to, \u017ce mo\u017cliwo\u015b\u0107 usuni\u0119cia pliku b\u0119dzie na sz\u00f3sty dzie\u0144. Je\u015bli w drugim dniu stworzymy File2, sk\u0142adaj\u0105cy si\u0119 z bloku b i odno\u015bnika do bloku a, to przewidywana data usuni\u0119cia nie zmieni si\u0119. Pozostaje na sz\u00f3sty dzie\u0144. W ten spos\u00f3b staramy si\u0119 zaoszcz\u0119dzi\u0107 pieni\u0105dze na liczbie zapyta\u0144. Jedyn\u0105 sytuacj\u0105, w kt\u00f3rej termin mo\u017ce by\u0107 przesuni\u0119ty, jest up\u0142yw okresu generacji. To znaczy, je\u015bli trzeciego dnia nowy File3 b\u0119dzie zawiera\u0107 odno\u015bnik do bloku a, to zostanie dodana generacja 2, poniewa\u017c Gen1 ju\u017c wygas\u0142a. A przewidywana data usuni\u0119cia bloku a przesunie si\u0119 na \u00f3smy dzie\u0144. Pozwoli to drastycznie zmniejszy\u0107 liczb\u0119 zapyta\u0144 o przed\u0142u\u017cenie czasu \u017cycia zduplikowanych blok\u00f3w, co oszcz\u0119dza mn\u00f3stwo pieni\u0119dzy dla klient\u00f3w.<\/p>\n<p><img decoding=\"async\" alt=\"Jak zmieni\u0142 si\u0119 Capacity Tier, gdy Veeam przeszed\u0142 na v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTechnologia ta jest dost\u0119pna dla u\u017cytkownik\u00f3w S3 oraz sprz\u0119tu zgodnego z S3, kt\u00f3rego producenci gwarantuj\u0105, \u017ce ich implementacja nie r\u00f3\u017cni si\u0119 od amazonowej. St\u0105d odpowied\u017a na uzasadnione pytanie, dlaczego Azure nie jest wspierane \u2014 maj\u0105 podobn\u0105 funkcj\u0119, ale dzia\u0142a ona na poziomie kontener\u00f3w, a nie pojedynczych obiekt\u00f3w. Swoj\u0105 drog\u0105, w samym Amazonie object lock wyst\u0119puje w dw\u00f3ch trybach: compliance i governance. W drugim przypadku pozostaje mo\u017cliwo\u015b\u0107, aby najpot\u0119\u017cniejszy administrator nad administratorami i root nad rootami, mimo object lock, jednak usun\u0105\u0142 dane. W przypadku compliance wszystko jest trwa\u0142e i nikt, nawet admini Amazona (wed\u0142ug ich oficjalnych o\u015bwiadcze\u0144), nie ma mo\u017cliwo\u015bci usuni\u0119cia kopii zapasowych. Wspieramy w\u0142a\u015bnie ten tryb.<\/p>\n<p>\nI, tradycyjnie, kilka przydatnych link\u00f3w:<\/p>\n<ul>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generowanie blok\u00f3w<\/a><\/noindex> we wszystkich szczeg\u00f3\u0142ach.<\/li>\n<li>Wszystkie informacje o <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> w najlepszej formie<\/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> w szczeg\u00f3\u0142ach<\/li>\n<\/ul>\n<p>\u0179r\u00f3d\u0142o: <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.1.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\/pl\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\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\/pl\/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\udd47Co zmieni\u0142o si\u0119 w Capacity Tier, kiedy Veeam sta\u0142 si\u0119 v10 | ProHoster","description":"Capacity Tier (lub jak nazywamy to u nas wewn\u0119trznie \u2014 kaptier) pojawi\u0142 si\u0119 ju\u017c w czasach Veeam Backup and Replication 9.5 Update 4 pod nazw\u0105 Archive Tier.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}