Capacity Tier (of soos ons dit binne Vim noem - captir) het in die dae van Veeam Backup and Replication 9.5 Update 4 verskyn onder die naam Archive Tier. Die idee daaragter is om dit moontlik te maak om rugsteune wat uit die sogenaamde operasionele herstelvenster geval het, na voorwerpberging te skuif. Dit het gehelp om skyfspasie op te ruim vir gebruikers wat min daarvan gehad het. En hierdie opsie is Move Mode genoem.

Om hierdie eenvoudige (soos dit lyk) aksie uit te voer, was dit genoeg om aan twee voorwaardes te voldoen: alle punte van die geskuifde rugsteun moet buite die grense van die bogenoemde operasionele herstelvenster wees, wat uitdruklik in die UI gestel is. En tweedens: die ketting moet in die sogenaamde “verseëlde vorm” (verseëlde rugsteunketting of Inaktiewe Rugsteunketting) wees. Dit wil sê, geen veranderinge vind oor tyd in hierdie ketting plaas nie.

Maar in VBR v10 is die konsep aangevul met nuwe funksies - Copy Mode, Sealed Mode en 'n ding met die moeilik uit te spreek naam Immutability het verskyn.

Dit is die fassinerende dinge waaroor ons vandag sal praat. Eerstens oor hoe dit in VBR9.5u4 gewerk het, en dan oor die veranderinge in die tiende weergawe.

En mag die kampvegters van suiwer taal my vergewe, maar daar is te veel terme wat nie vertaal kan word nie.
So daar sal 'n ton van anglisismes hier wees.
En baie gifs.
En prentjies.

• Sonder die minste spyt. Skrywer van die artikel.

Soos dit was

Wel, kom ons begin deur die operasionele herstelvenster en verseëlde rugsteun te ontleed (of soos dit in die Inactive Backup Chain-dokumentasie genoem word). Sonder hulle begrip sal verdere verduideliking nie moontlik wees nie.

Soos ons in die prentjie sien, het ons 'n soort rugsteunketting met datablokke, wat geleë is op die prestasievlak SOBR van die bewaarplek waaraan die kapasiteitsvlak gekoppel is. Ons operasionele rugsteunvenster is drie dae.

Gevolglik verseël die .vbk wat Maandag geskep is, die vorige ketting, waarvan die venster op drie dae gestel is. En dit beteken jy kan veilig begin om alles ouer as hierdie drie dae na die skietbaan te vervoer.

Maar wat presies is bedoel met 'n verseëlde ketting en wat kan na die kapasiteit skietbaan gestuur word in opdatering 4?

Vir Forward Incremental is 'n teken van verseëling van die ketting die skepping van 'n nuwe volledige rugsteun. En dit maak nie saak hoe hierdie volledige rugsteun verkry word nie: beide sintetiese volle en aktiewe volledige rugsteun word oorweeg.

In die geval van Reverse is dit alles lêers wat nie in die bedryfsvenster val nie.

In die geval van Voorwaartse inkrement met terugrol, is dit almal terugrol en .vbk, as daar nog 'n .vbk op die prestasieomvang is

Kom ons kyk nou na die opsie om met Backup Copy-kettings te werk. Slegs items wat onder GFS-retensie val, is hierheen vervoer. Omdat alles wat in meer onlangse rugsteunkopiekettings gestoor is, op een of ander manier verander kan word.

Kom ons kyk nou onder die enjinkap. Daar vind 'n proses plaas wat dehidrasie genoem word - om leë rugsteunlêers op die omvang te laat en blokke van hierdie lêers na die kapasiteitskietbaan te sleep. Om hierdie proses te optimaliseer, word die sogenaamde dehidrasie-indeks gebruik, wat jou toelaat om die kopiëring van blokke wat reeds na die kapasiteitskietbaan gekopieer is, te vermy.

