Talpos pakopa (arba kaip vadiname Vim viduje – captir) pasirodė dar Veeam atsarginės kopijos ir replikacijos 9.5 atnaujinimo 4 laikais pavadinimu Archyvo pakopa. Jo idėja yra suteikti galimybę perkelti atsargines kopijas, kurios iškrito iš vadinamojo operatyvinio atkūrimo lango, į objektų saugyklą. Tai padėjo atlaisvinti vietos diske tiems vartotojams, kurie jos turėjo mažai. Ir ši parinktis vadinosi „Move Mode“.

Norint atlikti šį paprastą (kaip atrodo) veiksmą, pakako įvykdyti dvi sąlygas: visi taškai iš perkeltos atsarginės kopijos turi būti už aukščiau minėto operatyvinio atkūrimo lango ribų, kuris yra aiškiai nustatytas vartotojo sąsajoje. Antra: grandinė turi būti taip vadinama „užantspauduota“ (sandaryta atsarginė grandinė arba neaktyvi atsarginė grandinė). Tai reiškia, kad laikui bėgant šioje grandinėje nevyksta jokių pokyčių.

Tačiau VBR v10 koncepcija buvo papildyta naujomis funkcijomis – atsirado Copy Mode, Sealed Mode ir daiktas sunkiai ištariamu pavadinimu Immutability.

Tai yra žavūs dalykai, apie kuriuos šiandien kalbėsime. Pirmiausia apie tai, kaip tai veikė VBR9.5u4, o tada apie dešimtosios versijos pakeitimus.

Ir tegul grynos kalbos čempionai man atleidžia, bet yra per daug terminų, kurių negalima išversti.
Taigi anglicizmų čia bus daug.
Ir daug gifų.
Ir nuotraukos.

• Be menkiausio gailesčio. Straipsnio autorius.

Kaip tai buvo

Na, pradėkime nuo operatyvinio atkūrimo lango ir uždarosios atsarginės kopijos (arba kaip jie vadinami neaktyvios atsarginės kopijos grandinės dokumentacijoje) analizė. Be jų supratimo tolesnis paaiškinimas nebus įmanomas.

Kaip matome paveikslėlyje, turime tam tikrą atsarginę grandinę su duomenų blokais, esančias saugyklos, prie kurios prijungta talpos pakopa, našumo pakopoje SOBR. Mūsų operatyvinis atsarginis langas yra trys dienos.

Atitinkamai, pirmadienį sukurtas .vbk užsandarina ankstesnę grandinę, kurios langas nustatytas į tris dienas. O tai reiškia, kad galite drąsiai pradėti vežti į šaudyklą viską, kas senesnė nei šios trys dienos.

Bet ką tiksliai reiškia sandari grandinė ir ką galima nusiųsti į šaudyklą 4 atnaujinime?

Forward Incremental atveju grandinės sandarinimo ženklas yra naujos pilnos atsarginės kopijos sukūrimas. Ir nesvarbu, kaip ši visa atsarginė kopija gaunama: atsižvelgiama į tiek sintetinės pilnos, tiek aktyvios pilnos atsarginės kopijos.

Reverse atveju tai visi failai, kurie nepatenka į operacinį langą.

Jei prieaugis į priekį su atšaukimu, tai visi atšaukimai ir .vbk, jei yra kitas .vbk našumo mastas

Dabar apsvarstykime galimybę dirbti su atsarginės kopijos grandinėmis. Čia buvo vežami tik daiktai, kuriems taikomas GFS saugojimas. Nes viskas, kas saugoma naujesnėse atsarginių kopijų grandinėse, gali būti vienaip ar kitaip pakeista.

Dabar pažiūrėkime po gaubtu. Ten įvyksta procesas, vadinamas dehidratacija – paliekami tušti atsarginės kopijos failai ir nutempiami blokai iš šių failų į talpos šaudyklą. Šiam procesui optimizuoti naudojamas vadinamasis dehidratacijos indeksas, leidžiantis nekopijuoti blokų, kurie jau buvo nukopijuoti į talpos šaudyklą.

