Capacity Tier (ili kako ga zovemo unutar Vim - captir) pojavio se još u danima Veeam Backup and Replication 9.5 Update 4 pod imenom Archive Tier. Ideja iza toga je da omogući premještanje sigurnosnih kopija koje su ispale iz takozvanog prozora operativnog vraćanja u pohranu objekata. Ovo je pomoglo da se oslobodi prostor na disku za one korisnike koji su ga imali malo. A ova opcija se zvala Move Mode.

Za izvođenje ove jednostavne (kako se čini) radnje bilo je dovoljno ispuniti dva uslova: sve tačke iz premeštene rezervne kopije moraju biti izvan granica gore pomenutog prozora operativnog vraćanja, koji je eksplicitno postavljen u korisničkom interfejsu. I drugo: lanac mora biti u takozvanom “zapečaćenom obliku” (zapečaćeni rezervni lanac ili Inactive Backup Chain). Odnosno, u ovom lancu ne dolazi do promjena tokom vremena.

Ali u VBR v10 koncept je dopunjen novim funkcijama - Copy Mode, Sealed Mode i pojavila se stvar sa teško izgovorljivim imenom Immutability.

Ovo su fascinantne stvari o kojima ćemo danas pričati. Prvo o tome kako je to funkcioniralo u VBR9.5u4, a zatim o promjenama u desetoj verziji.

I neka mi oproste šampioni čistog jezika, ali previše je pojmova koji se ne mogu prevesti.
Dakle, ovdje će biti mnogo anglicizama.
I puno gifova.
I slike.

• Bez imalo žaljenja. Autor članka.

Kao što je bilo

Pa, počnimo s analizom operativnog prozora za vraćanje i zapečaćene sigurnosne kopije (ili kako se zovu u dokumentaciji lanca neaktivnih sigurnosnih kopija). Bez njihovog razumijevanja, dalje objašnjenje neće biti moguće.

Kao što vidimo na slici, imamo neku vrstu backup lanca sa blokovima podataka, koji se nalazi na nivou performansi SOBR spremišta na koje je povezan nivo kapaciteta. Naš operativni rezervni period je tri dana.

Shodno tome, .vbk kreiran u ponedjeljak zatvara prethodni lanac, čiji je prozor postavljen na tri dana. A to znači da možete bezbedno da počnete da prevozite sve starije od ova tri dana na streljanu.

Ali šta se tačno podrazumevalo pod zapečaćenim lancem i šta se moglo poslati na strelište kapaciteta u ažuriranju 4?

Za Forward Incremental, znak zaptivanja lanca je stvaranje nove potpune rezervne kopije. I nije važno kako se dobiva ova potpuna sigurnosna kopija: uzimaju se u obzir i sintetičke pune i aktivne pune sigurnosne kopije.

U slučaju Reverse, to su sve datoteke koje ne padaju u operativni prozor.

U slučaju povećanja naprijed sa vraćanjem, to su sve vraćanja i .vbk, ako postoji još jedan .vbk na opsegu performansi

Sada razmotrimo opciju rada sa lancima sigurnosne kopije. Ovdje su transportovani samo predmeti koji potpadaju pod GFS zadržavanje. Jer sve što je pohranjeno u novijim lancima rezervnih kopija može se promijeniti na ovaj ili onaj način.

Pogledajmo sada ispod haube. Tamo se dešava proces koji se zove dehidracija - ostavljajući prazne rezervne fajlove na opsegu i povlačenjem blokova iz tih fajlova u opseg snimanja kapaciteta. Za optimizaciju ovog procesa koristi se takozvani indeks dehidracije, koji vam omogućava da izbjegnete kopiranje blokova koji su već kopirani u strelište kapaciteta.