Kom ons kyk hoe dit lyk met 'n voorbeeld: Kom ons sê ons het 'n .vbk wat by die transaksievenster uitgekom het en aan 'n verseëlde ketting behoort. Dit beteken dat ons alle reg het om dit na die kapasiteitskietbaan te skuif. Ten tyde van verskuiwing word 'n metadatalêer in die kapasiteitsstreep en blokke van die oorgedra lêer geskep. Die skakelvlak-metadatalêer beskryf uit watter blokke ons lêer bestaan. In die geval in die prentjie bestaan ​​ons eerste lêer uit blokke a, b, c en die metadata bevat skakels na hierdie blokke. Wanneer ons 'n tweede .vbk-lêer het, gereed om te skuif en wat uit blokke a, b en d bestaan, verstaan ​​ons, wat die dehidrasie-indeks ontleed, dat slegs blok d oorgedra moet word. En sy metadatalêer sal skakels bevat na twee vorige blokke en een nuwe een.

Gevolglik word die proses om hierdie leë spasies met data terug te vul, rehidrasie genoem. Dit gebruik reeds sy eie rehidrasie-indeks, gebaseer op die oudste .vbk-lêer op die plaaslike prestasie-omvang. Dit wil sê, as die gebruiker 'n lêer van die kapasiteitskietbaan wil terugstuur, skep ons eers 'n indeks van die blokke van die oudste volledige rugsteun en dra slegs die ontbrekende blokke van die kapasiteitskietgalery oor. In die geval wat in die prentjie aangebied word, om FullBackup1.vbk volgens die rehidrasie-indeks te herhidreer, benodig ons slegs blok C, wat ons van die kapasiteitskietbaan neem. As 'n bergingswolkvoorwerp as 'n kapasiteitskietbaan dien, laat dit jou toe om enorme bedrae geld te bespaar.

Hier kan dit lyk asof hierdie tegnologie identies is aan dié wat in WAN-versnellers gebruik word, maar dit lyk net so. In versnellers is deduplisering wêreldwyd; hier word plaaslike deduplisering binne elke lêer gebruik teen 'n spesifieke afwyking. Dit gebeur as gevolg van die verskil in die take wat opgelos word: hier moet ons groot volledige rugsteunlêers kopieer, en volgens ons navorsing, selfs al verloop 'n lang tydperk tussen hulle, gee hierdie dedupliseringsalgoritme die beste resultaat.

Maar meer indekse vir die god van indekse! Daar is ook 'n indeks vir dataherwinning! Wanneer ons begin om 'n masjien te herstel wat in die kapasiteitsstreep is, sal ons slegs unieke datablokke lees wat nie in die werkverrigtingstreep is nie.

Hoe het dit gebeur

Dit is al vir die inleidende deel. Dit is redelik gedetailleerd, maar soos hierbo genoem, sal dit nie moontlik wees om te verduidelik hoe die nuwe funksies werk sonder hierdie besonderhede nie. Kom ons gaan dus sonder meer oor na die eerste.

Kopieermodus

Dit is grootliks gebaseer op bestaande tegnologieë, maar dra 'n heeltemal ander logika van gebruik. 

Die doel van hierdie modus is om te verseker dat alle data wat op die plaaslike omvang geleë is, 'n kopie in die kapasiteitsstreep het.

As jy die Skuif- en Kopieer-modusse reguit vergelyk, sal dit soos volg lyk:

• Slegs die verseëlde ketting kan geskuif word. In die geval van 'n kopieermodus word absoluut alles oorgedra, ongeag wat in die rugsteuntaak gebeur.
• Beweeg word geaktiveer wanneer die lêers oor die grense van die operasionele rugsteunvenster gaan, en kopiëring word geaktiveer sodra die rugsteunlêer verskyn.
• Monitering van nuwe data vir kopiëring vind voortdurend plaas, en vir die verskuiwing is dit een keer elke 4 uur geaktiveer.

In die oorweging van die nuwe modus, stel ek voor om van eenvoudige voorbeelde na komplekse te beweeg.

In die mees algemene geval het ons eenvoudig nuwe lêers met inkremente, en ons kopieer dit eenvoudig na die kapasiteitskietbaan. Ongeag watter modus in die rugsteunwerk gebruik word, ongeag of dit aan die verseëlde deel van die ketting behoort of nie, ongeag of ons bedryfsvenster verval het. Hulle het dit net geneem en dit gekopieer.