Pažiūrėkime, kaip tai atrodo su pavyzdžiu: Tarkime, kad turime .vbk, kuris išėjo iš operacijos lango ir priklauso sandariai grandinei. Tai reiškia, kad turime visas teises perkelti jį į pajėgumų šaudyklą. Perkėlimo metu metaduomenų failas sukuriamas perkelto failo talpos brūkšnelyje ir blokuose. Nuorodos lygio metaduomenų failas aprašo, iš kokių blokų susideda mūsų failas. Paveikslėlio atveju mūsų pirmasis failas susideda iš blokų a, b, c, o metaduomenyse yra nuorodos į šiuos blokus. Kai turime antrą .vbk failą, paruoštą judėti ir susidedantį iš a, b ir d blokų, analizuodami dehidratacijos indeksą suprantame, kad reikia perkelti tik bloką d. Jo metaduomenų faile bus nuorodos į du ankstesnius blokus ir vieną naują.

Atitinkamai, šių tuščių erdvių užpildymo duomenimis, procesas vadinamas rehidratacija. Ji jau naudoja savo rehidratacijos indeksą, pagrįstą seniausiu .vbk failu apie vietinį našumą. Tai yra, jei vartotojas nori grąžinti failą iš talpos šaudyklų, pirmiausia sukuriame seniausios pilnos atsarginės kopijos blokų indeksą ir iš talpos šaudymo galerijos perkeliame tik trūkstamus blokus. Paveikslėlyje pateiktu atveju, norint rehidratuoti FullBackup1.vbk pagal rehidratacijos indeksą, mums reikia tik bloko C, kurį paimame iš talpos šaudyklos. Jei saugyklos debesies objektas naudojamas kaip talpos šaudykla, tai leidžia sutaupyti milžiniškas pinigų sumas.

Čia gali atrodyti, kad ši technologija yra identiška tai, kas naudojama WAN Accelerators, bet taip tik atrodo. Greitintuvuose dubliavimo panaikinimas yra visuotinis; čia vietinis dubliavimo panaikinimas naudojamas kiekviename faile tam tikru poslinkiu. Taip nutinka dėl sprendžiamų užduočių skirtumo: čia reikia nukopijuoti didelius pilnus atsarginių kopijų failus, o mūsų tyrimų duomenimis, net jei tarp jų praeina ilgas laiko tarpas, šis deduplikacijos algoritmas duoda geriausią rezultatą.

Bet daugiau indeksų indeksų dievui! Taip pat yra duomenų atkūrimo indeksas! Kai pradėsime atkurti talpos brūkšnelyje esančią mašiną, skaitysime tik unikalius duomenų blokus, kurių nėra našumo brūkšnelyje.

Kaip tai nutiko?

Tai viskas įžanginei daliai. Jis gana detalus, tačiau, kaip minėta aukščiau, be šių detalių nebus įmanoma paaiškinti, kaip veikia naujosios funkcijos. Todėl, nieko nelaukdami, pereikime prie pirmojo.

Kopijavimo režimas

Jis daugiausia pagrįstas esamomis technologijomis, tačiau turi visiškai kitokią naudojimo logiką. 

Šio režimo tikslas yra užtikrinti, kad visi duomenys, esantys vietos mastu, turėtų kopiją talpos brūkšnelyje.

Jei lyginsite perkėlimo ir kopijavimo režimus, jis atrodys taip:

• Galima perkelti tik sandarią grandinę. Kopijavimo režimu perduodama absoliučiai viskas, neatsižvelgiant į tai, kas vyksta atliekant atsarginę kopiją.
• Perkėlimas suaktyvinamas, kai failai peržengia operatyvinės atsarginės kopijos lango ribas, o kopijavimas suaktyvinamas, kai tik pasirodo atsarginės kopijos failas.
• Naujų duomenų stebėjimas kopijavimui vyksta nuolat, o perkėlimui jie buvo suaktyvinti kartą per 4 valandas.

Svarstydamas apie naują režimą, siūlau pereiti nuo paprastų pavyzdžių prie sudėtingų.

Dažniausiu atveju mes tiesiog turime naujus failus su prieaugiais ir tiesiog nukopijuojame juos į talpos šaudyklą. Nepriklausomai nuo to, koks režimas naudojamas atliekant atsarginę kopiją, nesvarbu, ar jis priklauso sandariai grandinės daliai, ar ne, nesvarbu, ar mūsų veikimo langas pasibaigė. Jie tiesiog paėmė ir nukopijavo.

