Capacity Tier (of zoals we het binnen Vim noemen - captir) verscheen in de tijd van Veeam Backup and Replication 9.5 Update 4 onder de naam Archive Tier. Het idee hierachter is om het mogelijk te maken back-ups die buiten het zogenaamde operationele herstelvenster zijn gevallen, te verplaatsen naar objectopslag. Dit hielp schijfruimte vrij te maken voor gebruikers die er weinig van hadden. En deze optie heette Verplaatsmodus.

Om deze eenvoudige (zo lijkt het) actie uit te voeren, was het voldoende om aan twee voorwaarden te voldoen: alle punten van de verplaatste back-up moeten zich buiten de grenzen van het bovengenoemde operationele herstelvenster bevinden, dat expliciet in de gebruikersinterface is ingesteld. En ten tweede: de keten moet zich in de zogenaamde “verzegelde vorm” bevinden (verzegelde back-upketen of Inactieve back-upketen). Dat wil zeggen dat er in de loop van de tijd geen veranderingen optreden in deze keten.

Maar in VBR v10 werd het concept aangevuld met nieuwe functies: Copy Mode, Sealed Mode en iets met de moeilijk uit te spreken naam Immutability verscheen.

Dit zijn de fascinerende dingen waar we het vandaag over zullen hebben. Eerst over hoe het werkte in VBR9.5u4, en vervolgens over de veranderingen in de tiende versie.

En mogen de kampioenen van de zuivere taal mij vergeven, maar er zijn te veel termen die niet vertaald kunnen worden.
Er zullen hier dus heel veel anglicismen voorkomen.
En veel gifjes.
En foto's.

• Zonder de minste spijt. Auteur van het artikel.

Zoals het was

Laten we beginnen met het analyseren van het operationele herstelvenster en de verzegelde back-up (of zoals ze worden genoemd in de Inactive Backup Chain-documentatie). Zonder hun begrip zal verdere uitleg niet mogelijk zijn.

Zoals we in de afbeelding zien, hebben we een soort back-upketen met datablokken, die zich bevindt op de Performance-laag SOBR van de repository waarmee de Capaciteitslaag is verbonden. Onze operationele back-upperiode bedraagt ​​drie dagen.

Dienovereenkomstig verzegelt de .vbk die op maandag is gemaakt de vorige keten, waarvan de periode is ingesteld op drie dagen. En dat betekent dat u alles ouder dan deze drie dagen veilig kunt gaan vervoeren naar de schietbaan.

Maar wat werd precies bedoeld met een verzegelde ketting en wat kon er in update 4 naar de schietbaan worden gestuurd?

Voor Forward Incremental is het creëren van een nieuwe volledige back-up een teken van het verzegelen van de keten. En het maakt niet uit hoe deze volledige back-up wordt verkregen: zowel synthetische volledige als actieve volledige back-ups komen in aanmerking.

In het geval van Reverse zijn dit alle bestanden die niet in het bedieningsvenster vallen.

In het geval van Forward increment met rollbacks zijn dit allemaal rollbacks en .vbk, als er nog een .vbk op de prestatieomvang staat

Laten we nu eens kijken naar de mogelijkheid om met Backup Copy-ketens te werken. Hierheen zijn alleen spullen vervoerd die onder het GFS-retentierecht vielen. Omdat alles dat is opgeslagen in recentere back-upkopieketens op de een of andere manier kan worden gewijzigd.

Laten we nu eens onder de motorkap kijken. Daar vindt een proces plaats dat uitdroging wordt genoemd, waarbij lege back-upbestanden op de omvang achterblijven en blokken van deze bestanden naar de capaciteitsschietbaan worden gesleept. Om dit proces te optimaliseren wordt gebruik gemaakt van de zogenaamde dehydratie-index, waarmee u kunt voorkomen dat blokken die al zijn gekopieerd naar de capaciteitsschietbaan worden gekopieerd.