Die proses hieragter is steeds dehidrasie soos hierbo beskryf. In kopieermodus maak dit ook seker dat ons nie blokke kopieer wat reeds op ons berging is nie. Die enigste verskil is dat as ons in fliekmodus regte lêers met dummy-lêers vervang het, hier raak ons ​​hulle op geen manier aan nie en laat alles soos dit is. Andersins is dit presies dieselfde dehidrasie-indeks, wat versigtig probeer om jou geld en tyd te bespaar.

Die vraag ontstaan ​​- as jy na die UI kyk, is daar 'n geleentheid om albei opsies gelyktydig te kies. Hoe sal so 'n gekombineerde modus werk?

Laat ons dit uitvind.

Die begin is standaard: 'n rugsteunlêer word geskep en onmiddellik gekopieer. 'n Inkrement word daarby geskep en ook gekopieer. Dit gebeur tot die oomblik wanneer ons besef dat die lêers ons bedryfsvenster verlaat het en 'n verseëlde ketting verskyn het. Op hierdie stadium voer ons 'n dehidrasie-operasie uit en vervang hierdie lêers met dummy-lêers. Natuurlik kopieer ons niks weer na die kapasiteit skietbaan nie.

Al hierdie fassinerende logika is verantwoordelik vir net een merkblokkie in die koppelvlak: Kopieer rugsteun na voorwerpberging sodra dit geskep word.

Hoekom het ons hierdie kopieermodus nodig?

Dit is selfs beter om die vraag so te herformuleer: van watter risiko's word ons met die hulp daarvan beskerm? Watter probleem help dit ons oplos?

Die antwoord is voor die hand liggend: dit is natuurlik dataherwinning. As ons 'n volledige kopie van plaaslike data op die voorwerpberging het, maak nie saak wat met ons produk gebeur nie, ons kan altyd data herstel vanaf lêers wat in die voorwaardelike Amazon geleë is.

Kom ons gaan dus deur die moontlike scenario's, van die eenvoudigste tot die meer komplekse.

Die eenvoudigste ongeluk wat op ons koppe kan val, is die ontoeganklikheid van een van die lêers in die rugsteunketting.

'n Hartseerder storie is dat een van die omvang van ons SOBR-bewaarplek gebreek het.

Dit word nog erger wanneer die hele SOBR-bewaarplek ontoeganklik geword het, maar die kapasiteitskietbaan werk.
En alles is regtig sleg - dit is wanneer die rugsteunbediener sterf en jou eerste begeerte is om binne tien minute na die Kanadese grens te probeer hardloop.

Kom ons kyk nou na elke situasie afsonderlik.

Wanneer ons een (en selfs verskeie) rugsteunlêers verloor het, is al wat ons hoef te doen om die repository-herskandeerproses te begin, en die verlore lêer sal met 'n dummy-lêer vervang word. En met behulp van die rehidrasieproses (wat aan die begin van die artikel bespreek is), sal die gebruiker data van die kapasiteitskietbaan na plaaslike berging kan aflaai.

Nou is die situasie meer ingewikkeld. Kom ons neem aan dat ons SOBR bestaan ​​uit twee mate wat in Prestasie-modus loop, wat beteken dat ons .vbk en .vib in 'n taamlik ongelyke laag oor hulle versprei is. En op 'n sekere tydstip word een van die omvang onbeskikbaar, en die gebruiker moet die masjien dringend herstel, waarvan 'n deel van die data presies op hierdie omvang lê.

Die gebruiker begin die herstel-towenaar, kies die punt waarheen hy wil herstel, en die towenaar, terwyl hy werk, kom tot die besef dat hy nie al die data het wat nodig is vir herstel plaaslik nie en dus afgelaai moet word vanaf die kapasiteitskiet. galery. Terselfdertyd sal blokke wat op plaaslike berging bly, nie van die wolk afgelaai word nie. Glorie aan die herstel-indeks (ja, dit is ook aan die begin van die artikel genoem).

'n Subtipe van hierdie geval is dat die hele SOBR-bewaarplek ontoeganklik geword het. In hierdie geval het ons niks om van plaaslike berging af te kopieer nie, en alle blokke word van die wolk afgelaai.