Pogledajmo kako ovo izgleda na primjeru: Recimo da imamo .vbk koji je izašao iz prozora transakcije i pripada zapečaćenom lancu. To znači da imamo svako pravo da ga premestimo u kapacitet strelišta. U trenutku premještanja, datoteka metapodataka se kreira u crtici kapaciteta i blokovima prenesene datoteke. Datoteka metapodataka na nivou veze opisuje od kojih blokova se sastoji naš fajl. U slučaju na slici, naš prvi fajl se sastoji od blokova a, b, c i metapodaci sadrže veze do ovih blokova. Kada imamo drugi .vbk fajl, spreman za pokret i koji se sastoji od blokova a, b i d, mi, analizirajući indeks dehidracije, shvatimo da je potrebno prenijeti samo blok d. A njegova datoteka metapodataka će sadržavati veze do dva prethodna bloka i jednog novog.

U skladu s tim, proces vraćanja ovih praznih prostora podacima naziva se rehidracija. Već koristi svoj vlastiti indeks rehidratacije, zasnovan na najstarijoj .vbk datoteci na lokalnom opsegu performansi. Odnosno, ako korisnik želi da vrati datoteku sa strelišta kapaciteta, prvo kreiramo indeks blokova najstarije potpune rezervne kopije i prenosimo samo blokove koji nedostaju iz galerije kapaciteta. U slučaju prikazanom na slici, da bismo rehidrirali FullBackup1.vbk prema indeksu rehidracije, potreban nam je samo blok C koji preuzimamo sa strelišta kapaciteta. Ako objekat u oblaku za skladištenje služi kao strelište kapaciteta, to vam omogućava da uštedite ogromne količine novca.

Ovdje se može činiti da je ova tehnologija identična onoj koja se koristi u WAN akceleratorima, ali tako se samo čini. U akceleratorima, deduplikacija je globalna; ovdje se lokalna deduplikacija koristi unutar svake datoteke na određenom pomaku. To se događa zbog razlike u zadacima koji se rješavaju: ovdje trebamo kopirati velike datoteke pune sigurnosne kopije, a prema našem istraživanju, čak i ako između njih prođe duži vremenski period, ovaj algoritam deduplikacije daje najbolji rezultat.

Ali više indeksa za boga indeksa! Tu je i indeks za oporavak podataka! Kada počnemo obnavljati mašinu koja se nalazi u tablici kapaciteta, čitat ćemo samo jedinstvene blokove podataka koji se ne nalaze u tablici performansi.

Kako se to dogodilo?

To je sve za uvodni dio. Prilično je detaljan, ali kao što je već spomenuto, bez ovih detalja neće biti moguće objasniti kako funkcioniraju nove funkcije. Stoga, bez daljnjeg, prijeđimo na prvu.

Način kopiranja

Umnogome se zasniva na postojećim tehnologijama, ali ima potpuno drugačiju logiku upotrebe. 

Svrha ovog načina je osigurati da svi podaci koji se nalaze na lokalnom opsegu imaju kopiju u crtici kapaciteta.

Ako uporedite modove Move i Copy, to će izgledati ovako:

• Samo zapečaćeni lanac se može pomerati. U slučaju režima kopiranja, prenosi se apsolutno sve, bez obzira na to što se događa u zadatku sigurnosne kopije.
• Premještanje se pokreće kada datoteke izađu izvan granica operativnog prozora sigurnosne kopije, a kopiranje se pokreće čim se datoteka sigurnosne kopije pojavi.
• Praćenje novih podataka za kopiranje se dešava konstantno, a za premještanje se pokreće jednom svaka 4 sata.

U razmatranju novog načina rada predlažem da prijeđemo s jednostavnih primjera na složene.

U najčešćem slučaju, jednostavno imamo nove fajlove sa inkrementima i jednostavno ih kopiramo u strelište kapaciteta. Bez obzira na to koji način se koristi u backup poslu, bez obzira da li pripada zapečaćenom dijelu lanca ili ne, bez obzira da li je naš operativni prozor istekao. Samo su ga uzeli i kopirali.

