Capacity Tier (ali kot ga imenujemo v Vimu - captir) se je pojavil že v času Veeam Backup and Replication 9.5 Update 4 pod imenom Archive Tier. Ideja v ozadju je omogočiti premik varnostnih kopij, ki so padle iz tako imenovanega okna za obnovitev delovanja, v shrambo objektov. To je pomagalo sprostiti prostor na disku za tiste uporabnike, ki so ga imeli malo. In ta možnost se je imenovala Move Mode.

Za izvedbo tega preprostega (kot se zdi) dejanja je bilo dovolj, da sta bila izpolnjena dva pogoja: vse točke iz premaknjene varnostne kopije morajo biti zunaj meja zgoraj omenjenega okna operativne obnovitve, ki je izrecno nastavljeno v uporabniškem vmesniku. In drugič: veriga mora biti v tako imenovani "zapečateni obliki" (sealed backup chain ali Inactive Backup Chain). To pomeni, da v tej verigi sčasoma ne pride do sprememb.

Toda v VBR v10 je bil koncept dopolnjen z novimi funkcijami - pojavil se je Copy Mode, Sealed Mode in stvar s težko izgovorljivim imenom Immutability.

To so fascinantne stvari, o katerih bomo danes govorili. Najprej o tem, kako je delovalo v VBR9.5u4, nato pa o spremembah v deseti različici.

In naj mi zagovorniki čistega jezika oprostijo, vendar je preveč izrazov, ki jih ni mogoče prevesti.
Tako bo tukaj ogromno anglicizmov.
In veliko gifov.
In slike.

• Brez trohice obžalovanja. Avtor članka.

Kot je bilo

No, začnimo z analizo okna za obnovitev delovanja in zapečatene varnostne kopije (ali kot se imenujeta v dokumentaciji o neaktivni varnostni kopiji). Brez njihovega razumevanja nadaljnja razlaga ne bo mogoča.

Kot vidimo na sliki, imamo nekakšno rezervno verigo s podatkovnimi bloki, ki se nahaja na Performance tier SOBR repozitorija, na katerega je povezan Capacity Tier. Naše operativno varnostno obdobje je tri dni.

V skladu s tem .vbk, ustvarjen v ponedeljek, zapečati prejšnjo verigo, katere okno je nastavljeno na tri dni. In to pomeni, da lahko mirno začnete prevažati vse, kar je starejše od teh treh dni, na strelišče.

Toda kaj točno je mišljeno z zapečateno verigo in kaj je bilo mogoče poslati na zmogljivost strelišča v posodobitvi 4?

Za Forward Incremental je znak tesnjenja verige ustvarjanje nove popolne varnostne kopije. In ni pomembno, kako se ta popolna varnostna kopija pridobi: upoštevata se tako sintetična polna kot aktivna polna varnostna kopija.

V primeru Reverse so to vse datoteke, ki ne sodijo v operacijsko okno.

V primeru naprednega prirastka s povrnitvami so to vsi povrnitve in .vbk, če obstaja drug .vbk na obsegu zmogljivosti

Zdaj pa razmislimo o možnosti dela z verigami varnostnih kopij. Sem so bili prepeljani samo predmeti, ki spadajo v hrambo GFS. Ker je vse, kar je shranjeno v novejših verigah varnostnih kopij, mogoče spremeniti na tak ali drugačen način.

Zdaj pa poglejmo pod pokrov. Tam pride do procesa, imenovanega dehidracija - puščanje praznih datotek varnostne kopije na ekstentu in vlečenje blokov iz teh datotek na strelišče zmogljivosti. Za optimizacijo tega procesa se uporablja tako imenovani dehidracijski indeks, ki vam omogoča, da se izognete kopiranju blokov, ki so že bili kopirani na kapacitetno strelišče.