En die interessantste situasie is dat die rugsteunbediener dood is. Daar is twee opsies hier: die admin is wonderlik en het konfigurasie-rugsteun gemaak, en die admin is self 'n bose Pinocchio en het nie konfigurasie-rugsteun gemaak nie.

In die eerste geval sal dit vir hom genoeg wees om bloot 'n skoon installasie van VBR iewers te ontplooi en sy databasis te herstel vanaf 'n rugsteun met behulp van standaardmiddels. Aan die einde van hierdie proses sal alles na normaal terugkeer. Of dit sal volgens een van die scenario's hierbo herstel word.

Maar as die administrateur óf sy eie vyand is, óf die konfigurasie-rugsteun ook 'n epiese mislukking gely het, sal ons hom selfs hier nie aan die genade van die noodlot oorlaat nie. Vir hierdie geval het ons 'n nuwe prosedure bekendgestel genaamd Import Object Storage. Dit laat jou toe om die proses oor te slaan om 'n SOBR-bewaarplek met die hand te herskep en 'n kapasiteitskietbaan daaraan te koppel met daaropvolgende herskandering, en eenvoudig 'n stoorvoorwerp by die Vim-koppelvlak te voeg en die Invoerbergingsbewaarplek-prosedure uit te voer. Die enigste ding wat in die pad kan staan ​​tussen jou en jou rugsteun is 'n versoek om 'n wagwoord in te voer as jou rugsteun geënkripteer is.

Dit gaan waarskynlik alles oor Kopieermodus en ons gaan verder na

Verseëlde modus

Die hoofgedagte is dat nuwe rugsteun nie op die geselekteerde SOBR-omvang van die bewaarplek kan verskyn nie. Voor v10 het ons net onderhoudsmodus gehad, toe enige werk met die bewaarplek heeltemal verbied was. 'n Soort hardcore-modus om berging af te sluit, waar slegs die Evacuate-knoppie beskikbaar is, wat eenmalig rugsteun in 'n ander mate vervoer.

En verseëlde modus is 'n soort "sagte" opsie: ons verbied die skep van nuwe rugsteun en verwyder oues geleidelik volgens die geselekteerde behoud, maar in die proses verloor ons nie die vermoë om te herstel vanaf gestoorde punte nie. 'n Baie nuttige ding wanneer ons óf 'n stuk hardeware het wat die einde van sy leeftyd nader en dit moet vervang, óf ons moet dit net vir iets belangriker vrymaak, maar daar is nêrens om dit te neem en alles tegelyk te skuif nie. Of dit kan nie uitgevee word nie.

Gevolglik is die werkingsbeginsel redelik eenvoudig: dit is nodig om alle skryfbewerkings (die verskyning van nuwe data) te verbied, lees te laat (herstel) en uitvee (behoud).

Albei modusse kan gelyktydig gebruik word, maar hou in gedagte dat Onderhoud hoër prioriteit het.

As 'n voorbeeld, oorweeg 'n SOBR wat uit twee omvangs bestaan. Kom ons neem aan dat ons vir die eerste vier dae rugsteun geskep het in die Forward Forever Incremental-modus, en dan verseël ons die omvang. Dit lei daartoe dat ons die skepping van 'n nuwe aktiewe vol op die tweede beskikbare omvang begin. As ons retensie vier is, dan word dit met 'n skoon gewete uitgevee wanneer die hele ketting geleë op die verseëlde omvang oor sy perke gaan.

Daar is situasies wanneer verwydering vroeër plaasvind. Byvoorbeeld, dit is Vorentoe inkrementeel met periodieke vols. As ons vir die eerste twee dae volledige rugsteun geskep het, en Donderdag besluit ons om die bewaarplek te verseël, dan op Vrydag, wanneer 'n nuwe rugsteun geskep word, sal die lêer vir Maandag uitgevee word omdat daar is geen afhanklikhede tot hierdie punt nie. En die punt self hang van niemand af nie. Dan wag ons totdat vier punte op die beskikbare omvang geskep word en skrap die oorblywende drie, wat nie onafhanklik van mekaar uitgevee kan word nie.

