Capacity Tier (eller som vi kalder det inde i Vim - captir) dukkede op tilbage i tiden med Veeam Backup and Replication 9.5 Update 4 under navnet Archive Tier. Tanken bag er at gøre det muligt at flytte sikkerhedskopier, der er faldet ud af det såkaldte operationelle gendannelsesvindue, til objektlager. Dette hjalp med at rydde op på diskplads for de brugere, der havde lidt af det. Og denne mulighed blev kaldt Move Mode.

For at udføre denne enkle (som det ser ud til) handling var det nok at opfylde to betingelser: alle punkter fra den flyttede sikkerhedskopi skal være uden for grænserne for det ovennævnte operationelle gendannelsesvindue, som er angivet eksplicit i brugergrænsefladen. Og for det andet: kæden skal være i den såkaldte "sealed form" (sealed backup chain eller Inactive Backup Chain). Det vil sige, at der ikke sker ændringer i denne kæde over tid.

Men i VBR v10 blev konceptet suppleret med nye funktioner - Copy Mode, Sealed Mode og en ting med det svære at udtale navn Immutability dukkede op.

Det er de fascinerende ting, vi vil tale om i dag. Først om, hvordan det fungerede i VBR9.5u4, og derefter om ændringerne i den tiende version.

Og må det rene sprogs forkæmpere tilgive mig, men der er for mange udtryk, der ikke kan oversættes.
Så der vil være et væld af anglicismer her.
Og en masse gifs.
Og billeder.

• Uden den mindste fortrydelse. Forfatter til artiklen.

Som det var

Nå, lad os starte med at analysere det operationelle gendannelsesvindue og forseglede backup (eller som de kaldes i Inactive Backup Chain-dokumentationen). Uden deres forståelse vil yderligere forklaring ikke være mulig.

Som vi ser på billedet, har vi en slags backup-kæde med datablokke, som er placeret på Performance tier SOBR i det repository, som Capacity Tier er forbundet til. Vores operationelle backup-vindue er tre dage.

Derfor forsegler den .vbk, der blev oprettet på mandag, den tidligere kæde, hvis vindue er sat til tre dage. Og det betyder, at du trygt kan begynde at transportere alt, der er ældre end disse tre dage, til skydebanen.

Men hvad mente man egentlig med en forseglet kæde, og hvad kunne sendes til kapacitetsskydebanen i opdatering 4?

For Forward Incremental er et tegn på forsegling af kæden oprettelsen af ​​en ny fuld backup. Og det er ligegyldigt, hvordan denne fulde backup opnås: både syntetiske fulde og aktive fulde backups tages i betragtning.

I tilfælde af Reverse er disse alle filer, der ikke falder ind i betjeningsvinduet.

I tilfælde af Forward increment med rollbacks, er disse alle rollbacks og .vbk, hvis der er en anden .vbk på ydeevneomfanget

Lad os nu overveje muligheden for at arbejde med Backup Copy-kæder. Kun varer, der falder ind under GFS-retention, blev transporteret hertil. Fordi alt gemt i nyere backup-kæder kan ændres på den ene eller anden måde.

Lad os nu se under motorhjelmen. Der opstår en proces kaldet dehydrering - efterlader tomme backupfiler på omfanget og trækker blokke fra disse filer til kapacitetsskydebanen. For at optimere denne proces anvendes det såkaldte dehydreringsindeks, som gør det muligt at undgå kopiering af blokke, der allerede er kopieret til kapacitetsskydebanen.

Lad os se, hvordan det ser ud med et eksempel: Lad os sige, at vi har en .vbk, der kom ud af transaktionsvinduet og tilhører en forseglet kæde. Det betyder, at vi har al mulig ret til at flytte den til kapacitetsskydebanen. På tidspunktet for flytningen oprettes en metadatafil i kapacitetsstregen og blokkene i den overførte fil. Metadatafilen på linkniveau beskriver, hvilke blokke vores fil består af. I tilfældet på billedet består vores første fil af blokkene a, b, c og metadataene indeholder links til disse blokke. Når vi har en anden .vbk-fil, klar til at flytte og bestående af blokkene a, b og d, forstår vi, ved at analysere dehydreringsindekset, at kun blok d skal overføres. Og dens metadatafil vil indeholde links til to tidligere blokke og en ny.

