Capacity Tier (eller som vi kallar det inuti Vim - captir) dök upp redan under Veeam Backup and Replication 9.5 Update 4 under namnet Archive Tier. Tanken bakom är att göra det möjligt att flytta säkerhetskopior som fallit ut ur det så kallade operationella återställningsfönstret till objektlagring. Detta hjälpte till att rensa upp diskutrymme för de användare som hade lite av det. Och det här alternativet kallades Move Mode.

För att utföra denna enkla (som det verkar) åtgärd räckte det med att uppfylla två villkor: alla punkter från den flyttade säkerhetskopian måste vara utanför gränserna för det ovan nämnda operationella återställningsfönstret, som är uttryckligen inställt i användargränssnittet. Och för det andra: kedjan måste vara i den så kallade "sealed formen" (sealed backup chain eller Inactive Backup Chain). Det vill säga inga förändringar sker i denna kedja över tid.

Men i VBR v10 kompletterades konceptet med nya funktioner – Copy Mode, Sealed Mode och en grej med det svåruttalade namnet Immutability dök upp.

Det här är de fascinerande sakerna vi kommer att prata om idag. Först om hur det fungerade i VBR9.5u4, och sedan om ändringarna i den tionde versionen.

Och må det rena språkets förkämpar förlåta mig, men det finns för många termer som inte går att översätta.
Så det kommer att finnas massor av anglicismer här.
Och många gifs.
Och bilder.

• Utan den minsta ånger. Författare till artikeln.

Som det var

Nåväl, låt oss börja med att analysera det operativa återställningsfönstret och den förseglade säkerhetskopieringen (eller som de kallas i dokumentationen för Inactive Backup Chain). Utan deras förståelse kommer ytterligare förklaring inte att vara möjlig.

Som vi ser på bilden har vi en slags backup-kedja med datablock, som är placerad på Performance-tier SOBR i arkivet som Capacity Tier är anslutet till. Vårt operativa backup-fönster är tre dagar.

Följaktligen förseglar .vbk som skapades på måndag den tidigare kedjan, vars fönster är inställt på tre dagar. Och det betyder att du säkert kan börja transportera allt äldre än dessa tre dagar till skjutbanan.

Men exakt vad menades med en förseglad kedja och vad kunde skickas till kapacitetsskjutbanan i uppdatering 4?

För Forward Incremental är ett tecken på att täta kedjan skapandet av en ny fullständig backup. Och det spelar ingen roll hur denna fullständiga säkerhetskopia erhålls: både syntetiska fullständiga och aktiva fullständiga säkerhetskopior beaktas.

I fallet med Reverse är dessa alla filer som inte hamnar i operativfönstret.

I fallet med Framåtstegring med återställningar är dessa alla återkallningar och .vbk, om det finns en annan .vbk på prestandaomfattningen

Låt oss nu överväga alternativet att arbeta med Backup Copy-kedjor. Endast föremål som faller under GFS-retention transporterades hit. Eftersom allt som lagras i nyare backup-kedjor kan ändras på ett eller annat sätt.

Låt oss nu titta under huven. Där inträffar en process som kallas uttorkning - lämna tomma säkerhetskopior på omfattningen och dra block från dessa filer till kapacitetsskjutbanan. För att optimera denna process används det så kallade uttorkningsindexet, vilket gör att du slipper kopiera block som redan har kopierats till kapacitetsskjutbanan.

Låt oss se hur det här ser ut med ett exempel: Låt oss säga att vi har en .vbk som kom ut från transaktionsfönstret och som tillhör en förseglad kedja. Det betyder att vi har all rätt att flytta den till kapacitetsskjutbanan. Vid flytttillfället skapas en metadatafil i kapacitetsstrecket och blocken för den överförda filen. Metadatafilen på länknivå beskriver vilka block vår fil består av. I fallet på bilden består vår första fil av blocken a, b, c och metadatan innehåller länkar till dessa block. När vi har en andra .vbk-fil, redo att flytta och som består av blocken a, b och d, förstår vi, när vi analyserar uttorkningsindexet, att endast block d behöver överföras. Och dess metadatafil kommer att innehålla länkar till två tidigare block och ett nytt.

