Kapasiteit Tier (of sa't wy it binnen Vim neame - captir) ferskynde werom yn 'e dagen fan Veeam Backup and Replication 9.5 Update 4 ûnder de namme Archive Tier. It idee derachter is om it mooglik te meitsjen om backups dy't út it saneamde operasjonele werstelfinster falle binne te ferpleatsen nei objektopslach. Dit holp skiifromte op te romjen foar dy brûkers dy't der net folle fan hiene. En dizze opsje waard Move Mode neamd.

Om dizze ienfâldige (sa't it liket) aksje út te fieren, wie it genôch om te foldwaan oan twa betingsten: alle punten fan 'e ferpleatse reservekopy moatte bûten de grinzen wêze fan it boppeneamde operasjonele werstelfinster, dat eksplisyt yn' e UI ynsteld is. En twadde: de ketting moat wêze yn 'e saneamde "fersegele foarm" (fersegele backupketen of Inactive Backup Chain). Dat is, gjin feroarings foarkomme yn dizze keten oer de tiid.

Mar yn VBR v10 waard it konsept oanfolle mei nije funksjes - Copy Mode, Sealed Mode en in ding mei de dreech út te sprekken namme Immutability ferskynde.

Dit binne de fassinearjende dingen dy't wy hjoed sille prate. Earst oer hoe't it wurke yn VBR9.5u4, en dan oer de feroarings yn 'e tsiende ferzje.

En meie de kampioenen fan suvere taal my ferjaan, mar der binne tefolle termen dy't net oerset wurde kinne.
Dat d'r sil hjir in ton fan anglisismen wêze.
En in protte gifs.
En foto's.

• Sûnder de minste spyt. Auteur fan it artikel.

Sa't it wie

No, lit ús begjinne mei it analysearjen fan it operasjonele werstelfinster en fersegele reservekopy (of sa't se wurde neamd yn 'e dokumintaasje fan Inactive Backup Chain). Sûnder harren begryp is fierdere útlis net mooglik.

As wy yn 'e foto sjogge, hawwe wy in soarte fan reservekopyketen mei gegevensblokken, dy't leit op' e Performance tier SOBR fan 'e repository wêrmei't de Capacity Tier is ferbûn. Us operasjonele reservekopyfinster is trije dagen.

Dêrtroch, de .vbk makke op moandei sealen de foarige ketting, waans finster is ynsteld op trije dagen. En dat betsjut dat jo feilich begjinne kinne mei it ferfieren fan alles âlder as dizze trije dagen nei de sjitbaan.

Mar wat wie krekt bedoeld mei in fersegele ketting en wat koe wurde stjoerd nei de kapasiteit sjitterij berik yn update 4?

Foar Forward Incremental is in teken fan it fersegeljen fan 'e ketting de skepping fan in nije folsleine reservekopy. En it makket net út hoe't dizze folsleine reservekopy wurdt krigen: sawol syntetyske folsleine as aktive folsleine backups wurde beskôge.

Yn it gefal fan Reverse binne dit allegear bestannen dy't net yn it bestjoeringsfinster falle.

Yn it gefal fan Forward increment mei rollbacks, dit binne allegear rollbacks en .vbk, as der in oare .vbk op 'e prestaasjes mjitte

Litte wy no de opsje beskôgje om te wurkjen mei Reservekopy-keatlingen. Allinnich items dy't ûnder GFS-behâld falle waarden hjir ferfierd. Omdat alles opslein yn mear resinte reservekopy keatlingen kin feroare wurde yn ien of oare wize.

Litte wy no ûnder de motorkap sjen. Dêr bart in proses neamd útdroeging - it ferlitten fan lege reservekopy triemmen op 'e omfang en slepe blokken fan dizze triemmen nei de kapasiteit sjitterij berik. Om dit proses te optimalisearjen, wurdt de saneamde útdroegingsyndeks brûkt, wêrtroch jo kinne foarkomme dat jo blokken kopiearje dy't al kopiearre binne nei it kapasiteitssjitfjild.

Lit ús sjen hoe't dit liket mei in foarbyld: Litte wy sizze dat wy hawwe in .vbk dat kaam út de transaksje finster en heart ta in fersegele keatling. Dit betsjut dat wy alle rjocht hawwe om it te ferpleatsen nei de kapasiteitssjitbaan. Op it momint fan ferpleatse wurdt in metadata-bestân makke yn 'e kapasiteitsdash en blokken fan it oerdroegen bestân. It metadata-bestân op linknivo beskriuwt hokker blokken ús bestân bestiet út. Yn it gefal op 'e foto bestiet ús earste bestân út blokken a, b, c en de metadata befettet keppelings nei dizze blokken. As wy hawwe in twadde .vbk triem, klear om te ferpleatsen en besteande út blokken a, b en d, wy, analysearje de útdroeging yndeks, begripe dat allinnich blok d moat wurde oerdroegen. En syn metadata-bestân sil keppelings befetsje nei twa eardere blokken en ien nije.

Dêrtroch wurdt it proses fan it ynfoljen fan dizze lege romten werom mei gegevens neamd rehydration. It brûkt al syn eigen rehydration index, basearre op de âldste .vbk triem op de lokale prestaasje omfang. Dat is, as de brûker wol werom in triem út de kapasiteit shooting berik, wy earst meitsje in yndeks fan de blokken fan de âldste folsleine reservekopy en oerdrage allinnich de ûntbrekkende blokken út de kapasiteit shooting gallery. Yn it gefal presintearre yn 'e foto, om te rehydrate FullBackup1.vbk neffens de rehydration yndeks, wy moatte allinne blok C, dat wy nimme út de kapasiteit sjitterij berik. As in opslach wolk foarwerp tsjinnet as in kapasiteit sjitterij berik, dit kinne jo besparje enoarme bedraggen fan jild.

Hjir kin it lykje dat dizze technology identyk is oan dy brûkt yn WAN Accelerators, mar it liket allinich sa. Yn accelerators is deduplikaasje globaal; hjir wurdt lokale deduplikaasje brûkt binnen elk bestân op in spesifike offset. Dit bart troch it ferskil yn 'e taken dy't wurde oplost: hjir moatte wy grutte folsleine reservekopybestannen kopiearje, en neffens ús ûndersyk, sels as der in lange perioade tusken giet, jout dit deduplikaasjealgoritme it bêste resultaat.

Mar mear yndeksen foar de god fan yndeksen! D'r is ek in yndeks foar gegevensherstel! As wy begjinne mei it herstellen fan in masine dy't leit yn 'e kapasiteit dash, wy sille allinne lêze unike gegevens blokken dy't net yn it prestaasje dash.

Hoe is it bard?

Dat is alles foar it ynliedend diel. It is frij detaillearre, mar lykas hjirboppe neamd, sûnder dizze details sil it net mooglik wêze om út te lizzen hoe't de nije funksjes wurkje. Dêrom, sûnder fierdere ado, litte wy nei de earste gean.

Kopiearje modus

It is foar in grut part basearre op besteande technologyen, mar draacht in folslein oare logika fan gebrûk. 

It doel fan dizze modus is om te soargjen dat alle gegevens op 'e lokale omfang in kopy hawwe yn' e kapasiteitsdash.

As jo ​​​​de Move- en Kopiearje-modi head-on fergelykje, sil it der sa útsjen:

• Allinich de fersegele ketting kin ferpleatst wurde. Yn it gefal fan in kopy modus, absolút alles wurdt oerdroegen, nettsjinsteande wat bart yn de reservekopy baan.
• It ferpleatsen wurdt aktivearre as de bestannen oer de grinzen fan it operasjonele reservekopyfinster geane, en it kopiearjen wurdt aktivearre sa gau as de reservekopybestân ferskynt.
• Monitoring fan nije gegevens foar kopiearjen bart konstant, en foar it ferpleatsen waard it ien kear elke 4 oeren útsteld.

By it beskôgjen fan de nije modus stel ik foar om te gean fan ienfâldige foarbylden nei komplekse.

Yn it meast foarkommende gefal hawwe wy gewoan nije bestannen mei ynkommens, en wy kopiearje se gewoan nei it kapasiteitssjitfjild. Nettsjinsteande hokker modus wurdt brûkt yn de reservekopy baan, nettsjinsteande oft it heart ta it fersegele diel fan 'e keatling of net, likefolle oft ús bestjoeringssysteem finster is ferrûn. Se namen it gewoan en kopieare it.

It proses efter dit is noch útdroeging lykas hjirboppe beskreaun. Yn kopymodus soarget it ek dat wy blokken net kopiearje dy't al op ús opslach binne. It ienige ferskil is dat as wy yn 'e filmmodus echte bestannen ferfongen hawwe mei dummy-bestannen, wy reitsje se hjir op gjin inkelde manier oan en litte alles sa't it is. Oars, it is krekt deselde útdroeging yndeks, dy't foarsichtich besiket te bewarjen jo jild en tiid.

De fraach ûntstiet - as jo nei de UI sjogge, is d'r in kâns om beide opsjes tagelyk te selektearjen. Hoe sil sa'n kombinearre modus wurkje?

Litte wy it útfine.

It begjin is standert: in reservekopy triem wurdt makke en kopiearre fuortendaliks. In tanimming wurdt oanmakke en ek kopiearre. Dit bart oant it momint dat wy realisearje dat de bestannen ús bestjoeringsfinster hawwe ferlitten en in fersegele ketting is ferskynd. Op dit punt fiere wy in útdroeging operaasje en ferfange dizze triemmen mei dummy triemmen. Fansels kopiearje wy neat wer nei de kapasiteitssjitterij.

Al dizze fassinearjende logika is ferantwurdlik foar mar ien karfakje yn 'e ynterface: Kopiearje backups nei objektopslach sa gau as se binne makke.

Wêrom hawwe wy dizze kopymodus nedich?

It is noch better om de fraach op dizze manier opnij te formulearjen: tsjin hokker risiko's binne wy ​​mei har help beskerme? Hokker probleem helpt it ús op te lossen?

It antwurd is fanselssprekkend: fansels is dit gegevensherstel. As wy in folsleine kopy fan lokale gegevens hawwe op 'e objektopslach, dan kinne wy ​​​​altyd gegevens weromsette fan bestannen dy't yn' e betingsten Amazon lizze, nettsjinsteande wat der bart mei ús produkt.

Dat litte wy de mooglike senario's trochgean, fan 'e ienfâldichste oant de mear komplekse.

It ienfâldichste ûngelok dat ús op 'e holle kin falle is de ûnberikberens fan ien fan' e bestannen yn 'e reservekopyketen.

In tryster ferhaal is dat ien fan 'e omfangen fan ús SOBR-repository bruts.

It wurdt noch slimmer as de hiele SOBR repository is wurden ûnberikber, mar de kapasiteit sjitterij berik wurket.
En alles is echt min - dit is as de reservekopytsjinner stjert en jo earste winsk is om te besykjen om yn tsien minuten nei de Kanadeeske grins te rinnen.

Litte wy no elke situaasje apart besjen.

As wy ien (en sels ferskate) reservekopybestannen ferlern hawwe, dan moatte wy allinich it repository-rescanproses begjinne, en it ferlerne bestân sil wurde ferfongen troch in dummy-bestân. En mei help fan it rehydration proses (dat waard besprutsen oan it begjin fan it artikel), de brûker sil by steat wêze om te downloaden gegevens út de kapasiteit sjitterij berik nei lokale opslach.

No is de situaasje komplisearre. Lit ús oannimme dat ús SOBR bestiet út twa omfangen dy't rinne yn Performance modus, wat betsjut dat ús .vbk en .vib binne ferspraat oer harren yn in frij ûngelikense laach. En op in stuit yn 'e tiid wurdt ien fan' e omfangen net beskikber, en de brûker moat de masine driuwend werstelle, in diel fan 'e gegevens wêrfan krekt op dizze mjitte leit.

De brûker lanseart de herstelwizard, selekteart it punt wêrop hy weromsette wol, en de tsjoender, wylst it wurket, komt ta it besef dat hy net alle gegevens hat dy't nedich binne foar herstel lokaal en dêrom moat wurde downloade fan 'e kapasiteitssjitten galery. Tagelyk sille blokken dy't bliuwe op lokale opslach net wurde ynladen fan 'e wolk. Glory foar de weromsette-yndeks (ja, it waard ek neamd oan it begjin fan it artikel).

In subtype fan dit gefal is dat it hiele SOBR-repository net tagonklik waard. Yn dit gefal hawwe wy neat te kopiearjen fan lokale opslach, en alle blokken wurde downloade fan 'e wolk.

En de meast nijsgjirrige situaasje is dat de reservekopytsjinner stoar. D'r binne hjir twa opsjes: de admin is geweldich en makke konfiguraasje-backups, en de admin is in kweade Pinocchio sels en makke gjin konfiguraasje-backups.

Yn it earste gefal sil it genôch wêze foar him om gewoan in skjinne ynstallaasje fan VBR earne yn te setten en syn databank te herstellen fan in reservekopy mei standert middels. Oan 'e ein fan dit proses sil alles weromgean nei normaal. Of it sil restaurearre wurde neffens ien fan 'e boppesteande senario's.

Mar as de admin of syn eigen fijân is, of de konfiguraasje-backup hat ek in epyske mislearring te lijen, dan sille wy him hjir net oerlitte oan 'e genede fan it needlot. Foar dit gefal hawwe wy in nije proseduere yntrodusearre mei de namme Ymport Object Storage. It lit jo it proses oerslaan fan it manuell opnij oanmeitsjen fan in SOBR-repository en it heakjen fan in kapasiteitssjitberik oan it mei folgjende rescan, en gewoan in opslachobjekt tafoegje oan 'e Vim-ynterface en útfiere de ymportearje Storage Repository-proseduere. It ienige ding dat yn 'e wei kin stean tusken jo en jo backups is in fersyk om in wachtwurd yn te fieren as jo backups fersifere binne.

Dit is wierskynlik alles oer Kopiearjemodus en wy geane troch

Fersegele modus

It haadidee is dat nije backups net ferskine kinne op 'e selektearre SOBR-omfang fan it repository. Foar v10 hienen wy allinich Underhâldsmodus, doe't elk wurk mei de repository folslein ferbean wie. In soarte fan hardcore modus foar it ôfsluten fan opslach, wêr't allinich de knop Evakuearje beskikber is, dy't backups yn in oare mjitte ien kear ferfiert.

En Sealed modus is in soarte fan "sêfte" opsje: wy ferbiede it meitsjen fan nije reservekopy en stadichoan wiskje âlde neffens de selektearre behâld, mar yn it proses wy net ferlieze de mooglikheid om te herstellen fan opslein punten. In heul nuttich ding as wy in stik hardware hawwe dy't it ein fan syn libben tichterby binne en it moatte ferfange, of wy moatte it gewoan frijmeitsje foar wat wichtiger, mar d'r is nearne om it te nimmen en alles tagelyk te ferpleatsen. Of it kin net wiske wurde.

Dêrtroch is it prinsipe fan wurking frij simpel: it is needsaaklik om alle skriuwoperaasjes te ferbieden (it ferskinen fan nije gegevens), it lêzen (restauraasjes) litte en wiskje (behâlden).

Beide modi kinne tagelyk brûkt wurde, mar hâld der rekken mei dat Underhâld hegere prioriteit hat.

As foarbyld, beskôgje in SOBR besteande út twa omfangen. Litte wy oannimme dat wy foar de earste fjouwer dagen backups makke hawwe yn 'e Forward Forever Incremental modus, en dan fersegelje wy de omfang. Dit liedt ta it feit dat wy begjinne mei it meitsjen fan in nije aktive folsleine op' e twadde beskikbere omfang. As ús behâld is fjouwer, dan as de hiele ketting leit op 'e fersegele omfang giet oer syn grinzen, wurdt wiske mei in dúdlik gewisse.

D'r binne situaasjes as wiskjen earder foarkomt. Dit is bygelyks Foarút inkrementeel mei periodike folsleinen. As wy de earste twa dagen folsleine reservekopy hawwe makke, en op tongersdei beslute wy it repository te fersegeljen, dan sil op freed, as in nije reservekopy wurdt makke, it bestân foar moandei wiske wurde om't der binne gjin ôfhinklikens oan dit punt. En it punt sels hinget fan gjinien ôf. Dan wachtsje wy oant fjouwer punten wurde makke op 'e beskikbere omfang en wiskje de oerbleaune trije, dy't net ûnôfhinklik fan elkoar kinne wurde wiske.

Dingen binne ienfâldiger mei Reverse Incremental. Dêryn binne de âldste punten fan neat ôfhinklik en kinne se feilich wiske wurde. Sa gau as in nije .vbk wurdt makke op in nije omfang, wurde de âlde .vrbs ien foar ien wiske.

Trouwens, wêrom meitsje wy elke kear in nije .vbk oan: as wy it net oanmakke hawwe, mar de âlde ketting fan ynkommens trochgean, dan soe de âlde .vbk yn elke modus ûneinich lange tiid befrieze, it foarkommen fan it wiskjen. Dêrom waard besletten dat sa gau as de omfang is fersegele, meitsje wy in folsleine reservekopy op 'e frije omfang.

Dingen binne komplisearre mei de kapasiteit sjitterij berik.

Litte wy earst nei de kopymodus sjen. Litte wy oannimme dat wy fjouwer dagen aktyf backups makken, en dan waard it kapasiteitssjitfjild fersegele. Wy wiskje neat, mar ferneare nederich it behâld, wêrnei't wy de gegevens fan 'e kapasiteitssjitbaan wiskje.

Likernôch itselde ding bart yn bewegingsmodus - wy wachtsje op de retouche, wiskje de âlde yn 'e lokale opslach, en wiskje de opsleine yn' e objektopslach.

In nijsgjirrich foarbyld mei Forever foarút incremental. Wy ynstallearje behâld op trije punten en begjinne op moandei backups te meitsjen, dy't regelmjittich nei de wolk wurde kopieare. Nei it fersegeljen fan de opslach, bliuwe backups makke, trije punten behâlden, mar de gegevens opslein yn 'e kapasiteitsdash bliuwe ôfhinklik en kinne net wiske wurde. Dêrom, wy wachtsje oant tongersdei, as ús .vbk giet fierder as fêsthâlden, en pas dan wiskje wy rêstich de hiele bewarre keten.

En in lytse disclaimer: alle foarbylden hjir wurde werjûn mei ien masine. As jo ​​​​ferskate fan har yn jo reservekopy hawwe, dan sil har retouchering ferskille ôfhinklik fan oft Active Full is makke of net.

Dat is yn prinsipe alles wat der is. Dat litte wy trochgean nei de meast hardcore-funksje -

Unferoarlikheid

Lykas by de foarige punten, is it earste ding wat probleem dizze funksje oplost. Sadree't wy ús backups earne uploade foar opslach, is d'r in sterke winsk om har feiligens te garandearjen, dat is, har wiskjen en elke wiziging fysyk te ferbieden tidens in opjûne behâld. Ynklusyf admins, ynklusyf ûnder har root-akkounts. Hjirmei kinne jo se beskermje tsjin tafallige of opsetlike skea. Elkenien dy't wurket mei AWS kin in ferlykbere funksje tsjinkaam hawwe neamd Object Lock.

Litte wy no sjen nei de modus yn algemiene termen, en dûke dan yn 'e details. Yn ús foarbyld sil Immutability ynskeakele wurde foar ús kapasiteit sjitberik mei in behâld fan fjouwer dagen. En de Kopiearjemodus is ynskeakele yn 'e reservekopy.

Unferoarlikens ynteraksje op gjin inkelde manier mei algemiene retinsje. It jout bygelyks gjin ekstra punten of sa. It is gewoan dat in persoan gjin reservekopybestannen binnen fjouwer dagen kin wiskje. As jo ​​​​moandei in reservekopy meitsje, kinne jo it bestân allinich op freed wiskje.

Alle earder ferklearre begripen fan útdroeging, yndeksen en metadata wurkje krekt itselde. Mar mei ien betingst - it blok is ynsteld net allinnich foar gegevens, mar ek foar metadata. Dit wurdt dien yn it gefal dat in slûchslimme oanfaller beslút om ús metadata-database te wiskjen en foar te kommen dat gegevensblokken yn nutteleaze binary mush wurde.

No is in geweldige tiid om ús technology foar blokgeneraasje út te lizzen. Of blok generaasje. Om dit te dwaan, beskôgje de situaasje dy't late ta syn uterlik.

Litte wy in tiidskaal fan seis dagen nimme en hjirûnder sille wy de tiid markearje fan it ferwachte ferrin fan ûnferoarlikens. Op de earste dei nimme en meitsje wy in bestân besteande út gegevensblok a en har metadata. As ûnferoarlikens is ynsteld op trije dagen, is it logysk om oan te nimmen dat op 'e fjirde dei de gegevens wurde ûntskoattele en wiske. Op de twadde dei sille wy in nije file2 tafoegje, besteande út blok b mei deselde ynstellings. Blok a moat op de fjirde dei noch fuorthelle wurde. Mar op 'e tredde dei bart der wat ferskrikliks - in File3-bestân wurdt makke, besteande út in nij blok d en in keppeling nei it âlde blok a. Dit betsjut dat foar in blok en syn immutability flagge moat wurde reset nei in nije datum, dat wurdt ferskood nei de seisde dei. En hjir ûntstiet in probleem - yn echte backups binne d'r in grut oantal sokke blokken. En om har ûnferoarlikensperioade te ferlingjen, moatte jo elke kear in enoarm oantal oanfragen meitsje. En yn feite sil dit in hast einleaze deistich proses wêze, om't wy mei in hege graad fan kâns by elke kopy heftige stapels fan deduplicate blokken sille fine. Wat betsjuttet in grut oantal oanfragen fan oanbieders fan objektopslach? Rjochts! Enorme rekken oan 'e ein fan' e moanne.

En om jo favorite kliïnten net út 'e blau te eksposearjen foar substansjeel jild, waard it blokgeneraasjemeganisme útfûn. Dit is in ekstra perioade dy't wy tafoegje oan 'e ynstelde ûnferoarlikensperioade. Yn it foarbyld hjirûnder is dizze perioade twa dagen. Mar dit is mar in foarbyld. Yn werklikheid, se brûke harren eigen formule, dat jout likernôch tsien ekstra dagen tidens in moanlikse slot.

Litte wy deselde situaasje trochgean, mar mei blokgeneraasje. Op de earste dei meitsje wy file1 fan blok a en metadata. Wy tafoegje de generaasjeperioade en ûnferoarlikens - dit betsjut dat de kâns om it bestân te wiskjen op 'e sechsde dei sil wêze. As wy op 'e twadde dei File2 meitsje, besteande út blok b en in keppeling om a te blokkearjen, dan bart der neat mei de ferwachte wiskdatum. Hja stie sa't hja op 'e seisde dei die. En sa besykje wy jild te besparjen op it oantal oanfragen. De ienige situaasje wêryn de deadline kin wurde ferskood is as de generaasjeperioade is ferrûn. Dat is, as op 'e tredde dei de nije File3 in keppeling befettet om a te blokkearjen, dan sil generaasje 2 wurde tafoege sûnt Gen1 is al ferrûn. En de ferwachte datum foar it wiskjen fan blok a sil ferskowe nei de achtste dei. Dit lit ús it oantal oanfragen dramatysk ferminderje om it libben fan deduplicate blokken te ferlingjen, wat kliïnten in ton jild besparret.

De technology sels is beskikber foar brûkers fan S3 en S3-kompatible hardware, waans fabrikanten garandearje dat har ymplemintaasje net ferskilt fan Amazon's. Dêrfandinne it antwurd op 'e legitime fraach wêrom't Azure net wurdt stipe - se hawwe in ferlykbere funksje, mar it wurket op it nivo fan konteners, net yndividuele objekten. Trouwens, Amazon sels hat objektslot yn twa modi: neilibjen en bestjoer. Yn it twadde gefal bliuwt d'r de mooglikheid dat de grutste admin boppe admins en root boppe woartels, nettsjinsteande it objektslot, de gegevens noch wisket. Yn it gefal fan neilibjen wurdt alles strak nagele en gjinien kin de backups wiskje. Sels Amazon admins (neffens harren offisjele útspraken). Dit is de modus dy't wy stypje.

En, lykas gewoanlik, wat nuttige keppelings:

• op Block Generation yn elk detail.
• Alle ynformaasje oer Veeam Reservekopy en replikaasje 10 op syn bêst
• О Kapasiteit Tier yn detail

Boarne: www.habr.com