Derfor kaldes processen med at fylde disse tomme pladser tilbage med data rehydrering. Den bruger allerede sit eget rehydreringsindeks, baseret på den ældste .vbk-fil på den lokale ydeevne. Det vil sige, at hvis brugeren ønsker at returnere en fil fra kapacitetsskydebanen, opretter vi først et indeks over blokkene af den ældste fuld backup og overfører kun de manglende blokke fra kapacitetsskydegalleriet. I tilfældet præsenteret på billedet, for at rehydrere FullBackup1.vbk i henhold til rehydreringsindekset, behøver vi kun blok C, som vi tager fra kapacitetsskydebanen. Hvis et lagringsskyobjekt fungerer som en kapacitetsskydebane, giver dette dig mulighed for at spare enorme mængder penge.

Her kan det se ud til, at denne teknologi er identisk med den, der bruges i WAN Acceleratorer, men det virker kun sådan. I acceleratorer er deduplikering global; her bruges lokal deduplikering inden for hver fil med en specifik offset. Dette sker på grund af forskellen i de opgaver, der løses: her skal vi kopiere store fulde backup-filer, og ifølge vores forskning, selvom der går lang tid imellem dem, giver denne deduplikeringsalgoritme det bedste resultat.

Men flere indekser til indeksguden! Der er også et indeks for datagendannelse! Når vi begynder at gendanne en maskine, der er placeret i kapacitets-dashen, vil vi kun læse unikke datablokke, der ikke er i performance-dashen.

Hvordan skete det

Det er alt til den indledende del. Det er ret detaljeret, men som nævnt ovenfor vil det uden disse detaljer ikke være muligt at forklare, hvordan de nye funktioner fungerer. Lad os derfor uden videre gå videre til den første.

Kopieringstilstand

Det er i høj grad baseret på eksisterende teknologier, men har en helt anden brugslogik. 

Formålet med denne tilstand er at sikre, at alle data, der er placeret på det lokale område, har en kopi i kapacitetsstregen.

Hvis du sammenligner Flyt- og Kopier-tilstandene frontalt, vil det se sådan ud:

• Kun den forseglede kæde kan flyttes. I tilfælde af en kopitilstand overføres absolut alt, uanset hvad der sker i backup-jobbet.
• Flytning udløses, når filerne går ud over grænserne for det operationelle sikkerhedskopieringsvindue, og kopiering udløses, så snart backupfilen vises.
• Overvågning af nye data til kopiering sker konstant, og til flytning blev det udløst en gang hver 4. time.

Når jeg overvejer den nye tilstand, foreslår jeg at gå fra simple eksempler til komplekse.

I det mest almindelige tilfælde har vi blot nye filer med trin, og vi kopierer dem blot til kapacitetsskydebanen. Uanset hvilken tilstand der bruges i backup-jobbet, uanset om det tilhører den forseglede del af kæden eller ej, uanset om vores driftsvindue er udløbet. De tog det bare og kopierede det.

Processen bag dette er stadig dehydrering som beskrevet ovenfor. I kopieringstilstand sørger den også for, at vi ikke kopierer blokke, der allerede er på vores lager. Den eneste forskel er, at hvis vi i filmtilstand erstattede rigtige filer med dummy-filer, rører vi dem ikke på nogen måde og lader alt være som det er. Ellers er det præcis det samme dehydreringsindeks, som omhyggeligt forsøger at spare dine penge og tid.

Spørgsmålet melder sig – ser man på UI’en er der mulighed for at vælge begge muligheder på samme tid. Hvordan vil en sådan kombineret tilstand fungere?

Lad os finde ud af det.

Begyndelsen er standard: en backup-fil oprettes og kopieres med det samme. Der oprettes et trin til det og kopieres også. Dette sker indtil det øjeblik, hvor vi indser, at filerne har forladt vores betjeningsvindue, og en forseglet kæde er dukket op. På dette tidspunkt udfører vi en dehydreringsoperation og erstatter disse filer med dummy-filer. Vi kopierer selvfølgelig ikke noget igen til kapacitetsskydebanen.

Al denne fascinerende logik er ansvarlig for kun ét afkrydsningsfelt i grænsefladen: Kopier sikkerhedskopier til objektlageret, så snart de er oprettet.

Hvorfor har vi brug for denne kopitilstand?

Det er endnu bedre at omformulere spørgsmålet på denne måde: hvilke risici er vi beskyttet mod med dets hjælp? Hvilket problem hjælper det os med at løse?