Följaktligen kallas processen att fylla dessa tomma utrymmen tillbaka med data rehydrering. Den använder redan sitt eget rehydreringsindex, baserat på den äldsta .vbk-filen på den lokala prestandaomfattningen. Det vill säga, om användaren vill returnera en fil från kapacitetsskjutbanan skapar vi först ett index över blocken för den äldsta fullständiga säkerhetskopian och överför endast de saknade blocken från kapacitetsskjutningsgalleriet. I fallet som presenteras på bilden, för att rehydrera FullBackup1.vbk enligt rehydreringsindexet, behöver vi bara block C, som vi tar från kapacitetsskjutbanan. Om ett lagringsmolnobjekt fungerar som en kapacitetsskjutbana kan du spara enorma summor pengar.

Här kan det tyckas att denna teknik är identisk med den som används i WAN-acceleratorer, men det verkar bara så. I acceleratorer är deduplicering global, här används lokal deduplicering inom varje fil med en specifik offset. Detta sker på grund av skillnaden i de uppgifter som löses: här måste vi kopiera stora fullständiga säkerhetskopior, och enligt vår forskning, även om det går lång tid mellan dem, ger denna dedupliceringsalgoritm det bästa resultatet.

Men fler index för indexens gud! Det finns också ett index för dataåterställning! När vi börjar återställa en maskin som finns i kapacitetsstrecket kommer vi bara att läsa unika datablock som inte finns i prestandastrecket.

Hur blev det

Det var allt för den inledande delen. Det är ganska detaljerat, men som nämnt ovan, utan dessa detaljer kommer det inte att vara möjligt att förklara hur de nya funktionerna fungerar. Låt oss därför, utan vidare, gå vidare till den första.

Kopieringsläge

Den är till stor del baserad på befintlig teknik, men har en helt annan användningslogik. 

Syftet med det här läget är att säkerställa att all data som finns på den lokala omfattningen har en kopia i kapacitetsstrecket.

Om du jämför lägena Flytta och Kopiera rakt ut kommer det att se ut så här:

• Endast den förseglade kedjan kan flyttas. Vid kopieringsläge överförs absolut allt, oavsett vad som händer i backupjobbet.
• Flyttning utlöses när filerna går utanför gränserna för det operativa säkerhetskopieringsfönstret, och kopiering utlöses så snart säkerhetskopian visas.
• Övervakning av nya data för kopiering sker ständigt och för att flytta den utlöstes en gång var fjärde timme.

När jag överväger det nya läget, föreslår jag att gå från enkla exempel till komplexa.

I det vanligaste fallet har vi helt enkelt nya filer med inkrement, och vi kopierar dem helt enkelt till kapacitetsskjutbanan. Oavsett vilket läge som används i backupjobbet, oavsett om det tillhör den förseglade delen av kedjan eller inte, oavsett om vårt driftfönster har gått ut. De bara tog det och kopierade det.

Processen bakom detta är fortfarande uttorkning som beskrivits ovan. I kopieringsläge ser den också till att vi inte kopierar block som redan finns på vårt lager. Den enda skillnaden är att om vi i filmläge ersatte riktiga filer med dummy-filer, här rör vi dem inte på något sätt och lämnar allt som det är. Annars är det exakt samma uttorkningsindex, som noggrant försöker spara pengar och tid.

Frågan uppstår – om man tittar på UI finns det en möjlighet att välja båda alternativen samtidigt. Hur kommer ett sådant kombinerat läge att fungera?

Låt oss räkna ut det.

Början är standard: en säkerhetskopia skapas och kopieras omedelbart. Ett steg skapas till det och kopieras också. Detta händer tills det ögonblick då vi inser att filerna har lämnat vårt operationsfönster och en förseglad kedja har dykt upp. Vid denna tidpunkt utför vi en uttorkningsoperation och ersätter dessa filer med dummyfiler. Naturligtvis kopierar vi ingenting igen till kapacitetsskjutbanan.

All denna fascinerande logik är ansvarig för bara en kryssruta i gränssnittet: Kopiera säkerhetskopior till objektlagring så snart de skapas.

Varför behöver vi detta kopieringsläge?

Det är ännu bättre att omformulera frågan så här: vilka risker skyddas vi från med dess hjälp? Vilket problem hjälper det oss att lösa?

Svaret är uppenbart: naturligtvis är detta dataåterställning. Om vi ​​har en fullständig kopia av lokal data på objektlagringen, kan vi, oavsett vad som händer med vår produkt, alltid återställa data från filer som finns i den villkorliga Amazon.