Dinge is eenvoudiger met Reverse Incremental. Daarin is die oudste punte van niks afhanklik nie en kan veilig uitgevee word. Dus, sodra 'n nuwe .vbk op 'n nuwe omvang geskep word, sal die ou .vrbs een vir een uitgevee word.

Terloops, hoekom skep ons elke keer 'n nuwe .vbk: as ons dit nie geskep het nie, maar die ou ketting van inkremente voortgesit het, dan sou die ou .vbk vir 'n oneindige lang tyd in enige modus vries, wat verhoed dat dit uitgevee word. Daarom is besluit dat sodra die omvang verseël is, ons 'n volledige rugsteun op die vrye omvang skep.

Dinge is meer ingewikkeld met die kapasiteit skietbaan.

Kom ons kyk eers na kopieermodus. Kom ons neem aan dat ons aktief rugsteun geskep het vir vier dae, en toe is die kapasiteit skietbaan verseël. Ons vee niks uit nie, maar verdra nederig die retensie, waarna ons die data van die kapasiteitskietbaan uitvee.

Ongeveer dieselfde ding gebeur in skuifmodus - ons wag vir die retouchering, vee die ou een in die plaaslike berging uit en vee die een uit wat in die objekberging gestoor is.

'n Interessante voorbeeld met Forever forward incremental. Ons installeer retensie by drie punte en begin Maandag rugsteun maak, wat gereeld na die wolk gekopieer word. Nadat die berging verseël is, word rugsteun steeds geskep, met drie punte, maar die data wat in die kapasiteitsstreep gestoor word, bly afhanklik en kan nie uitgevee word nie. Daarom wag ons tot Donderdag, wanneer ons .vbk verder gaan as retensie, en eers dan vee ons rustig die hele gestoorde ketting uit.

En 'n klein vrywaring: alle voorbeelde hier word met een masjien getoon. As jy verskeie van hulle in jou rugsteun het, sal hul retouchering verskil afhangende van of Active Full gemaak is of nie.

Dit is basies al wat daar is. Laat ons dus aanbeweeg na die mees hardcore kenmerk -

Onveranderlikheid

Soos met die vorige punte, is die eerste ding watter probleem hierdie funksie oplos. Sodra ons ons rugsteun iewers vir berging oplaai, is daar 'n sterk begeerte om hul veiligheid te waarborg, dit wil sê om fisies die uitvee en enige wysiging tydens 'n gegewe bewaring te verbied. Insluitend administrateurs, insluitend onder hul wortelrekeninge. Dit laat jou toe om hulle te beskerm teen toevallige of opsetlike skade. Enigiemand wat met AWS werk, het dalk 'n soortgelyke kenmerk genaamd Object Lock teëgekom.

Kom ons kyk nou na die modus in algemene terme, en delf dan in die besonderhede. In ons voorbeeld sal Onveranderlikheid vir ons kapasiteit skietbaan geaktiveer word met 'n retensie van vier dae. En die Kopieermodus is in die rugsteun geaktiveer.

Onveranderlikheid het geen interaksie met algemene retensie nie. Dit voeg byvoorbeeld nie ekstra punte of iets dergeliks by nie. Dit is net dat 'n persoon nie rugsteunlêers binne vier dae kan uitvee nie. As jy Maandag 'n rugsteun maak, sal jy eers Vrydag die lêer daarvan kan uitvee.

Alle voorheen verduidelikde konsepte van dehidrasie, indekse en metadata werk steeds presies dieselfde. Maar met een voorwaarde - die blok is nie net vir data gestel nie, maar ook vir metadata. Dit word gedoen ingeval 'n slinkse aanvaller besluit om ons metadatadatabasis uit te vee en om te verhoed dat datablokke in nuttelose binêre pap verander.

Dit is nou 'n goeie tyd om ons blokgenerasie-tegnologie te verduidelik. Of blokgenerasie. Om dit te doen, oorweeg die situasie wat tot sy verskyning gelei het.