Svaret er indlysende: selvfølgelig er dette datagendannelse. Hvis vi har en komplet kopi af lokale data på objektlageret, så uanset hvad der sker med vores produkt, kan vi altid gendanne data fra filer placeret i den betingede Amazon.

Så lad os gennemgå de mulige scenarier, fra de enkleste til de mere komplekse.

Den enkleste ulykke, der kan falde os over hovedet, er utilgængeligheden af ​​en af ​​filerne i backup-kæden.

En mere trist historie er, at et af omfanget af vores SOBR-depot gik i stykker.

Det bliver endnu værre, når hele SOBR-depotet er blevet utilgængeligt, men kapacitetsskydebanen fungerer.
Og alt er virkelig dårligt - det er, når backup-serveren dør, og dit første ønske er at prøve at løbe til den canadiske grænse på ti minutter.

Lad os nu se på hver situation separat.

Når vi har mistet en (og endda flere) sikkerhedskopifiler, så skal vi bare starte genscanningsprocessen for depotet, og den tabte fil vil blive erstattet med en dummy-fil. Og ved at bruge rehydreringsprocessen (som blev diskuteret i begyndelsen af ​​artiklen), vil brugeren være i stand til at downloade data fra kapacitetsskydebanen til lokal lagring.

Nu er situationen mere kompliceret. Lad os antage, at vores SOBR består af to udstrækninger, der kører i Performance mode, hvilket betyder, at vores .vbk og .vib er spredt over dem i et ret ujævnt lag. Og på et tidspunkt bliver et af omfanget utilgængeligt, og brugeren har et presserende behov for at gendanne maskinen, hvor en del af dataene netop ligger på dette omfang.

Brugeren starter gendannelsesguiden, vælger det punkt, hvortil han vil gendanne, og guiden, mens han arbejder, kommer til den erkendelse, at han ikke har alle de nødvendige data til gendannelse lokalt og derfor skal downloades fra kapacitetsoptagelsen galleri. Samtidig vil blokke, der forbliver på lokal lagring, ikke blive downloadet fra skyen. Ære til gendannelsesindekset (ja, det blev også nævnt i begyndelsen af ​​artiklen).

En undertype af denne sag er, at hele SOBR-depotet blev utilgængeligt. I dette tilfælde har vi intet at kopiere fra lokalt lager, og alle blokke downloades fra skyen.

Og den mest interessante situation er, at backup-serveren døde. Der er to muligheder her: administratoren er fantastisk og lavede konfigurationssikkerhedskopier, og administratoren er en ond Pinocchio selv og lavede ikke konfigurationssikkerhedskopier.

I det første tilfælde vil det være nok for ham blot at installere en ren installation af VBR et sted og gendanne dens database fra en sikkerhedskopi ved hjælp af standardmidler. Ved afslutningen af ​​denne proces vil alt vende tilbage til det normale. Eller det vil blive gendannet i henhold til et af scenarierne ovenfor.

Men hvis administratoren enten er sin egen fjende, eller hvis konfigurations-backupen også led en episk fiasko, så vil vi heller ikke her overlade ham til skæbnens nåde. Til dette tilfælde har vi introduceret en ny procedure kaldet Import Object Storage. Det giver dig mulighed for at springe over processen med manuelt at genskabe et SOBR-lager og knytte en kapacitetsskydebane til det med efterfølgende genscanning og blot tilføje et lagerobjekt til Vim-grænsefladen og køre Import Storage Repository-proceduren. Det eneste, der kan stå i vejen mellem dig og dine backups, er en anmodning om at indtaste en adgangskode, hvis dine backups var krypteret.

Dette handler sandsynligvis alt om Copy Mode, og vi går videre til

Forseglet tilstand

Hovedideen er, at nye sikkerhedskopier ikke kan vises på den valgte SOBR-udstrækning af depotet. Før v10 havde vi kun vedligeholdelsestilstand, hvor alt arbejde med depotet var fuldstændig forbudt. En slags hardcore-tilstand til nedlukning af lagring, hvor kun Evacuate-knappen er tilgængelig, som transporterer backups i et andet omfang én gang.

Og forseglet tilstand er en slags "blød" mulighed: vi forbyder oprettelse af nye sikkerhedskopier og sletter gradvist gamle i henhold til den valgte opbevaring, men i processen mister vi ikke muligheden for at gendanne fra lagrede punkter. En meget nyttig ting, når vi enten har et stykke hardware, der nærmer sig slutningen af ​​dets levetid og skal udskifte det, eller vi bare skal frigøre det til noget vigtigere, men der er ingen steder at tage det og flytte alt på én gang. Eller det kan ikke slettes.