Proces iza ovoga je i dalje dehidracija kao što je gore opisano. U načinu kopiranja, također osigurava da ne kopiramo blokove koji su već u našoj memoriji. Jedina razlika je u tome što ako smo u filmskom modu zamijenili prave datoteke lažnim datotekama, ovdje ih nikako ne diramo i ostavljamo sve kako jeste. Inače, to je potpuno isti indeks dehidracije, koji pažljivo pokušava uštedjeti vaš novac i vrijeme.

Postavlja se pitanje - ako pogledate korisničko sučelje, postoji mogućnost odabira obje opcije u isto vrijeme. Kako će funkcionirati takav kombinovani način rada?

Hajde da shvatimo.

Početak je standardan: kreira se sigurnosna kopija koja se odmah kopira. Kreira se inkrement na njega i također se kopira. To se dešava do trenutka kada shvatimo da su fajlovi napustili naš operativni prozor i pojavio se zapečaćeni lanac. U ovom trenutku izvodimo operaciju dehidracije i zamjenjujemo ove datoteke lažnim datotekama. Naravno, više ništa ne kopiramo na strelište kapaciteta.

Sva ova fascinantna logika je odgovorna za samo jedno polje za potvrdu u interfejsu: Kopirajte rezervne kopije u skladište objekata čim se kreiraju.

Zašto nam je potreban ovaj način kopiranja?

Još je bolje preformulisati pitanje na ovaj način: od kojih smo rizika zaštićeni uz njegovu pomoć? Koji problem nam pomaže da riješimo?

Odgovor je očigledan: naravno, ovo je oporavak podataka. Ako imamo potpunu kopiju lokalnih podataka na skladištu objekata, onda bez obzira na to što se dogodi s našim proizvodom, uvijek možemo vratiti podatke iz datoteka koje se nalaze u uvjetnom Amazonu.

Pa idemo kroz moguće scenarije, od najjednostavnijih do složenijih.

Najjednostavnija nesreća koja nam može pasti na glavu je nedostupnost jednog od fajlova u lancu rezervnih kopija.

Tužnija priča je da se pokvario jedan od ekstenata našeg SOBR repozitorija.

Postaje još gore kada je cijelo SOBR spremište postalo nedostupno, ali strelište kapaciteta radi.
I sve je jako loše - tada rezervni server umire i prva želja vam je da pokušate otrčati do kanadske granice za deset minuta.

Pogledajmo sada svaku situaciju posebno.

Kada izgubimo jednu (pa čak i nekoliko) rezervnih datoteka, sve što treba da uradimo je da pokrenemo proces ponovnog skeniranja spremišta, a izgubljena datoteka će biti zamenjena lažnom datotekom. A koristeći proces rehidracije (o kojem je bilo riječi na početku članka), korisnik će moći preuzeti podatke sa strelišta kapaciteta u lokalnu pohranu.

Sada je situacija komplikovanija. Pretpostavimo da se naš SOBR sastoji od dva ekstenta koji rade u načinu rada Performance, što znači da su naši .vbk i .vib raspoređeni po njima u prilično neravnom sloju. I u nekom trenutku jedan od ekstenata postaje nedostupan, a korisnik hitno treba da vrati mašinu, čiji deo podataka leži upravo na ovom ekstentu.

Korisnik pokreće čarobnjak za oporavak, bira tačku na koju želi da se vrati, a čarobnjak u radu dolazi do spoznaje da nema sve podatke potrebne za oporavak lokalno i da ga stoga treba skinuti sa snimanja kapaciteta galerija. Istovremeno, blokovi koji ostaju na lokalnoj pohrani neće se preuzimati iz oblaka. Slava indeksu vraćanja (da, spomenuto je i na početku članka).

Podtip ovog slučaja je da je cijelo SOBR spremište postalo nedostupno. U ovom slučaju nemamo ništa za kopirati iz lokalne memorije, a svi blokovi se preuzimaju iz oblaka.

