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

Za izvođenje ove jednostavne (kako se čini) radnje bilo je dovoljno ispuniti dva uvjeta: sve točke iz premještene sigurnosne kopije moraju biti izvan granica gore spomenutog operativnog prozora vraćanja, koji je eksplicitno postavljen u korisničkom sučelju. I drugo: lanac mora biti u takozvanom “zapečaćenom obliku” (sealed backup chain ili Inactive Backup Chain). Odnosno, tijekom vremena u ovom lancu ne dolazi do promjena.

Ali u VBR v10 koncept je nadopunjen novim funkcijama - pojavio se Copy Mode, Sealed Mode i nešto teško izgovorljivog naziva Immutability.

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

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

• Bez imalo žaljenja. Autor članka.

Kao što je bilo

Pa, počnimo s analizom prozora operativnog vraćanja i zapečaćene sigurnosne kopije (ili kako se zovu u dokumentaciji Inactive Backup Chain). Bez njihovog razumijevanja daljnje objašnjenje neće biti moguće.

Kao što vidimo na slici, imamo svojevrsni backup lanac s podatkovnim blokovima, koji se nalazi na Performance tier SOBR repozitorija na koji je Capacity Tier povezan. Naš operativni rezervni prozor je tri dana.

U skladu s tim, .vbk kreiran u ponedjeljak zatvara prethodni lanac, čiji je prozor postavljen na tri dana. A to znači da možete bezbrižno početi prevoziti sve starije od ova tri dana na streljanu.

Ali što se točno mislilo pod zapečaćenim lancem i što se moglo poslati na kapacitet streljane u ažuriranju 4?

Za Forward Incremental, znak zatvaranja lanca je stvaranje nove pune sigurnosne kopije. I nije važno kako se dobiva ova puna 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 ulaze u radni prozor.

U slučaju povećanja naprijed s povratima, to su svi povrati i .vbk, ako postoji drugi .vbk na opsegu izvedbe

Sada razmotrimo mogućnost rada s lancima sigurnosne kopije. Ovdje su transportirani samo predmeti koji spadaju pod GFS zadržavanje. Jer sve pohranjeno u novijim lancima sigurnosne kopije može se promijeniti na ovaj ili onaj način.

Sada pogledajmo ispod haube. Tamo se događa proces koji se zove dehidracija - ostavljanje praznih datoteka sigurnosne kopije na ekstentu i povlačenje blokova iz tih datoteka na streljanu kapaciteta. Kako bi se optimizirao ovaj proces, koristi se takozvani indeks dehidracije, koji vam omogućuje da izbjegnete kopiranje blokova koji su već kopirani na kapacitet strelišta.

Pogledajmo kako to izgleda na primjeru: Recimo da imamo .vbk koji je izašao iz transakcijskog prozora i pripada zapečaćenom lancu. To znači da ga imamo puno pravo premjestiti na kapacitet streljane. U trenutku premještanja stvara se datoteka metapodataka u crtici kapaciteta i blokovima prenesene datoteke. Datoteka metapodataka na razini veze opisuje od kojih se blokova sastoji naša datoteka. U slučaju na slici, naša prva datoteka sastoji se od blokova a, b, c i metapodaci sadrže poveznice na te blokove. Kada imamo drugu .vbk datoteku, spremnu za prijenos i koja se sastoji od blokova a, b i d, mi, analizirajući indeks dehidracije, razumijemo da samo blok d treba prenijeti. A njegova datoteka s metapodacima sadržavat će poveznice na dva prethodna bloka i jedan novi.