Så låt oss gå igenom de möjliga scenarierna, från de enklaste till de mer komplexa.

Den enklaste olyckan som kan falla på våra huvuden är otillgängligheten av en av filerna i säkerhetskopieringskedjan.

En tråkigare historia är att en av omfattningarna av vårt SOBR-förvar gick sönder.

Ännu värre blir det när hela SOBR-förvaret har blivit otillgängligt, men kapacitetsskjutbanan fungerar.
Och allt är riktigt dåligt - det är när backupservern dör och din första önskan är att försöka springa till den kanadensiska gränsen på tio minuter.

Låt oss nu titta på varje situation separat.

När vi har förlorat en (och till och med flera) säkerhetskopior behöver vi bara starta omsökningsprocessen för förvaret, och den förlorade filen kommer att ersättas med en dummy-fil. Och genom att använda rehydreringsprocessen (som diskuterades i början av artikeln), kommer användaren att kunna ladda ner data från kapacitetsskjutbanan till lokal lagring.

Nu är situationen mer komplicerad. Låt oss anta att vår SOBR består av två grader som körs i Performance-läge, vilket innebär att våra .vbk och .vib är utspridda över dem i ett ganska ojämnt lager. Och någon gång i tiden blir en av omfattningarna otillgänglig, och användaren behöver omedelbart återställa maskinen, vars en del av data ligger just på denna omfattning.

Användaren startar återställningsguiden, väljer den punkt till vilken han vill återställa och guiden, medan han arbetar, kommer till insikten att han inte har all data som behövs för återställning lokalt och därför måste laddas ner från kapacitetsfotograferingen Galleri. Samtidigt kommer block som finns kvar på lokal lagring inte att laddas ner från molnet. Ära till återställningsindexet (ja, det nämndes också i början av artikeln).

En subtyp av detta fall är att hela SOBR-förvaret blev otillgängligt. I det här fallet har vi inget att kopiera från lokal lagring, och alla block laddas ner från molnet.

Och den mest intressanta situationen är att backupservern dog. Det finns två alternativ här: administratören är bra och gjorde säkerhetskopior av konfigurationer, och administratören är en ond Pinocchio själv och gjorde inte säkerhetskopior av konfigurationer.

I det första fallet kommer det att räcka för honom att helt enkelt distribuera en ren installation av VBR någonstans och återställa dess databas från en säkerhetskopia med standardmetoder. I slutet av denna process kommer allt att återgå till det normala. Eller så kommer den att återställas enligt något av scenarierna ovan.

Men om administratören antingen är sin egen fiende, eller om konfigurationsbackupen också drabbades av ett episkt misslyckande, kommer vi inte ens här att lämna honom åt ödets nåd. För det här fallet har vi introducerat en ny procedur som heter Import Object Storage. Det låter dig hoppa över processen att manuellt återskapa ett SOBR-förråd och koppla en kapacitetsskjutbana till det med efterföljande omskanning, och helt enkelt lägga till ett lagringsobjekt till Vim-gränssnittet och köra Import Storage Repository-proceduren. Det enda som kan stå i vägen mellan dig och dina säkerhetskopior är en begäran om att ange ett lösenord om dina säkerhetskopior var krypterade.

Det här handlar förmodligen om kopieringsläge och vi går vidare till

Förseglat läge

Huvudtanken är att nya säkerhetskopior inte kan visas på den valda SOBR-omfattningen av förvaret. Före v10 hade vi bara underhållsläge, då allt arbete med förvaret var helt förbjudet. Ett slags hardcore-läge för att stänga av lagring, där endast Evakuera-knappen är tillgänglig, som transporterar säkerhetskopior till en annan omfattning en gång.

Och förseglat läge är ett slags "mjukt" alternativ: vi förbjuder skapandet av nya säkerhetskopior och raderar gradvis gamla enligt den valda retentionen, men i processen förlorar vi inte möjligheten att återställa från lagrade punkter. En mycket användbar sak när vi antingen har en hårdvara som närmar sig slutet av sin livslängd och behöver byta ut den, eller så behöver vi bara frigöra den för något viktigare, men det finns ingenstans att ta den och flytta allt på en gång. Eller så går det inte att radera.