A najzanimljivija situacija je da je backup server umro. Ovdje postoje dvije opcije: admin je super i napravio je sigurnosne kopije konfiguracije, a admin je sam zli Pinokio i nije napravio sigurnosne kopije konfiguracije.

U prvom slučaju će mu biti dovoljno da jednostavno negdje postavi čistu instalaciju VBR-a i vrati njegovu bazu podataka iz sigurnosne kopije standardnim sredstvima. Na kraju ovog procesa sve će se vratiti u normalu. Ili će biti obnovljen prema jednom od gore navedenih scenarija.

Ali ako je administrator ili sam sebi neprijatelj, ili je sigurnosna kopija konfiguracije također pretrpjela epski neuspjeh, onda ga ni ovdje nećemo prepustiti na milost i nemilost sudbini. Za ovaj slučaj, uveli smo novu proceduru pod nazivom Import Object Storage. Omogućava vam da preskočite proces ručnog ponovnog kreiranja SOBR spremišta i pričvršćivanja raspona snimanja kapaciteta uz naknadno ponovno skeniranje i jednostavno dodate objekt za skladištenje Vim interfejsu i pokrenete proceduru Import Storage Repository. Jedina stvar koja može stajati na putu između vas i vaših rezervnih kopija je zahtjev za unosom lozinke ako su vaše sigurnosne kopije šifrirane.

Ovo je vjerovatno sve o načinu kopiranja i prelazimo na njega

Sealed Mode

Glavna ideja je da se nove sigurnosne kopije ne mogu pojaviti na odabranom SOBR opsegu spremišta. Prije v10, imali smo samo način održavanja, kada je svaki rad sa spremištem bio potpuno zabranjen. Neka vrsta hardcore režima za gašenje skladišta, gde je dostupno samo dugme Evacuate, koje prenosi rezervne kopije u drugoj meri jednokratno.

I Sealed mod je neka vrsta „meke“ opcije: zabranjujemo stvaranje novih sigurnosnih kopija i postepeno brišemo stare prema odabranom zadržavanju, ali u tom procesu ne gubimo mogućnost vraćanja iz pohranjenih tačaka. Vrlo korisna stvar kada ili imamo dio hardvera koji je pri kraju svog vijeka i treba ga zamijeniti, ili ga jednostavno trebamo osloboditi za nešto važnije, ali ga nema gdje uzeti i sve odjednom premjestiti. Ili se ne može izbrisati.

Shodno tome, princip rada je prilično jednostavan: potrebno je zabraniti sve operacije pisanja (pojava novih podataka), ostaviti čitanje (restauracije) i brisanje (zadržavanje).

Oba načina se mogu koristiti istovremeno, ali imajte na umu da održavanje ima veći prioritet.

Kao primjer, uzmite SOBR koji se sastoji od dva ekstenta. Pretpostavimo da smo prva četiri dana kreirali sigurnosne kopije u Forward Forever Incremental modu, a zatim zapečatili ekstent, što dovodi do toga da iniciramo kreiranje novog aktivnog full na drugom dostupnom ekstentu. Ako je naše zadržavanje četiri, onda kada cijeli lanac koji se nalazi na zapečaćenom opsegu pređe svoje granice, briše se čiste savjesti.

Postoje situacije kada se brisanje dogodi ranije. Na primjer, ovo je inkrementalno naprijed s periodičnim punjenja. Ako smo prva dva dana napravili pune sigurnosne kopije, a u četvrtak odlučimo da zapečatimo spremište, onda će u petak, kada se napravi nova sigurnosna kopija, fajl za ponedjeljak biti obrisan jer do ove tačke nema zavisnosti. A sama poenta ne zavisi ni od koga. Zatim čekamo da se kreiraju četiri tačke na dostupnom ekstentu i brišemo preostale tri, koje se ne mogu brisati nezavisno jedna od druge.

Stvari su jednostavnije sa Reverse Incremental. U njemu najstarije tačke ne ovise ni o čemu i mogu se sigurno brisati. Stoga, čim se novi .vbk kreira na novom ekstentu, stari .vrbs će se brisati jedan po jedan.