Procesas, susijęs su tuo, vis dar yra dehidratacija, kaip aprašyta aukščiau. Kopijavimo režimu jis taip pat užtikrina, kad nekopijuotume blokų, kurie jau yra mūsų saugykloje. Skirtumas tik tas, kad jei filmavimo režimu tikrus failus pakeitėme fiktyviais failais, tai čia jokiu būdu jų neliečiame ir paliekame viską kaip yra. Priešingu atveju tai yra lygiai tas pats dehidratacijos indeksas, kuris kruopščiai bando sutaupyti jūsų pinigus ir laiką.

Kyla klausimas – pasižiūrėjus į vartotojo sąsają, yra galimybė vienu metu pasirinkti abi parinktis. Kaip veiks toks kombinuotas režimas?

Paimkime.

Pradžia standartinė: sukuriamas atsarginės kopijos failas ir iš karto nukopijuojamas. Prie jo sukuriamas ir taip pat nukopijuotas prieaugis. Taip nutinka iki to momento, kai suprantame, kad failai išėjo iš mūsų veikimo lango ir atsirado sandari grandinė. Šiuo metu atliekame dehidratacijos operaciją ir pakeičiame šiuos failus netikrais failais. Žinoma, mes vėl nieko nekopijuojame į pajėgumų šaudyklą.

Visa ši įspūdinga logika yra atsakinga už tik vieną sąsajos žymimąjį langelį: Nukopijuokite atsargines kopijas į objektų saugyklą, kai tik jos bus sukurtos.

Kodėl mums reikia šio kopijavimo režimo?

Dar geriau klausimą perfrazuoti taip: nuo kokių pavojų esame apsaugoti jo pagalba? Kokią problemą tai padeda mums išspręsti?

Atsakymas akivaizdus: žinoma, tai yra duomenų atkūrimas. Jei objekto saugykloje turime visą vietinių duomenų kopiją, nesvarbu, kas nutiktų mūsų produktui, visada galime atkurti duomenis iš failų, esančių sąlyginėje „Amazon“.

Taigi panagrinėkime galimus scenarijus, nuo paprasčiausių iki sudėtingesnių.

Paprasčiausia nelaimė, kuri gali nukristi ant mūsų galvų, yra vieno iš atsarginės kopijos grandinės failų nepasiekiamumas.

Liūdnesnė istorija yra ta, kad sugedo viena iš mūsų SOBR saugyklos dalių.

Dar blogiau būna, kai visa SOBR saugykla tapo nepasiekiama, bet talpos šaudykla veikia.
Ir viskas tikrai blogai – štai kai miršta atsarginis serveris ir jūsų pirmasis noras yra per dešimt minučių pabandyti nubėgti iki Kanados sienos.

Dabar pažvelkime į kiekvieną situaciją atskirai.

Kai praradome vieną (ir net keletą) atsarginių failų, tereikia pradėti saugyklos pakartotinio nuskaitymo procesą, o prarastas failas bus pakeistas netikru failu. O naudojant rehidratacijos procesą (kuris buvo aptartas straipsnio pradžioje), vartotojas galės atsisiųsti duomenis iš talpos šaudyklų į vietinę saugyklą.

Dabar situacija sudėtingesnė. Tarkime, kad mūsų SOBR susideda iš dviejų apimčių, veikiančių našumo režimu, o tai reiškia, kad mūsų .vbk ir .vib yra paskirstyti ant jų gana nelygiu sluoksniu. Ir tam tikru momentu vienas iš apimčių tampa nepasiekiamas, o vartotojui reikia skubiai atkurti mašiną, kurios dalis duomenų yra būtent šiame mastame.

Vartotojas paleidžia atkūrimo vedlį, pasirenka tašką, iki kurio nori atkurti, o vedlys dirbdamas supranta, kad jis neturi visų duomenų, reikalingų vietiniam atkūrimui, todėl juos reikia atsisiųsti iš talpos fotografavimo. galerija. Tuo pačiu metu vietinėje saugykloje likę blokai nebus atsisiunčiami iš debesies. Šlovė atkūrimo indeksui (taip, tai taip pat buvo paminėta straipsnio pradžioje).

