{"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\/sv\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Kapacitetsteamet (eller som vi kallar det internt \u2014 kaptir) introducerades redan under Veeam Backup and Replication 9.5 Update 4 under namnet Archive Tier. Id\u00e9n bakom det \u00e4r att ge m\u00f6jlighet att flytta backuper som har fallit utanf\u00f6r det s\u00e5 kallade operationella \u00e5terst\u00e4llningsf\u00f6nstret till objektlagring. Detta hj\u00e4lpte till att frig\u00f6ra diskutrymme f\u00f6r anv\u00e4ndare som hade ont om det. Denna funktion kallades Move Mode.<\/p>\n<p>F\u00f6r att utf\u00f6ra denna relativt enkla (som det verkar) \u00e5tg\u00e4rd kr\u00e4vdes det att tv\u00e5 villkor uppfylls: alla punkter fr\u00e5n den flyttade backupen m\u00e5ste ligga utanf\u00f6r det ovan n\u00e4mnda operationella \u00e5terst\u00e4llningsf\u00f6nstret, vilket anges tydligt i anv\u00e4ndargr\u00e4nssnittet. Och f\u00f6r det andra: kedjan m\u00e5ste vara i s\u00e5 kallad \"f\u00f6rseglad form\" (sealed backup chain eller Inactive Backup Chain). Det betyder att det inte sker n\u00e5gra f\u00f6r\u00e4ndringar i kedjan \u00f6ver tid.<\/p>\n<p>Men i VBR v10 kompletterades konceptet med nya funktioner \u2014 Copy Mode, Sealed Mode och en grej med det sv\u00e5ra namnet Immutability d\u00f6k upp.<\/p>\n<p>Det \u00e4r om dessa fascinerande saker vi kommer att prata idag. F\u00f6rst om hur det fungerade i VBR9.5u4 och sedan om f\u00f6r\u00e4ndringarna i den tionde versionen.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch f\u00f6rl\u00e5t mig spr\u00e5kv\u00e5rdare, men det finns f\u00f6r m\u00e5nga termer som \u00e4r om\u00f6jliga att \u00f6vers\u00e4tta.<br \/>\nS\u00e5 h\u00e4r kommer det att vara fullt av anglicismer.<br \/>\nOch m\u00e5nga gifar. <br \/>\nOch bilder.<\/p>\n<ul>\n<li>Utan minsta sorg. Artikelns f\u00f6rfattare.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Som det var<\/h1>\n<p>\nS\u00e5, vi b\u00f6rjar med att diskutera operationella \u00e5terst\u00e4llningsf\u00f6nstret och sealed backup (eller som de kallas i dokumentationen Inactive Backup Chain). Utan f\u00f6rst\u00e5elsen av dessa tv\u00e5 g\u00e5r det inte att f\u00f6rklara vidare.<\/p>\n<p>Som vi ser p\u00e5 bilden har vi en viss backupkedja med datablokkar, som ligger p\u00e5 Performance tier av SOBR-repositoriet, som \u00e4r kopplat till Capacity Tier. V\u00e5rt operationella backupf\u00f6nster \u00e4r tre dagar.<\/p>\n<p>D\u00e4rmed f\u00f6rseglade den skapade .vbk-filen kedjan som har ett f\u00f6nster inst\u00e4llt p\u00e5 tre dagar. Och det betyder att man lugnt kan b\u00f6rja flytta till kapacitetstier allt som \u00e4r \u00e4ldre \u00e4n dessa tre dagar.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen vad menades egentligen med en sealed kedja och vad kunde skickas till kapacitetstier i update 4?<\/p>\n<p>F\u00f6r Forward Incremental \u00e4r k\u00e4nnetecknet f\u00f6r att kedjan \u00e4r f\u00f6rseglad att en ny full backup skapas. Och det spelar ingen roll hur denna fulla backup erh\u00e5lls: b\u00e5de syntetiska fullbackuper och aktiva fullbackuper r\u00e4knas.<\/p>\n<p>I fallet Reverse \u00e4r det alla filer som inte faller inom det operationella f\u00f6nstret. <\/p>\n<p>I fallet Forward increment med rollbacks \u00e4r det alla rollbacks och .vbk, om det finns en annan .vbk p\u00e5 performance extenten.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNu ska vi titta p\u00e5 alternativet att arbeta med Backup Copy-kedjor. H\u00e4r bevarades endast det som omfattades av GFS-retention. Eftersom allt som finns i nyare backup copy-kedjor kan p\u00e5 olika s\u00e4tt ha \u00e4ndrats.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNu ser vi under huven. D\u00e4r sker en process som kallas dehydrering - att l\u00e4mna tomma backupfiler p\u00e5 extenten och flytta block fr\u00e5n dessa filer till capacity tier. F\u00f6r att optimera denna process anv\u00e4nds en s\u00e5 kallad dehydrering-index som g\u00f6r att vi inte beh\u00f6ver kopiera block som redan har kopierats till capacity tier. <\/p>\n<p>L\u00e5t oss se hur detta ser ut med ett exempel: l\u00e5t oss anta att vi har en .vbk som har g\u00e5tt ut fr\u00e5n det operationella f\u00f6nstret och tillh\u00f6r en f\u00f6rseglad kedja. Det betyder att vi har full r\u00e4tt att flytta den till capacity tier. N\u00e4r vi flyttar skapas en metadatas fil i capacity tier och blocken fr\u00e5n den flyttade filen. I metadatafilen p\u00e5 l\u00e4nkiv\u00e5 beskrivs av vilka block v\u00e5r fil best\u00e5r. I bilden best\u00e5r v\u00e5r f\u00f6rsta fil av blocken a, b, c och i metadata finns l\u00e4nkar till dessa block. N\u00e4r vi f\u00e5r en andra .vbk-fil, redo att flytta och best\u00e5ende av block a, b och d, f\u00f6rst\u00e5r vi genom att analysera dehydrering-index att vi bara beh\u00f6ver flytta block d. Dess metadatafil kommer att inneh\u00e5lla l\u00e4nkar till de tv\u00e5 tidigare blocken och ett nytt.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nD\u00e4rf\u00f6r kallas processen f\u00f6r att fylla dessa tomma block med data f\u00f6r rehydrering. H\u00e4r anv\u00e4nds redan sitt eget rehydrering-index som baseras p\u00e5 den \u00e4ldsta .vbk-filen p\u00e5 den lokala performance extenten. Det vill s\u00e4ga, om anv\u00e4ndaren vill \u00e5terst\u00e4lla en fil fr\u00e5n capacity tier, skapar vi f\u00f6rst en index \u00f6ver blocken fr\u00e5n den \u00e4ldsta fulla backupen och flyttar endast de saknade blocken fr\u00e5n capacity tier. I det visade fallet, f\u00f6r att rehydrera FullBackup1.vbk enligt rehydrering-indexet saknar vi endast block C, som vi h\u00e4mtar fr\u00e5n capacity tier. Om capacity tier \u00e4r en molnlagringsl\u00f6sning sparar detta enorma pengar.<\/p>\n<p>H\u00e4r kan det verka som att denna teknik \u00e4r identisk med den som anv\u00e4nds i WAN Accelerators, men det \u00e4r bara en illusion. I acceleratorer sker en global deduplicering, medan h\u00e4r anv\u00e4nds lokal deduplicering inom varje fil baserat p\u00e5 ett visst offset. Detta beror p\u00e5 skillnaden i de uppgifter som ska l\u00f6sas: h\u00e4r beh\u00f6ver vi kopiera stora filer av fullst\u00e4ndiga s\u00e4kerhetskopior, och enligt v\u00e5ra unders\u00f6kningar ger en s\u00e5dan dedupliceringsalgoritm b\u00e4ttre resultat \u00e4ven om det g\u00e5r l\u00e5ng tid mellan dem.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen fler index till indexens gud! Det finns ocks\u00e5 ett index f\u00f6r \u00e5terst\u00e4llning av data! N\u00e4r vi p\u00e5b\u00f6rjar \u00e5terst\u00e4llningen av en maskin som ligger i ett kapacitetsterr\u00e4ng, l\u00e4ser vi bara de unika databloken som inte finns i prestandaterr\u00e4ng.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Som det blev<\/h1>\n<p>\nDetta avslutar introduktionen. Den \u00e4r ganska detaljerad, men som n\u00e4mnts ovan g\u00e5r det inte att f\u00f6rklara hur de nya funktionerna fungerar utan dessa detaljer. S\u00e5 utan fler f\u00f6rord \u00f6verg\u00e5r vi till det f\u00f6rsta.<\/p>\n<h3>Kopieringsl\u00e4get<\/h3>\n<p>\n\u00c4ven om det till stor del bygger p\u00e5 existerande teknologier, b\u00e4r det med sig en helt annan logik f\u00f6r anv\u00e4ndning.\u00a0<\/p>\n<p>M\u00e5let med detta l\u00e4ge \u00e4r att s\u00e4kerst\u00e4lla att all data som finns p\u00e5 det lokala utrymmet har en kopia i kapacitetsterr\u00e4ngen.<\/p>\n<p>Om vi j\u00e4mf\u00f6r Move och Copy-l\u00e4gena direkt, ser det ut s\u00e5 h\u00e4r:<\/p>\n<ul>\n<li>Flyttning kan endast ske f\u00f6r en l\u00e5st kedja. I kopieringsl\u00e4get transporteras allt, oavsett vad som h\u00e4nder i s\u00e4kerhetskopieringsjobbet.<\/li>\n<li>Flyttning aktiveras n\u00e4r filer g\u00e5r utanf\u00f6r f\u00f6nstret f\u00f6r operationell s\u00e4kerhetskopiering, medan kopiering aktiveras s\u00e5 snart s\u00e4kerhetskopieringsfilen blir tillg\u00e4nglig.<\/li>\n<li>\u00d6vervakning av nya data f\u00f6r kopiering sker kontinuerligt, medan flyttning aktiverades var fj\u00e4rde timme.<\/li>\n<\/ul>\n<p>\nVid framst\u00e4llningen av det nya l\u00e4get f\u00f6resl\u00e5r jag att vi b\u00f6rjar med enkla exempel och g\u00e5r mot mer komplicerade.<\/p>\n<p>I det mest grundl\u00e4ggande fallet dyker det helt enkelt upp nya filer med inkrement, och vi kopierar dem till kapacitetsterr\u00e4ngen. Oavsett vilket l\u00e4ge som anv\u00e4nds i s\u00e4kerhetskopieringsjobbet, oavsett om det h\u00f6r till den l\u00e5sta delen av kedjan eller inte, oavsett om v\u00e5rt operationella f\u00f6nster har l\u00f6pt ut. Vi tog bara och kopierade.<\/p>\n<p>Processen bakom detta \u00e4r fortfarande dehydrering p\u00e5 det s\u00e4tt som beskrivits ovan. I kopieringsl\u00e4ge ser den \u00e4ven till att vi inte kopierar block som redan finns i v\u00e5rt objektlager. Den enda skillnaden \u00e4r att om vi i flyttl\u00e4ge ersatte riktiga filer med platsh\u00e5llarfiler, s\u00e5 r\u00f6r vi dem inte h\u00e4r utan l\u00e4mnar allt som det \u00e4r. I \u00f6vrigt \u00e4r detta precis samma dehydreringindex som noggrant f\u00f6rs\u00f6ker spara dina pengar och tid.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFr\u00e5gan uppst\u00e5r \u2014 om man tittar p\u00e5 anv\u00e4ndargr\u00e4nssnittet finns det m\u00f6jlighet att v\u00e4lja b\u00e5da alternativen samtidigt. Hur kommer ett s\u00e5dant kombinerat l\u00e4ge att fungera?<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL\u00e5t oss reda ut detta.<\/p>\n<p>Inledningen \u00e4r standard: en backupfil skapas och kopieras direkt. En inkrement skapas och kopieras ocks\u00e5. Detta forts\u00e4tter tills vi inser att filer har passerat v\u00e5rt operationella f\u00f6nster och en innesluten kedja har uppst\u00e5tt. Vid denna punkt utf\u00f6r vi dehydrationsoperationen och ers\u00e4tter dessa filer med platsh\u00e5llare. Naturligtvis kopierar vi ingenting tillbaka till kapacitetstj\u00e4rnan.<\/p>\n<p>All denna sp\u00e4nnande logik styrs av bara en kryssruta i gr\u00e4nssnittet: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Men varf\u00f6r beh\u00f6ver vi detta kopieringsl\u00e4ge? <\/h3>\n<p>\nDet \u00e4r \u00e4nnu b\u00e4ttre att omformulera fr\u00e5gan s\u00e5 h\u00e4r \u2014 vilka risker skyddar vi oss ifr\u00e5n med hj\u00e4lp av det? Vilket problem hj\u00e4lper det oss att l\u00f6sa?<\/p>\n<p>Svaret \u00e4r uppenbart: sj\u00e4lvklart handlar det om datar\u00e4ddning. Om vi har en fullst\u00e4ndig kopia av lokala data i objektlagret, s\u00e5 spelar det ingen roll vad som h\u00e4nder med v\u00e5r produktion, vi kan alltid \u00e5terst\u00e4lla data fr\u00e5n filer som finns i den hypotetiska Amazon.<\/p>\n<p>D\u00e4rf\u00f6r l\u00e5t oss g\u00e5 igenom m\u00f6jliga scenarier, fr\u00e5n det enklaste till det mer komplexa.<\/p>\n<p>Den enklaste olyckan som kan drabba oss \u00e4r n\u00e4r en av filerna i backupkedjan blir otillg\u00e4nglig.<\/p>\n<p>En mer sorglig historia \u00e4r om en av extensorna i v\u00e5rt SOBR-repositorium har g\u00e5tt s\u00f6nder.<\/p>\n<p>Det blir \u00e4nnu v\u00e4rre n\u00e4r hela SOBR-repositoriet har blivit otillg\u00e4ngligt, men kapacitetstj\u00e4rnan fungerar.<br \/>\nOch allt \u00e4r verkligen d\u00e5ligt \u2014 det \u00e4r n\u00e4r backupservern d\u00f6r och din f\u00f6rsta impuls \u00e4r att f\u00f6rs\u00f6ka springa till den kanadensiska gr\u00e4nsen p\u00e5 tio minuter.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch nu l\u00e5t oss g\u00e5 igenom varje situation separat.<\/p>\n<p>N\u00e4r vi f\u00f6rlorade en (ja, och till och med flera) backupfiler, r\u00e4cker det med att starta processen f\u00f6r att skanna om lagret, och den f\u00f6rlorade filen ers\u00e4tts av en tom fil. Med hj\u00e4lp av \u00e5terhydratiseringsprocessen (som n\u00e4mnts i inledningen av artikeln) kan anv\u00e4ndaren ladda ner data fr\u00e5n kapacitetslagret till det lokala lagret.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNu blir situationen mer komplicerad. Anta att v\u00e5r SOBR best\u00e5r av tv\u00e5 extenter som arbetar i prestandal\u00e4ge, vilket inneb\u00e4r att v\u00e5ra .vbk och .vib \u00e4r f\u00f6rdelade \u00f6ver dem med ganska oj\u00e4mn t\u00e4ckning. Vid en viss tidpunkt blir en av extenterna otillg\u00e4nglig, och anv\u00e4ndaren beh\u00f6ver snabbt \u00e5terst\u00e4lla en maskin vars data delvis ligger just p\u00e5 denna extention. <\/p>\n<p>Anv\u00e4ndaren startar \u00e5terst\u00e4llningsguiden, v\u00e4ljer en punkt att \u00e5terst\u00e4lla till, och i processen inser guiden att alla n\u00f6dv\u00e4ndiga data f\u00f6r \u00e5terst\u00e4llning inte finns lokalt och d\u00e4rf\u00f6r m\u00e5ste laddas ner fr\u00e5n kapacitetslagret. Under tiden kommer de block som finns kvar p\u00e5 det lokala lagret inte att laddas ner fr\u00e5n molnet. Tack vare restore-indexet (ja, det n\u00e4mndes ocks\u00e5 i inledningen av artikeln).<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn underkategori av detta fall \u00e4r att hela SOBR-lagret blivit otillg\u00e4ngligt. I s\u00e5 fall har vi inget att kopiera fr\u00e5n de lokala lagren, och alla block laddas ner fr\u00e5n molnet.<\/p>\n<p>Och den mest intressanta situationen \u00e4r att backupservern har kraschat. H\u00e4r finns det tv\u00e5 alternativ: administrat\u00f6ren \u00e4r duktig och har gjort konfigurationsbackups, eller s\u00e5 har administrat\u00f6ren sj\u00e4lv varit en elak Puppa och inte gjort en konfigurationsbackup.<\/p>\n<p>I det f\u00f6rsta fallet r\u00e4cker det med att p\u00e5 n\u00e5got s\u00e4tt installera en ren version av VBR och \u00e5terst\u00e4lla dess databas fr\u00e5n backup med hj\u00e4lp av de inbyggda verktygen. I slutet av denna process kommer allt att \u00e5terg\u00e5 till det normala. Eller s\u00e5 kommer \u00e5terst\u00e4llningen att ske enligt n\u00e5got av de ovan n\u00e4mnda scenarierna.<\/p>\n<p>Men om administrat\u00f6ren \u00e4r sin egen fiende, eller om backupkonfigurationen drabbas av en sagolik otur, kommer vi inte att \u00f6verge dem \u00e5t sitt \u00f6de. F\u00f6r detta fall har vi inf\u00f6rt en ny procedur som kallas Import Object Storage. Denna procedur m\u00f6jligg\u00f6r att hoppa \u00f6ver den manuella \u00e5terst\u00e4llningen av SOBR-repositoriet och kopplingen av kapacitetstiran med efterf\u00f6ljande skanning, och helt enkelt l\u00e4gga till objektlagring i Vima-gr\u00e4nssnittet och starta Import Storage Repository- proceduren. Det enda som kan st\u00e5 i v\u00e4gen mellan dig och dina backuper \u00e4r en beg\u00e4ran om att ange ett l\u00f6senord om dina backuper har krypterats.<\/p>\n<p>Detta var allt om Copy Mode, och vi g\u00e5r vidare till<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nDet grundl\u00e4ggande syftet \u00e4r att inga nya backuper f\u00e5r skapas p\u00e5 den valda delen av SOBR-repositoriet. Fram till version 10 hade vi bara Maintenance Mode, d\u00e4r all verksamhet med repositoriet var helt f\u00f6rbjuden. Det var en h\u00e5rd k\u00e4rnprocess som st\u00e4ngde lagringen, d\u00e4r endast knappen Evacuate var tillg\u00e4nglig, vilket en g\u00e5ng f\u00f6rde bort backuperna till en annan del.<\/p>\n<p>Sealed Mode \u00e4r en slags 'mjuk' version: vi f\u00f6rhindrar skapandet av nya backuper och tar gradvis bort gamla enligt den valda retentionen, men f\u00f6rlorar inte m\u00f6jligheten att \u00e5terst\u00e4lla fr\u00e5n de lagrade punkterna. Mycket anv\u00e4ndbart n\u00e4r maskinens livsl\u00e4ngd n\u00e4rmar sig sitt slut och den beh\u00f6ver bytas ut, eller n\u00e4r den helt enkelt beh\u00f6ver frig\u00f6ras f\u00f6r n\u00e5got viktigare, och det finns ingen m\u00f6jlighet att flytta allt p\u00e5 en g\u00e5ng. Eller s\u00e5 kan det vara om\u00f6jligt att ta bort. <\/p>\n<p>D\u00e4rf\u00f6r \u00e4r arbetsprincipen ganska enkel: man m\u00e5ste f\u00f6rbjuda alla skrivoperationer (skapande av nya data), och l\u00e4mna l\u00e4sningar (\u00e5terst\u00e4llningar) och radering (retention).<\/p>\n<p>B\u00e5da l\u00e4gena kan anv\u00e4ndas samtidigt, men man m\u00e5ste ocks\u00e5 beakta att Maintenance har h\u00f6gre prioritet.<\/p>\n<p>Som exempel \u00f6verv\u00e4ger vi en SOBR best\u00e5ende av tv\u00e5 delar. Anta att vi under de f\u00f6rsta fyra dagarna skapat backuper i l\u00e4get Forward Forever Incremental, och sedan st\u00e4nger vi den ena delen. Detta leder till att vi initierar skapandet av en ny aktiv full \u00e5terst\u00e4llning p\u00e5 den andra tillg\u00e4ngliga delen. Om v\u00e5r retention \u00e4r fyra, d\u00e5 n\u00e4r hela kedjan som ligger p\u00e5 den st\u00e4ngda delen \u00f6verskrider dess gr\u00e4nser, kan den utan bet\u00e4nkligheter tas bort.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet finns situationer d\u00e4r raderingen sker tidigare. Till exempel \u00e4r detta fallet med Forward incremental med periodiska fulla s\u00e4kerhetskopior. Om vi har skapat fulla s\u00e4kerhetskopior de f\u00f6rsta tv\u00e5 dagarna, och p\u00e5 torsdag best\u00e4mmer vi oss f\u00f6r att st\u00e4nga lagringsutrymmet, s\u00e5 n\u00e4r vi p\u00e5 fredag skapar en ny fullst\u00e4ndig s\u00e4kerhetskopiering kommer filen fr\u00e5n m\u00e5ndag att raderas eftersom det vid denna tidpunkt inte finns n\u00e5gra beroenden. Och sj\u00e4lva punkten \u00e4r inte beroende av n\u00e5gon annan. D\u00e4refter v\u00e4ntar vi tills fyra punkter har skapats p\u00e5 det tillg\u00e4ngliga utrymmet och raderar de tre kvarst\u00e5ende, som inte kan raderas oberoende av varandra.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet \u00e4r enklare med Reverse Incremental. I det fallet \u00e4r de \u00e4ldsta punkterna oberoende och kan raderas utan problem. S\u00e5 snart det nya .vbk har skapats p\u00e5 det nya utrymmet, kommer de gamla .vrb att raderas en och en.<\/p>\n<p>F\u00f6r \u00f6vrigt, varf\u00f6r skapar vi varje g\u00e5ng en ny .vbk: om vi inte g\u00f6r det och forts\u00e4tter den gamla inkrementella kedjan, skulle den gamla .vbk h\u00e4nga kvar f\u00f6r en o\u00e4ndligt l\u00e5ng tid i vilket l\u00e4ge som helst, vilket hindrar radering. D\u00e4rf\u00f6r fattades beslutet att s\u00e5 snart utrymmet st\u00e4ngs, skapar vi en fullst\u00e4ndig s\u00e4kerhetskopiering p\u00e5 ett ledigt utrymme.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSv\u00e5rare \u00e4r situationen med kapacitetstira. <\/p>\n<p>F\u00f6rst ser vi p\u00e5 copy mode. Anta att vi har skapat s\u00e4kerhetskopior aktivt i fyra dagar, och sedan st\u00e4ngdes kapacitetstiran. Vi raderar ingenting, utan t\u00e5lamod v\u00e4ntar vi p\u00e5 retentionen, varefter vi raderar data fr\u00e5n kapacitetstiran.<\/p>\n<p>Ungef\u00e4r samma sak h\u00e4nder i move mode \u2014 vi v\u00e4ntar p\u00e5 retentionen, raderar det gamla i det lokala lagret och raderar det som lagras i objektlagret.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEtt intressant exempel med Forever forward incremental. Vi st\u00e4ller retentionen till tre punkter och b\u00f6rjar g\u00f6ra s\u00e4kerhetskopior fr\u00e5n m\u00e5ndag, som p\u00e5litligt kopieras till molnet. Efter att lagringen st\u00e4ngts forts\u00e4tter s\u00e4kerhetskopiorna att skapas, vilket uppr\u00e4tth\u00e5ller tre punkter, men de data som lagras i kapacitetstiran f\u00f6rblir beroende och kan inte raderas. D\u00e4rf\u00f6r v\u00e4ntar vi till torsdag n\u00e4r v\u00e5r .vbk g\u00e5r utanf\u00f6r retentionen, och f\u00f6rst d\u00e5 raderar vi hela den sparade kedjan.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch en liten kommentar: alla exempel h\u00e4r visas med en maskin. Om ni har flera i s\u00e4kerhetskopian kommer retentionen att skilja sig beroende p\u00e5 om en Aktiv Full har gjorts eller inte.<\/p>\n<p>Detta \u00e4r, i princip, allt. S\u00e5 vi g\u00e5r vidare till den mest hardcore-funktionen \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nPrecis som med de tidigare punkterna, b\u00f6rjar vi med att f\u00f6rklara vilket problem denna funktion l\u00f6ser. S\u00e5 snart vi laddar upp v\u00e5ra s\u00e4kerhetskopior f\u00f6r lagring, uppst\u00e5r en stark \u00f6nskan att garantera deras s\u00e4kerhet, det vill s\u00e4ga att fysiskt f\u00f6rbjuda deras radering och all modifiering under den angivna retentionstiden. Detta inkluderar administrat\u00f6rer, \u00e4ven under deras root-konton. Detta g\u00f6r det m\u00f6jligt att skydda dem mot oavsiktlig eller avsiktlig skada. Den som arbetar med AWS kan ha st\u00f6tt p\u00e5 en liknande funktion kallad Object Lock.<\/p>\n<p>L\u00e5t oss nu titta p\u00e5 l\u00e4get i allm\u00e4nna ordalag, och sedan dyka djupare in i detaljerna. I v\u00e5rt exempel kommer Immutability att aktiveras f\u00f6r v\u00e5r kapacitetstier med en retention p\u00e5 fyra dagar. Och i s\u00e4kerhetskopian aktiveras kopieringsl\u00e4get.<\/p>\n<p>Immutability interagerar inte med den allm\u00e4nna retentionen. Till exempel l\u00e4gger det inte till n\u00e5gra extra punkter eller liknande. Under fyra dagar kan personen inte ta bort s\u00e4kerhetskopiornas filer. Om en s\u00e4kerhetskopia g\u00f6rs p\u00e5 m\u00e5ndag, kan filen tas bort f\u00f6rst p\u00e5 fredag.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlla tidigare f\u00f6rklarade koncept av dehydrering, index och metadata forts\u00e4tter att fungera p\u00e5 exakt samma s\u00e4tt. Men med ett villkor \u2014 blocket s\u00e4tts inte bara f\u00f6r datan, utan ocks\u00e5 f\u00f6r metadata. Detta g\u00f6rs ifall en listig angripare skulle besluta att radera v\u00e5r metadata-databas, s\u00e5 att datablocken inte f\u00f6rvandlas till en meningsl\u00f6s bin\u00e4r r\u00f6ra.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch nu \u00e4r det ett utm\u00e4rkt tillf\u00e4lle att f\u00f6rklara v\u00e5r blockgenereringsteknik. Eller block generation. F\u00f6r detta kommer vi att betrakta situationen som ledde till dess uppkomst.<\/p>\n<p>L\u00e5t oss ta en tidslinje p\u00e5 sex dagar och markera tiden f\u00f6r f\u00f6rv\u00e4ntad utg\u00e5ng av immutability l\u00e4ngst ner. Vi skapar en fil p\u00e5 den f\u00f6rsta dagen som best\u00e5r av datablocket a och dess metadata. Om immutability \u00e4r inst\u00e4llt p\u00e5 tre dagar, \u00e4r det rimligt att anta att data kommer att l\u00e5sas upp och tas bort p\u00e5 den fj\u00e4rde dagen. P\u00e5 den andra dagen l\u00e4gger vi till en ny file2 som best\u00e5r av block b med samma inst\u00e4llningar. Block a b\u00f6r fortfarande tas bort p\u00e5 den fj\u00e4rde dagen. Men p\u00e5 den tredje dagen h\u00e4nder n\u00e5got hemskt \u2014 en fil File3 skapas som best\u00e5r av det nya blocket d och en l\u00e4nk till det gamla blocket a. Detta inneb\u00e4r att immutability-flagg f\u00f6r block a m\u00e5ste st\u00e4llas om till en ny period, som flyttas till den sj\u00e4tte dagen. Och h\u00e4r uppst\u00e5r problemet \u2014 i verkliga s\u00e4kerhetskopior av s\u00e5dana block uppst\u00e5r en stor m\u00e4ngd. F\u00f6r att f\u00f6rl\u00e4nga deras immutability-period m\u00e5ste vi hela tiden g\u00f6ra en stor m\u00e4ngd f\u00f6rfr\u00e5gningar. Detta blir i praktiken en n\u00e4stan o\u00e4ndlig daglig process, eftersom vi med stor sannolikhet kommer att hitta stora h\u00f6gar av deduplicerade block vid varje kopiering. Vad inneb\u00e4r detta stora antal f\u00f6rfr\u00e5gningar f\u00f6r leverant\u00f6rer av objektlagring? R\u00e4tt! En enorm r\u00e4kning i slutet av m\u00e5naden.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOch f\u00f6r att inte fakturera sina \u00e4lskade kunder med stora summor f\u00f6r inget, har mekanismen block generation skapats. Detta \u00e4r en till\u00e4ggsperiod som vi l\u00e4gger till den befintliga immutability-perioden. I exemplet nedan \u00e4r en s\u00e5dan period tv\u00e5 dagar. Men detta \u00e4r bara f\u00f6r exemplet. I verkligheten anv\u00e4nds en egen formel som ger ungef\u00e4r tio ytterligare dagar vid en m\u00e5nads l\u00e5s. <\/p>\n<p>Vi forts\u00e4tter att \u00f6verv\u00e4ga samma situation, men med blockgenerering. Den f\u00f6rsta dagen skapar vi filen file1 fr\u00e5n block a och metadata. Vi sammanst\u00e4ller generationsperioden och of\u00f6r\u00e4nderliga data \u2014 vilket inneb\u00e4r att filen kan tas bort f\u00f6rst p\u00e5 sj\u00e4tte dagen. Om vi p\u00e5 andra dagen skapar File2, som best\u00e5r av block b och en l\u00e4nk till block a, h\u00e4nder inget med den f\u00f6rv\u00e4ntade borttagningsdatumet. Den f\u00f6rblev som tidigare p\u00e5 sj\u00e4tte dagen. Vi f\u00f6rs\u00f6ker s\u00e5ledes spara pengar p\u00e5 antalet f\u00f6rfr\u00e5gningar. Den enda situation d\u00e4r tidsperioden kan flyttas \u00e4r om generationsperioden har g\u00e5tt ut. Om det p\u00e5 tredje dagen nya File3 inneh\u00e5ller en l\u00e4nk till block a, kommer generation 2 att l\u00e4ggas till eftersom Gen1 redan har g\u00e5tt ut. Det f\u00f6rv\u00e4ntade borttagningsdatumet f\u00f6r block a flyttas d\u00e5 till \u00e5ttonde dagen. Detta g\u00f6r att vi dramatiskt kan minska antalet f\u00f6rfr\u00e5gningar f\u00f6r att f\u00f6rl\u00e4nga livsl\u00e4ngden f\u00f6r deduplicerade block, vilket sparar mycket pengar f\u00f6r kunderna.<\/p>\n<p><img decoding=\"async\" alt=\"Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSj\u00e4lva teknologin \u00e4r tillg\u00e4nglig f\u00f6r S3-anv\u00e4ndare och S3-kompatibel h\u00e5rdvara, vars tillverkare garanterar att deras implementationer inte skiljer sig fr\u00e5n Amazons. D\u00e4rf\u00f6r svarar vi p\u00e5 den ber\u00e4ttigade fr\u00e5gan om varf\u00f6r Azure inte st\u00f6ds \u2014 de har en liknande funktion, men den fungerar p\u00e5 kontoniv\u00e5, inte p\u00e5 enskilda objekt. F\u00f6rresten, i sj\u00e4lva Amazon finns objektlokalisering i tv\u00e5 l\u00e4gen: compliance och governance. I det andra fallet finns m\u00f6jligheten kvar f\u00f6r den h\u00f6gsta administrat\u00f6ren av alla administrat\u00f6rer och roten av alla r\u00f6tter, trots objektlokaliseringen, att radera data. I compliance-l\u00e4get \u00e4r allt spikat f\u00f6r alltid och ingen kan ta bort s\u00e4kerhetskopior, inte ens Amazons administrat\u00f6rer (enligt deras officiella uttalanden). Vi st\u00f6der just det l\u00e4get.<\/p>\n<p>\nOch, traditionellt, lite anv\u00e4ndbara l\u00e4nkar:<\/p>\n<ul>\n<li>Om <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Blockgenerering<\/a><\/noindex> i alla detaljer.<\/li>\n<li>All information om <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> i b\u00e4sta skick<\/li>\n<li>Till <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> i detalj<\/li>\n<\/ul>\n<p>K\u00e4lla: <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.4 - 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\/sv\/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.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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\udd47Vad har f\u00f6r\u00e4ndrats i Capacity Tier n\u00e4r Veeam blev v10 | ProHoster","description":"Capacity Tier (eller som vi kallar det internt i Veeam \u2014 kap-tier) introducerades redan under Veeam Backup and Replication 9.5 Update 4 under namnet Archive Tier.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}