Poglejmo, kako to izgleda na primeru: Recimo, da imamo .vbk, ki je prišel iz transakcijskega okna in pripada zapečateni verigi. To pomeni, da imamo vso pravico, da ga prestavimo na kapaciteto strelišča. V času premikanja se ustvari datoteka z metapodatki v pomišljaju zmogljivosti in blokih prenesene datoteke. Datoteka z metapodatki na ravni povezave opisuje, iz katerih blokov je sestavljena naša datoteka. V primeru na sliki je naša prva datoteka sestavljena iz blokov a, b, c in metapodatki vsebujejo povezave do teh blokov. Ko imamo drugo datoteko .vbk, pripravljeno za premikanje in sestavljeno iz blokov a, b in d, z analizo indeksa dehidracije razumemo, da je treba prenesti samo blok d. Njegova datoteka z metapodatki bo vsebovala povezave do dveh prejšnjih blokov in enega novega.

V skladu s tem se postopek zapolnitve teh praznih prostorov nazaj s podatki imenuje rehidracija. Že uporablja lasten rehidracijski indeks, ki temelji na najstarejši datoteki .vbk v lokalnem obsegu zmogljivosti. To pomeni, da če želi uporabnik vrniti datoteko s kapacitetnega strelišča, najprej ustvarimo indeks blokov najstarejše polne varnostne kopije in prenesemo le manjkajoče bloke iz kapacitetnega strelišča. V primeru, predstavljenem na sliki, za rehidracijo FullBackup1.vbk glede na rehidracijski indeks potrebujemo samo blok C, ki ga vzamemo iz kapacitetnega strelišča. Če objekt v oblaku za shranjevanje služi kot prostor za streljanje, vam to omogoča, da prihranite ogromne količine denarja.

Tukaj se morda zdi, da je ta tehnologija enaka tisti, ki se uporablja v pospeševalnikih WAN, vendar se samo zdi tako. V pospeševalnikih je deduplikacija globalna; tukaj se lokalna deduplikacija uporablja znotraj vsake datoteke pri določenem odmiku. To se zgodi zaradi razlike v nalogah, ki se rešujejo: tukaj moramo kopirati velike polne varnostne kopije datotek in glede na naše raziskave, tudi če med njimi preteče veliko časa, ta algoritem deduplikacije daje najboljši rezultat.

Ampak več indeksov za boga indeksov! Obstaja tudi indeks za obnovitev podatkov! Ko začnemo obnavljati stroj, ki se nahaja v pomišljaju zmogljivosti, bomo brali samo edinstvene podatkovne bloke, ki niso v pomišljaju zmogljivosti.

Kako se je to zgodilo?

To je vse za uvodni del. Je precej podroben, a kot že omenjeno, brez teh podrobnosti ne bo mogoče razložiti delovanja novih funkcij. Zato, brez odlašanja, preidimo na prvo.

Način kopiranja

V veliki meri temelji na obstoječih tehnologijah, vendar nosi popolnoma drugačno logiko uporabe. 

Namen tega načina je zagotoviti, da imajo vsi podatki v lokalnem obsegu kopijo v pomišljaju zmogljivosti.

Če neposredno primerjate načina premikanja in kopiranja, bo videti takole:

• Premika se lahko samo zaprta veriga. V primeru načina kopiranja se prenese popolnoma vse, ne glede na to, kaj se zgodi v opravilu varnostnega kopiranja.
• Premikanje se sproži, ko datoteke presežejo meje okna operativne varnostne kopije, kopiranje pa se sproži takoj, ko se pojavi datoteka varnostne kopije.
• Spremljanje novih podatkov za kopiranje poteka nenehno, za premikanje pa se je sprožilo enkrat na 4 ure.

Pri obravnavi novega načina predlagam prehod od preprostih primerov k zapletenim.

V najpogostejšem primeru imamo preprosto nove datoteke z inkrementi in jih preprosto kopiramo na kapacitetno strelišče. Ne glede na to, kateri način je uporabljen v rezervnem opravilu, ne glede na to, ali pripada zapečatenemu delu verige ali ne, ne glede na to, ali je naše operacijsko okno poteklo. Samo vzeli so in kopirali.