Usput, zašto svaki put kreiramo novi .vbk: ako ga nismo kreirali, već nastavili stari lanac inkremenata, onda bi se stari .vbk zamrznuo na beskonačno dugo vrijeme u bilo kojem načinu, sprečavajući njegovo brisanje. Stoga je odlučeno da čim se ekstent zatvori, napravimo potpunu sigurnosnu kopiju na slobodnom ekstentu.

Stvari su složenije sa kapacitetom gađanja.

Pogledajmo prvo način kopiranja. Pretpostavimo da smo četiri dana aktivno stvarali rezervne kopije, a onda je kapacitet strelišta bio zapečaćen. Ništa ne brišemo, već ponizno podnosimo zadržavanje, nakon čega brišemo podatke iz kapaciteta strelišta.

Otprilike ista stvar se događa i u pokretnom modu - čekamo retuširanje, brišemo stari u lokalnoj memoriji, a brišemo onaj koji je pohranjen u skladištu objekata.

Zanimljiv primjer sa Forever inkrementalnim naprijed. Instaliramo retenciju na tri tačke i počinjemo da pravimo rezervne kopije u ponedeljak, koje se redovno kopiraju u oblak. Nakon zatvaranja skladišta, sigurnosne kopije nastavljaju da se kreiraju, održavajući tri tačke, ali podaci pohranjeni u tablici kapaciteta ostaju zavisni i ne mogu se izbrisati. Stoga čekamo do četvrtka, kada naš .vbk pređe dalje od zadržavanja, pa tek tada mirno brišemo cijeli sačuvani lanac.

I malo odricanje od odgovornosti: svi primjeri ovdje su prikazani sa jednom mašinom. Ako ih imate nekoliko u sigurnosnoj kopiji, tada će se njihovo retuširanje razlikovati ovisno o tome da li je Active Full napravljen ili ne.

To je u suštini sve što je tu. Dakle, pređimo na najtvrdokorniju funkciju -

Nepromjenjivost

Kao i kod prethodnih tačaka, prva stvar je koji problem rješava ova funkcija. Čim svoje sigurnosne kopije otpremimo negdje za skladištenje, postoji snažna želja da garantujemo njihovu sigurnost, odnosno da fizički zabranimo njihovo brisanje i bilo kakvu modifikaciju tokom datog zadržavanja. Uključujući administratore, uključujući pod njihovim root računima. To vam omogućava da ih zaštitite od slučajnog ili namjernog oštećenja. Svako ko radi sa AWS-om možda je naišao na sličnu funkciju pod nazivom Object Lock.

Sada pogledajmo način rada općenito, a zatim se udubimo u detalje. U našem primjeru, nepromjenjivost će biti omogućena za naše strelište kapaciteta sa zadržavanjem od četiri dana. A režim kopiranja je omogućen u sigurnosnoj kopiji.

Nepromjenjivost ni na koji način nije u interakciji s općim zadržavanjem. Na primjer, ne dodaje dodatne bodove ili nešto slično. Jednostavno, osoba ne može izbrisati backup fajlove u roku od četiri dana. Ako napravite rezervnu kopiju u ponedjeljak, moći ćete izbrisati njen fajl tek u petak.

Svi prethodno objašnjeni koncepti dehidracije, indeksi i metapodaci i dalje rade potpuno isto. Ali uz jedan uslov - blok je postavljen ne samo za podatke, već i za metapodatke. Ovo se radi u slučaju da lukavi napadač odluči obrisati našu bazu metapodataka i spriječiti da se blokovi podataka pretvore u beskorisnu binarnu kašu.

Sada je sjajno vrijeme da objasnimo našu tehnologiju generiranja blokova. Ili generiranje blokova. Da biste to učinili, razmotrite situaciju koja je dovela do njegovog pojavljivanja.