U skladu s tim, proces ponovnog popunjavanja tih praznih mjesta podacima naziva se rehidracija. Već koristi vlastiti indeks rehidracije, temeljen na najstarijoj .vbk datoteci na lokalnom stupnju izvedbe. Odnosno, ako korisnik želi vratiti datoteku iz kapaciteta streljane, prvo kreiramo indeks blokova najstarije pune sigurnosne kopije i prenosimo samo blokove koji nedostaju iz kapaciteta strelišta. U slučaju prikazanom na slici, da bismo rehidrirali FullBackup1.vbk prema rehidracijskom indeksu, potreban nam je samo blok C koji uzimamo iz kapaciteta streljane. Ako objekt u oblaku za pohranu služi kao strelište kapaciteta, to vam omogućuje uštedu enormnih količina 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 moramo kopirati velike potpune sigurnosne kopije datoteka, a prema našem istraživanju, čak i ako između njih prođe duže vrijeme, ovaj algoritam deduplikacije daje najbolji rezultat.

Ali više indeksa za boga indeksa! Postoji i indeks za oporavak podataka! Kada počnemo vraćati stroj koji se nalazi u crtici kapaciteta, čitat ćemo samo jedinstvene blokove podataka koji nisu u crtici performansi.

Kako se to dogodilo?

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

Način kopiranja

Uvelike se temelji na postojećim tehnologijama, ali nosi potpuno drugačiju logiku korištenja. 

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

Usporedite li izravno načine rada Premjesti i Kopiraj, izgledat će ovako:

• Samo zapečaćeni lanac se može pomicati. U slučaju načina kopiranja, prenosi se apsolutno sve, bez obzira što se događa u zadatku sigurnosne kopije.
• Premještanje se pokreće kada datoteke prijeđu granice prozora operativne sigurnosne kopije, a kopiranje se pokreće čim se datoteka sigurnosne kopije pojavi.
• Praćenje novih podataka za kopiranje odvija se stalno, a za premještanje se aktiviralo jednom svaka 4 sata.

U razmatranju novog načina, predlažem prijelaz s jednostavnih primjera na složene.

U najčešćem slučaju jednostavno imamo nove datoteke s inkrementima i jednostavno ih kopiramo na kapacitet streljane. Bez obzira na to koji se način rada koristi u backup poslu, bez obzira na to pripada li zatvorenom dijelu lanca ili ne, bez obzira na to je li naš operativni prozor istekao. Samo su to uzeli i kopirali.

Proces iza ovoga i dalje je dehidracija kao što je gore opisano. U načinu kopiranja također osigurava da ne kopiramo blokove koji su već u našoj pohrani. Jedina je razlika u tome što ako smo u filmskom načinu rada stvarne datoteke zamijenili lažnim datotekama, ovdje ih ni na koji način ne diramo i ostavljamo sve kako jest. Inače, to je točno 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 kombinirani način rada?

Hajde da shvatimo.

Početak je standardan: sigurnosna kopija se kreira i odmah kopira. Za njega se stvara inkrement koji se također kopira. To se događa sve do trenutka kada shvatimo da su datoteke izašle iz našeg operativnog prozora i pojavio se zapečaćeni lanac. U ovom trenutku izvodimo operaciju dehidracije i zamjenjujemo ove datoteke lažnim datotekama. Naravno, ništa više ne kopiramo na kapacitet streljane.

Za svu ovu fascinantnu logiku odgovoran je samo jedan potvrdni okvir u sučelju: Kopiraj sigurnosne kopije u objektnu pohranu čim se kreiraju.

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

Još je bolje preformulirati pitanje na sljedeći način: od kojih se rizika štitimo uz njegovu pomoć? Koji problem nam pomaže riješiti?

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

Pa prođimo kroz moguće scenarije, od najjednostavnijih do složenijih.

Najobičnija nesreća koja nam se može obiti o glavu je nedostupnost jedne od datoteka u backup lancu.

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

Još gore postaje kada je cijelo skladište SOBR-a postalo nedostupno, ali kapacitet streljane radi.
I sve je jako loše - tada crkne rezervni server i prva vam je želja pokušati otrčati do kanadske granice za desetak minuta.

Sada pogledajmo svaku situaciju zasebno.