Kom ons neem 'n tydskaal van ses dae en hieronder sal ons die tyd merk van die verwagte verstryking van onveranderlikheid. Op die eerste dag neem en skep ons 'n lêer wat bestaan ​​uit datablok a en sy metadata. As onveranderlikheid op drie dae gestel is, is dit logies om aan te neem dat die data op die vierde dag ontsluit en uitgevee sal word. Op die tweede dag sal ons 'n nuwe lêer2 byvoeg, bestaande uit blok b met dieselfde instellings. Blok a moet nog op die vierde dag verwyder word. Maar op die derde dag gebeur iets verskrikliks - 'n File3-lêer word geskep wat bestaan ​​uit 'n nuwe blok d en 'n skakel na die ou blok a. Dit beteken dat vir 'n blok en sy onveranderlikheid vlag moet teruggestel word na 'n nuwe datum, wat verskuif word na die sesde dag. En hier ontstaan ​​'n probleem - in regte rugsteun is daar 'n groot aantal sulke blokke. En om hul onveranderlikheidstydperk te verleng, moet jy elke keer 'n groot aantal versoeke rig. En in werklikheid sal dit 'n byna eindelose daaglikse proses wees, aangesien ons met 'n hoë mate van waarskynlikheid stewige stapels gededupliseerde blokke by elke kopie sal vind. Wat beteken 'n groot aantal versoeke van verskaffers van voorwerpberging? Reg! Groot rekening aan die einde van die maand.

En om nie uit die bloute jou gunstelingkliënte vir aansienlike geld bloot te stel nie, is die blokgenereringsmeganisme uitgevind. Dit is 'n bykomende tydperk wat ons by die vasgestelde onveranderlikheidstydperk voeg. In die voorbeeld hieronder is hierdie tydperk twee dae. Maar dit is net 'n voorbeeld. In werklikheid gebruik hulle hul eie formule, wat ongeveer tien bykomende dae tydens 'n maandelikse slot gee.

Kom ons gaan voort om dieselfde situasie te oorweeg, maar met blokgenerering. Op die eerste dag skep ons lêer1 vanaf blok a en metadata. Ons tel die generasieperiode en onveranderlikheid by - dit beteken dat die geleentheid om die lêer te skrap op die sesde dag sal wees. As ons op die tweede dag File2 skep, bestaande uit blok b en 'n skakel na blok a, dan gebeur niks met die verwagte skrapdatum nie. Sy het gestaan ​​soos op die sesde dag. En dus probeer ons geld spaar op die aantal versoeke. Die enigste situasie wanneer die sperdatum verskuif kan word, is as die generasietydperk verstryk het. Dit wil sê, as die nuwe File3 op die derde dag 'n skakel bevat om a te blokkeer, sal generasie 2 bygevoeg word aangesien Gen1 reeds verval het. En die verwagte datum vir die verwydering van blok a sal na die agtste dag verskuif. Dit stel ons in staat om die aantal versoeke om die leeftyd van gededupliseerde blokke te verleng dramaties te verminder, wat kliënte 'n klomp geld bespaar.

Die tegnologie self is beskikbaar vir gebruikers van S3- en S3-versoenbare hardeware, wie se vervaardigers waarborg dat hul implementering nie van Amazon s'n verskil nie. Vandaar die antwoord op die wettige vraag waarom Azure nie ondersteun word nie - hulle het 'n soortgelyke kenmerk, maar dit werk op die vlak van houers, nie individuele voorwerpe nie. Terloops, Amazon het self objekslot in twee modusse: nakoming en bestuur. In die tweede geval bly daar die moontlikheid dat die grootste admin bo admins en root bo roots, ten spyte van die objek slot, steeds die data uitvee. In die geval van voldoening is alles styf vasgespyker en niemand kan die rugsteun uitvee nie. Selfs Amazon-admins (volgens hul amptelike verklarings). Dit is die modus wat ons ondersteun.

En, soos gewoonlik, 'n paar nuttige skakels:

• op Blok Generasie in elke detail.
• Alle inligting oor Veeam-rugsteun en replikasie 10 op sy beste
• О Kapasiteitsvlak in besonderhede

Bron: will.com