Proces za tem je še vedno dehidracija, kot je opisano zgoraj. V načinu kopiranja tudi poskrbi, da ne kopiramo blokov, ki so že v našem pomnilniku. Edina razlika je v tem, da če smo v filmskem načinu zamenjali prave datoteke z navideznimi datotekami, se jih tu nikakor ne dotikamo in pustimo vse tako, kot je. V nasprotnem primeru gre za popolnoma enak indeks dehidracije, ki skrbno poskuša prihraniti vaš denar in čas.

Postavlja se vprašanje - če pogledate uporabniški vmesnik, obstaja možnost, da izberete obe možnosti hkrati. Kako bo deloval tak kombiniran način?

Ugotovimo to.

Začetek je standarden: varnostna kopija se ustvari in takoj kopira. Zanj je ustvarjen prirastek in tudi kopiran. To se dogaja do trenutka, ko ugotovimo, da so datoteke zapustile naše operacijsko okno in se je pojavila zapečatena veriga. Na tej točki izvedemo operacijo dehidracije in zamenjamo te datoteke z lažnimi datotekami. Seveda ničesar ne kopiramo spet na zmogljivost strelišča.

Vsa ta fascinantna logika je odgovorna za samo eno potrditveno polje v vmesniku: Kopiraj varnostne kopije v shrambo objektov takoj, ko so ustvarjene.

Zakaj potrebujemo ta način kopiranja?

Še bolje je vprašanje preoblikovati takole: pred kakšnimi nevarnostmi se z njegovo pomočjo zaščitimo? Katero težavo nam pomaga rešiti?

Odgovor je očiten: seveda gre za obnovitev podatkov. Če imamo popolno kopijo lokalnih podatkov v objektni shrambi, potem lahko ne glede na to, kaj se zgodi z našim izdelkom, vedno obnovimo podatke iz datotek, ki se nahajajo v pogojnem Amazonu.

Oglejmo si torej možne scenarije, od najpreprostejših do bolj zapletenih.

Najenostavnejša nesreča, ki nam lahko pade na glavo, je nedostopnost ene od datotek v varnostni verigi.

Bolj žalostna zgodba je, da se je pokvaril eden od obsegov našega skladišča SOBR.

Še huje postane, ko je celotno skladišče SOBR postalo nedostopno, zmogljivost strelišča pa deluje.
In vse je res hudo - takrat umre rezervni strežnik in vaša prva želja je poskusiti v desetih minutah zbežati do kanadske meje.

Zdaj pa poglejmo vsako situacijo posebej.

Ko smo izgubili eno (ali celo več) datotek varnostne kopije, je vse, kar moramo storiti, začeti postopek ponovnega skeniranja skladišča in izgubljena datoteka bo nadomeščena z navidezno datoteko. In s postopkom rehidracije (o katerem je bilo govora na začetku članka) bo uporabnik lahko prenesel podatke iz zmogljivosti strelišča v lokalni pomnilnik.

Zdaj je situacija bolj zapletena. Predpostavimo, da je naš SOBR sestavljen iz dveh ekstentov, ki se izvajata v načinu Performance, kar pomeni, da sta naša .vbk in .vib razporejena po njih v precej neenakomerni plasti. In v nekem trenutku eden od obsegov postane nedosegljiv in uporabnik mora nujno obnoviti stroj, katerega del podatkov leži ravno na tem obsegu.

Uporabnik zažene čarovnika za obnovitev, izbere točko, do katere želi obnoviti, čarovnik pa med delom ugotovi, da nima vseh podatkov, ki so potrebni za obnovitev lokalno in jih je zato treba prenesti s snemanja zmogljivosti. galerija. Hkrati bloki, ki ostanejo v lokalnem pomnilniku, ne bodo preneseni iz oblaka. Slava indeksu obnovitve (da, omenjeno je bilo tudi na začetku članka).