Følgelig er operationsprincippet ret simpelt: det er nødvendigt at forbyde alle skriveoperationer (fremkomsten af ​​nye data), efterlade læsning (gendannelser) og sletning (retention).

Begge tilstande kan bruges samtidigt, men husk på, at vedligeholdelse har højere prioritet.

Som et eksempel kan du overveje en SOBR bestående af to udstrækninger. Lad os antage, at vi i de første fire dage lavede sikkerhedskopier i Forward Forever Incremental mode, og derefter forsegler vi omfanget.Dette fører til, at vi starter oprettelsen af ​​en ny aktiv fuld på den anden tilgængelige udstrækning. Hvis vores fastholdelse er fire, så slettes den med god samvittighed, når hele kæden placeret på den forseglede udstrækning går ud over sine grænser.

Der er situationer, hvor sletningen sker tidligere. Dette er f.eks. Videresend trinvis med periodiske fulder. Hvis vi lavede fuld backup for de første to dage, og om torsdagen beslutter os for at forsegle depotet, så på fredag, når der oprettes en ny backup, slettes filen for mandag pga. der er ingen afhængigheder til dette punkt. Og selve pointen afhænger ikke af nogen. Derefter venter vi til der er oprettet fire point på det tilgængelige omfang og sletter de resterende tre, som ikke kan slettes uafhængigt af hinanden.

Tingene er enklere med Reverse Incremental. I den er de ældste punkter ikke afhængige af noget og kan sikkert slettes. Så snart der oprettes en ny .vbk på et nyt omfang, vil de gamle .vrbs derfor blive slettet én efter én.

Forresten, hvorfor opretter vi en ny .vbk hver gang: hvis vi ikke oprettede den, men fortsatte den gamle kæde af trin, så ville den gamle .vbk fryse i uendelig lang tid i enhver tilstand, hvilket forhindrede sletningen. Derfor blev det besluttet, at så snart omfanget er forseglet, opretter vi en fuld backup på det frie omfang.

Tingene er mere komplicerede med kapacitetsskydebanen.

Lad os først se på kopieringstilstand. Lad os antage, at vi aktivt lavede backups i fire dage, og så var kapacitetsskydebanen forseglet. Vi sletter ikke noget, men tåler ydmygt tilbageholdelsen, hvorefter vi sletter dataene fra kapacitetsskydebanen.

Omtrent det samme sker i flyttetilstand - vi venter på retoucheringen, sletter den gamle i det lokale lager og sletter den, der er gemt i objektlageret.

Et interessant eksempel med Forever forward incremental. Vi installerer retention på tre punkter og begynder at lave backups på mandag, som jævnligt kopieres til skyen. Efter forsegling af lageret fortsætter der med at blive oprettet sikkerhedskopier, idet tre punkter bibeholdes, men de data, der er gemt i kapacitetsstregen, forbliver afhængige og kan ikke slettes. Derfor venter vi til torsdag, hvor vores .vbk går ud over retention, og først derefter sletter vi roligt hele den gemte kæde.

Og en lille ansvarsfraskrivelse: alle eksempler her er vist med én maskine. Hvis du har flere af dem i din backup, så vil deres retouchering variere afhængigt af, om Active Full blev lavet eller ej.

Det er dybest set alt, hvad der er til det. Så lad os gå videre til den mest hardcore-funktion -

uforanderlighed

Som med de foregående punkter er den første ting, hvilket problem denne funktion løser. Så snart vi uploader vores sikkerhedskopier et sted til opbevaring, er der et stærkt ønske om at garantere deres sikkerhed, det vil sige fysisk at forbyde deres sletning og enhver ændring under en given opbevaring. Inklusive administratorer, herunder under deres root-konti. Dette giver dig mulighed for at beskytte dem mod utilsigtet eller forsætlig skade. Enhver, der arbejder med AWS, kan være stødt på en lignende funktion kaldet Objektlås.

Lad os nu se på tilstanden i generelle vendinger, og derefter dykke ned i detaljerne. I vores eksempel vil Immutability være aktiveret for vores kapacitetsskydebane med en retention på fire dage. Og kopitilstanden er aktiveret i sikkerhedskopien.

Uforanderlighed interagerer ikke med generel retention på nogen måde. Det giver for eksempel ikke ekstra point eller noget i den stil. Det er bare, at en person ikke kan slette backup-filer inden for fire dage. Hvis du laver en sikkerhedskopi på mandag, vil du først kunne slette dens fil på fredag.