Kada smo izgubili jednu (pa čak i nekoliko) datoteka sigurnosne kopije, tada sve što trebamo učiniti je pokrenuti proces ponovnog skeniranja repozitorija, a izgubljena datoteka će biti zamijenjena lažnom datotekom. A korištenjem procesa rehidracije (o čemu je bilo riječi na početku članka), korisnik će moći preuzeti podatke s kapaciteta strelišta u lokalnu pohranu.

Sada je situacija kompliciranija. 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 preko njih u prilično neravnomjernom sloju. I u nekom trenutku, jedan od opsega postaje nedostupan, a korisnik hitno mora vratiti stroj, čiji dio podataka leži upravo na tom opsegu.

Korisnik pokreće čarobnjak za oporavak, odabire točku do koje želi vratiti, a čarobnjak tijekom rada dolazi do spoznaje da on nema sve podatke potrebne za oporavak lokalno te ih stoga treba preuzeti sa snimanja kapaciteta. galerija. Istodobno, blokovi koji ostanu na lokalnoj pohrani neće se preuzeti iz oblaka. Slava indeksu vraćanja (da, također je spomenuto na početku članka).

Podvrsta ovog slučaja je da je cijeli SOBR repozitorij postao nedostupan. U ovom slučaju nemamo što kopirati iz lokalne pohrane, 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 sigurnosnu kopiju konfiguracije, a admin je sam zli Pinokio i nije napravio sigurnosnu kopiju konfiguracije.

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

Ali ako je admin sam sebi neprijatelj ili je sigurnosna kopija konfiguracije također pretrpjela epski kvar, onda ga ni ovdje nećemo ostaviti na milost i nemilost. Za ovaj slučaj uveli smo novi postupak pod nazivom Import Object Storage. Omogućuje vam da preskočite proces ručnog ponovnog kreiranja SOBR repozitorija i pripajanja kapaciteta streljane na njega s naknadnim ponovnim skeniranjem, te jednostavno dodate objekt za pohranu u Vim sučelje i pokrenete proceduru Import Storage Repository. Jedina stvar koja može stajati na putu između vas i vaših sigurnosnih kopija je zahtjev za unos lozinke ako su vaše sigurnosne kopije šifrirane.

Ovo je vjerojatno sve o načinu kopiranja i idemo dalje

Zatvoreni način rada

Glavna ideja je da se nove sigurnosne kopije ne mogu pojaviti na odabranom SOBR opsegu repozitorija. Prije v10 imali smo samo Maintenance Mode, kada je svaki rad s repozitorijem bio potpuno zabranjen. Neka vrsta hardcore moda za gašenje pohrane, gdje je dostupna samo tipka Evacuate, koja jednokratno prenosi sigurnosne kopije na drugu razinu.

A Sealed način je neka vrsta "meke" opcije: zabranjujemo stvaranje novih sigurnosnih kopija i postupno brišemo stare prema odabranom zadržavanju, ali pritom ne gubimo mogućnost vraćanja iz pohranjenih točaka. Vrlo korisna stvar kada ili imamo neki hardver pri kraju životnog vijeka i trebamo ga zamijeniti ili ga samo trebamo osloboditi za nešto važnije, ali ga nemamo gdje uzeti i sve odjednom preseliti. Ili se ne može izbrisati.

Sukladno tome, princip rada je vrlo jednostavan: potrebno je zabraniti sve operacije pisanja (pojava novih podataka), ostavljanja čitanja (restoracije) i brisanja (zadržavanja).

Oba načina rada mogu se koristiti istovremeno, ali imajte na umu da Održavanje ima viši prioritet.

Kao primjer, razmotrite SOBR koji se sastoji od dva opsega. Pretpostavimo da smo prva četiri dana stvorili sigurnosne kopije u Forward Forever Incremental modu, a zatim smo zapečatili ekstent. To dovodi do činjenice da smo pokrenuli stvaranje novog aktivnog punog na drugom dostupnom ekstentu. Ako je naše zadržavanje četiri, tada kada cijeli lanac koji se nalazi na zapečaćenom opsegu prijeđe svoje granice, briše se čiste savjesti.

