Groeten aan onze bloglezers! We zijn er gedeeltelijk al bekend mee - mijn Engelstalige berichten zijn hier verschenen, vertaald door mijn lieve collega . Deze keer besloot ik het Russischsprekende publiek rechtstreeks toe te spreken.
Voor mijn debuut wilde ik een onderwerp vinden dat interessant zou zijn voor een zo breed mogelijk publiek en dat gedetailleerde aandacht vereist. Daniel Defoe betoogde dat de dood en belastingen ieder mens te wachten staan. Wat mij betreft kan ik zeggen dat elke ondersteuningsingenieur vragen zal hebben over het opslagbeleid voor herstelpunten (of, eenvoudiger gezegd, retentie). Ik begon vier jaar geleden uit te leggen hoe retentie werkt, als junior ingenieur op het eerste niveau, en ik blijf het nu uitleggen, al als leider van een Spaans- en Italiaanssprekend team. Ik weet zeker dat mijn collega’s uit het tweede en zelfs derde ondersteuningsniveau ook regelmatig dezelfde vragen beantwoorden.
In dit licht wilde ik een laatste, zo gedetailleerd mogelijk bericht schrijven, waar Russischsprekende gebruikers keer op keer naar terug konden keren als naslagwerk. Het moment is rijp: de onlangs uitgebrachte versie voor het tienjarig jubileum heeft nieuwe functies toegevoegd aan de basisfunctionaliteit die al jaren niet zijn veranderd. Mijn bericht is voornamelijk op deze versie gericht - hoewel het meeste van wat er is geschreven waar is voor eerdere versies, zul je daar eenvoudigweg een deel van de beschreven functionaliteit niet vinden. Ten slotte, als ik een beetje in de toekomst kijk, zal ik zeggen dat er in de volgende versie enkele veranderingen worden verwacht, maar we zullen u hierover vertellen als de tijd daar is. Dus laten we beginnen.
Back-uptaken
Laten we eerst eens kijken naar het gedeelte dat in versie 10 niet is veranderd. Het bewaarbeleid wordt bepaald door verschillende parameters. Laten we het venster openen voor het maken van een nieuwe taak en naar het tabblad Opslag gaan. Hier zien we een parameter die het gewenste aantal herstelpunten bepaalt:
Dit is echter slechts een deel van de vergelijking. Het werkelijke aantal punten wordt ook bepaald door de back-upmodus die voor de taak is ingesteld. Om deze optie te selecteren, klikt u op de knop Geavanceerd op hetzelfde tabblad. Er wordt een nieuw venster geopend met veel opties. Laten we ze nummeren en ze één voor één bekijken:
Als u alleen optie 1 inschakelt, wordt de taak uitgevoerd in de modus “forever forward incremental”. Er zijn hier geen problemen: de taak slaat het opgegeven aantal herstelpunten op vanaf een volledige back-up (bestand met de VBK-extensie) tot de laatste stap (bestand met de VIB-extensie). Wanneer het aantal punten de ingestelde waarde overschrijdt, wordt de oudste stap samengevoegd met de volledige back-up. Met andere woorden, als de taak is ingesteld om 3 punten op te slaan, zullen er onmiddellijk na de volgende sessie 4 punten in de repository staan, waarna de volledige back-up wordt samengevoegd met de oudste stap en het totale aantal punten terugkeert naar 3.
Ook het vasthouden voor de “reverse incremental” modus (optie 2) is uiterst eenvoudig. Omdat in dit geval het nieuwste punt een volledige back-up zal zijn, gevolgd door een reeks zogenaamde rollbacks (bestanden met de VRB-extensie), is het voor het toepassen van retentie voldoende om eenvoudigweg de oudste rollback te verwijderen. De situatie zal hetzelfde zijn: direct na de sessie zal het aantal punten de ingestelde waarde met 1 overschrijden, waarna het terugkeert naar de gewenste waarde.
Houd er rekening mee dat u met de reverse-incremental-modus ook periodieke volledige back-ups kunt inschakelen (optie 4), maar dit verandert niets aan de essentie. Ja, er verschijnen volledige herstelpunten in de keten, maar we verwijderen nog steeds eenvoudigweg de oudste punten één voor één.
Eindelijk komen we bij het interessante deel. Als u incrementele back-up activeert, maar bovendien optie 3 of 4 inschakelt (of beide tegelijkertijd), begint de taak met het maken van periodieke volledige back-ups met behulp van de “actieve” of synthetische methode. De methode voor het maken van een volledige back-up is niet belangrijk: deze zal dezelfde gegevens bevatten en de incrementele keten zal worden verdeeld in "subketens". Deze methode wordt forward incremental genoemd en het is deze methode die een aanzienlijk deel van de vragen bij onze klanten oproept.
Retentie wordt hier toegepast door het oudste deel van de keten te verwijderen (van een volledige back-up tot een increment). Tegelijkertijd zullen we niet alleen een volledige back-up of slechts een deel van de stappen verwijderen. De hele “subketen” wordt in één keer volledig verwijderd. De betekenis van het instellen van het aantal punten verandert ook - als dit bij andere methoden het maximaal toegestane aantal is, waarna retentie moet worden toegepast, dan bepaalt deze instelling hier het minimumaantal. Met andere woorden: na het verwijderen van de oudste “subketen” mag het aantal punten in het resterende deel niet onder dit minimum komen.
Ik zal proberen dit concept grafisch weer te geven. Laten we zeggen dat de retentie is ingesteld op 3 punten, de taak wordt elke dag uitgevoerd met een volledige back-up op maandag. Retentie wordt in dit geval toegepast wanneer het totale aantal punten 10 bereikt:
Waarom zijn er al 10 als ze er 3 ophangen? Maandag is er een volledige back-up gemaakt. Van dinsdag tot en met zondag creëerde de taak verhogingen. Tenslotte wordt er aanstaande maandag weer een volledige back-up gemaakt en pas als er 2 ophogingen zijn gemaakt kan uiteindelijk het hele oude deel van de keten worden verwijderd, want het resterende aantal punten zal niet onder de set 3 komen.
Als het idee duidelijk is, raad ik u aan om zelf de retentie te berekenen. Laten we de volgende voorwaarden nemen: de taak wordt donderdag voor het eerst gestart (uiteraard wordt er een volledige back-up gemaakt). De taak is om op woensdag en zondag een volledige back-up te maken en 8 herstelpunten op te slaan. Wanneer wordt retentie voor het eerst toegepast?
Om deze vraag te beantwoorden, raad ik u aan een vel papier te nemen, het op de dag van de week te ordenen en op te schrijven welk punt elke dag wordt gemaakt. Het antwoord zal duidelijk worden
Beantwoorden
Uitleg: om te antwoorden, hoeft u zich alleen maar de vraag te stellen: “wanneer wordt retentie toegepast”? Het antwoord is wanneer we de eerste 3 punten (VBK, VIB, VIB) kunnen verwijderen en de rest van de keten niet onder de vereiste 8 punten komt. Het wordt duidelijk dat we dit kunnen doen als we in totaal 11 punten hebben, dat wil zeggen op zondag van de tweede week.
Sommige lezers zullen misschien tegenwerpen: “Waarom dit allemaal doen als dat zo is ?. Het lijdt geen twijfel dat dit een zeer nuttig hulpmiddel is, en in sommige gevallen zou ik het gebruiken, maar het heeft ook beperkingen. Allereerst kun je de initiële voorwaarden niet specificeren, en in veel gevallen is de vraag juist: "we hebben zo'n keten, wat zal er gebeuren als we die en die instellingen veranderen?" Ten tweede is de tool nog steeds enigszins onduidelijk. Toen ik de RPS-pagina aan klanten liet zien, vond ik er geen begrip voor, maar nadat ik het had geschilderd zoals in het voorbeeld (zelfs met dezelfde Paint), dag na dag, werd alles duidelijk.
Ten slotte hebben we de optie ‘Vorige back-upketens transformeren in rollbacks’ (gemarkeerd met nummer 5) niet in overweging genomen. Deze optie brengt soms klanten in verwarring die deze “automatisch” activeren en simpelweg een synthetische back-up willen inschakelen. Ondertussen activeert deze optie een heel speciale back-upmodus. Zonder in details te treden, zeg ik meteen dat in deze fase van de productontwikkeling het ‘transformeren van eerdere back-upketens in rollbacks’ een achterhaalde optie is, en ik kan geen enkel scenario bedenken waarin dit zou moeten worden gebruikt. De waarde ervan is zo twijfelachtig dat Anton Gostev zelf enige tijd via het forum riep en vroeg hem voorbeelden te sturen van het nuttige gebruik ervan (als je die hebt, schrijf dan in de reacties, ik ben zeer geïnteresseerd). Als die er niet zijn (ik denk dat dit het geval zal zijn), dan zal de optie in toekomstige versies worden verwijderd.
De taak maakt stappen (VIB) tot de dag waarop een synthetische volledige back-up is gepland. Op deze dag wordt feitelijk een VBK aangemaakt, maar alle punten vóór deze VBK worden omgezet in rollbacks (VRB). Hierna gaat de taak door met het maken van stappen voor de volledige back-up tot de volgende synthetische back-up. Hierdoor ontstaat er in de keten een explosieve mix van VBK-, VBR- en VIB-bestanden. Retentie wordt heel eenvoudig toegepast - door de laatste VBR te verwijderen:
Problemen
Behalve dat je daadwerkelijk begrijpt hoe het werkt, houden de meeste problemen die zich voordoen bij het gebruik van de incrementele modus meestal verband met een volledige back-up. Voor deze modus zijn regelmatige volledige back-ups nodig, anders verzamelt de repository punten totdat deze vol is.
Het kan bijvoorbeeld gebeuren dat er te zelden een volledige back-up wordt gemaakt. Stel dat de taak is ingesteld om 10 punten op te slaan en dat er één keer per maand een volledige back-up wordt gemaakt. Het is duidelijk dat het werkelijke aantal punten hier aanzienlijk groter zal zijn dan het weergegeven aantal. Of de taak is over het algemeen ingesteld om in een oneindig incrementele modus te werken en 50 punten op te slaan. Vervolgens heeft iemand per ongeluk een volledige back-up gemaakt. Dat is alles, vanaf nu zal de taak wachten tot het volledige punt 49 stappen heeft verzameld, waarna retentie wordt toegepast en terugkeert naar de oneindig volledige modus.
In andere gevallen wordt er regelmatig een volledige back-up gemaakt, maar om de een of andere reden gebeurt dit niet. Ik zal hier de meest populaire reden noemen. Sommige klanten geven er de voorkeur aan de planningsoptie 'uitvoeren na' te gebruiken en taken zo te configureren dat ze in een keten worden uitgevoerd. Laten we dit voorbeeld nemen: er zijn 3 taken die elke dag worden uitgevoerd en die op zondag een volledige back-up maken. De eerste taak begint om 22.30 uur, de rest wordt in een ketting gelanceerd. Een incrementele back-up duurt 10 minuten en daarom zijn alle taken om 23.00 uur klaar. Maar een volledige backup duurt een uur, dus op zondag gebeurt het volgende: de eerste taak loopt van 22.30 tot 23.30 uur. Vervolgens van 23.30 tot 00.30 uur. Maar de derde taak begint maandag. Er is een volledige back-up ingesteld voor zondag, dus in dit geval zal dat simpelweg niet gebeuren. De taak wacht op een volledige back-up voordat de retentie wordt toegepast. Wees dus voorzichtig als u de optie “uitvoeren na” gebruikt, of gebruik deze helemaal niet. Stel de taken gewoon in om op hetzelfde tijdstip te starten en laat de resourceplanner zijn werk doen.
De moeilijke optie “Verwijderde items verwijderen”
Nadat u de instellingen van de taak Opslag – Geavanceerd – Onderhoud heeft doorlopen, kunt u de optie “gegevens verwijderde items verwijderen na” tegenkomen, die in dagen kan worden geteld.
Sommige klanten verwachten dat dit retentie is. In feite is dit een volledig aparte optie, waarvan een verkeerd begrip tot onverwachte gevolgen kan leiden. Maar eerst moeten we uitleggen hoe B&R reageert op situaties waarin tijdens een sessie slechts een paar machines met succes worden geback-upt.
Laten we ons dit scenario voorstellen: een oneindig incrementele taak die is geconfigureerd om 6 punten op te slaan. Er zijn 2 machines in de taak, van de ene is altijd een succesvolle back-up gemaakt, van de andere zijn er soms fouten opgetreden. Als gevolg hiervan ontstond bij het zevende punt de volgende situatie:
Tijd om retentie toe te passen, maar de ene auto heeft 7 punten en de andere slechts 4. Wordt hier retentie toegepast? Het antwoord is: ja, dat zal gebeuren. Als er van ten minste één object een back-up is gemaakt, gaat B&R ervan uit dat het punt is gemaakt.
Een soortgelijke situatie kan zich voordoen als een machine tijdens een bepaalde sessie eenvoudigweg niet bij de taak was betrokken. Dit gebeurt bijvoorbeeld wanneer machines niet afzonderlijk aan een taak worden toegevoegd, maar als onderdeel van containers (mappen, opslag) en een machine tijdelijk naar een andere container migreert. In dit geval wordt de taak als succesvol beschouwd, maar in de statistieken vindt u een bericht waarin u wordt gevraagd erop te letten dat die en die machine niet langer door de taak wordt verwerkt.
Wat gebeurt er als je hier geen aandacht aan besteedt? In het geval van oneindig-incrementele of omgekeerd-incrementele modi zal het aantal herstelpunten van de “probleem”-machine bij elke sessie afnemen totdat het 1 bereikt, opgeslagen in VBK. Met andere woorden: zelfs als er lange tijd geen back-up van de machine is gemaakt, blijft er nog steeds één herstelpunt over. De situatie is anders als periodieke volledige back-ups zijn ingeschakeld. Als je de signalen van B&R negeert, kan het laatste punt uiteindelijk samen met het oude deel van de keten worden verwijderd.
Nadat u deze details heeft begrepen, kunt u eindelijk de optie “Verwijderde itemgegevens verwijderen na” overwegen. Het verwijdert alle punten voor een specifieke machine als er gedurende X dagen geen back-up van die machine is gemaakt. Houd er rekening mee dat deze instelling niet reageert op fouten (heb het geprobeerd, maar het werkte niet). Er mag niet eens worden geprobeerd een back-up van de machine te maken. Het lijkt erop dat de optie nuttig is en altijd ingeschakeld moet blijven. Als de beheerder de machine uit de taak heeft verwijderd, is het na enige tijd logisch om de keten van onnodige gegevens te wissen. Maatwerk vergt echter discipline en zorgvuldigheid.
Laat me je een voorbeeld uit de praktijk geven: er zijn verschillende containers aan de taak toegevoegd, waarvan de samenstelling behoorlijk dynamisch was. Door het gebrek aan RAM ondervond de B&R-server problemen die onopgemerkt bleven. De taak startte en probeerde een back-up te maken van de machines, op één na, die op dat moment niet in de container aanwezig was. Omdat veel machines fouten genereerden, zou B&R standaard 3 extra pogingen moeten doen om een back-up te maken van de “probleem”-machines. Vanwege voortdurende problemen met RAM duurden deze pogingen enkele dagen. Er is geen herhaalde poging gedaan om een back-up te maken van de ontbrekende VM (het ontbreken van een VM is geen fout). Als gevolg hiervan werd tijdens een van de herhaalde pogingen voldaan aan de voorwaarde "Verwijderde items verwijderen" en werden alle punten op de machine verwijderd.
Wat dit betreft kan ik het volgende zeggen: als je meldingen hebt ingesteld over taakresultaten, en nog beter, gebruik maakt van de integratie met Veeam ONE, dan zal dit jou hoogstwaarschijnlijk niet overkomen. Als je één keer per week op de B&R-server kijkt om te controleren of alles werkt, kun je beter opties weigeren die mogelijk kunnen leiden tot het verwijderen van back-ups.
Wat is toegevoegd in v.10
Waar we het eerder over hadden, bestaat in B&R voor veel versies. Nu we deze werkingsprincipes hebben begrepen, gaan we nu kijken naar wat er is toegevoegd aan het jubileum "tien".
Dagelijkse retentie
Hierboven keken we naar het “klassieke” opslagbeleid op basis van het aantal punten. Een alternatieve aanpak is om in hetzelfde menu “dagen” in te stellen in plaats van “herstelpunten”.
Het idee blijkt duidelijk uit de naam: de retentie slaat een bepaald aantal dagen op, maar het aantal punten per dag doet er niet toe. In dit geval moet u het volgende onthouden:
- Bij de berekening van de retentie wordt geen rekening gehouden met de huidige dag
- Dagen waarop de taak helemaal niet werkte, worden ook meegeteld. Houd hier rekening mee om niet per ongeluk de punten te verliezen van taken die onregelmatig werken.
- Het herstelpunt wordt geteld vanaf de dag waarop het aanmaken ervan begon (dat wil zeggen: als de taak op maandag begon te werken en op dinsdag eindigde, dan is dit het punt vanaf maandag)
Anders worden de principes voor het gebruik van retentie door taken ook bepaald door de geselecteerde back-upmethode. Laten we een andere berekeningstaak proberen met dezelfde incrementele methode. Stel dat de retentie is ingesteld op 8 dagen, dan wordt de taak elke 6 uur uitgevoerd met een volledige back-up op woensdag. De taak werkt echter niet op zondag. De klus start voor het eerst op maandag. Wanneer wordt retentie toegepast?
Beantwoorden
Zoals altijd kun je het beste een bord tekenen. Ik zal mezelf toestaan de taak te vereenvoudigen en niet alle punten die voor elke dag zijn gecreëerd, te trekken, omdat het aantal punten per dag hier niet van belang is. Het is voor ons alleen belangrijk dat op de eerste maandag en op woensdag het eerste punt een volledige back-up zal zijn, maar op de resterende dagen zal de taak eenvoudigweg 4 incrementele punten creëren.
We maken duidelijk dat de retentie zal worden toegepast door de volledige back-up van maandag en de verhoging ervan te verwijderen. Wanneer zal dit gebeuren? Wanneer de rest van de keten 8 dagen bevat. Tegelijkertijd tellen we niet de huidige dag, maar integendeel, we tellen wel de zondag. Daarom is het antwoord donderdag van de tweede week.
GFS-archivering voor reguliere opdrachten
Vóór v.10 was de GFS-opslagmethode (Grandfather-Father-Son) alleen beschikbaar voor back-upkopieertaken en tapekopieertaken. Nu is het beschikbaar voor regelmatige back-up.
Hoewel dit geen verband houdt met het huidige onderwerp, kan ik niet anders dan zeggen dat de nieuwe functionaliteit geen afwijking betekent van de 3-2-1-strategie. De aanwezigheid van archiefpunten in de hoofdrepository heeft op geen enkele manier invloed op de betrouwbaarheid ervan. Het is duidelijk dat GFS zal worden gebruikt in combinatie met een Scale-out-repository om deze punten naar S3 en soortgelijke opslagplaatsen te uploaden. Als u het niet gebruikt, is het beter om primaire en archiefpunten in verschillende repository's op te slaan.
Laten we nu eens kijken naar de principes van het creëren van GFS-punten. In de taakinstellingen is bij de stap Opslag een speciale knop verschenen die het volgende menu oproept:
De essentie van GFS kan in verschillende punten worden samengevat (merk op dat GFS bij andere soorten taken anders werkt, maar daarover later meer):
- De taak maakt geen afzonderlijke volledige back-up voor het GFS-punt. In plaats daarvan wordt de meest geschikte volledige back-up gebruikt die beschikbaar is. Daarom moet de taak in incrementele modus werken met periodieke volledige back-ups, of moet er handmatig een volledige back-up door de gebruiker worden gemaakt.
- Als er slechts één periode is ingeschakeld (bijvoorbeeld een week), zal de taak aan het begin van de GFS-periode eenvoudigweg wachten op een volledige back-up en de eerste geschikte back-up markeren als GFS.
Voorbeeld: de taak is geconfigureerd om een wekelijkse GFS op te slaan met behulp van een back-up op woensdag. De taak wordt elke dag uitgevoerd, maar een volledige back-up staat gepland voor vrijdag. In dit geval begint de GFS-periode op woensdag en begint de taak te wachten op een geschikt punt. Deze verschijnt vrijdag en wordt gemarkeerd met de GFS-vlag.
- Als meerdere perioden tegelijk worden opgenomen (bijvoorbeeld wekelijks en maandelijks), zal B&R een methode gebruiken waarmee hetzelfde punt kan worden gebruikt als GFS met meerdere intervallen (om ruimte te besparen). De vlaggen worden op volgorde toegewezen, te beginnen met de jongste.
Voorbeeld: de wekelijkse GFS is ingesteld op woensdag en de maandelijkse GFS is ingesteld op de laatste week van de maand. De taak wordt elke dag uitgevoerd en er worden volledige back-ups gemaakt op maandag en vrijdag.
Laten we voor de eenvoud beginnen met tellen vanaf de voorlaatste week van de maand. Deze week wordt op maandag een volledige back-up gemaakt, maar deze wordt genegeerd omdat het wekelijkse GFS-interval op woensdag begint. Maar de volledige backup van vrijdag is helemaal 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. Het maandelijkse GFS-interval begint op maandag, maar de VBK van maandag wordt niet gemarkeerd als GFS omdat de taak probeert één VBK te markeren als zowel een maandelijks als een wekelijks GFS-punt. In dit geval begint de zoekopdracht met de wekelijkse, omdat deze per definitie ook de maandelijkse kan worden.
Als u echter alleen de wekelijkse en jaarlijkse intervallen meetelt, werken deze onafhankelijk van elkaar en kunnen twee afzonderlijke VBK's als corresponderende GFS-intervallen worden gemarkeerd.
Back-upkopieertaken
Een ander soort taak waarbij vaak verduidelijking over het werk nodig is. Laten we eerst eens kijken naar de “klassieke” werkwijze, zonder innovaties v.10
Eenvoudige retentiemethode
Standaard worden dergelijke taken uitgevoerd in de oneindige incrementele modus. Het aanmaken van punten wordt bepaald door twee parameters: het kopieerinterval en het gewenste aantal herstelpunten (er is hier geen retentie per dag). Het kopieerinterval wordt ingesteld op het eerste tabblad Taak bij het maken van een taak:
Het aantal punten wordt iets verder bepaald op het tabblad Doel
De taak creëert 1 nieuw punt voor elk interval (hoeveel punten er door de oorspronkelijke taken voor de VM zijn gecreëerd, doet er niet toe). Aan het einde van het interval wordt het nieuwe punt definitief gemaakt en wordt, indien nodig, retentie toegepast door VBK en de oudste stapgrootte te combineren. Dit mechanisme is ons al bekend.
Retentiemethode met behulp van GFS
BCJ kan ook archiefpunten opslaan. Dit wordt geconfigureerd op hetzelfde tabblad Doel, net onder de instelling voor het aantal herstelpunten:
GFS-punten kunnen op twee manieren worden aangemaakt: synthetisch, met behulp van gegevens in een secundaire opslagplaats, of door een volledige back-up te simuleren en alle gegevens uit de primaire opslagplaats te lezen (geactiveerd door de optie gemarkeerd met 3). De retentie zal in beide gevallen heel verschillend zijn, dus we zullen ze afzonderlijk bekijken.
Synthetische GFS
In dit geval wordt het GFS-punt niet precies op de afgesproken dag aangemaakt. In plaats daarvan wordt er een GFS-punt aangemaakt wanneer de VIB van de dag waarvoor het GFS-punt gepland was, wordt samengevoegd met een volledige back-up. Dit zorgt soms voor misverstanden, omdat de tijd verstrijkt en er nog steeds geen GFS-punt is. En alleen een krachtige sjamaan van de technische ondersteuning kan voorspellen op welke dag het punt zal verschijnen. In feite is magie niet nodig - kijk maar naar het ingestelde aantal punten en het synchronisatie-interval (hoeveel punten worden er elke dag gemaakt). Probeer het zelf te berekenen met behulp 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 voor deze dag staat de oprichting van een GFS-punt gepland. Op welke dag wordt het gemaakt?
Beantwoorden
Hier is het beter om te beschrijven hoe de keten in de loop van de tijd, van dag tot dag, zal veranderen:
Dus op maandag wordt de laatste stap in de keten gemarkeerd als GFS, maar er vinden geen andere zichtbare veranderingen plaats. Elke dag creëert de taak 2 nieuwe punten, en retentie brengt de keten onverbiddelijk vooruit. Eindelijk is het donderdag tijd om retentie op datzelfde bedrag toe te passen. Deze sessie zal langer duren dan normaal - omdat de taak de noodzakelijke blokken uit de keten zal "extraheren" en een nieuw compleet punt zal creëren. Vanaf dit moment zijn er al 8 punten in de keten - 7 in de hoofdketen + GFS.
GFS-punten aanmaken met de optie “Lees het hele punt”.
Hierboven zei ik dat BCJ in een oneindig incrementele modus werkt. Nu zullen we kijken naar de enige uitzondering op deze regel. Wanneer de optie “Hele punt lezen” is ingeschakeld, wordt het GFS-punt precies op de geplande dag aangemaakt. De taak zelf werkt in incrementele modus met periodieke volledige back-ups, die we hierboven hebben besproken. Retentie wordt eveneens toegepast door het oudste deel van de keten te verwijderen. In dit geval worden echter alleen de stappen verwijderd en blijft de volledige back-up als GFS-punt achter. Dienovereenkomstig worden punten gemarkeerd met GFS-vlaggen niet in aanmerking genomen bij het berekenen van de retentie.
Stel dat de taak is ingesteld om 7 punten op te slaan en op maandag een wekelijks GFS-punt te creëren. In dit geval zal de taak elke maandag daadwerkelijk een volledige back-up maken en deze markeren als GFS. Retentie wordt toegepast wanneer, na het verwijderen van de verhogingen uit het oudste deel, het aantal resterende verhogingen niet onder de 7 komt. Zo ziet het er in het diagram uit:
Dus tegen het einde van de tweede week zijn er in totaal 14 punten in de keten. Tijdens de tweede week leverde de taak 7 punten op. Als dit een eenvoudige taak was geweest, zou retentie al zijn toegepast. Maar dit is een BCJ met GFS-retentie, dus we tellen geen GFS-punten mee, wat betekent dat er maar 6 zijn. Dat wil zeggen dat we nog geen retentie kunnen toepassen. In de derde week maken we nog een volledige back-up met de GFS-vlag. 15 punten, maar ook deze tellen we niet mee. En ten slotte creëren we op dinsdag van de derde week een verhoging. Als we nu de ketenstappen van de eerste week verwijderen, zal het totale aantal stappen voldoen aan de vastgestelde retentie.
Zoals hierboven vermeld, is het bij deze methode erg belangrijk dat er regelmatig volledige back-ups worden gemaakt. Laten we zeggen dat als u de hoofdretentie instelt op 7 dagen, maar slechts op 1 jaarpunt, u zich gemakkelijk kunt voorstellen dat de verhogingen zich veel, veel meer dan 7 dagen zullen ophopen. In dergelijke gevallen is het beter om de synthetische methode van creëren te gebruiken GFS.
En nogmaals “Verwijderde items verwijderen”
Deze optie is ook aanwezig voor BCJ:
De logica van deze optie is hier hetzelfde als bij reguliere back-uptaken: als een machine het opgegeven aantal dagen niet wordt verwerkt, worden de gegevens uit de keten verwijderd. Voor BCJ is het nut van deze optie echter objectief gezien groter, en dit is de reden.
In de normale modus werkt BCJ in een oneindig incrementele modus, dus als op een gegeven moment een machine uit de taak wordt verwijderd, zal retentie geleidelijk alle herstelpunten verwijderen totdat er nog maar één over is: in VBK. Laten we ons nu voorstellen dat de taak nog steeds is geconfigureerd om synthetische GFS-punten te maken. Als de tijd daar is, zal de klus een GFS moeten creëren voor alle machines in de keten. Als een machine helemaal geen nieuwe punten heeft, dan moet je degene gebruiken die dat wel is. En dus elke keer. Als gevolg hiervan kan de volgende situatie ontstaan:
Let op de sectie Bestanden: we hebben de belangrijkste VBK- en 2 wekelijkse GFS-punten. En nu naar de sectie Herstelpunten: in feite bevatten deze bestanden dezelfde afbeelding van de machine. Dergelijke GFS-punten hebben uiteraard geen zin, ze nemen alleen ruimte in beslag.
Deze situatie is alleen mogelijk bij gebruik van synthetische GFS. Om dit te voorkomen, gebruikt u de optie “Verwijderde items verwijderen”. Vergeet niet om het in te stellen op een voldoende aantal dagen. Technische ondersteuning heeft gevallen gezien waarin de optie werd ingesteld op minder dagen dan het synchronisatie-interval. BCJ begon razend te worden en punten te verwijderen voordat ze konden worden gemaakt.
Houd er ook rekening mee dat deze optie geen invloed heeft op reeds aangemaakte GFS-punten. Als u de archieven wilt opschonen, moet u dit handmatig doen - door met de rechtermuisknop op de machine te klikken en "Verwijderen van schijf" te selecteren (vergeet in het venster dat verschijnt niet het vakje "Volledige GFS-back-up verwijderen" aan te vinken) :
Innovatie v.10 – onmiddellijke kopie
Nadat we de “klassieke” functionaliteit hebben behandeld, gaan we verder met de nieuwe. Er is één innovatie, maar wel een heel belangrijke. Dit is een nieuwe manier van werken.
Er bestaat niet zoiets als een “synchronisatie-interval”; de taak zal voortdurend controleren of er nieuwe punten zijn verschenen en deze allemaal kopiëren, ongeacht hoeveel er zijn. Maar tegelijkertijd blijft de taak incrementeel, dat wil zeggen dat zelfs als de hoofdtaak een VBK of VRB creëert, deze punten als VIB zullen worden gekopieerd. Anders zijn er geen verrassingen in deze modus: zowel standaard- als GFS-retentie werken volgens de hierboven beschreven regels (hier is echter alleen synthetische GFS beschikbaar).
Schijven draaien. Kenmerken van opslagplaatsen met geroteerde schijven
Door de constante dreiging van ransomware-virussen is het de facto een beveiligingsstandaard geworden om een kopie van gegevens op een medium te hebben waar het virus niet kan komen. Eén optie is het gebruik van opslagplaatsen voor schijfrotatie, waarbij schijven één voor één worden gebruikt: terwijl één schijf is aangesloten en beschrijfbaar is, wordt de rest op een veilige locatie opgeslagen.
Om B&R te leren werken met dergelijke repositories, klikt u op de knop Geavanceerd in de repository-instellingen, bij de Repository-stap, en selecteert u de juiste optie:
Hierna verwacht VBR dat de bestaande keten periodiek uit de repository zal verdwijnen, wat schijfrotatie betekent. Afhankelijk van het type repository en het type taak zal B&R zich anders gedragen. Dit kan worden weergegeven met de volgende tabel:
Laten we elke optie overwegen.
Normale taak en Windows-repository
We hebben dus een taak die ketens op de eerste schijf opslaat. Tijdens de rotatie verdwijnt de gecreëerde keten feitelijk en moet de taak dit verlies op de een of andere manier overleven. Ze vindt troost in het maken van een volledige back-up. Elke rotatie betekent dus een volledige back-up. Maar wat gebeurt er met de punten op de losgekoppelde schijf? Ze worden onthouden en er wordt rekening mee gehouden bij de berekening van de retentie. Het ingestelde aantal punten in een taak is dus het aantal punten dat op alle schijven moet worden bewaard. Hier is een voorbeeld:
De taak wordt uitgevoerd in een oneindige incrementele modus en is geconfigureerd om 3 herstelpunten op te slaan. Maar we hebben ook een tweede schijf, en deze draaien we één keer per week (er kunnen meer schijven zijn, dit verandert niets aan de essentie).
In de eerste week creëert de taak punten op de eerste schijf en voegt de extra punten samen. Het totale aantal punten is dus gelijk aan drie:
Vervolgens verbinden we de tweede schijf. Bij het opstarten zal B&R merken dat de schijf is vervangen. De keten op de eerste schijf verdwijnt uit de interface, maar informatie daarover blijft in de database. Nu behoudt de taak 3 punten op de tweede schijf. De algemene situatie zal als volgt zijn:
Ten slotte sluiten we de eerste schijf opnieuw aan. Voordat een nieuw punt wordt aangemaakt, controleert de taak wat er met de retentie gebeurt. En ik herinner u eraan dat de retentie 3 punten zal opleveren. Ondertussen hebben we 3 punten op schijf 2 (maar deze is losgekoppeld en opgeslagen op een veilige plek waar B&R niet bij kan) en 3 punten op schijf 1 (maar deze is wel aangesloten). Dit betekent dat we veilig 3 punten van schijf 1 kunnen verwijderen, aangezien deze de retentie overschrijden. Daarna maakt de taak weer een volledige back-up en begint onze keten er als volgt uit te zien:
Als retentie is geconfigureerd om dagen op te slaan in plaats van het aantal punten, verandert de logica niet. Bovendien wordt GFS-retentie helemaal niet ondersteund bij het gebruik van opslagplaatsen met schijfrotatie.
Reguliere taak- en Linux-repository-netwerkopslag
Deze optie is ook mogelijk, maar wordt over het algemeen minder aanbevolen vanwege de opgelegde beperkingen. De taak zal op dezelfde manier reageren op schijfrotatie en het verdwijnen van de keten: door een volledige back-up te maken. De beperking is te wijten aan het cut-off-retentiemechanisme.
Hierbij wordt tijdens rotatie de gehele keten op de losgekoppelde schijf eenvoudigweg uit de B&R database verwijderd. Houd er rekening mee dat vanuit de database de bestanden zelf op de schijf blijven staan. Ze kunnen worden geïmporteerd en gebruikt voor herstel, maar het is gemakkelijk te raden dat dergelijke vergeten ketens vroeg of laat de hele opslagplaats zullen vullen.
De oplossing is om DWORD ForceDeleteBackupFiles toe te voegen zoals aangegeven op deze pagina: . De taak begint dan bij elke rotatie eenvoudigweg de volledige inhoud van de taakmap of repositorymap (afhankelijk van de waarde) te verwijderen.
Dit is echter geen elegante retentie, maar eerder een reiniging van de volledige inhoud. Helaas kwam de technische ondersteuning gevallen tegen waarin de repository eenvoudigweg de hoofdmap van de schijf was, waar naast back-ups ook andere gegevens zich bevonden. Dit alles werd tijdens de rotatie vernietigd.
Als ForceDeleteBackupFiles is ingeschakeld, werkt het bovendien voor alle soorten opslagplaatsen, dat wil zeggen dat zelfs opslagplaatsen op Windows 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 een dergelijk back-upopslagsysteem.
Back-upkopie en Windows-repository
Met BCJ wordt het nog interessanter. Het biedt niet alleen volledige retentie, maar het is ook niet nodig om elke keer dat u van schijf wisselt een volledige back-up te maken! 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 instellen. De taak werkt in een oneindig incrementele modus en voegt al het onnodige samen (ik herinner u eraan dat GFS-retentie in dit geval niet wordt ondersteund).
Vervolgens verbinden we de tweede schijf. Omdat er nog geen ketting op zit, maken we een volledige back-up, waarna we een tweede ketting van drie punten hebben:
Eindelijk is het tijd om de eerste schijf opnieuw aan te sluiten. En dit is waar de magie begint, aangezien de taak geen volledige back-up zal maken, maar in plaats daarvan eenvoudigweg de incrementele keten zal voortzetten:
Hierna heeft vrijwel elke schijf zijn eigen onafhankelijke keten. Retentie betekent hier dus niet het aantal punten op alle schijven, maar het aantal punten op elke schijf afzonderlijk.
Back-upkopie en Linux-repositorynetwerkopslag
Nogmaals, alle elegantie gaat verloren als de repository zich niet op een lokaal Windows-station bevindt. Dit script werkt op dezelfde manier als het hierboven besproken script met een eenvoudige taak. Bij elke rotatie maakt BCJ een volledige back-up en worden bestaande punten vergeten. Om te voorkomen dat u onvoldoende vrije ruimte krijgt, moet u DWORD ForceDeleteBackupFiles gebruiken.
Conclusie
Dus als resultaat van zo'n lange tekst hebben we naar twee soorten taken gekeken. Natuurlijk zijn er nog veel meer taken, maar het zal niet mogelijk zijn om ze allemaal in de vorm van één artikel te beschouwen. Als je na het lezen nog vragen hebt, schrijf ze dan in de reacties, ik beantwoord ze graag persoonlijk.
Bron: www.habr.com