Welkom lezers van onze blog! We zijn deels al bekend — mijn Engelstalige berichten verschenen hier in de vertaling van mijn lieve collega. . Dit keer besloot ik rechtstreeks tot het Nederlandstalige publiek te spreken.
Voor mijn debuut wilde ik een onderwerp vinden dat interessant is voor een zo breed mogelijk publiek en gedetailleerde beschouwing vereist. Daniel Defoe beweerde dat iedereen wordt geconfronteerd met de dood en belastingen. Vanuit mijn perspectief kan ik zeggen dat elke support engineer wordt geconfronteerd met vragen over opslagbeleid voor herstelpunten (of eenvoudiger gezegd – retention). Hoe retention werkt, begon ik vier jaar geleden uit te leggen, toen ik junior engineer op het eerste niveau was, en ik blijf dat nu uitleggen, terwijl ik inmiddels teamleider ben van het Spaanstalige en Italiaanstalige team. Ik ben ervan overtuigd dat mijn collega's op het tweede en zelfs derde niveau ook regelmatig dezelfde vragen beantwoorden.
In dit opzicht wilde ik een definitieve, uiterst gedetailleerde post schrijven waar Nederlandstalige gebruikers keer op keer naar kunnen terugkeren als naslagwerk. Het moment is gepast – de onlangs uitgebrachte tiende jubileumversie heeft nieuwe mogelijkheden aan de basisfunctionaliteit toegevoegd, die jarenlang onveranderd is gebleven. Mijn post is voornamelijk gericht op deze versie — hoewel het grootste deel van wat is geschreven ook geldt voor eerdere versies, zult u sommige beschreven functionaliteiten daar eenvoudigweg niet vinden. Ten slotte, met een blik op de toekomst, kan ik zeggen dat er in de volgende versie enkele wijzigingen worden verwacht, maar daar zullen we op het juiste moment meer over vertellen. Laten we beginnen.
Back-up taken (Backup job)
Laten we beginnen met het deel dat niet gewijzigd is in versie 10. Het retentionbeleid wordt bepaald door verschillende parameters. Laten we het venster voor het aanmaken van een nieuwe taak openen en naar het tabblad Opslag gaan. Hier zien we een parameter die het gewenste aantal herstelpunten definieert:
Maar dit is slechts een deel van de vergelijking. Het werkelijke aantal punten wordt ook bepaald door de back-upmodus die is ingesteld voor de taak. Om deze parameter te selecteren, moet je op de knop Geavanceerd klikken op hetzelfde tabblad. Dit opent een nieuw venster met tal van opties. Laten we ze nummeren en één voor één bekijken:
Als u alleen optie 1 inschakelt, zal de taak werken in de "oneindig incrementele" modus (forever forward incremental). Hier ontstaan geen complicaties – de taak zal het ingestelde aantal herstelpunten opslaan van de volledige back-up (bestand met de extensie VBK) tot de laatste increment (bestand met de extensie VIB). Wanneer het aantal punten het ingestelde maximum overschrijdt, wordt de oudste increment samengevoegd met de volledige back-up. Met andere woorden, als de taak is ingesteld om 3 punten te bewaren, zou er direct na de volgende sessie 4 punten op de repository staan, waarna de volledige back-up zal worden samengevoegd met de oudste increment en het totale aantal punten weer op 3 komt.
Het behoud voor de "reverse incremental" (optie 2) modus is ook zeer eenvoudig. Aangezien in dit geval het nieuwste punt de volledige back-up zal zijn, gevolgd door een keten van zogenaamde rollbacks (bestanden met de extensie VRB), is het voldoende om gewoon de oudste rollback te verwijderen om het behoud toe te passen. De situatie blijft hetzelfde: direct na de sessie zal het aantal punten met 1 toenemen, waarna het weer op de gewenste waarde terugkomt.
Houd er rekening mee dat u met de reverse incremental modus ook een periodieke volledige back-up kunt inschakelen (optie 4), maar de essentie zal hierdoor niet veranderen. Ja, er zullen volledige herstelpunten in de keten komen, maar we zullen nog steeds gewoon de oudste punten één voor één verwijderen.
Ten slotte komen we bij het interessante deel. Als u een incrementele back-up activeert, maar ook optie 3 of 4 inschakelt (of beide tegelijkertijd), zal de taak beginnen met het maken van periodieke volledige back-ups via de "actieve" of synthetische methode. De methode voor het maken van een volledige back-up is niet belangrijk – deze zal dezelfde gegevens bevatten, terwijl de incrementele keten zal worden verdeeld in "subketens". Deze methode wordt forward incremental genoemd, en juist deze roept een aanzienlijk deel van de vragen bij onze klanten op.
Retention wordt hier toegepast door het verwijderen van het oudste deel van de keten (van de volledige back-up tot de incrementele). We zullen echter geen lege back-up of alleen een deel van de incrementele verwijderen. De gehele "subketen" wordt in één keer volledig verwijderd. De betekenis van de instelling van het aantal punten verandert - terwijl dit bij andere methoden het maximaal toegestane aantal is waarna de retentie moet worden toegepast, bepaalt deze instelling hier de minimumhoeveelheid. Met andere woorden, na het verwijderen van de oudste "subketen" mag het aantal punten in het resterende deel niet onder dit minimum vallen.
Ik zal proberen deze concept grafisch weer te geven. Stel dat de retentie is ingesteld op 3 punten, de taak draait elke dag met een volledige back-up op maandag. In dit geval zal de retentie worden toegepast wanneer het totale aantal punten 10 bereikt:
Waarom 10, terwijl we 3 hebben ingesteld? Op maandag werd er een volledige back-up gemaakt. Van dinsdag tot zondag creëerde de taak incrementele back-ups. Uiteindelijk wordt er de volgende maandag weer een volledige back-up gemaakt en pas wanneer er 2 incrementele zijn gecreëerd, kan het oude deel van de keten eindelijk worden verwijderd, omdat het resterende aantal punten niet onder de ingestelde 3 zal dalen.
Als het idee duidelijk is, stel ik voor dat je zelf probeert de retentie te berekenen. Laten we de volgende voorwaarden nemen: de taak wordt voor het eerst uitgevoerd op donderdag (natuurlijk wordt er een volledige back-up gemaakt). De taak is ingesteld om elke woensdag en zondag een volledige back-up te maken en 8 herstelpunten op te slaan. Wanneer zal de retentie voor het eerst worden toegepast?
Om deze vraag te beantwoorden, raad ik je aan om een vel papier te nemen, het in te tekenen op dagen van de week en te noteren welk punt elke dag wordt aangemaakt. Het antwoord zal duidelijk worden.
Antwoord
Uitleg: Om te antwoorden, moet je jezelf afvragen "wanneer zal de retentie worden toegepast"? Het antwoord is wanneer we de eerste 3 punten (VBK, VIB, VIB) kunnen verwijderen en de resterende keten boven de vereiste 8 punten blijft. Het wordt duidelijk dat we dit kunnen doen wanneer we in totaal 11 punten hebben, dat is op zondag van de tweede week.
Sommige lezers kunnen tegenwerpen: "waarom al dit, als er ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Uiteindelijk hebben we de optie ‘Transform previous backup chains into rollbacks’ (gemarkeerd met het cijfer 5) niet behandeld. Deze optie verwart soms klanten die deze ‘automatisch’ inschakelen in de veronderstelling dat ze gewoon een synthetische back-up willen uitvoeren. In werkelijkheid activeert deze optie een heel specifieke modus van back-up. Ik zal niet in detail treden, maar ik kan meteen zeggen dat deze optie in deze fase van de productontwikkeling ‘Transform previous backup chains into rollbacks’ verouderd is, en ik kan geen scenario bedenken waarin deze nuttig zou zijn. De waarde ervan is zo twijfelachtig dat Anton Gostev enige tijd geleden een oproep deed op het forum om hem voorbeelden van nuttig gebruik te sturen (als je die hebt, laat het me weten in de reacties, ik ben er erg benieuwd naar). Als er geen voorbeelden zijn (wat ik vermoed), zal de optie in de volgende versies worden verwijderd.
De taak zal incrementele back-ups (VIB) aanmaken tot de dag waarop de synthetische volledige back-up is gepland. Op deze dag wordt er inderdaad een VBK aangemaakt, maar alle punten tot aan deze VBK worden omgevormd tot rollbacks (VRB). Daarna blijft de taak incrementele back-ups maken tot de volgende synthetische back-up. Het resultaat is een explosieve mix van VBK, VBR en VIB-bestanden. Retentie wordt heel eenvoudig toegepast door de laatste VBR te verwijderen:
Problemen
Naast het eigenlijke begrip van hoe dit werkt, zijn de meeste problemen die zich voordoen bij het gebruik van de incrementale modus meestal gerelateerd aan de volledige back-up. Een regelmatige volledige back-up is noodzakelijk voor deze modus, anders zal de repository punten verzamelen totdat deze vol is.
Bijvoorbeeld, een volledige back-up kan te zelden worden gemaakt. Stel dat de taak is ingesteld om 10 punten te bewaren, maar de volledige back-up wordt eens per maand gemaakt. Het is duidelijk dat het werkelijke aantal punten veel groter zal zijn dan het ingestelde aantal. Of de taak is helemaal ingesteld om in een oneindig incrementele modus te werken en 50 punten te bewaren. Dan heeft iemand per ongeluk een volledige back-up gemaakt. Vanaf dat moment zal de taak wachten totdat de volledige punt 49 incrementen heeft verzameld, waarna de retentie zal worden toegepast en het weer terugkeert naar de oneindig volledige modus.
In andere gevallen wordt een volledige back-up regelmatig ingesteld, maar om de een of andere reden gebeurt dit niet. Hier beschrijf ik de meest populaire reden. Sommige klanten geven de voorkeur aan de optie 'run after' en stellen taken in om in een keten te werken. Laten we als voorbeeld nemen: er zijn 3 taken die elke dag draaien en een volledige back-up maken op zondag. De eerste taak start om 22:30, de overige starten in een keten. De incrementele back-up duurt 10 minuten en daarom zijn alle taken om 23:00 klaar. Maar de volledige back-up duurt een uur, dus op zondag gebeurt het volgende: de eerste taak draait van 22:30 tot 23:30. De tweede van 23:30 tot 00:30. En de derde taak start al op maandag. De volledige back-up is ingesteld voor zondag, dus in dit geval is deze er gewoon niet. De taak zal wachten op de volledige back-up om de retentie toe te passen. Wees daarom voorzichtig bij het gebruik van de optie 'run after' of gebruik het helemaal niet – stel eenvoudigweg de taken in om tegelijk te starten en laat de resource scheduler zijn werk doen.
Lastige optie 'Verwijder verwijderde items'
Door de instellingen van de taak Storage – Advanced – Maintenance te doorlopen, kunt u de optie 'verwijder gegevens van verwijderde items na' tegenkomen, gemeten in dagen.
Sommige klanten verwachten dat dit de retentie is. In werkelijkheid is dit een compleet aparte optie, waarvan het onbegrip tot onverwachte gevolgen kan leiden. Maar eerst moet worden uitgelegd hoe B&R reageert op situaties waarin tijdens een sessie slechts enkele machines succesvol worden geback-upt.
Stel dit scenario voor: een oneindig incrementele taak, ingesteld om 6 punten te bewaren. In de taak zijn 2 machines, de ene is altijd succesvol geback-upt, de andere gaf soms fouten. Uiteindelijk is er bij het zevende punt de volgende situatie ontstaan:
Het is tijd om de retentie toe te passen, maar de ene machine heeft 7 punten, terwijl de andere er slechts 4 heeft. Zal hier de retentie worden toegepast? Het antwoord is – ja, dat zal zo zijn. Als zelfs maar één object is geback-upt, beschouwt B&R dit als een gecreëerd punt.
Een soortgelijke situatie kan zich voordoen als een bepaalde machine eenvoudigweg niet in de opdracht werd opgenomen tijdens een bepaalde sessie. Dit gebeurt bijvoorbeeld wanneer machines niet individueel aan de opdracht zijn toegevoegd, maar als deel van containers (mappen, opslag), en een bepaalde machine tijdelijk migreert naar een andere container. In dat geval wordt de opdracht als succesvol beschouwd, maar in de statistieken zult u een bericht vinden dat aangeeft dat die bepaalde machine niet meer door de opdracht wordt verwerkt.
Wat gebeurt er als hier geen aandacht aan wordt besteed? In het geval van oneindig incrementele of terug-incrementele modi, zal het aantal herstelpunten van de 'problematische' machine met elke sessie afnemen totdat het uitkomt op 1, opgeslagen in VBK. Met andere woorden, zelfs als de machine lange tijd niet geback-upt wordt, zal er toch één herstelpunt overblijven. Dit is anders als er periodieke volledige back-ups zijn ingeschakeld. Als signalen van B&R worden genegeerd, kan uiteindelijk het laatste punt samen met het oude deel van de keten worden verwijderd.
Na het begrijpen van deze details kunnen we eindelijk de optie 'Verwijder gegevens van verwijderde items na' bekijken. Deze zal alle punten voor een bepaalde machine verwijderen als deze machine gedurende X dagen niet wordt geback-upt. Let op, deze instelling reageert niet op fouten (we hebben het geprobeerd – het werkte niet). Er mag zelfs geen poging tot back-up van de machine zijn gedaan. Het lijkt erop dat de optie nuttig is en altijd ingeschakeld moet zijn. Als de beheerder de machine uit de opdracht heeft verwijderd, is het logisch om na enige tijd onnodige gegevens en de keten op te schonen. Echter, de instelling vereist discipline en aandacht.
Ik geef een praktisch voorbeeld: er werden verschillende containers aan de taak toegevoegd, waarvan de samenstelling vrij dynamisch was. Vanwege een gebrek aan RAM had de B&R-server problemen die onopgemerkt bleven. De taak werd gestart en probeerde backups van machines te maken, behalve van één die op dat moment niet in de container aanwezig was. Aangezien veel machines fouten vertoonden, moet B&R standaard 3 extra pogingen ondernemen om de ‘problematische’ machines te backupen. Door constante problemen met het RAM, strekten deze pogingen zich over meerdere dagen uit. Er was geen herhaalde poging om een ontbrekende VM te backupen (het ontbreken van de VM is geen fout). Uiteindelijk, tijdens een van de herhaalde pogingen, werd de voorwaarde “Verwijder verwijderde items” uitgevoerd en werden alle punten van de machine verwijderd.
Wat ik hierover kan zeggen is het volgende: als je waarschuwingen instelt voor de resultaten van taken, en nog beter — integratie met Veeam ONE gebruikt, dan is de kans groot dat jou dit niet overkomt. Als je echter eens per week op de B&R-server kijkt om te controleren of alles werkt, is het beter om af te zien van opties die mogelijk kunnen leiden tot het verwijderen van backups.
Wat is er toegevoegd in v.10
Wat we eerder bespraken, bestond al in B&R gedurende vele versies. Nadat we deze werkprincipes hebben begrepen, laten we nu kijken wat er toegevoegd is in de feestelijke ‘tien’.
Dagelijks behoud
Boven hebben we de ‘klassieke’ opslagpolicy besproken, gebaseerd op het aantal punten. Een alternatieve aanpak is om in hetzelfde menu “dagen” in te stellen in plaats van “herstelpunten”.
Het idee is duidelijk uit de naam — het behoud zal het ingebouwde aantal dagen bewaren, waarbij het aantal punten in elke dag niet van belang is. Houd hierbij het volgende in gedachten:
- De huidige dag wordt niet meegerekend bij het berekenen van het behoud
- Dagen waarop de taak helemaal niet heeft gewerkt, worden ook geteld. Dit moet in overweging worden genomen om per ongeluk punten te verliezen van die taken die onregelmatig werken.
- Een herstelpunt wordt beschouwd vanaf de dag waarop het creëren ervan begon (d.w.z. als de taak op maandag begon en dinsdag eindigde, dan is dit een punt van maandag)
In andere opzichten worden de principes voor het toepassen van retentie door de taken nog steeds bepaald door de gekozen back-upmethode. Laten we nog een opdracht voor de berekening proberen, met dezelfde incrementele methode. Stel, de retentie is ingesteld op 8 dagen, de taak draait elke 6 uur met een volledige back-up op woensdag. De taak draait niet op zondag. De taak wordt voor het eerst gestart op maandag. Wanneer wordt de retentie toegepast?
Antwoord
Zoals gewoonlijk is het het beste om een tabel te tekenen. Ik laat me de taak vereenvoudigen en zal niet alle punten die elke dag gemaakt zijn tekenen, omdat het aantal punten per dag hier niet van belang is. Het is belangrijk dat de eerste punt in de eerste maandag en op woensdag een volledige back-up zal zijn, terwijl op andere dagen de taak gewoon 4 incrementele punten zal creëren.
We maken onszelf duidelijk dat de retentie zal worden toegepast door het verwijderen van de volledige back-up van maandag en de bijbehorende incrementele back-up. Wanneer gebeurt dit? Wanneer de resterende keten 8 dagen zal bevatten. Hierbij tellen we de huidige dag niet mee, maar zondag echter wel. Dus het antwoord is donderdag van de tweede week.
Archivering met de GFS-methode voor reguliere taken
Tot v.10 was de Grandfather-Father-Son (GFS) opslagmethode alleen beschikbaar voor taken om archieffiles (Backup copy) te maken en voor taken om naar magnetische tape te kopiëren. Nu is het ook beschikbaar voor reguliere back-ups.
Hoewel dit niet direct verband houdt met het huidige onderwerp, moet ik wel zeggen dat de nieuwe functionaliteit niet betekent dat we ons hebben afgekeerd van de 3-2-1 strategie. De aanwezigheid van archiefpunten in de hoofdrepository heeft geen invloed op de betrouwbaarheid ervan. Het wordt verondersteld dat GFS zal worden gebruikt in combinatie met een schaalbare (Scale-out) repository, voor het uploaden van deze punten naar S3 en soortgelijke opslagplaatsen. Als je deze niet gebruikt, is het beter om de primaire en archiefpunten in verschillende repositories op te slaan.
Laten we nu de principes van het maken van GFS-punten bekijken. In de instellingen van de taak, op de stap Opslag, is er een speciale knop toegevoegd die het volgende menu oproept:
De kern van GFS kan worden samengevat in een aantal punten (let op, GFS werkt anders in andere soorten taken, maar daar straks meer over):
- De taak maakt geen aparte volledige back-up voor het GFS-punt. In plaats daarvan wordt de meest geschikte volledige back-up uit de beschikbare back-ups gebruikt. Daarom moet de taak in incrementele modus werken met periodieke volledige back-ups, of moet de volledige back-up handmatig door de gebruiker worden gemaakt.
- Als er slechts één periode is ingeschakeld (bijvoorbeeld wekelijks), begint de taak aan het begin van de GFS-periode eenvoudigweg te wachten op een volledige back-up en markeert de eerste geschikte als GFS.
Voorbeeld: de taak is ingesteld om een wekelijkse GFS op te slaan, gebruikmakend van de back-up op woensdag. De taak draait elke dag, maar de volledige back-up is gepland voor vrijdag. In dit geval begint de GFS-periode op woensdag en begint de taak te wachten op een geschikte punt. Deze verschijnt op vrijdag en wordt gemarkeerd met de GFS-vlag.
- Als er meerdere perioden zijn ingeschakeld (bijvoorbeeld wekelijks en maandelijks), past B&R een methode toe waarmee dezelfde punt als GFS voor meerdere intervallen kan worden gebruikt (om ruimte te besparen). De vlaggen worden om de beurt toegewezen, te beginnen met de jongste.
Voorbeeld: de wekelijkse GFS staat ingesteld op woensdag, en de maandelijkse op de laatste week van de maand. De taak draait elke dag en maakt volledige back-ups op maandag en vrijdag.
Voor de eenvoud beginnen we de telling vanaf de voorlaatste week van de maand. In deze week wordt er op maandag een volledige back-up gemaakt, maar deze wordt genegeerd omdat de wekelijkse GFS-periode op woensdag begint. Daarentegen is de volledige back-up op vrijdag volledig geschikt voor het GFS-punt. Dit systeem is ons al bekend.
Laten we nu eens kijken wat er in de laatste week van de maand gebeurt. De maandelijkse GFS-periode begint op maandag, maar de maandagochtend VBK wordt niet gemarkeerd als GFS, omdat de taak probeert om één VBK zowel als maandelijkse als wekelijkse GFS-punt te markeren. Hierbij begint de zoektocht precies bij de wekelijkse, omdat deze per definitie ook maandelijk kan worden.
Als alleen de wekelijkse en jaarlijkse intervallen zijn ingeschakeld, zullen deze onafhankelijk van elkaar werken en kunnen ze 2 aparte VBK markeren als overeenkomstige GFS-intervallen.
Taken voor het maken van een back-up (Backup copy)
Een ander type taak dat vaak uitleg vereist over de werking. Laten we beginnen met de 'klassieke' werkmethode, zonder de vernieuwingen in v.10.
Eenvoudige methode voor retentie
Standaard werken dergelijke taken in een oneindig incrementele modus. Het creëren van punten wordt bepaald door twee parameters: het kopieerinterval en het gewenste aantal herstelpunten (retentie in dagen is hier niet van toepassing). Het kopieerinterval wordt ingesteld op het eerste tabblad Job bij het aanmaken van de taak:
Het aantal punten wordt iets verderop ingesteld op het tabblad Target.
De taak creëert 1 nieuw punt voor elk interval (het aantal punten dat voor de VM door de oorspronkelijke taken is aangemaakt, doet er niet toe). Aan het einde van het interval wordt het nieuwe punt gefinaliseerd en, indien nodig, wordt de retentie toegepast door de VBK en de oudste incrementele te combineren. Dit mechanisme is ons al bekend.
Retentiemethode met behulp van GFS.
BCJ kan ook archiefpunten opslaan. Dit wordt ingesteld op hetzelfde tabblad Target, iets onder de instellingen voor het aantal herstelpunten:
GFS-punten kunnen op twee manieren worden aangemaakt: synthetisch, met behulp van gegevens van het secundaire repository, of door een volledige back-up na te bootsen en alle gegevens van het primaire repository te lezen (geactiveerd door de optie gemarkeerd met cijfer 3). De retentie zal in beide gevallen sterk verschillen, daarom zullen we ze apart bekijken.
Synthetische GFS.
In dit geval wordt het GFS-punt niet precies op de aangewezen dag aangemaakt. In plaats daarvan zal het GFS-punt worden aangemaakt wanneer de VIB van de dag waarvoor het GFS-punt is gepland, wordt samengevoegd met de volledige back-up. Dit kan soms tot misverstanden leiden, aangezien de tijd verstrijkt en het GFS-punt nog steeds niet is aangemaakt. Alleen de machtige sjamaan van de technische ondersteuning kan voorspellen op welke dag het punt uiteindelijk zal verschijnen. In werkelijkheid is er geen magie nodig – het is voldoende om naar het aantal ingesteld punten en het synchronisatie-interval te kijken (hoeveel punten er elke dag worden aangemaakt). Probeer zelf te berekenen aan de hand van dit voorbeeld: de taak is ingesteld om 7 punten op te slaan, het synchronisatie-interval is 12 uur (d.w.z. 2 punten per dag). Op dit moment zijn er al 7 punten in de keten, vandaag is het maandag en op deze dag is de creatie van het GFS-punt gepland. Op welke dag zal het worden aangemaakt?
Antwoord
Hier is het beter om uit te leggen hoe de keten dynamisch zal veranderen, per dag:
Op maandag wordt de laatste increment in de keten gemarkeerd als GFS, maar verder zijn er geen zichtbare veranderingen. Elke dag maakt de taak 2 nieuwe punten aan, en de retentie duwt de keten onverbiddelijk naar voren. Uiteindelijk is het op donderdag tijd om de retentie toe te passen op diezelfde increment. Deze sessie zal meer tijd kosten dan gebruikelijk, omdat de taak de benodigde blokken uit de keten 'uithaalt' en een nieuw volledig punt aanmaakt. Vanaf dat moment zijn er al 8 punten in de keten - 7 in de hoofdketen + GFS.
Het creëren van GFS-punten met de optie “Lees volledig punt”
Boven heb ik gezegd dat BCJ in een oneindig incrementeel mode werkt. Nu zullen we de enkele uitzondering op deze regel bekijken. Wanneer de optie “Lees volledig punt” is ingeschakeld, zal het GFS-punt precies op de geplande dag worden aangemaakt. De taak zelf zal in de incrementele modus draaien met periodieke volledige back-ups die we hierboven hebben behandeld. Retentie zal ook worden toegepast door het verwijderen van het oudste deel van de keten. In dit geval worden echter alleen de increments verwijderd, terwijl de volledige back-up als GFS-punt wordt bewaard. Dienovereenkomstig worden de punten gemarkeerd met GFS-vlaggen niet meegeteld bij de berekening van de retentie.
Stel dat de taak is ingesteld om 7 punten te bewaren en om wekelijks een GFS-punt op maandag aan te maken. In dat geval zal de taak elke maandag inderdaad een volledige back-up aanmaken en deze markeren als GFS. Retentie zal worden toegepast wanneer, na het verwijderen van increments uit het oudste deel, het aantal resterende increments niet onder de 7 daalt. Zo ziet dat eruit in een diagram:
Aan het einde van de tweede week zijn er in totaal 14 punten in de keten. Gedurende de tweede week heeft de taak 7 punten aangemaakt. Als dit een eenvoudige taak was, zou de retentie al zijn toegepast. Maar dit is BCJ met GFS-retentie, dus tellen we de GFS-punten niet mee, en blijven er dus maar 6 over. Dat betekent dat we de retentie nog niet kunnen toepassen. In de derde week maken we weer een volledige back-up aan met de GFS-vlag. 15 punten, maar deze tellen we weer niet mee. En tenslotte, op dinsdag van de derde week, maken we een increment aan. Nu, als we de increments van de eerste week uit de keten verwijderen, zal het totale aantal increments voldoen aan de ingestelde retentie.
Zoals hierboven al vermeld, is het in deze methode van groot belang dat volledige back-ups regelmatig worden gemaakt. Stel dat je de hoofdretentie op 7 dagen instelt, maar slechts 1 jaarlijkse versie heeft, dan is het niet moeilijk voor te stellen dat er veel meer incrementele back-ups zullen zijn dan 7. In dergelijke gevallen is het beter om de synthetische methode voor het maken van GFS te gebruiken.
En opnieuw “Verwijder verwijderde items”
Deze optie is ook aanwezig voor BCJ:
De logica van deze optie is hier hetzelfde als bij reguliere back-upopdrachten – als een machine niet binnen het opgegeven aantal dagen wordt verwerkt, worden de gegevens ervan uit de keten verwijderd. Voor BCJ is het nut van deze optie echter objectief groter, en hier is waarom.
In de normale modus werkt BCJ in een oneindig incrementele modus, dus als een machine op een gegeven moment uit de taak wordt verwijderd, zal de retentie geleidelijk alle herstelpunten verwijderen, totdat er slechts één overblijft – in VBK. Stel je voor dat de taak nu ook is ingesteld om synthetische GFS-punten te maken. Wanneer het tijd is, moet de taak GFS maken voor alle machines in de keten. Als er voor een bepaalde machine helemaal geen nieuwe punten zijn – tja, dan zal je moeten gebruikmaken van wat er is. En dat elke keer opnieuw. Uiteindelijk kan het volgende scenario zich voordoen:
Let op de sectie Bestanden: we hebben de hoofd-VBK en 2 wekelijkse GFS-punten. Kijk nu naar de sectie Herstelpunten – in feite bevatten deze bestanden hetzelfde afbeeldingsbestand van de machine. Natuurlijk heeft het geen enkele zin om dergelijke GFS-punten te hebben; ze nemen alleen maar ruimte in.
Deze situatie is alleen mogelijk bij gebruik van synthetische GFS. Om dit te voorkomen, gebruik de optie “Verwijder verwijderde items”. Vergeet alleen niet om deze optie in te stellen op een adequaat aantal dagen. De ondersteuning heeft gevallen gezien waarin de optie op een korter aantal dagen werd ingesteld dan de synchronisatie-intervallen – BCJ begon te razen en verwijderde punten voordat ze konden worden aangemaakt.
Houd er ook rekening mee dat deze optie bestaande GFS-punten niet aanraakt. Als je archieven wilt opruimen, moet je dit handmatig doen – klik met de rechtermuisknop op de machine en kies “Verwijder van schijf” (vergeet in het venster dat verschijnt niet om het vakje “Verwijder GFS volledige back-up” aan te vinken):
Nieuw in v.10 – directe kopie (immediate copy)
Nu we de ‘klassieke’ functionaliteit hebben begrepen, gaan we over op het nieuwe. Er is één nieuwe functie, maar het is een zeer belangrijke. Dit is de nieuwe werkmodus.
Er is geen begrip zoals 'sync interval', de taak zal continu controleren of er nieuwe punten zijn en deze kopiëren, ongeacht hoeveel er zijn. De taak blijft echter incrementeel, wat betekent dat zelfs als de basisopdracht een VBK of VRB maakt, deze punten worden gekopieerd als VIB. Verder zijn er in deze modus geen verrassingen - zowel standaard- als GFS-retentiemodellen werken volgens de hierboven beschreven regels (let op, hier is alleen synthetische GFS beschikbaar).
Schijven draaien. Kenmerken van repositories met roterende schijven (rotated drives)
De constante dreiging van ransomware heeft de facto de standaard beveiligingsmaatregel gemaakt dat er een kopie van gegevens op een medium aanwezig moet zijn dat het virus niet kan bereiken. Een van de opties is het gebruik van repositories met roterende schijven, waarbij schijven om de beurt worden gebruikt: terwijl één schijf is aangesloten en beschikbaar is voor schrijven, worden de andere op een veilige plaats bewaard.
Om B&R te laten werken met dergelijke repositories, moet je in de repository-instellingen, op de stap 'Repository', op de knop 'Advanced' klikken en de bijbehorende optie selecteren:
Daarna zal VBR verwachten dat de bestaande keten periodiek uit de repository verdwijnt, wat duidt op schijfrotatie. Afhankelijk van het type repository en de aard van de taak, zal B&R zich verschillend gedragen. Dit kan worden weergegeven in de onderstaande tabel:
Laten we elk optie bekijken.
Standaardtaak en Windows-repository
Dus, we hebben een taak die ketens op de eerste schijf opslaat. Bij rotatie verdwijnt de gemaakte keten feitelijk, en de taak moet een manier vinden om dit verlies te overleven. De troost komt in de vorm van het maken van een volledige back-up. Dit betekent dat elke rotatie een volledige back-up inhoudt. Maar wat gebeurt er met de punten op de uitgeschakelde schijf? Ze worden onthouden en meegeteld bij het berekenen van de retentie. Het aantal punten dat in de taak is ingesteld, is hoeveel punten er op alle schijven moeten worden bewaard. Laten we ter illustratie een voorbeeld geven:
De taak werkt in een oneindig incrementeel modus en is ingesteld om 3 herstelpunten te bewaren. Maar we hebben nog een tweede schijf, en we draaien elke week (er kunnen meer schijven zijn, dat verandert de essentie niet).
In de eerste week zal de taak punten creëren op de eerste schijf en overtollige samenvoegen. Op deze manier zal het totale aantal punten drie zijn:
Vervolgens sluiten we de tweede schijf aan. Bij het starten zal B&R merken dat de schijf is veranderd. De keten op de eerste schijf zal uit de interface verdwijnen, maar de informatie daarover blijft in de database. Nu zal de taak 3 punten op de tweede schijf bewaren. De algehele situatie zal zijn:
Tenslotte sluiten we de eerste schijf opnieuw aan. Voordat er een nieuw punt wordt aangemaakt, controleert de taak wat er met de retentie is. En de retentie, herinner ik u, is ingesteld om 3 punten te bewaren. Ondertussen hebben we 3 punten op schijf 2 (maar deze is uitgeschakeld en wordt op een veilige plaats bewaard waar B&R geen toegang toe heeft) en 3 punten op schijf 1 (en deze is aangesloten). Dit betekent dat we gerust 3 punten van schijf 1 kunnen verwijderen, aangezien ze de retentie overschrijden. Daarna maakt de taak opnieuw een volledige backup aan, en onze keten begint er zo uit te zien:
Als de retentie is ingesteld om dagen in plaats van het aantal punten op te slaan, verandert de logica niet. Bovendien wordt GFS-retentie helemaal niet ondersteund bij het gebruik van repositories met schijfrotatie.
Een gewone taak en Linux repository netwerOpslag
Zo'n optie is ook mogelijk, maar wordt over het algemeen minder aanbevolen vanwege de opgelegde beperkingen. Bij schijfrotatie en het verdwijnen van de keten zal de taak ook op dezelfde manier reageren - door het maken van een volledige backup. De beperking heeft te maken met het ingekorte retentie-mechanisme.
Hierbij wordt bij rotatie de hele keten op de uitgeschakelde schijf gewoon uit de B&R-database verwijderd. Let op - uit de database, de bestanden blijven ondertussen op de schijf. Ze kunnen worden geïmporteerd en gebruikt voor herstel, maar het is niet moeilijk te raden dat dergelijke vergeten ketens op den duur de hele repository zullen vullen.
De oplossing is het toevoegen van DWORD ForceDeleteBackupFiles zoals vermeld op deze pagina: . Daarna zal de taak gewoon alle inhoud van de taakmap of de repositorymap (afhankelijk van de waarde) bij elke rotatie gaan verwijderen.
Dit is echter geen elegante retentie, maar simpelweg het schoonmaken van de hele inhoud. Helaas heeft de klantenservice gevallen gezien waarbij de root-map van de schijf als repository was opgegeven, waar naast backups ook andere gegevens lagen. Al deze gegevens werden vernietigd tijdens de rotatie.
Bovendien, wanneer ForceDeleteBackupFiles is ingeschakeld, werkt het voor alle typen repositories, wat betekent dat zelfs repositories op Windows zullen stoppen met het toepassen van retentie en beginnen met het verwijderen van inhoud. Met andere woorden, een lokale schijf op Windows is de beste keuze voor zo'n backupsysteem.
Backup copy en Windows repository
Met BCJ wordt alles nog interessanter. Niet alleen is er een volledige retentie, maar er is ook geen volledige backup nodig bij elke schijfwissel! Het werkt als volgt:
Eerst begint B&R met het creëren van punten op de eerste schijf. Laten we zeggen dat we de retentie op 3 punten hebben ingesteld. De taak zal werken in een oneindig incrementele modus en al het overbodige samenvoegen (ik herinner eraan, GFS-retentie wordt in dit geval niet ondersteund).
Vervolgens sluiten we de tweede schijf aan. Aangezien er nog geen keten op staat, creëren we een volledige backup, waarna we een tweede keten van drie punten hebben:
Ten slotte is het tijd om de eerste schijf opnieuw aan te sluiten. En hier begint de magie, omdat de taak geen volledige backup zal maken, maar in plaats daarvan gewoon de incrementele keten zal voortzetten:
Hierdoor zal er op elke schijf een onafhankelijke keten bestaan. Daarom betekent retentie hier niet het aantal punten op alle schijven, maar het aantal punten op elke schijf afzonderlijk.
Backup copy en Linux repository netopslag
En opnieuw, de elegantie verdwijnt als de repository niet op de lokale schijf van Windows staat. Dit scenario werkt op dezelfde manier als besproken hierboven met een eenvoudige taak. Bij elke rotatie zal BCJ een volledige backup maken, en de bestaande punten zullen worden vergeten. Om niet zonder vrije ruimte te komen, moet DWORD ForceDeleteBackupFiles worden gebruikt.
Conclusie
Dus, als resultaat van deze lange tekst, hebben we twee typen taken besproken. Natuurlijk zijn er veel meer taken, maar het is niet mogelijk om ze allemaal in één artikel te behandelen. Als je na het lezen nog vragen hebt, stel die dan in de reacties, ik beantwoord ze graag persoonlijk.
Bron: habr.com