Alle tidligere forklarede begreber om dehydrering, indekser og metadata fortsætter med at fungere nøjagtigt det samme. Men med én betingelse - blokeringen er ikke kun sat for data, men også for metadata. Dette gøres i tilfælde af at en snedig angriber beslutter sig for at slette vores metadatadatabase og for at forhindre datablokke i at blive til ubrugelig binær grød.

Nu er et godt tidspunkt at forklare vores blokgenereringsteknologi. Eller blokgenerering. For at gøre dette skal du overveje den situation, der førte til dets udseende.

Lad os tage en tidsskala på seks dage, og nedenfor vil vi markere tidspunktet for det forventede udløb af uforanderlighed. På den første dag tager og opretter vi en fil bestående af datablok a og dens metadata. Hvis uforanderlighed er sat til tre dage, er det logisk at antage, at dataene på den fjerde dag bliver låst op og slettet. På den anden dag tilføjer vi en ny fil2, bestående af blok b med de samme indstillinger. Blok a skal stadig fjernes på den fjerde dag. Men på den tredje dag sker der noget forfærdeligt - en File3-fil oprettes, bestående af en ny blok d og et link til den gamle blok a. Dette betyder, at for en blok og dens uforanderlighed skal flaget nulstilles til en ny dato, som flyttes til den sjette dag. Og her opstår et problem - i rigtige sikkerhedskopier er der et stort antal sådanne blokke. Og for at forlænge deres uforanderlighedsperiode skal du lave et stort antal anmodninger hver gang. Og faktisk vil dette være en næsten uendelig daglig proces, da vi med en høj grad af sandsynlighed vil finde heftige stakke af deduplikerede blokke med hver kopi. Hvad betyder et stort antal anmodninger fra udbydere af objektlagring? Højre! Kæmpe regning i slutningen af ​​måneden.

Og for ikke ud af det blå at afsløre dine yndlingsklienter for betydelige penge, blev blokgenereringsmekanismen opfundet. Dette er en ekstra periode, som vi tilføjer til den fastsatte uforanderlighedsperiode. I eksemplet nedenfor er denne periode to dage. Men dette er blot et eksempel. I virkeligheden bruger de deres egen formel, som giver cirka ti ekstra dage i løbet af en månedlig lås.

Lad os fortsætte med at overveje den samme situation, men med blokgenerering. På den første dag opretter vi fil1 fra blok a og metadata. Vi lægger generationsperioden og uforanderligheden sammen - det betyder, at muligheden for at slette filen vil være på den sjette dag. Hvis vi på andendagen opretter File2, bestående af blok b og et link til blok a, så sker der ikke noget med den forventede sletningsdato. Hun stod, som hun gjorde den sjette dag. Og dermed forsøger vi at spare penge på antallet af forespørgsler. Den eneste situation, hvor fristen kan flyttes, er, hvis generationsperioden er udløbet. Det vil sige, at hvis den nye File3 på tredjedagen indeholder et link til at blokere a, så vil generation 2 blive tilføjet, da Gen1 allerede er udløbet. Og den forventede dato for sletning af blok a vil skifte til den ottende dag. Dette giver os mulighed for dramatisk at reducere antallet af anmodninger om at forlænge levetiden af ​​deduplikerede blokke, hvilket sparer kunder for masser af penge.

Selve teknologien er tilgængelig for brugere af S3 og S3-kompatibel hardware, hvis producenter garanterer, at deres implementering ikke adskiller sig fra Amazons. Deraf svaret på det legitime spørgsmål, hvorfor Azure ikke understøttes - de har en lignende funktion, men den fungerer på niveau med containere, ikke individuelle objekter. Forresten har Amazon selv objektlås i to tilstande: compliance og governance. I det andet tilfælde er der stadig mulighed for, at den største admin over administratorer og root over roots, på trods af objektlåsen, stadig sletter dataene. I tilfælde af compliance er alt naglet stramt, og ingen kan slette sikkerhedskopierne. Selv Amazon-administratorer (ifølge deres officielle udtalelser). Dette er den tilstand, vi understøtter.

Og som sædvanlig nogle nyttige links:

• Про Blokgenerering i alle detaljer.
• Alle oplysninger vedr Veeam Backup & Replikering 10 når det er bedst
• О Kapacitetsniveau i detaljer

Kilde: www.habr.com