{"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\/da\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Capacity Tier (eller hvad vi kalder det internt \u2014 kaptier) blev introduceret allerede i Veeam Backup and Replication 9.5 Update 4 under navnet Archive Tier. Ideen bag det er at give mulighed for at flytte backups, der er uden for det s\u00e5kaldte operational restore window, til objektlagre. Dette hjalp med at frig\u00f8re diskplads for de brugere, der havde lidt af det. Denne mulighed kaldes Move Mode.<\/p>\n<p>For at udf\u00f8re denne enkle (som det ser ud) handling var det n\u00f8dvendigt at opfylde to betingelser: alle punkter fra den flyttede backup skal v\u00e6re uden for det ovenn\u00e6vnte operational restore window, som eksplicit angives i UI. Og for det andet: k\u00e6den skal v\u00e6re i s\u00e5kaldt \"sealed mode\" (sealed backup chain eller Inactive Backup Chain). Det vil sige, at der med tiden ikke sker \u00e6ndringer i denne k\u00e6de.<\/p>\n<p>Men i VBR v10 blev konceptet udvidet med nye funktioner \u2014 Copy Mode, Sealed Mode og en funktion med det vanskeligt udtalte navn Immutability.<\/p>\n<p>Det er om disse sp\u00e6ndende emner, vi vil tale i dag. F\u00f8rst om hvordan det fungerede i VBR9.5u4, og derefter om \u00e6ndringerne i den tiende version.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg lad mig undskylde til fortalere for rent sprog, men det er umuligt at overs\u00e6tte s\u00e5 mange termer.<br \/>\nS\u00e5 der vil v\u00e6re en del anglicismer her.<br \/>\nOg mange GIF'er. <br \/>\nOg billeder.<\/p>\n<ul>\n<li>Uden mindste fortrydelse. Artikels forfatter.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Hvordan det var<\/h1>\n<p>\nS\u00e5 lad os starte med at gennemg\u00e5 operational restore window og sealed backup (eller hvad de kaldes i dokumentationen Inactive Backup Chain). Uden deres forst\u00e5else kan yderligere forklaring ikke gives.<\/p>\n<p>Som vi ser p\u00e5 billedet, har vi en backup-k\u00e6de med datablokke, der er placeret p\u00e5 Performance tier SOBR-repositoriet, til hvilket Capacity Tier er tilsluttet. Vores vindue for operationel backup er tre dage.<\/p>\n<p>Dermed forsegler den oprettede .vbk fil fra mandag den tidligere k\u00e6de, hvis vindue er sat til tre dage. Og derfor kan vi trygt begynde at flytte alt, hvad der er \u00e6ldre end disse tre dage, til capacity tier.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen hvad var pr\u00e6cist meningen med den sealed k\u00e6de, og hvad kunne sendes til capacity tier i update 4?<\/p>\n<p>For Forward Incremental er tegnet p\u00e5, at k\u00e6den er forseglet, ved oprettelsen af en ny fuld backup. Og det er ligegyldigt, hvordan denne fuld backup opn\u00e5s: b\u00e5de synthetic full og active full backups t\u00e6lles med.<\/p>\n<p>I tilf\u00e6lde af Reverse er det alle filer, der ikke falder inden for det operationelle vindue. <\/p>\n<p>I tilf\u00e6lde af Forward increment med rollbacks, er det alle rollbacks og .vbk, hvis der p\u00e5 performance extentet er en anden .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLad os nu se p\u00e5 muligheden for at arbejde med Backup Copy k\u00e6der. Her blev der kun taget hensyn til det, der falder ind under GFS retention. Fordi alt, der er gemt i nyere backup copy k\u00e6der, kan p\u00e5 en eller anden m\u00e5de v\u00e6re \u00e6ndret.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLad os kigge under motorhjelmen. Her sker der en proces kaldet dehydriering \u2014 efterladelse af tomme backup-filer p\u00e5 extentet og flytning af blokke fra disse filer til capacity tier. For at optimere denne proces anvendes s\u00e5kaldt dehydreringsindeks, som g\u00f8r det muligt ikke at kopiere blokke, der allerede er blevet kopieret til capacity tier. <\/p>\n<p>Lad os se, hvordan det ser ud med et eksempel: antag at vi har en .vbk, der er g\u00e5et ud af driftvinduet og tilh\u00f8rer en forseglet k\u00e6de. Det betyder, at vi har fuld ret til at flytte den til capacity tier. P\u00e5 tidspunktet for flytningen oprettes der en metadatafil i capacity tier og blokke fra den flyttede fil. I metadatafilen beskrives det p\u00e5 blokniveau, hvilke blokke vores fil best\u00e5r af. I tilf\u00e6ldet vist p\u00e5 billedet best\u00e5r vores f\u00f8rste fil af blokke a, b, c, og i metadataene er der links til disse blokke. N\u00e5r vi f\u00e5r en anden .vbk fil, klar til at flytte og best\u00e5ende af blokke a, b og d, forst\u00e5r vi, ved at analysere dehydreringsindekset, at vi kun skal flytte blok d. Og dens metadatafil vil indeholde links til de to tidligere blokke og en ny.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerfor kaldes processen med at udfylde disse tomrum med data reghydrering. Her anvendes et specielt reghydrationsindeks, der bygger p\u00e5 den \u00e6ldste .vbk fil p\u00e5 det lokale performance extent. Det vil sige, at hvis brugeren \u00f8nsker at genskabe en fil fra capacity tier, opretter vi f\u00f8rst et indeks over blokke fra den \u00e6ldste komplette backup og flytter kun de manglende blokke fra capacity tier. I det viste tilf\u00e6lde, for at reghydrere FullBackup1.vbk i henhold til reghydrationsindekset, mangler vi kun blok C, som vi henter fra capacity tier. Hvis capacity tier er en cloud object storage, kan det spare enorme omkostninger.<\/p>\n<p>Det kan se ud til, at denne teknologi er identisk med den, der anvendes i WAN-acceleratorer, men det er kun en illusion. I acceleratorer foreg\u00e5r der global deduplicering, mens der her anvendes lokal deduplicering inden for hver fil baseret p\u00e5 en bestemt offset. Dette skyldes forskellene i de opgaver, der skal l\u00f8ses: her skal vi kopiere store filer med fuld backup, og if\u00f8lge vores unders\u00f8gelser giver en s\u00e5dan dedupliceringsalgoritme det bedste resultat, selvom der g\u00e5r lang tid imellem.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen der er mere til indekserne! Der er ogs\u00e5 et indeks til datagendannelse! N\u00e5r vi starter gendannelsen af en maskine, der er placeret i kapacitetstierne, vil vi kun l\u00e6se unikke datablokke, som ikke er i performance-stierne.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da 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>\nDet var alt for introduktionen. Den er ret detaljeret, men som n\u00e6vnt tidligere kan vi ikke forklare, hvordan de nye funktioner fungerer uden disse detaljer. Derfor, uden yderligere forord, g\u00e5r vi videre til det f\u00f8rste punkt.<\/p>\n<h3>Copy mode<\/h3>\n<p>\nI h\u00f8j grad baseret p\u00e5 eksisterende teknologier, men b\u00e6rer en helt anden logik af brug.\u00a0<\/p>\n<p>M\u00e5let med denne tilstand er at sikre, at alle data, der er placeret p\u00e5 det lokale ekstent, har en kopi i kapacitetstierne.<\/p>\n<p>Hvis man sammenligner Move og Copy-tilstande direkte, ser det s\u00e5ledes ud:<\/p>\n<ul>\n<li>Flytning kan kun ske med en forseglet k\u00e6de. I tilf\u00e6lde af copy-tilstanden sendes absolut alt, uanset hvad der sker i backup-jobbet.<\/li>\n<li>Flytning udl\u00f8ses, n\u00e5r filer g\u00e5r ud over vinduet for operationel backup, mens kopiering udl\u00f8ses lige s\u00e5 snart backup-filen er tilg\u00e6ngelig.<\/li>\n<li>Sporing af nye data til kopiering sker konstant, mens flytning kun udl\u00f8ses hver fjerde time.<\/li>\n<\/ul>\n<p>\nI betragtnings af den nye tilstand vil jeg foresl\u00e5 at starte med simple eksempler, f\u00f8r vi g\u00e5r til de mere komplekse.<\/p>\n<p>I det mest banale tilf\u00e6lde modtager vi blot nye filer med inkrementer, og vi kopierer dem til kapacitetstierne. Uanset hvilken tilstand der bruges i backup-jobbet, uanset om den tilh\u00f8rer den forseglede del af k\u00e6den eller ej, og uanset om vores operationelle vindue er udl\u00f8bet. Vi tager bare og kopierer.<\/p>\n<p>Processen bag dette er stadig dehydrering, som beskrevet ovenfor. I kopi-tilstand s\u00f8rger den ogs\u00e5 for, at vi ikke kopierer blokke, der allerede findes i vores objektlager. Den eneste forskel er, at hvis vi i bev\u00e6gelses-tilstand erstatter rigtige filer med dummy-filer, s\u00e5 r\u00f8rer vi ikke ved dem her og lader alt forblive som det er. Ellers er det n\u00f8jagtigt den samme dehydreringsteknik, der omhyggeligt pr\u00f8ver at spare dine penge og tid.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSp\u00f8rgsm\u00e5let opst\u00e5r \u2014 hvis vi ser p\u00e5 brugergr\u00e6nsefladen, er der mulighed for at v\u00e6lge begge muligheder samtidigt. Hvordan vil en s\u00e5dan kombineret tilstand fungere?<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLad os finde ud af det.<\/p>\n<p>Det starter standardm\u00e6ssigt: en backupfil oprettes og kopieres straks. Der oprettes en inkrementel backup og kopieres ogs\u00e5. Dette forts\u00e6tter, indtil vi indser, at filerne er kommet uden for vores operationelle vindue, og der opst\u00e5r en indkapslet k\u00e6de. P\u00e5 dette tidspunkt udf\u00f8rer vi dehydrering og erstatter disse filer med dummy-filer. Naturligvis kopierer vi ikke igen til kapacitetstier.<\/p>\n<p>Hele denne interessante logik styres blot af et enkelt flueben i gr\u00e6nsefladen: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Hvorfor har vi denne Copy tilstand? <\/h3>\n<p>\nDet ville v\u00e6re bedre at omformulere sp\u00f8rgsm\u00e5let \u2014 hvilke risici beskytter vi os imod med det? Hvilket problem hj\u00e6lper det os med at l\u00f8se?<\/p>\n<p>Svaret er indlysende: det er selvf\u00f8lgelig datagendannelse. Hvis vi har en fuld kopi af lokale data p\u00e5 objektlageret, s\u00e5 er det ligegyldigt, hvad der sker med vores produktionsmilj\u00f8, vi kan altid gendanne data fra filer placeret i en hypotetisk Amazon.<\/p>\n<p>Lad os derfor gennemg\u00e5 de mulige scenarier fra det mest enkle til det mere komplekse.<\/p>\n<p>Den enkleste ulykke, der kan ramme os, er utilg\u00e6ngeligheden af en af filerne i backupk\u00e6den.<\/p>\n<p>En mere s\u00f8rgelig historie er, at en af extentserne i vores SOBR-lager er g\u00e5et i stykker.<\/p>\n<p>Det bliver endnu v\u00e6rre, n\u00e5r hele SOBR-lageret bliver utilg\u00e6ngeligt, men kapacitetstierne fungerer.<br \/>\nOg det er helt slemt \u2014 n\u00e5r backupserveren d\u00f8r, og dit f\u00f8rste \u00f8nske er at pr\u00f8ve at n\u00e5 den canadiske gr\u00e6nse p\u00e5 ti minutter.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLad os s\u00e5 tage et kig p\u00e5 hver situation enkeltvis.<\/p>\n<p>N\u00e5r vi mister en (eller m\u00e5ske endda flere) backupfiler, er det nok at starte genindscanningen af \u200b\u200bdatabasen, og den mistede fil vil blive erstattet af en tom fil. Og ved hj\u00e6lp af regenereringsprocessen (som n\u00e6vnt i begyndelsen af artiklen) kan brugeren downloade data fra kapacitetspoolen til det lokale lager.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNu er situationen mere kompleks. Lad os antage, at vores SOBR best\u00e5r af to extent, der k\u00f8rer i Performance-tilstand, hvilket betyder, at vores .vbk- og .vib-filer er spredt over dem i et ret uregelm\u00e6ssigt lag. P\u00e5 et tidspunkt bliver en af \u200b\u200bextentene utilg\u00e6ngelig, og brugeren skal hurtigt gendanne maskinen, hvor en del af dataene ligger p\u00e5 netop denne extent. <\/p>\n<p>Brugeren starter genopretningsguiden, v\u00e6lger det punkt, han \u00f8nsker at gendanne til, og i l\u00f8bet af arbejdet indser guiden, at han ikke har alle n\u00f8dvendige data lokalt, og derfor skal de downloades fra kapacitetspoolen. De blokke, der er tilbage p\u00e5 det lokale lager, vil ikke blive downloadet fra skyen. Tak til restore-indekset (ja, det blev ogs\u00e5 omtalt i begyndelsen af artiklen).<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn underkategori af dette tilf\u00e6lde er, at hele SOBR-repositoriet er blevet utilg\u00e6ngeligt. I dette tilf\u00e6lde har vi intet at kopiere fra de lokale lagre, og alle blokke downloades fra skyen.<\/p>\n<p>Og den mest interessante situation er, at backup-serveren er d\u00f8d. Her er der to muligheder: enten er administratoren dygtig og har lavet konfigurationsbackups, eller administratoren har v\u00e6ret sin egen v\u00e6rste fjende og ikke lavet konfigurationsbackup.<\/p>\n<p>I det f\u00f8rste tilf\u00e6lde vil han bare skulle implementere en ren installation af VBR et eller andet sted og gendanne sin database fra backup med standardv\u00e6rkt\u00f8jer. Ved afslutningen af denne proces vil alt vende tilbage til det s\u00e6dvanlige. Eller det vil blive gendannet if\u00f8lge et af de ovenst\u00e5ende scenarier.<\/p>\n<p>Men hvis administrationen enten er sin egen fjende, eller backup-konfigurationen ogs\u00e5 har lidt den sk\u00e6bnesvangre fejl, s\u00e5 vil vi ikke lade dem i stikken selv her. Til dette tilf\u00e6lde har vi indf\u00f8rt en ny procedure kaldet Import Object Storage. Den tillader os at springe den manuelle proces med at genskabe SOBR-repositoriet over og knytte det til et kapacitetstier med efterf\u00f8lgende rescanning, og blot tilf\u00f8je objektlagringen i VIMAP-interfacet og starte proceduren Import Storage Repository. Det eneste, der kan st\u00e5 imellem dig og dine backups, er en anmodning om at indtaste adgangskoden, hvis dine backups er blevet krypteret.<\/p>\n<p>Det var det for Copy Mode, og vi g\u00e5r videre til<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nHovedkonceptet er, at der ikke m\u00e5 opst\u00e5 nye backups p\u00e5 den valgte extent af SOBR-repositoriet. Indtil v10 havde vi kun Maintenance Mode, hvor al aktivitet med repositoriet var fuldst\u00e6ndig forbudt. En slags h\u00e5rdkogt tilstand for at tage lageret ud af drift, hvor kun knappen Evacuate var tilg\u00e6ngelig, som \u00e9n gang transporterer backups til en anden extent.<\/p>\n<p>Sealed mode er en slags \"bl\u00f8d\" version: vi forbyder oprettelse af nye backups og sletter gradvist gamle i henhold til den valgte retention, men undervejs mister vi ikke muligheden for at gendanne fra de gemte punkter. Det er en meget nyttig funktion, n\u00e5r vi enten n\u00e6rmer os slutningen af levetiden for maskinvaren, som skal udskiftes, eller n\u00e5r det bare skal frig\u00f8res til noget vigtigere, og man ikke har nogen steder at transportere alt p\u00e5 \u00e9n gang. Eller det er ikke muligt at slette. <\/p>\n<p>Princippet for arbejdet er ganske enkelt: man skal forbyde alle write-operationer (oprettelse af nye data) og tillade read (gendannelse) og delete (retention).<\/p>\n<p>Begge tilstande kan anvendes samtidigt, men man skal huske, at Maintenance har h\u00f8jere prioritet.<\/p>\n<p>Som et eksempel kan vi tage et SOBR, der best\u00e5r af to extents. Antag, at der blev oprettet backups i Forward Forever Incremental-tilstand i de f\u00f8rste fire dage, og derefter forseglede vi extenten. Dette f\u00f8rer til, at vi initierer oprettelsen af en ny aktiv fuld p\u00e5 den anden tilg\u00e6ngelige extent. Hvis vores retention er fire, s\u00e5 n\u00e5r hele k\u00e6den, der ligger p\u00e5 den forseglede extent, overskrider dens gr\u00e6nse, kan den med god samvittighed slettes.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer er situationer, hvor sletning sker tidligere. For eksempel, i Forward incremental med periodiske fulde sikkerhedskopier. Hvis vi i de f\u00f8rste to dage har oprettet fulde sikkerhedskopier, og vi beslutter os for at forsegle depotet om torsdagen, vil filen fra mandag blive slettet om fredagen, n\u00e5r der oprettes en ny fuld sikkerhedskopi, da der ikke er afh\u00e6ngigheder til dette punkt. Og selve punktet afh\u00e6nger ikke af nogen. Derefter venter vi, indtil der er oprettet fire punkter p\u00e5 det tilg\u00e6ngelige omfang, og sletter de resterende tre, som ikke kan slettes uafh\u00e6ngigt af hinanden.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet er lettere med Reverse Incremental. Her afh\u00e6nger de \u00e6ldste punkter ikke af noget, og kan derfor slettes uden problemer. S\u00e5 snart en ny .vbk er oprettet p\u00e5 det nye omfang, vil de gamle .vrb blive slettet \u00e9n ad gangen.<\/p>\n<p>Forresten, hvorfor opretter vi hver gang en ny .vbk: Hvis vi ikke gjorde det, men fortsatte den gamle k\u00e6de af inkrementer, ville den gamle .vbk h\u00e6nge i lang tid i enhver tilstand, hvilket ville forhindre dens sletning. Derfor blev det besluttet, at s\u00e5 snart omfanget forsegles, opretter vi en fuld sikkerhedskopi p\u00e5 et ledigt omfang.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet er mere kompliceret med kapacitetstier. <\/p>\n<p>Lad os f\u00f8rst se p\u00e5 copy mode. Antag, at vi aktivt har oprettet sikkerhedskopier i fire dage, og derefter blev kapacitetstien forseglet. Vi sletter ikke noget, men holder t\u00e5lmodigt retention, hvorefter vi sletter data fra kapacitetstien.<\/p>\n<p>Det samme sker i move mode \u2014 vi venter p\u00e5 retention, sletter det gamle i lokal lagring, sletter det, der er gemt i object storage.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt interessant eksempel med Forever forward incremental. Vi indstiller retention til tre punkter og begynder at lave sikkerhedskopier fra mandag, som flittigt kopieres til skyen. Efter forsegling af depotrummet forts\u00e6tter sikkerhedskopierne med at blive oprettet og overholder tre punkter, men de data, der er gemt i kapacitetstien, forbliver afh\u00e6ngige og kan ikke slettes. Derfor venter vi p\u00e5 torsdag, n\u00e5r vores .vbk overskrider retention, og f\u00f8rst derefter kan vi trygt slette hele den gemte k\u00e6de.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg en lille bem\u00e6rkning: Alle eksempler her er vist med \u00e9n maskine. Hvis du har flere i sikkerhedskopien, vil retention v\u00e6re forskellig afh\u00e6ngigt af, om der er lavet en Active Full eller ej.<\/p>\n<p>Og det er i princippet alt. S\u00e5 lad os g\u00e5 videre til den mest hardcore funktion \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nLigesom med de tidligere punkter, skal vi f\u00f8rst tale om, hvilket problem denne funktion l\u00f8ser. N\u00e5r vi f\u00f8rst gemmer vores backups et sted, opst\u00e5r der et st\u00e6rkt \u00f8nske om at sikre deres integritet, alts\u00e5 fysisk forhindre enhver sletning eller modifikation i l\u00f8bet af den angivne retention. Dette g\u00e6lder ogs\u00e5 for administratorer og deres root-konti. Det g\u00f8r det muligt at beskytte dem mod utilsigtet eller bevidst \u00f8del\u00e6ggelse. Dem, der arbejder med AWS, kan have st\u00f8dt p\u00e5 en lignende funktion kaldet Object Lock.<\/p>\n<p>Lad os nu se p\u00e5 tilstanden i almindelige vendinger, og s\u00e5 g\u00e5r vi i dybden med detaljerne. I vores eksempel vil Immutability blive aktiveret for vores kapacitetsskive med en retention p\u00e5 fire dage. Og backup\u2019en vil have Copy-tilstand aktiveret.<\/p>\n<p>Immutability interagerer ikke med den generelle retention. For eksempel tilf\u00f8jer det ikke ekstra punkter eller lignende. Bare i l\u00f8bet af de fire dage kan en person ikke slette backup-filer. Hvis man laver en backup om mandagen, kan filen kun slettes om fredag.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlle tidligere forklarede koncepter vedr\u00f8rende dehydrering, indekser og metadata fungerer stadig p\u00e5 n\u00f8jagtig samme m\u00e5de. Men med en foruds\u00e6tning \u2014 blokken anvendes ikke kun til data, men ogs\u00e5 til metadata. Dette er lavet for at beskytte mod, hvis en ondsindet angriber beslutter sig for at slette vores metadata-database, s\u00e5 blokke med data ikke bliver til en ubrugelig bin\u00e6r gr\u00f8d.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg nu er det et godt tidspunkt at forklare vores teknologi til blokgeneration. Eller block generation. For dette vil vi se p\u00e5 den situation, der f\u00f8rte til dens fremkomst.<\/p>\n<p>Lad os tage en tidslinje p\u00e5 seks dage, hvor vi nedenfor markerer tidspunktet for forventet udl\u00f8b af immutability. Vi opretter en fil p\u00e5 den f\u00f8rste dag, best\u00e5ende af blok data a og dens metadata. Hvis immutability er indstillet til tre dage, er det logisk at antage, at dataene vil blive l\u00e5st op og slettet p\u00e5 den fjerde dag. P\u00e5 den anden dag tilf\u00f8jer vi en ny file2, der best\u00e5r af blok b med de samme indstillinger. Blok a skal stadig slettes p\u00e5 den fjerde dag. Men p\u00e5 den tredje dag sker der noget skr\u00e6mmende \u2014 der oprettes en fil File3, best\u00e5ende af en ny blok d og et link til den gamle blok a. Det betyder, at immutability-flaget for blok a skal genindstilles til en ny periode, der flyttes til den sjette dag. Og her opst\u00e5r der et problem \u2014 der opst\u00e5r et enormt antal af s\u00e5danne blokke i virkelige backup'er. For at forl\u00e6nge deres immutability-periode skal man konstant lave et stort antal foresp\u00f8rgsler. Og faktisk bliver det en n\u00e6sten uendelig daglig proces, da vi med stor sandsynlighed ved hver kopiering vil finde store bunker af deduplicerede blokke. Hvad betyder et stort antal foresp\u00f8rgsler hos objektstorage-udbydere? Rigtigt! En enorm regning ved slutningen af m\u00e5neden.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOg for ikke at priss\u00e6tte mine dyrebare kunder urimeligt h\u00f8jt, blev der opfundet en mekanisme til block generation. Dette er en ekstra periode, som vi tilf\u00f8jer til den fastsatte immutability-periode. I eksemplet nedenfor er denne periode lig med to dage. Men det er kun til illustration. I virkeligheden anvendes der en formel, der giver cirka ti ekstra dage ved m\u00e5nedlig l\u00e5sning. <\/p>\n<p>Lad os forts\u00e6tte med at se p\u00e5 den samme situation, men denne gang med block generation. Vi opretter file1 fra blok a og metadata den f\u00f8rste dag. Vi aggregerer generationsperioden og immutability \u2014 hvilket betyder, at filen kan slettes f\u00f8rst p\u00e5 den sjette dag. Hvis vi p\u00e5 den anden dag opretter File2, der best\u00e5r af blok b og en reference til blok a, sker der ikke noget med den forventede slettedato. Den forbliver som den var p\u00e5 den sjette dag. P\u00e5 den m\u00e5de fors\u00f8ger vi at spare penge p\u00e5 antallet af foresp\u00f8rgsler. Den eneste situation, hvor tidsrammen kan skubbes, er hvis generationsperioden er udl\u00f8bet. Det vil sige, at hvis File3 p\u00e5 den tredje dag indeholder en reference til blok a, vil generation 2 blive tilf\u00f8jet, da Gen1 allerede er udl\u00f8bet. Og den forventede slettedato for blok a vil blive skubbet til den ottende dag. Dette g\u00f8r det muligt for os at dramatisk reducere antallet af foresp\u00f8rgsler for at forl\u00e6nge levetiden for deduplikering af blokke, hvilket sparer en masse penge for kunderne.<\/p>\n<p><img decoding=\"async\" alt=\"Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelve teknologien er tilg\u00e6ngelig for S3-brugere og S3-kompatibelt udstyr, hvis producenter garanterer, at deres implementering ikke adskiller sig fra Amazons. Herfra kommer svaret p\u00e5 det legitime sp\u00f8rgsm\u00e5l om, hvorfor Azure ikke underst\u00f8ttes \u2014 de har en lignende funktion, men den fungerer p\u00e5 container-niveau, ikke individuelle objekter. Forresten, i selve Amazon er der object lock i to tilstande: compliance og governance. I den sidstn\u00e6vnte tilstand bevares muligheden for, at den st\u00f8rste administrator af administratorer og root af r\u00f8dderne, p\u00e5 trods af object lock, stadig kan slette data. I compliance-tilstanden er alt l\u00e5st fast, og back-ups kan ikke slettes af nogen. Selv ikke af Amazons administratorer (if\u00f8lge deres officielle udtalelser). Vi underst\u00f8tter netop denne tilstand.<\/p>\n<p>\nOg, traditionelt, nogle nyttige links:<\/p>\n<ul>\n<li>Om <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Block Generation<\/a><\/noindex> i alle detaljer.<\/li>\n<li>Al 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 bedste form<\/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> i detaljer<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Hvad er \u00e6ndret i Capacity Tier, da Veeam blev v10 | ProHoster","description":"Capacity Tier (eller som vi kalder det internt i Veeam \u2014 cap tier) dukkede op allerede i Veeam Backup and Replication 9.5 Update 4 under navnet Archive Tier.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}