Laten we eens kijken hoe dit eruit ziet met een voorbeeld: Laten we zeggen dat we een .vbk hebben die uit het transactievenster komt en tot een verzegelde keten behoort. Dit betekent dat we het volste recht hebben om het naar de schietbaan te verplaatsen. Op het moment van verplaatsing wordt er een metadatabestand aangemaakt in het capaciteitsstreepje en de blokken van het overgedragen bestand. Het metadatabestand op linkniveau beschrijft uit welke blokken ons bestand bestaat. In het geval op de afbeelding bestaat ons eerste bestand uit blokken a, b, c en de metadata bevat links naar deze blokken. Wanneer we een tweede .vbk-bestand hebben, klaar om te verplaatsen en bestaande uit de blokken a, b en d, begrijpen we, door de dehydratie-index te analyseren, dat alleen blok d hoeft te worden overgedragen. En het metadatabestand zal links bevatten naar twee eerdere blokken en één nieuwe.

Dienovereenkomstig wordt het proces van het weer opvullen van deze lege ruimtes met gegevens rehydratie genoemd. Het gebruikt al zijn eigen rehydratatie-index, gebaseerd op het oudste .vbk-bestand op het lokale prestatieniveau. Dat wil zeggen dat als de gebruiker een bestand uit de capaciteitsschietbaan wil retourneren, we eerst een index van de blokken van de oudste volledige back-up maken en alleen de ontbrekende blokken uit de capaciteitsschietgalerij overbrengen. In het geval dat in de afbeelding wordt weergegeven, hebben we, om FullBackup1.vbk te rehydrateren volgens de rehydratie-index, alleen blok C nodig, dat we uit de capaciteitsschietbaan halen. Als een opslagwolkobject als capaciteitsschietbaan dient, kunt u enorme hoeveelheden geld besparen.

Hier lijkt het misschien dat deze technologie identiek is aan de technologie die wordt gebruikt in WAN Accelerators, maar dat lijkt alleen maar zo. Bij accelerators is deduplicatie globaal; hier wordt binnen elk bestand lokale deduplicatie met een specifieke offset gebruikt. Dit gebeurt vanwege het verschil in de taken die worden opgelost: hier moeten we grote volledige back-upbestanden kopiëren, en volgens ons onderzoek geeft dit deduplicatie-algoritme, zelfs als er een lange tijdsperiode tussen zit, het beste resultaat.

Maar meer indexen voor de god van de indexen! Er is ook een index voor gegevensherstel! Wanneer we beginnen met het herstellen van een machine die zich in het capaciteitsdashboard bevindt, lezen we alleen unieke datablokken die niet in het prestatiedashboard voorkomen.

Hoe is het geworden?

Dat is alles voor het inleidende gedeelte. Het is behoorlijk gedetailleerd, maar zoals hierboven vermeld, zal het zonder deze details niet mogelijk zijn om uit te leggen hoe de nieuwe functies werken. Laten we daarom zonder verder oponthoud verder gaan met de eerste.

Kopieer modus

Het is grotendeels gebaseerd op bestaande technologieën, maar kent een geheel andere gebruikslogica. 

Het doel van deze modus is ervoor te zorgen dat alle gegevens die zich op de lokale omvang bevinden, een kopie hebben in het capaciteitsstreepje.

Als je de modi Verplaatsen en Kopiëren rechtstreeks vergelijkt, ziet het er als volgt uit:

• Alleen de verzegelde ketting kan worden verplaatst. In het geval van een kopieermodus wordt absoluut alles overgedragen, ongeacht wat er in de back-uptaak ​​gebeurt.
• Het verplaatsen wordt geactiveerd wanneer de bestanden de grenzen van het operationele back-upvenster overschrijden, en het kopiëren wordt geactiveerd zodra het back-upbestand verschijnt.
• Het monitoren van nieuwe gegevens voor kopiëren vindt voortdurend plaats en voor verplaatsing werd deze eens in de vier uur geactiveerd.

Bij het overwegen van de nieuwe modus stel ik voor om van eenvoudige voorbeelden naar complexe voorbeelden te gaan.

In het meest voorkomende geval hebben we eenvoudigweg nieuwe bestanden met verhogingen en kopiëren we deze eenvoudigweg naar de schietbaan met capaciteit. Ongeacht welke modus wordt gebruikt in de back-uptaak, ongeacht of deze tot het verzegelde deel van de keten behoort of niet, ongeacht of ons werkingsvenster is verstreken. Ze namen het gewoon en kopieerden het.