Šio atvejo potipis yra tai, kad visa SOBR saugykla tapo neprieinama. Tokiu atveju neturime ko kopijuoti iš vietinės saugyklos, o visi blokai atsisiunčiami iš debesies.

O įdomiausia situacija yra ta, kad atsarginis serveris mirė. Čia yra du variantai: admin yra puikus ir padarė konfigūracijos atsargines kopijas, o administratorius yra pats piktasis Pinokis ir nedarė konfigūracijos atsarginių kopijų.

Pirmuoju atveju jam pakaks tiesiog kur nors įdiegti švarų VBR diegimą ir standartinėmis priemonėmis atkurti jo duomenų bazę iš atsarginės kopijos. Pasibaigus šiam procesui, viskas grįš į įprastas vėžes. Arba jis bus atkurtas pagal vieną iš anksčiau pateiktų scenarijų.

Bet jei administratorius yra arba jo paties priešas, arba konfigūracijos atsarginė kopija taip pat patyrė epinį gedimą, net ir čia mes jo nepaliksime likimo valiai. Šiuo atveju pristatėme naują procedūrą, pavadintą Importuoti objektų saugyklą. Tai leidžia praleisti rankinį SOBR saugyklos atkūrimo procesą ir prijungti prie jos talpos šaudyklą su vėlesniu nuskaitymu, tiesiog pridėti saugojimo objektą prie Vim sąsajos ir paleisti saugyklos importavimo procedūrą. Vienintelis dalykas, kuris gali trukdyti jums ir jūsų atsarginėms kopijoms, yra prašymas įvesti slaptažodį, jei jūsų atsarginės kopijos buvo užšifruotos.

Tikriausiai visa tai susiję su kopijavimo režimu ir pereiname prie

Uždarytas režimas

Pagrindinė idėja yra ta, kad naujos atsarginės kopijos negali atsirasti pasirinktame saugyklos SOBR apimtyje. Iki 10 versijos turėjome tik priežiūros režimą, kai bet koks darbas su saugykla buvo visiškai uždraustas. Tam tikras sunkus saugyklos išjungimo režimas, kai pasiekiamas tik mygtukas Evacuate, kuris vieną kartą perkelia atsargines kopijas kitu mastu.

O „Sealed“ režimas yra savotiškas „minkštasis“ variantas: draudžiame kurti naujas atsargines kopijas ir palaipsniui triname senas pagal pasirinktą išsaugojimą, tačiau proceso metu neprarandame galimybės atkurti iš saugomų taškų. Labai naudingas dalykas, kai arba turime aparatūros dalį, kuri artėja prie savo eksploatavimo pabaigos ir ją reikia pakeisti, arba tiesiog reikia atlaisvinti kažkam svarbesniam, bet nėra kur imti ir visko iš karto perkelti. Arba jo negalima ištrinti.

Atitinkamai, veikimo principas yra gana paprastas: būtina uždrausti visas rašymo operacijas (naujų duomenų atsiradimą), paliekant skaitymą (atkūrimą) ir trynimą (saugojimą).

Abu režimai gali būti naudojami vienu metu, tačiau atminkite, kad priežiūra turi didesnį prioritetą.

Kaip pavyzdį apsvarstykite SOBR, kurį sudaro du mastai. Tarkime, kad pirmąsias keturias dienas kūrėme atsargines kopijas Forward Forever Incremental režimu, o tada užplombuojame apimtį.Tai lemia tai, kad pradedame kurti naują aktyvią pilną antruoju prieinamu mastu. Jei mūsų sulaikymas yra keturi, tada, kai visa grandinė, esanti ant sandarios apimties, peržengia savo ribas, ji ištrinama ramia sąžine.

Yra situacijų, kai ištrynimas įvyksta anksčiau. Pavyzdžiui, tai yra prieauginis pirmyn su periodinėmis pilnomis dalimis. Jei pirmąsias dvi dienas sukūrėme visas atsargines kopijas, o ketvirtadienį nusprendėme užantspauduoti saugyklą, tai penktadienį, kai bus sukurta nauja atsarginė kopija, pirmadienio failas bus ištrintas, nes šiuo klausimu nėra jokių priklausomybių. Ir pats taškas nuo nieko nepriklauso. Tada laukiame, kol bus sukurti keturi turimi taškai ir ištrinsime likusius tris, kurių negalima ištrinti atskirai vienas nuo kito.