Följaktligen är operationsprincipen ganska enkel: det är nödvändigt att förbjuda alla skrivoperationer (uppkomsten av nya data), lämna läsning (återställningar) och radering (retention).

Båda lägena kan användas samtidigt, men tänk på att underhåll har högre prioritet.

Som ett exempel, betrakta en SOBR som består av två omfattningar. Låt oss anta att vi under de första fyra dagarna skapade säkerhetskopior i Forever Forever Incremental-läget, och sedan förseglar vi omfattningen.Detta leder till att vi initierar skapandet av en ny aktiv full på den andra tillgängliga omfattningen. Om vår retention är fyra, så raderas den med gott samvete när hela kedjan som ligger på den förseglade utsträckningen överskrider sina gränser.

Det finns situationer när raderingen sker tidigare. Till exempel är detta Framåt inkrementellt med periodiska fuller. Om vi ​​skapade fullständiga säkerhetskopior under de första två dagarna, och på torsdag bestämmer vi oss för att försegla förvaret, kommer på fredag, när en ny säkerhetskopia skapas, filen för måndagen att raderas eftersom det finns inga beroenden till denna punkt. Och själva poängen beror inte på någon. Sedan väntar vi tills fyra punkter skapas på tillgänglig omfattning och raderar de återstående tre, som inte kan raderas oberoende av varandra.

Saker och ting är enklare med Reverse Incremental. I den är de äldsta punkterna inte beroende av någonting och kan säkert raderas. Så snart en ny .vbk skapas i en ny utsträckning kommer därför de gamla .vrbs att raderas en efter en.

Förresten, varför skapar vi en ny .vbk varje gång: om vi inte skapade den, utan fortsatte med den gamla kedjan av inkrement, så skulle den gamla .vbk frysa oändligt lång tid i vilket läge som helst, vilket förhindrar att den raderas. Därför beslutades att så fort omfattningen är förseglad skapar vi en fullständig backup på den fria omfattningen.

Saker och ting är mer komplicerade med kapacitetsskjutbanan.

Låt oss först titta på kopieringsläget. Låt oss anta att vi aktivt skapade säkerhetskopior i fyra dagar, och sedan var kapacitetsskjutbanan förseglad. Vi raderar ingenting, men uthärdar ödmjukt lagringen, varefter vi raderar data från kapacitetsskjutbanan.

Ungefär samma sak händer i flyttläge - vi väntar på retuscheringen, raderar den gamla i det lokala lagringsutrymmet och raderar den som lagrats i objektlagringen.

Ett intressant exempel med Forever forward incremental. Vi installerar retention vid tre punkter och börjar göra säkerhetskopior på måndag, som regelbundet kopieras till molnet. Efter försegling av lagringen fortsätter säkerhetskopior att skapas, med bibehållen tre punkter, men data som lagras i kapacitetsstrecket förblir beroende och kan inte raderas. Därför väntar vi till torsdag, då vår .vbk går utöver retention, och först då raderar vi lugnt hela den sparade kedjan.

Och en liten ansvarsfriskrivning: alla exempel här visas med en maskin. Om du har flera av dem i din säkerhetskopia kommer deras retuschering att skilja sig beroende på om Active Full gjordes eller inte.

Det är i princip allt som finns. Så låt oss gå vidare till den mest hårda funktionen -

Oföränderlighet

Som med de föregående punkterna är det första vilket problem denna funktion löser. Så fort vi laddar upp våra säkerhetskopior någonstans för lagring finns det en stark önskan att garantera deras säkerhet, det vill säga att fysiskt förbjuda radering och eventuella ändringar under en given lagring. Inklusive administratörer, inklusive under deras root-konton. Detta gör att du kan skydda dem från oavsiktlig eller avsiktlig skada. Alla som arbetar med AWS kan ha stött på en liknande funktion som heter Objektlås.

Låt oss nu titta på läget i allmänna termer och sedan fördjupa oss i detaljerna. I vårt exempel kommer Immutability att aktiveras för vår kapacitetsskjutbana med en retention på fyra dagar. Och kopieringsläget är aktiverat i säkerhetskopian.

Oföränderlighet interagerar inte med allmän retention på något sätt. Det ger till exempel inga extrapoäng eller liknande. Det är bara det att en person inte kan ta bort säkerhetskopior inom fyra dagar. Om du gör en säkerhetskopia på måndag kommer du bara att kunna ta bort filen på fredag.