Het proces hierachter is nog steeds uitdroging zoals hierboven beschreven. In de kopieermodus zorgt het er ook voor dat we geen blokken kopiëren die al in onze opslag staan. Het enige verschil is dat als we in de filmmodus echte bestanden vervangen door dummybestanden, we ze hier op geen enkele manier aanraken en alles laten zoals het is. Anders is het precies dezelfde uitdrogingsindex, die zorgvuldig probeert uw geld en tijd te besparen.

De vraag rijst: als je naar de gebruikersinterface kijkt, is er een mogelijkheid om beide opties tegelijkertijd te selecteren. Hoe werkt zo’n gecombineerde modus?

Laten we het uitzoeken.

Het begin is standaard: er wordt een back-upbestand gemaakt en onmiddellijk gekopieerd. Er wordt een verhoging voor gemaakt en ook gekopieerd. Dit gebeurt tot het moment waarop we ons realiseren dat de bestanden ons operatievenster hebben verlaten en er een verzegelde keten is verschenen. Op dit punt voeren we een dehydratatiebewerking uit en vervangen we deze bestanden door dummybestanden. Uiteraard kopiëren wij niets meer naar de capaciteit schietbaan.

Al deze fascinerende logica is verantwoordelijk voor slechts één selectievakje in de interface: kopieer back-ups naar objectopslag zodra ze zijn gemaakt.

Waarom hebben we deze kopieermodus nodig?

Het is nog beter om de vraag op deze manier te herformuleren: tegen welke risico’s worden we met de hulp ervan beschermd? Welk probleem helpt het ons oplossen?

Het antwoord ligt voor de hand: dit is natuurlijk gegevensherstel. Als we een volledige kopie van de lokale gegevens in de objectopslag hebben, kunnen we, wat er ook met ons product gebeurt, altijd gegevens herstellen van bestanden die zich in de voorwaardelijke Amazon bevinden.

Laten we dus de mogelijke scenario's doornemen, van de eenvoudigste tot de meer complexe.

Het eenvoudigste ongeluk dat op ons hoofd kan vallen, is de ontoegankelijkheid van een van de bestanden in de back-upketen.

Een treuriger verhaal is dat een van de delen van onze SOBR-repository kapot ging.

Het wordt nog erger als de hele SOBR-repository ontoegankelijk is geworden, maar de schietbaan met capaciteit werkt.
En alles is echt slecht - dit is het moment waarop de back-upserver het begeeft en je eerste wens is om binnen tien minuten naar de Canadese grens te rennen.

Laten we nu elke situatie afzonderlijk bekijken.

Wanneer we één (en zelfs meerdere) back-upbestanden kwijt zijn, hoeven we alleen maar het opnieuw scannen van de repository te starten, waarna het verloren bestand wordt vervangen door een dummybestand. En met behulp van het rehydratatieproces (dat aan het begin van het artikel werd besproken), kan de gebruiker gegevens downloaden van de schietbaan met capaciteit naar lokale opslag.

Nu is de situatie ingewikkelder. Laten we aannemen dat onze SOBR bestaat uit twee gebieden die in de Performance-modus draaien, wat betekent dat onze .vbk en .vib daarover zijn verspreid in een tamelijk ongelijke laag. En op een gegeven moment raakt een van de gebieden niet meer beschikbaar en moet de gebruiker dringend de machine herstellen, waarvan een deel van de gegevens precies in deze omvang ligt.

De gebruiker start de herstelwizard, selecteert het punt waarnaar hij wil herstellen, en de wizard komt tijdens het werken tot het besef dat hij niet over alle gegevens beschikt die nodig zijn voor herstel lokaal en daarom moet worden gedownload van de capaciteitsopname galerij. Tegelijkertijd worden blokken die op de lokale opslag achterblijven niet uit de cloud gedownload. Glorie voor de herstelindex (ja, deze werd ook vermeld aan het begin van het artikel).

Een subtype van deze zaak is dat de gehele SOBR-repository ontoegankelijk werd. In dit geval hoeven we niets te kopiëren vanuit de lokale opslag en worden alle blokken gedownload vanuit de cloud.