Podvrsta tega primera je, da je celotno skladišče SOBR postalo nedostopno. V tem primeru nimamo ničesar kopirati iz lokalnega pomnilnika in vsi bloki se prenesejo iz oblaka.

In najbolj zanimiva situacija je, da je rezervni strežnik umrl. Tukaj sta dve možnosti: admin je super in je naredil varnostne kopije konfiguracije, admin pa je sam zlobni Ostržek in ni naredil varnostnih kopij konfiguracije.

V prvem primeru bo dovolj, da preprosto nekje namesti čisto namestitev VBR in obnovi svojo bazo podatkov iz varnostne kopije s standardnimi sredstvi. Na koncu tega postopka se bo vse vrnilo v normalno stanje. Ali pa bo obnovljen v skladu z enim od zgornjih scenarijev.

Če pa je skrbnik sam sebi sovražnik ali pa je tudi varnostna kopija konfiguracije utrpela epsko napako, potem ga tudi tukaj ne bomo prepustili na milost in nemilost. Za ta primer smo uvedli nov postopek, imenovan Import Object Storage. Omogoča vam, da preskočite postopek ročnega ponovnega ustvarjanja repozitorija SOBR in mu pripnete strelišče zmogljivosti z naknadnim ponovnim skeniranjem ter preprosto dodate objekt za shranjevanje v vmesnik Vim in zaženete postopek Import Storage Repository. Edina stvar, ki lahko stoji med vami in vašimi varnostnimi kopijami, je zahteva po vnosu gesla, če so bile vaše varnostne kopije šifrirane.

To je verjetno vse o načinu kopiranja in nadaljujemo

Zaprti način

Glavna ideja je, da se nove varnostne kopije ne morejo pojaviti v izbranem obsegu SOBR skladišča. Pred v10 smo imeli samo vzdrževalni način, ko je bilo kakršno koli delo z repozitorijem popolnoma prepovedano. Nekakšen hardcore način za izklop shrambe, kjer je na voljo le gumb Evacuate, ki enkratno prenese varnostne kopije na drug obseg.

In Sealed mode je nekakšna "mehka" možnost: prepovemo ustvarjanje novih varnostnih kopij in postopoma brišemo stare glede na izbrano hrambo, vendar pri tem ne izgubimo možnosti obnovitve iz shranjenih točk. Zelo uporabna zadeva, ko imamo kos strojne opreme pri koncu življenjske dobe in ga moramo zamenjati ali pa ga moramo samo sprostiti za kaj bolj pomembnega, pa ga ni kam vzeti in premakniti vsega naenkrat. Ali pa ga ni mogoče izbrisati.

V skladu s tem je načelo delovanja precej preprosto: prepovedati je treba vse operacije pisanja (pojav novih podatkov), pustiti branje (obnove) in brisati (zadrževanje).

Oba načina lahko uporabljate hkrati, vendar ne pozabite, da ima vzdrževanje višjo prednost.

Kot primer upoštevajte SOBR, sestavljen iz dveh ekstentov. Predpostavimo, da smo prve štiri dni ustvarjali varnostne kopije v načinu Forward Forever Incremental, nato pa ekstent zapečatimo. To vodi do dejstva, da sprožimo ustvarjanje novega aktivnega polnega na drugem razpoložljivem ekstentu. Če je naša retenca štiri, potem ko celotna veriga, ki se nahaja na zapečatenem obsegu, preseže svoje meje, se z mirno vestjo izbriše.

Obstajajo situacije, ko se izbris zgodi prej. To je na primer inkrementalno naprej s periodičnimi polnitvami. Če smo prva dva dneva ustvarili popolne varnostne kopije in se v četrtek odločimo za zapiranje repozitorija, potem bo v petek, ko bo ustvarjena nova varnostna kopija, datoteka za ponedeljek izbrisana, ker do te točke ni nobenih odvisnosti. In sama točka ni odvisna od nikogar. Nato počakamo, da se na razpoložljivem ekstentu ustvarijo štiri točke in izbrišemo preostale tri, ki jih ni mogoče izbrisati neodvisno druga od druge.