Su Reverse Incremental viskas yra paprasčiau. Jame seniausi taškai nuo nieko nepriklauso ir gali būti saugiai ištrinti. Todėl, kai tik bus sukurtas naujas .vbk nauju mastu, senieji .vrbs bus ištrinti po vieną.

Beje, kodėl mes kaskart kuriame naują .vbk: jei nekurtume, o tęstume seną prieaugio grandinę, tai senasis .vbk sustingtų be galo ilgam bet kokiu režimu, neleisdamas jo ištrinti. Todėl buvo nuspręsta, kad kai tik apimtis bus užplombuota, sukuriame pilną laisvo apimčio atsarginę kopiją.

Su talpia šaudykla reikalai yra sudėtingesni.

Pirmiausia pažiūrėkime į kopijavimo režimą. Tarkime, kad keturias dienas aktyviai kūrėme atsargines kopijas, o tada talpos šaudykla buvo uždaryta. Nieko neištriname, o nuolankiai ištveriame išsaugojimą, po kurio ištriname duomenis iš talpos šaudyklų.

Maždaug tas pats nutinka ir perkėlimo režimu – laukiame retušavimo, ištriname seną vietinėje saugykloje, o ištriname saugomą objektų saugykloje.

Įdomus pavyzdys su Forever forever incremental. Mes įdiegiame saugojimą trijuose taškuose ir pirmadienį pradedame kurti atsargines kopijas, kurios reguliariai kopijuojamos į debesį. Užplombavus saugyklą, toliau kuriamos atsarginės kopijos, išlaikant tris taškus, tačiau talpos brūkšnelyje saugomi duomenys lieka priklausomi ir negali būti ištrinti. Todėl laukiame iki ketvirtadienio, kai mūsų .vbk peržengs saugojimo ribas ir tik tada ramiai triname visą išsaugotą grandinę.

Ir mažas atsisakymas: visi pavyzdžiai čia rodomi su vienu įrenginiu. Jei atsarginėje kopijoje turite kelis iš jų, jų retušavimas skirsis priklausomai nuo to, ar buvo sukurtas aktyvus pilnas, ar ne.

Tai iš esmės viskas. Taigi pereikime prie sudėtingiausios funkcijos -

Nekintamumas

Kaip ir ankstesniuose punktuose, pirmas dalykas yra tai, kokią problemą išsprendžia ši funkcija. Kai tik įkeliame savo atsargines kopijas kur nors saugoti, kyla didelis noras garantuoti jų saugumą, tai yra, fiziškai uždrausti jas ištrinti ir bet kokius pakeitimus per tam tikrą saugojimą. Įskaitant administratorius, įskaitant jų pagrindines paskyras. Tai leidžia apsaugoti juos nuo atsitiktinio ar tyčinio sugadinimo. Kiekvienas, kuris dirba su AWS, galėjo susidurti su panašia funkcija, vadinama Object Lock.

Dabar pažvelkime į režimą bendrai, o tada įsigilinkite į detales. Mūsų pavyzdyje nekeičiamumas bus įjungtas mūsų pajėgumų šaudykloje su keturių dienų išlaikymu. O kopijavimo režimas įjungtas atsarginėje kopijoje.

Nekintamumas niekaip nesusijęs su bendru išlaikymu. Pavyzdžiui, jis neprideda papildomų taškų ar panašiai. Tiesiog asmuo negali ištrinti atsarginių failų per keturias dienas. Jei atsarginę kopiją sukursite pirmadienį, jos failą galėsite ištrinti tik penktadienį.

Visos anksčiau paaiškintos dehidratacijos, indeksų ir metaduomenų sąvokos ir toliau veikia lygiai taip pat. Bet su viena sąlyga – blokas nustatytas ne tik duomenims, bet ir metaduomenims. Tai daroma tuo atveju, jei gudrus užpuolikas nusprendžia ištrinti mūsų metaduomenų bazę ir neleisti duomenų blokams virsti nenaudinga dvejetaine koše.

Dabar puikus laikas paaiškinti mūsų blokų generavimo technologiją. Arba bloko generavimas. Norėdami tai padaryti, apsvarstykite situaciją, dėl kurios ji atsirado.