Alla tidigare förklarade begrepp om uttorkning, index och metadata fortsätter att fungera exakt likadant. Men med ett villkor - blocket sätts inte bara för data, utan också för metadata. Detta görs om en listig angripare bestämmer sig för att radera vår metadatadatabas och för att förhindra datablock från att förvandlas till värdelös binär blandning.

Nu är det ett bra tillfälle att förklara vår blockgenereringsteknik. Eller blockgenerering. För att göra detta, överväga situationen som ledde till dess utseende.

Låt oss ta en tidsskala på sex dagar och nedan kommer vi att markera tidpunkten för den förväntade utgången av oföränderlighet. Den första dagen tar vi och skapar en fil som består av datablock a och dess metadata. Om oföränderlighet är inställd på tre dagar är det logiskt att anta att den fjärde dagen kommer data att låsas upp och raderas. På den andra dagen kommer vi att lägga till en ny fil2, bestående av block b med samma inställningar. Block a måste fortfarande tas bort den fjärde dagen. Men på den tredje dagen händer något hemskt - en File3-fil skapas, bestående av ett nytt block d och en länk till det gamla blocket a. Detta innebär att för ett block och dess oföränderlighet flaggan måste återställas till ett nytt datum, som flyttas till den sjätte dagen. Och här uppstår ett problem - i riktiga säkerhetskopior finns det ett stort antal sådana block. Och för att förlänga deras oföränderlighetsperiod måste du göra ett stort antal förfrågningar varje gång. Och i själva verket kommer detta att vara en nästan oändlig daglig process, eftersom vi med en hög grad av sannolikhet kommer att hitta rejäla högar av deduplicerade block med varje kopia. Vad betyder ett stort antal förfrågningar från objektlagringsleverantörer? Höger! Stor räkning i slutet av månaden.

Och för att inte direkt exponera dina favoritklienter för stora pengar, uppfanns blockgenereringsmekanismen. Detta är en extra period som vi lägger till den inställda oföränderlighetsperioden. I exemplet nedan är denna period två dagar. Men detta är bara ett exempel. I verkligheten använder de sin egen formel, vilket ger cirka tio extra dagar under en månatlig låsning.

Låt oss fortsätta att överväga samma situation, men med blockgenerering. Den första dagen skapar vi fil1 från block a och metadata. Vi lägger ihop generationsperioden och oföränderligheten - det betyder att möjligheten att ta bort filen kommer att vara den sjätte dagen. Om vi ​​den andra dagen skapar File2, bestående av block b och en länk till block a, så händer ingenting med det förväntade raderingsdatumet. Hon stod som hon gjorde den sjätte dagen. Och därmed försöker vi spara pengar på antalet förfrågningar. Den enda situationen när tidsfristen kan flyttas är om generationsperioden har löpt ut. Det vill säga, om den nya File3 den tredje dagen innehåller en länk för att blockera a, kommer generation 2 att läggas till eftersom Gen1 redan har gått ut. Och det förväntade datumet för borttagning av block a kommer att flyttas till den åttonde dagen. Detta tillåter oss att dramatiskt minska antalet förfrågningar för att förlänga livslängden för deduplicerade block, vilket sparar kunder massor av pengar.

Tekniken i sig är tillgänglig för användare av S3- och S3-kompatibel hårdvara, vars tillverkare garanterar att deras implementering inte skiljer sig från Amazons. Därav svaret på den legitima frågan varför Azure inte stöds - de har en liknande funktion, men den fungerar på behållarnivå, inte på enskilda objekt. Förresten, Amazon själv har objektlås i två lägen: efterlevnad och styrning. I det andra fallet kvarstår möjligheten att den största administratören ovanför administratörerna och roten ovanför rötterna, trots objektlåset, fortfarande tar bort data. I fallet med efterlevnad är allt spikat hårt och ingen kan radera säkerhetskopiorna. Även Amazon-administratörer (enligt deras officiella uttalanden). Det här är läget vi stödjer.

Och som vanligt några användbara länkar:

• Про Blockera generation i varje detalj.
• All information om Veeam Backup & Replikering 10 när den är som bäst
• О Kapacitetsnivå i detalj

Källa: will.com