Stvari so preprostejše z Reverse Incremental. V njem najstarejše točke niso odvisne od ničesar in jih je mogoče varno izbrisati. Takoj, ko je ustvarjen nov .vbk na novem obsegu, bodo stari .vrbs izbrisani eden za drugim.

Mimogrede, zakaj vsakič ustvarimo nov .vbk: če ga ne bi ustvarili, ampak bi nadaljevali staro verigo prirastkov, bi stari .vbk zamrznil za neskončno dolgo časa v katerem koli načinu, kar bi preprečilo njegovo brisanje. Zato je bilo odločeno, da takoj, ko je obseg zapečaten, ustvarimo popolno varnostno kopijo na prostem obsegu.

Stvari so bolj zapletene z zmogljivostjo strelišča.

Najprej si poglejmo način kopiranja. Predpostavimo, da smo štiri dni aktivno ustvarjali rezervne kopije, nato pa je bila zmogljivost strelišča zaprta. Ničesar ne brišemo, ampak ponižno prenašamo hrambo, nato pa izbrišemo podatke iz zmogljivosti strelišča.

Približno enako se zgodi v načinu premikanja - počakamo na retuširanje, izbrišemo staro v lokalni shrambi in izbrišemo tisto, ki je shranjena v shrambi objektov.

Zanimiv primer z Forever forward incremental. Retencijo namestimo na treh točkah in v ponedeljek začnemo delati varnostne kopije, ki jih redno kopiramo v oblak. Po zapiranju pomnilnika se varnostne kopije še naprej ustvarjajo in ohranjajo tri točke, vendar podatki, shranjeni v pomišljaju zmogljivosti, ostanejo odvisni in jih ni mogoče izbrisati. Zato počakamo do četrtka, ko naš .vbk preseže retencijo in šele takrat mirno izbrišemo celotno shranjeno verigo.

In majhna izjava o omejitvi odgovornosti: vsi primeri tukaj so prikazani z enim strojem. Če jih imate v varnostni kopiji več, se bo njihova retuša razlikovala glede na to, ali je bila narejena Active Full ali ne.

To je v bistvu vse. Pa pojdimo k najbolj zahtevni funkciji –

Nespremenljivost

Tako kot pri prejšnjih točkah je prva stvar, kateri problem rešuje ta funkcija. Takoj, ko svoje varnostne kopije naložimo nekam za shranjevanje, se pojavi močna želja, da zagotovimo njihovo varnost, to je, da fizično prepovemo njihovo brisanje in kakršno koli spreminjanje med določeno hrambo. Vključno s skrbniki, tudi pod njihovimi korenskimi računi. To vam omogoča, da jih zaščitite pred naključnimi ali namernimi poškodbami. Vsakdo, ki dela z AWS, je morda naletel na podobno funkcijo, imenovano Object Lock.

Zdaj pa si poglejmo način na splošno in se nato poglobimo v podrobnosti. V našem primeru bo nespremenljivost omogočena za naše zmogljivosti strelišča z hrambo štirih dni. V varnostni kopiji je omogočen način kopiranja.

Nespremenljivost na noben način ne vpliva na splošno hrambo. Na primer, ne dodaja dodatnih točk ali česa podobnega. Samo oseba ne more izbrisati varnostnih kopij v štirih dneh. Če naredite varnostno kopijo v ponedeljek, boste njeno datoteko lahko izbrisali šele v petek.

Vsi prej razloženi koncepti dehidracije, indeksi in metapodatki še naprej delujejo povsem enako. Toda z enim pogojem - blok je nastavljen ne samo za podatke, ampak tudi za metapodatke. To storimo v primeru, da se zvit napadalec odloči izbrisati našo zbirko metapodatkov in preprečiti, da bi se podatkovni bloki spremenili v neuporabno binarno kašo.

Zdaj je pravi čas, da razložimo našo tehnologijo generiranja blokov. Ali generacija blokov. Če želite to narediti, razmislite o situaciji, ki je privedla do njegovega videza.