En de meest interessante situatie is dat de back-upserver is overleden. Er zijn hier twee opties: de beheerder is geweldig en heeft configuratieback-ups gemaakt, en de beheerder is zelf een kwaadaardige Pinocchio en heeft geen configuratieback-ups gemaakt.

In het eerste geval is het voor hem voldoende om eenvoudigweg ergens een schone installatie van VBR te implementeren en de database met standaardmiddelen vanaf een back-up te herstellen. Aan het einde van dit proces zal alles weer normaal worden. Of het wordt hersteld volgens een van de bovenstaande scenario's.

Maar als de beheerder zijn eigen vijand is, of als de configuratieback-up ook een epische mislukking heeft geleden, dan zullen we hem zelfs hier niet aan de genade van het lot overlaten. Voor dit geval hebben we een nieuwe procedure geïntroduceerd genaamd Objectopslag importeren. Hiermee kunt u het proces van het handmatig opnieuw aanmaken van een SOBR-repository en het daaraan koppelen van een schietbaan met capaciteit en daaropvolgende herscan overslaan, en eenvoudigweg een opslagobject toevoegen aan de Vim-interface en de Import Storage Repository-procedure uitvoeren. Het enige dat u en uw back-ups in de weg kan staan, is een verzoek om een ​​wachtwoord in te voeren als uw back-ups gecodeerd zijn.

Dit gaat waarschijnlijk allemaal over de Kopieermodus en daar gaan we verder mee

Verzegelde modus

Het belangrijkste idee is dat nieuwe back-ups niet kunnen verschijnen op het geselecteerde SOBR-gebied van de repository. Vóór v10 hadden we alleen de Onderhoudsmodus, toen elk werk met de repository volledig verboden was. Een soort hardcore-modus voor het afsluiten van opslag, waarbij alleen de knop Evacueren beschikbaar is, die back-ups eenmalig naar een ander niveau transporteert.

En de verzegelde modus is een soort "zachte" optie: we verbieden het maken van nieuwe back-ups en verwijderen geleidelijk oude volgens de geselecteerde retentie, maar daarbij verliezen we niet de mogelijkheid om te herstellen vanaf opgeslagen punten. Een heel handig iets als we óf een stuk hardware hebben dat het einde van zijn levensduur nadert en het moet vervangen, óf als we het gewoon moeten vrijmaken voor iets belangrijkers, maar we het nergens mee naartoe kunnen nemen en alles in één keer kunnen verplaatsen. Of het kan niet worden verwijderd.

Dienovereenkomstig is het werkingsprincipe vrij eenvoudig: het is noodzakelijk om alle schrijfbewerkingen (het verschijnen van nieuwe gegevens) te verbieden, lezen (herstel) en verwijderen (retentie) achter te laten.

Beide modi kunnen tegelijkertijd worden gebruikt, maar houd er rekening mee dat Onderhoud een hogere prioriteit heeft.

Beschouw als voorbeeld een SOBR die uit twee gebieden bestaat. Laten we aannemen dat we de eerste vier dagen back-ups hebben gemaakt in de Forward Forever Incremental-modus, en dat we vervolgens de omvang verzegelen. Dit leidt ertoe dat we de creatie van een nieuwe actieve volledige op de tweede beschikbare omvang initiëren. Als onze retentie vier is, wordt de hele keten, die zich op het verzegelde gebied bevindt, buiten zijn grenzen verwijderd met een zuiver geweten.

Er zijn situaties waarin verwijdering eerder plaatsvindt. Dit is bijvoorbeeld Forward incrementeel met periodieke fulls. Als we voor de eerste twee dagen volledige back-ups hebben gemaakt en we op donderdag besluiten de repository te verzegelen, wordt op vrijdag, als er een nieuwe back-up wordt gemaakt, het bestand voor maandag verwijderd omdat er zijn op dit punt geen afhankelijkheden. En het punt zelf is van niemand afhankelijk. Vervolgens wachten we tot er vier punten zijn aangemaakt op de beschikbare omvang en verwijderen we de overige drie, die niet onafhankelijk van elkaar kunnen worden verwijderd.