Postoje situacije kada se brisanje dogodi ranije. Na primjer, ovo je Inkrementalni naprijed s periodičkim punim. Ako smo prva dva dana izradili pune sigurnosne kopije, au četvrtak odlučimo zapečatiti repozitorij, onda će u petak, kada se napravi nova sigurnosna kopija, datoteka za ponedjeljak biti izbrisana jer do ove točke nema ovisnosti. A sama točka ne ovisi ni o kome. Zatim čekamo dok se ne stvore četiri točke na dostupnom opsegu i brišemo preostale tri, koje se ne mogu brisati neovisno jedna o drugoj.

Stvari su jednostavnije s Obrnutim inkrementalnim. U njemu najstarije točke ne ovise ni o čemu i mogu se sigurno izbrisati. Stoga, čim se stvori novi .vbk na novom opsegu, stari .vrbs će se brisati jedan po jedan.

Usput, zašto svaki put stvaramo novi .vbk: ako ga nismo stvorili, nego nastavili stari lanac inkremenata, tada bi se stari .vbk zamrzao beskonačno dugo u bilo kojem načinu, sprječavajući njegovo brisanje. Stoga je odlučeno da čim se opseg zapečati, napravimo punu sigurnosnu kopiju na slobodnom opsegu.

Stvari su kompliciranije s kapacitetom strelišta.

Prvo, pogledajmo način kopiranja. Pretpostavimo da smo četiri dana aktivno stvarali rezerve, a onda je kapacitet streljane zapečaćen. Ništa ne brišemo, već skromno trpimo zadržavanje, nakon čega brišemo podatke sa streljane kapaciteta.

Otprilike ista stvar se događa u načinu premještanja - čekamo retuš, brišemo stari u lokalnoj pohrani, a brišemo onaj pohranjen u pohrani objekta.

Zanimljiv primjer s Forever forward incremental. Instaliramo retenciju na tri točke i od ponedjeljka krećemo s izradom backupa koji se redovito kopira u oblak. Nakon zatvaranja pohrane, sigurnosne kopije se nastavljaju stvarati, održavajući tri točke, ali podaci pohranjeni u ploči kapaciteta ostaju ovisni i ne mogu se izbrisati. Stoga čekamo četvrtak, kada naš .vbk pređe retenciju, pa tek onda mirno brišemo cijeli spremljeni lanac.

I malo odricanje od odgovornosti: svi primjeri ovdje prikazani su s jednim strojem. Ako ih imate nekoliko u sigurnosnoj kopiji, tada će se njihov retuš razlikovati ovisno o tome je li Active Full napravljen ili ne.

To je u biti sve što se tiče toga. Dakle, prijeđimo na najtvrđu značajku -

Nepromjenljivost

Kao i kod prethodnih točaka, prva stvar je koji problem ova funkcija rješava. Čim svoje sigurnosne kopije postavimo negdje na pohranu, postoji jaka želja da se zajamči njihova sigurnost, odnosno da se fizički zabrani njihovo brisanje i bilo kakva izmjena tijekom određenog zadržavanja. Uključujući administratore, uključujući pod njihovim root računima. To vam omogućuje da ih zaštitite od slučajnog ili namjernog oštećenja. Svatko tko radi s AWS-om možda je naišao na sličnu značajku koja se zove Object Lock.

Sada pogledajmo način općenito, a zatim zaronimo u detalje. U našem primjeru, nepromjenjivost će biti omogućena za naš kapacitet strelišta uz zadržavanje od četiri dana. A način 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. Samo što osoba ne može izbrisati sigurnosne kopije datoteka unutar četiri dana. Ako napravite sigurnosnu kopiju u ponedjeljak, moći ćete izbrisati njenu datoteku tek u petak.

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