Vzemimo časovno lestvico šestih dni in spodaj označimo čas pričakovanega poteka nespremenljivosti. Prvi dan vzamemo in ustvarimo datoteko, sestavljeno iz podatkovnega bloka a in njegovih metapodatkov. Če je nespremenljivost nastavljena na tri dni, je logično domnevati, da bodo četrti dan podatki odklenjeni in izbrisani. Drugi dan bomo dodali novo datoteko2, sestavljeno iz bloka b z enakimi nastavitvami. Četrti dan je še treba odstraniti blok a. Toda tretji dan se zgodi nekaj groznega - ustvarjena je datoteka File3, ki je sestavljena iz novega bloka d in povezave do starega bloka a. To pomeni, da je treba za blok in njegovo zastavo nespremenljivosti ponastaviti na nov datum, ki se premakne na šesti dan. In tu se pojavi težava - v resničnih varnostnih kopijah je takih blokov ogromno. In da bi podaljšali njihovo obdobje nespremenljivosti, morate vsakič vložiti ogromno zahtev. In pravzaprav bo to skoraj neskončen vsakodnevni proces, saj bomo z veliko verjetnostjo pri vsaki kopiji našli zajetne kupe dedupliciranih blokov. Kaj pomeni veliko število zahtev ponudnikov hrambe objektov? Prav! Velik račun na koncu meseca.

In da ne bi nenadoma razkrili svojih najljubših strank za precejšen denar, je bil izumljen mehanizem za ustvarjanje blokov. To je dodatno obdobje, ki ga prištejemo nastavljenemu obdobju nespremenljivosti. V spodnjem primeru je to obdobje dva dni. Ampak to je le primer. V resnici uporabljajo svojo formulo, ki daje približno deset dodatnih dni med mesečno blokado.

Nadaljujmo z obravnavanjem iste situacije, vendar z generacijo blokov. Prvi dan ustvarimo datoteko1 iz bloka a in metapodatkov. Seštejemo obdobje generiranja in nespremenljivost - to pomeni, da bo možnost izbrisa datoteke šesti dan. Če drugi dan ustvarimo File2, ki je sestavljen iz bloka b in povezave do bloka a, se s pričakovanim datumom izbrisa ne zgodi nič. Stala je tako kot šesti dan. In tako poskušamo prihraniti denar pri številu zahtev. Edini primer, ko se rok lahko premakne, je, če je generacijsko obdobje poteklo. To pomeni, če tretji dan nova datoteka 3 vsebuje povezavo za blokiranje a, bo dodana generacija 2, ker je Gen1 že potekla. In pričakovani datum za izbris bloka a se bo premaknil na osmi dan. To nam omogoča dramatično zmanjšanje števila zahtev za podaljšanje življenjske dobe dedupliciranih blokov, kar strankam prihrani kup denarja.

Sama tehnologija je na voljo uporabnikom S3 in S3 združljive strojne opreme, katerih proizvajalci zagotavljajo, da se njihova implementacija ne razlikuje od Amazonove. Od tod odgovor na upravičeno vprašanje, zakaj Azure ni podprt - imajo podobno funkcijo, vendar deluje na ravni vsebnikov, ne posameznih objektov. Mimogrede, sam Amazon ima zaklepanje objektov v dveh načinih: skladnost in upravljanje. V drugem primeru pa ostaja možnost, da največji admin nad admini in root nad rooti kljub zaklepu objekta vseeno izbriše podatke. V primeru skladnosti je vse tesno pribito in nihče ne more izbrisati varnostnih kopij. Tudi skrbniki Amazona (glede na njihove uradne izjave). To je način, ki ga podpiramo.

In kot ponavadi nekaj uporabnih povezav:

• na Generiranje blokov v vsaki podrobnosti.
• Vse informacije o Veeam Backup & Replication 10 v najboljšem primeru
• О Stopnja zmogljivosti Podrobno

Vir: www.habr.com