Uzmimo vremensku skalu od šest dana i ispod ćemo označiti vrijeme očekivanog isteka nepromjenjivosti. Prvog dana uzimamo i kreiramo fajl koji se sastoji od bloka podataka a i njegovih metapodataka. Ako je nepromjenjivost postavljena na tri dana, logično je pretpostaviti da će četvrtog dana podaci biti otključani i izbrisani. Drugog dana ćemo dodati novi fajl2 koji se sastoji od bloka b sa istim postavkama. Blok a i dalje treba ukloniti četvrtog dana. Ali trećeg dana se dešava nešto strašno - kreira se datoteka File3 koja se sastoji od novog bloka d i veze do starog bloka a. To znači da se za blok i njegovu nepromjenjivost zastavica mora vratiti na novi datum, koji se pomjera na šesti dan. I ovdje nastaje problem - u stvarnim sigurnosnim kopijama postoji ogroman broj takvih blokova. A da biste produžili njihov period nepromjenjivosti, svaki put morate napraviti ogroman broj zahtjeva. I u stvari, ovo će biti skoro beskonačan svakodnevni proces, jer ćemo sa velikom vjerovatnoćom pronaći ogromne hrpe dedupliciranih blokova sa svakom kopijom. Šta znači veliki broj zahtjeva od dobavljača skladištenja objekata? Tačno! Ogroman račun na kraju mjeseca.

A kako ne biste iz vedra neba razotkrili svoje omiljene klijente za pozamašan novac, izmišljen je mehanizam za generiranje blokova. Ovo je dodatni period koji dodajemo postavljenom periodu nepromjenjivosti. U primjeru ispod, ovaj period je dva dana. Ali ovo je samo primjer. U stvarnosti, oni koriste vlastitu formulu, koja daje otprilike deset dodatnih dana tokom mjesečnog zaključavanja.

Hajde da nastavimo da razmatramo istu situaciju, ali sa generisanjem blokova. Prvog dana kreiramo file1 od bloka a i metapodataka. Sabiramo period generisanja i nepromjenjivost - to znači da će prilika za brisanje datoteke biti šestog dana. Ako drugog dana kreiramo File2, koji se sastoji od bloka b i veze do bloka a, onda se ništa ne dešava sa očekivanim datumom brisanja. Stajala je kao i šestog dana. I na taj način pokušavamo uštedjeti na broju zahtjeva. Jedina situacija kada se rok može pomjeriti je ako je istekao period proizvodnje. Odnosno, ako trećeg dana novi File3 sadrži vezu za blokiranje a, tada će generacija 2 biti dodana jer je Gen1 već istekao. A očekivani datum za brisanje bloka a pomjeraće se na osmi dan. Ovo nam omogućava da dramatično smanjimo broj zahtjeva za produženje vijeka trajanja dedupliciranih blokova, što klijentima štedi tonu novca.

Sama tehnologija dostupna je korisnicima hardvera kompatibilnog sa S3 i S3, čiji proizvođači garantuju da se njihova implementacija ne razlikuje od Amazonove. Otuda i odgovor na legitimno pitanje zašto Azure nije podržan – imaju sličnu funkciju, ali radi na nivou kontejnera, a ne pojedinačnih objekata. Inače, sam Amazon ima zaključavanje objekata u dva načina: usklađenost i upravljanje. U drugom slučaju, ostaje mogućnost da najveći admin iznad administratora i root iznad roota, uprkos zaključavanju objekta, ipak briše podatke. U slučaju usklađenosti, sve je čvrsto prikovano i niko ne može izbrisati sigurnosne kopije. Čak i administratori Amazona (prema njihovim službenim izjavama). Ovo je način rada koji podržavamo.

I, kao i obično, nekoliko korisnih linkova:

• na Block Generation u svakom detalju.
• Sve informacije o Veeam Backup & Replication 10 u svom najboljem izdanju
• О Capacity Tier detaljno

izvor: www.habr.com