Met Reverse Incremental is het eenvoudiger. Daarin zijn de oudste punten nergens van afhankelijk en kunnen ze veilig worden verwijderd. Daarom zullen, zodra een nieuwe .vbk op een nieuwe omvang wordt aangemaakt, de oude .vrbs één voor één worden verwijderd.

Waarom maken we trouwens elke keer een nieuwe .vbk: als we deze niet zouden maken, maar de oude keten van verhogingen zouden voortzetten, dan zou de oude .vbk in elke modus oneindig lang bevriezen, waardoor verwijdering ervan wordt voorkomen. Daarom is besloten dat zodra de omvang is verzegeld, we een volledige back-up maken op de vrije omvang.

Bij het schietbereik met capaciteit is het ingewikkelder.

Laten we eerst eens kijken naar de kopieermodus. Laten we aannemen dat we gedurende vier dagen actief back-ups aan het maken waren, en dat daarna de schietbaan werd afgesloten. We verwijderen niets, maar ondergaan de retentie nederig, waarna we de gegevens van de capaciteitsschietbaan verwijderen.

Ongeveer hetzelfde gebeurt in de verplaatsingsmodus: we wachten op de retouchering, verwijderen de oude in de lokale opslag en verwijderen degene die is opgeslagen in de objectopslag.

Een interessant voorbeeld met Forever forward incremental. We installeren op drie punten retentie en beginnen maandag met het maken van back-ups, die regelmatig naar de cloud worden gekopieerd. Na het verzegelen van de opslag worden er nog steeds back-ups gemaakt, waarbij drie punten behouden blijven, maar de gegevens die zijn opgeslagen in het capaciteitsstreepje blijven afhankelijk en kunnen niet worden verwijderd. Daarom wachten we tot donderdag, wanneer onze .vbk verder gaat dan retentie, en pas dan verwijderen we rustig de hele opgeslagen keten.

En een kleine disclaimer: alle voorbeelden hier worden getoond met één machine. Als u er meerdere in uw back-up heeft, zal hun retouchering verschillen afhankelijk van of Active Full is gemaakt of niet.

Dat is eigenlijk alles wat er is. Dus laten we verder gaan met de meest hardcore functie:

Onveranderlijkheid

Net als bij de voorgaande punten is het eerste het probleem dat deze functie oplost. Zodra we onze back-ups ergens uploaden voor opslag, is er een sterke wens om de veiligheid ervan te garanderen, dat wil zeggen om het fysiek verwijderen ervan en elke wijziging tijdens een bepaalde bewaring fysiek te verbieden. Inclusief beheerders, ook onder hun root-accounts. Hierdoor kunt u ze beschermen tegen accidentele of opzettelijke schade. Iedereen die met AWS werkt, is misschien een soortgelijke functie tegengekomen, genaamd Object Lock.

Laten we nu de modus in algemene termen bekijken en vervolgens in de details duiken. In ons voorbeeld wordt Onveranderlijkheid ingeschakeld voor onze capaciteitsschietbaan met een retentie van vier dagen. En de kopieermodus is ingeschakeld in de back-up.

Onveranderlijkheid heeft op geen enkele manier invloed op algemene retentie. Het levert bijvoorbeeld geen extra punten op of iets dergelijks. Het is alleen zo dat iemand back-upbestanden niet binnen vier dagen kan verwijderen. Als u op maandag een back-up maakt, kunt u het bestand pas op vrijdag verwijderen.

Alle eerder uitgelegde concepten van uitdroging, indexen en metadata blijven precies hetzelfde werken. Maar met één voorwaarde: het blok is niet alleen ingesteld voor gegevens, maar ook voor metadata. Dit wordt gedaan voor het geval een sluwe aanvaller besluit onze metadatadatabase te wissen en te voorkomen dat datablokken veranderen in nutteloze binaire brij.

Dit is een goed moment om onze blokgeneratietechnologie uit te leggen. Of blokgeneratie. Om dit te doen, moet u rekening houden met de situatie die tot zijn verschijning heeft geleid.