Paimkime šešių dienų laiko skalę ir žemiau pažymėsime numatomo nekintamumo pabaigos laiką. Pirmą dieną paimame ir sukuriame failą, susidedantį iš duomenų bloko a ir jo metaduomenų. Jei nekintamumas nustatytas į tris dienas, logiška manyti, kad ketvirtą dieną duomenys bus atrakinti ir ištrinti. Antrą dieną pridėsime naują failą2, sudarytą iš bloko b su tais pačiais parametrais. Ketvirtą dieną reikia pašalinti bloką a. Tačiau trečią dieną atsitinka kažkas baisaus – sukuriamas failas3 failas, susidedantis iš naujo bloko d ir nuorodos į seną bloką a. Tai reiškia, kad bloko ir jo nekintamumo vėliavėlė turi būti iš naujo nustatyta į naują datą, kuri perkeliama į šeštą dieną. Ir čia iškyla problema - tikrose atsarginėse kopijose yra daugybė tokių blokų. Ir norint pratęsti jų nekintamumo laikotarpį, kiekvieną kartą reikia pateikti daugybę užklausų. Tiesą sakant, tai bus beveik nesibaigiantis kasdienis procesas, nes su didele tikimybe su kiekviena kopija rasime nemenkas šūsnis panaikintų blokų. Ką reiškia didelis užklausų skaičius iš objektų saugojimo tiekėjų? Teisingai! Mėnesio pabaigoje didžiulė sąskaita.

Ir tam, kad už didelius pinigus nebūtų atskleisti mėgstami klientai, buvo išrastas blokų generavimo mechanizmas. Tai papildomas laikotarpis, kurį pridedame prie nustatyto nekintamumo laikotarpio. Toliau pateiktame pavyzdyje šis laikotarpis yra dvi dienos. Bet tai tik pavyzdys. Iš tikrųjų jie naudoja savo formulę, kuri suteikia maždaug dešimt papildomų dienų per mėnesinį užraktą.

Toliau nagrinėkime tą pačią situaciją, bet su blokų generavimu. Pirmą dieną sukuriame failą1 iš bloko a ir metaduomenų. Sudedame generavimo laikotarpį ir nekintamumą – tai reiškia, kad galimybė ištrinti failą bus šeštą dieną. Jei antrą dieną sukuriame failą 2, susidedantį iš bloko b ir nuorodos blokuoti a, tada nieko nenutinka numatytai ištrynimo datai. Ji stovėjo kaip ir šeštą dieną. Ir taip stengiamės sutaupyti pinigų dėl užklausų skaičiaus. Vienintelė situacija, kai terminas gali būti perkeltas – pasibaigęs generavimo laikotarpis. Tai yra, jei trečią dieną naujajame faile3 yra nuoroda blokuoti a, tada bus pridėta 2 karta, nes Gen1 jau pasibaigė. Ir numatoma bloko a ištrynimo data pasislinks į aštuntą dieną. Tai leidžia mums žymiai sumažinti užklausų skaičių pratęsti panaikintų blokų eksploatavimo laiką, o tai sutaupo klientų daug pinigų.

Pati technologija prieinama su S3 ir S3 suderinamos aparatūros naudotojams, kurių gamintojai garantuoja, kad jų įgyvendinimas nesiskiria nuo Amazon. Iš čia ir atsakymas į teisėtą klausimą, kodėl Azure nepalaikomas – jie turi panašią funkciją, tačiau ji veikia konteinerių, o ne atskirų objektų lygyje. Beje, pati „Amazon“ turi objektų užraktą dviem režimais: atitikties ir valdymo. Antruoju atveju išlieka galimybė, kad didžiausias administratorius virš administratorių ir šaknis virš šaknų, nepaisant objekto užrakto, vis tiek ištrina duomenis. Atitikties atveju viskas yra tvirtai prikalta ir niekas negali ištrinti atsarginių kopijų. Net „Amazon“ administratoriai (pagal jų oficialius pareiškimus). Tai yra mūsų palaikomas režimas.

Ir, kaip įprasta, keletas naudingų nuorodų:

• apie Blokų generavimas visose smulkmenose.
• Visa informacija apie Veeam atsarginė kopija ir replikacija 10 geriausiu atveju
• О Talpos pakopa detalėse

Šaltinis: www.habr.com