Sada je pravo vrijeme da objasnimo našu tehnologiju generiranja blokova. Ili blok generacija. Da biste to učinili, razmotrite situaciju koja je dovela do njegovog izgleda.

Uzmimo vremensku skalu od šest dana i ispod ćemo označiti vrijeme očekivanog isteka nepromjenjivosti. Prvog dana uzimamo i stvaramo datoteku koja se sastoji od bloka podataka a i njegovih metapodataka. Ako je nepromjenjivost postavljena na tri dana, logično je pretpostaviti da će se četvrti dan podaci otključati i izbrisati. Drugog dana ćemo dodati novu datoteku2, koja se sastoji od bloka b s istim postavkama. Blok a još treba ukloniti četvrti dan. Ali trećeg dana događa se nešto strašno - stvorena je datoteka File3 koja se sastoji od novog bloka d i poveznice na stari blok a. To znači da se za blok i njegovu zastavu nepromjenjivosti mora resetirati na novi datum, koji se pomiče na šesti dan. I tu se javlja problem - u pravim sigurnosnim kopijama postoji ogroman broj takvih blokova. A da biste im produljili razdoblje nepromjenjivosti, svaki put morate podnijeti ogroman broj zahtjeva. I zapravo, to će biti gotovo beskonačan svakodnevni proces, jer ćemo s velikom vjerojatnošću pronaći pozamašne hrpe dedupliciranih blokova sa svakom kopijom. Što znači veliki broj zahtjeva od pružatelja usluga pohrane objekata? Pravo! Ogroman račun na kraju mjeseca.

A kako ne biste iz vedra neba izložili svoje omiljene klijente za značajan novac, izumljen je mehanizam za generiranje blokova. Ovo je dodatno razdoblje koje dodajemo postavljenom razdoblju nepromjenjivosti. U donjem primjeru, ovo razdoblje je dva dana. Ali ovo je samo primjer. U stvarnosti, oni koriste vlastitu formulu, koja daje otprilike deset dodatnih dana tijekom mjesečnog zaključavanja.

Nastavimo razmatrati istu situaciju, ali s generacijom blokova. Prvog dana stvaramo file1 iz bloka a i metapodataka. Zbrajamo razdoblje generiranja i nepromjenjivost - to znači da će mogućnost brisanja datoteke biti šesti dan. Ako drugog dana kreiramo File2, koji se sastoji od bloka b i veze na blok a, tada se ništa ne događa s očekivanim datumom brisanja. Stajala je kao i šesti dan. I time pokušavamo uštedjeti na broju zahtjeva. Jedina situacija kada se rok može pomaknuti je ako je isteklo proizvodno razdoblje. To jest, ako trećeg dana novi File3 sadrži vezu za blokiranje a, tada će se dodati generacija 2 jer je Gen1 već istekao. A očekivani datum brisanja bloka a pomaknut će se na osmi dan. To nam omogućuje dramatično smanjenje broja zahtjeva za produljenje životnog vijeka dedupliciranih blokova, što klijentima štedi gomilu novca.

Sama tehnologija dostupna je korisnicima S3 i S3-kompatibilnog hardvera, čiji proizvođači jamče da se njihova implementacija ne razlikuje od Amazonove. Otuda i odgovor na opravdano pitanje zašto Azure nije podržan – imaju sličnu značajku, ali radi na razini spremnika, a ne pojedinačnih objekata. Usput, 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 nad adminima i root nad rootovima unatoč zaključavanju objekta ipak izbriše podatke. U slučaju usklađenosti, sve je čvrsto zakovano i nitko ne može izbrisati sigurnosne kopije. Čak i Amazonovi administratori (prema njihovim službenim izjavama). Ovo je način rada koji podržavamo.

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

• na Generiranje blokova u svakom detalju.
• Sve informacije o Veeam Backup & Replication 10 u svom najboljem izdanju
• О Razina kapaciteta detaljno

Izvor: www.habr.com