Laten we een tijdschaal van zes dagen nemen en daaronder markeren we het tijdstip van het verwachte einde van de onveranderlijkheid. Op de eerste dag maken we een bestand dat bestaat uit datablok a en de bijbehorende metadata. Als de onveranderlijkheid is ingesteld op drie dagen, is het logisch om aan te nemen dat de gegevens op de vierde dag worden ontgrendeld en verwijderd. Op de tweede dag voegen we een nieuw bestand2 toe, bestaande uit blok b met dezelfde instellingen. Blok a moet op de vierde dag nog verwijderd worden. Maar op de derde dag gebeurt er iets vreselijks: er wordt een File3-bestand gemaakt, bestaande uit een nieuw blok d en een link naar het oude blok a. Dit betekent dat voor een blok en zijn onveranderlijkheidsvlag opnieuw moet worden ingesteld naar een nieuwe datum, die wordt verschoven naar de zesde dag. En hier doet zich een probleem voor: in echte back-ups zijn er een groot aantal van dergelijke blokken. En om hun onveranderlijkheidsperiode te verlengen, moet u elke keer een groot aantal verzoeken indienen. En in feite zal dit een vrijwel eindeloos dagelijks proces zijn, aangezien we met een hoge mate van waarschijnlijkheid bij elke kopie flinke stapels gededupliceerde blokken zullen aantreffen. Wat betekent een groot aantal verzoeken van aanbieders van objectopslag? Rechts! Enorme rekening aan het eind van de maand.

En om je favoriete klanten niet uit het niets bloot te stellen voor substantieel geld, werd het blokgeneratiemechanisme uitgevonden. Dit is een extra periode die we toevoegen aan de vastgestelde onveranderlijkheidsperiode. In het onderstaande voorbeeld bedraagt ​​deze periode twee dagen. Maar dit is slechts een voorbeeld. In werkelijkheid gebruiken ze hun eigen formule, die tijdens een maandelijkse blokkering ongeveer tien extra dagen oplevert.

Laten we dezelfde situatie blijven overwegen, maar dan met blokgeneratie. Op de eerste dag maken we bestand1 van blok a en metadata. We tellen de generatieperiode en de onveranderlijkheid bij elkaar op - dit betekent dat de mogelijkheid om het bestand te verwijderen op de zesde dag zal zijn. Als we op de tweede dag Bestand2 aanmaken, bestaande uit blok b en een link naar blok a, gebeurt er niets met de verwachte verwijderingsdatum. Ze stond zoals ze deed op de zesde dag. En zo proberen we geld te besparen op het aantal aanvragen. De enige situatie waarin de deadline kan worden verschoven, is als de generatieperiode is verstreken. Dat wil zeggen: als het nieuwe File3 op de derde dag een link bevat om a te blokkeren, wordt generatie 2 toegevoegd omdat Gen1 al is verlopen. En de verwachte datum voor het verwijderen van blok a verschuift naar de achtste dag. Hierdoor kunnen we het aantal verzoeken om de levensduur van gededupliceerde blokken te verlengen drastisch verminderen, wat klanten een hoop geld bespaart.

De technologie zelf is beschikbaar voor gebruikers van S3- en S3-compatibele hardware, waarvan de fabrikanten garanderen dat de implementatie ervan niet verschilt van die van Amazon. Vandaar het antwoord op de legitieme vraag waarom Azure niet wordt ondersteund: ze hebben een vergelijkbare functie, maar deze werkt op het niveau van containers, niet op individuele objecten. Overigens heeft Amazon zelf objectvergrendeling in twee modi: compliance en governance. In het tweede geval blijft de mogelijkheid bestaan ​​dat de grootste beheerder boven beheerders en root boven root, ondanks de objectvergrendeling, toch de gegevens verwijdert. In het geval van compliance zit alles strak vast en kan niemand de back-ups verwijderen. Zelfs Amazon-beheerders (volgens hun officiële verklaringen). Dit is de modus die wij ondersteunen.

En, zoals gewoonlijk, enkele nuttige links:

• Про Blokgeneratie in elk detail.
• Alle informatie over Veeam Back-up & Replicatie 10 op z'n best
• О Capaciteitsniveau in detail

Bron: www.habr.com