Hilsen våre blogglesere! Vi er delvis allerede kjent - mine engelskspråklige innlegg dukket opp her oversatt av min kjære kollega . Denne gangen bestemte jeg meg for å henvende meg direkte til det russisktalende publikummet.
Til debuten min ønsket jeg å finne et emne som ville være interessant for et bredest mulig publikum og som krever detaljert vurdering. Daniel Defoe hevdet at døden og skatter venter på hver person. For min del kan jeg si at enhver støttetekniker vil ha spørsmål om retningslinjer for lagring av gjenopprettingspunkter (eller, rett og slett, oppbevaring). Jeg begynte å forklare hvordan retensjon fungerer for 4 år siden, som junioringeniør på første nivå, og jeg fortsetter å forklare nå, allerede som leder for et spansk- og italiensktalende team. Jeg er sikker på at mine kolleger fra andre og til og med tredje nivå av støtte også jevnlig svarer på de samme spørsmålene.
I dette lyset ønsket jeg å skrive et siste, så detaljert innlegg som mulig, som russisktalende brukere kunne komme tilbake til igjen og igjen som en oppslagsbok. Øyeblikket er rett - den nylig utgitte tiårsjubileumsversjonen la til nye funksjoner til den grunnleggende funksjonaliteten som ikke hadde endret seg på flere år. Innlegget mitt er først og fremst fokusert på denne versjonen - selv om det meste av det som er skrevet er sant for tidligere versjoner, vil du rett og slett ikke finne noe av den beskrevne funksjonaliteten der. Til slutt, ser jeg litt inn i fremtiden, vil jeg si at det forventes noen endringer i neste versjon, men vi vil fortelle deg om dette når den tid kommer. Så la oss komme i gang.
Backup jobber
La oss først se på delen som ikke er endret i versjon 10. Oppbevaringspolicyen bestemmes av flere parametere. La oss åpne vinduet for å lage en ny oppgave og gå til fanen Lagring. Her vil vi se en parameter som bestemmer ønsket antall gjenopprettingspunkter:
Dette er imidlertid bare en del av ligningen. Det faktiske antallet poeng bestemmes også av sikkerhetskopieringsmodusen som er angitt for jobben. For å velge dette alternativet, klikk på Avansert-knappen på samme fane. Dette vil åpne et nytt vindu med mange alternativer. La oss nummerere dem og vurdere dem én etter én:
Hvis du bare aktiverer alternativ 1, vil jobben kjøre i "forever forward incremental"-modus. Det er ingen problemer her - oppgaven vil lagre det angitte antall gjenopprettingspunkter fra en fullstendig sikkerhetskopi (fil med VBK-utvidelsen) til siste inkrement (fil med VIB-utvidelsen). Når antall poeng overskrider den angitte verdien, vil den eldste økningen slås sammen med den fullstendige sikkerhetskopien. Med andre ord, hvis oppgaven er satt til å lagre 3 punkter, vil det umiddelbart etter neste økt være 4 punkter på depotet, hvoretter den fullstendige sikkerhetskopien vil bli slått sammen med det eldste inkrementet og det totale antallet punkter vil gå tilbake til 3.
Oppbevaringen for "revers inkrementell"-modus (alternativ 2) er også ekstremt enkel. Siden det nyeste punktet i dette tilfellet vil være en fullstendig sikkerhetskopi, etterfulgt av en kjede av såkalte tilbakeføringer (filer med VRB-utvidelsen), er det nok å slette den eldste tilbakeføringen for å bruke oppbevaring. Situasjonen vil være den samme: umiddelbart etter økten vil antall poeng overstige den innstilte verdien med 1, hvoretter det går tilbake til ønsket verdi.
Vær oppmerksom på at med omvendt inkrementell modus kan du også aktivere periodiske fullstendige sikkerhetskopier (alternativ 4), men dette vil ikke endre essensen. Ja, komplette gjenopprettingspunkter vil vises i kjeden, men vi sletter fortsatt de eldste punktene én etter én.
Til slutt kommer vi til den interessante delen. Hvis du aktiverer inkrementell sikkerhetskopiering, men i tillegg aktiverer alternativ 3 eller 4 (eller begge samtidig), vil oppgaven begynne å lage periodiske fullstendige sikkerhetskopier ved å bruke den "aktive" eller syntetiske metoden. Metoden for å lage en fullstendig sikkerhetskopi er ikke viktig - den vil inneholde de samme dataene, og den inkrementelle kjeden vil bli delt inn i "underkjeder". Denne metoden kalles forward incremental, og det er denne metoden som reiser en betydelig del av spørsmålene fra våre kunder.
Oppbevaring brukes her ved å slette den eldste delen av kjeden (fra en fullstendig sikkerhetskopi til en inkrement). Samtidig vil vi ikke slette bare en fullstendig sikkerhetskopi eller bare deler av trinnene. Hele "underkjeden" fjernes helt på en gang. Betydningen av å angi antall poeng endres også - hvis i andre metoder dette er det maksimalt tillatte antallet, hvoretter oppbevaring må brukes, så bestemmer denne innstillingen minimum antall. Med andre ord, etter å ha fjernet den eldste "underkjeden", skal antall poeng i den gjenværende delen ikke falle under dette minimum.
Jeg skal prøve å skildre dette konseptet grafisk. La oss si at oppbevaringen er satt til 3 poeng, oppgaven kjører hver dag med full sikkerhetskopi på mandag. Oppbevaring i dette tilfellet vil bli brukt når det totale antallet poeng når 10:
Hvorfor er det allerede 10 når de legger opp 3? En fullstendig sikkerhetskopi ble opprettet på mandag. Fra tirsdag til søndag skapte jobben inkrementer. Til slutt, neste mandag opprettes en fullstendig sikkerhetskopi igjen og først når 2 inkrementer er opprettet kan endelig hele den gamle delen av kjeden slettes, fordi det gjenværende antall poeng ikke vil falle under settet 3.
Hvis ideen er klar, foreslår jeg at du prøver å beregne retensjon selv. La oss ta følgende forhold: oppgaven lanseres for første gang på torsdag (naturligvis vil en fullstendig sikkerhetskopi bli laget). Oppgaven er satt til å lage en fullstendig sikkerhetskopi på onsdager og søndager og lagre 8 gjenopprettingspunkter. Når vil oppbevaring bli brukt for første gang?
For å svare på dette spørsmålet anbefaler jeg at du tar et stykke papir, stiller det opp etter ukedag og skriver ned hvilket punkt som opprettes hver dag. Svaret vil bli åpenbart
svar
Forklaring: For å svare, spør deg selv "når vil oppbevaring bli brukt"? Svaret er når vi kan fjerne de første 3 poengene (VBK, VIB, VIB) og resten av kjeden ikke faller under de nødvendige 8 poengene. Det blir klart at vi skal klare dette når vi har 11 poeng totalt, altså på søndag i andre uke.
Noen lesere kan innvende: "hvorfor gjøre alt dette hvis det er det ?. Det er ingen tvil om at dette er et veldig nyttig verktøy, og i noen tilfeller ville jeg brukt det, men det har også begrensninger. For det første tillater det deg ikke å spesifisere startbetingelsene, og i mange tilfeller er spørsmålet nettopp "vi har en slik kjede, hva vil skje hvis vi endrer slike og slike innstillinger?" For det andre mangler verktøyet fortsatt noe klarhet. Da jeg viste RPS-siden til klienter, fant jeg ingen forståelse, men etter å ha malt den som i eksemplet (til og med med samme maling), dag etter dag, ble alt klart.
Til slutt vurderte vi ikke alternativet "Transformer tidligere sikkerhetskopikjeder til tilbakeføringer" (merket med nummer 5). Dette alternativet forvirrer noen ganger klienter som aktiverer det "automatisk", som bare ønsker å aktivere en syntetisk sikkerhetskopi. I mellomtiden aktiverer dette alternativet en veldig spesiell sikkerhetskopimodus. Uten å gå inn på detaljer, vil jeg si med en gang at på dette stadiet av produktutviklingen er "Transformer tidligere sikkerhetskopikjeder til tilbakeføringer" et utdatert alternativ, og jeg kan ikke tenke på et enkelt scenario når det skal brukes. Verdien er så tvilsom at Anton Gostev selv ringte gjennom forumet i noen tid og ba om å sende ham eksempler på dens nyttige bruk (hvis du har dem, skriv i kommentarene, jeg er veldig interessert). Hvis det ikke er noen (jeg tror dette vil være tilfelle), vil alternativet bli fjernet i fremtidige versjoner.
Oppgaven vil lage inkrementer (VIB) frem til dagen da en syntetisk full backup er planlagt. På denne dagen blir det faktisk opprettet en VBK, men alle punkter før denne VBK blir omgjort til tilbakeføringer (VRB). Etter dette vil oppgaven fortsette å lage trinn til den fullstendige sikkerhetskopien til neste syntetiske sikkerhetskopi. Som et resultat dannes det en eksplosiv blanding av VBK-, VBR- og VIB-filer i kjeden. Oppbevaring brukes veldig enkelt - ved å fjerne den siste VBR:
Problemer
Bortsett fra å faktisk forstå hvordan det fungerer, er de fleste problemene som oppstår ved bruk av inkrementell modus vanligvis forbundet med en full sikkerhetskopi. Regelmessig full sikkerhetskopiering er nødvendig for denne modusen, ellers vil depotet samle poeng til det er fullt.
For eksempel kan en fullstendig sikkerhetskopi lages for sjelden. La oss si at oppgaven er satt til å lagre 10 poeng, og en full sikkerhetskopi lages en gang i måneden. Det er klart at det faktiske antall poeng her vil være betydelig større enn det som vises. Eller oppgaven er vanligvis satt til å fungere i uendelig inkrementell modus og lagre 50 poeng. Så opprettet noen ved et uhell en fullstendig sikkerhetskopi. Det er det, fra nå av vil oppgaven vente til det fulle punktet har samlet seg 49 trinn, hvoretter den vil bruke oppbevaring og gå tilbake til uendelig full modus.
I andre tilfeller er en fullstendig sikkerhetskopi satt til å opprettes regelmessig, men av en eller annen grunn gjør den det ikke. Jeg vil liste opp den mest populære grunnen her. Noen klienter foretrekker å bruke "kjør etter"-planleggingsalternativet og konfigurere jobber til å kjøre i en kjede. La oss ta dette eksemplet: det er 3 jobber som kjører hver dag og oppretter en fullstendig sikkerhetskopi på søndag. Første oppgave starter 22.30, resten lanseres i kjede. En inkrementell backup tar 10 minutter, og derfor er alle jobber ferdige innen kl. 23.00. Men en full backup tar en time, så på søndag skjer følgende: den første oppgaven går fra 22.30 til 23.30. Neste fra 23.30 til 00.30. Men den tredje oppgaven starter på mandag. En full sikkerhetskopi er satt til søndag, så i dette tilfellet vil det rett og slett ikke skje. Oppgaven vil vente på en fullstendig sikkerhetskopi for å bruke oppbevaringen. Så vær forsiktig når du bruker alternativet "kjør etter" eller ikke bruk det i det hele tatt - bare still jobbene til å starte samtidig og la ressursplanleggeren gjøre jobben sin.
Det vanskelige alternativet "Fjern slettede elementer"
Etter å ha gått gjennom innstillingene for oppgaven Lagring – Avansert – Vedlikehold, kan du komme over alternativet "fjern slettede elementdata etter", som kan telles i dager.
Noen kunder forventer at dette er oppbevaring. Faktisk er dette et helt eget alternativ, hvis misforståelse kan føre til uventede konsekvenser. Men først av alt må vi forklare hvordan B&R reagerer på situasjoner der bare noen få maskiner blir sikkerhetskopiert i løpet av en økt.
La oss forestille oss dette scenariet: en uendelig inkrementell jobb konfigurert til å lagre 6 poeng. Det er 2 maskiner i oppgaven, den ene sikkerhetskopieret alltid vellykket, den andre ga noen ganger feil. Som et resultat, ved det syvende punktet oppsto følgende situasjon:
På tide å søke oppbevaring, men den ene bilen har 7 poeng, og den andre kun 4. Vil oppbevaring bli brukt her? Svaret er ja, det vil det. Hvis minst ett objekt er sikkerhetskopiert, anser B&R at punktet er opprettet.
En lignende situasjon kan oppstå hvis en maskin rett og slett ikke ble inkludert i oppgaven under en bestemt økt. Dette skjer for eksempel når maskiner legges til en oppgave ikke individuelt, men som en del av beholdere (mapper, lagring) og noen maskiner midlertidig migrerer til en annen beholder. I dette tilfellet vil oppgaven anses som vellykket, men i statistikken finner du en melding som ber deg være oppmerksom på at en slik og en maskin ikke lenger behandles av oppgaven.
Hva vil skje hvis du ikke tar hensyn til dette? I tilfelle av uendelig-inkrementelle eller omvendt-inkrementelle moduser, vil antall gjenopprettingspunkter for "problem"-maskinen reduseres med hver økt til den når 1, lagret i VBK. Med andre ord, selv om maskinen ikke er sikkerhetskopiert på lang tid, vil det fortsatt være ett gjenopprettingspunkt. Situasjonen er annerledes hvis periodiske fullstendige sikkerhetskopier er aktivert. Hvis du ignorerer signalene fra B&R, kan det siste punktet til slutt bli slettet sammen med den gamle delen av kjeden.
Etter å ha forstått disse detaljene, kan du endelig vurdere alternativet "Fjern slettede elementer etter". Det vil slette alle poeng for en bestemt maskin hvis den maskinen ikke er sikkerhetskopiert på X dager. Vær oppmerksom på at denne innstillingen ikke reagerer på feil (prøvde det, men det fungerte ikke). Det bør ikke engang være et forsøk på å sikkerhetskopiere maskinen. Det ser ut til at alternativet er nyttig og bør alltid holdes aktivert. Hvis administratoren fjernet maskinen fra oppgaven, er det etter en stund logisk å fjerne kjeden for unødvendige data. Tilpasning krever imidlertid disiplin og omsorg.
La meg gi deg et eksempel fra praksis: flere beholdere ble lagt til oppgaven, hvis sammensetning var ganske dynamisk. På grunn av mangelen på RAM, opplevde B&R-serveren problemer som ikke ble oppdaget. Oppgaven startet og forsøkte å ta en sikkerhetskopi av maskinene, bortsett fra en, som på det tidspunktet ikke var til stede i containeren. Siden mange maskiner genererte feil, bør B&R som standard gjøre 3 ekstra forsøk på å sikkerhetskopiere "problem"-maskinene. På grunn av konstante problemer med RAM, varte disse forsøkene i flere dager. Det var ingen gjentatte forsøk på å lage en sikkerhetskopi av den manglende VM (fraværet av en VM er ikke en feil). Som et resultat, under ett av de gjentatte forsøkene, ble betingelsen "Fjern slettede elementer" oppfylt og alle punktene på maskinen ble slettet.
Angående dette kan jeg si følgende: hvis du har satt opp varsler om oppgaveresultater, og enda bedre, bruk integrasjon med Veeam ONE, så vil dette mest sannsynlig ikke skje med deg. Hvis du ser på B&R-serveren en gang i uken for å sjekke at alt fungerer, er det bedre å nekte alternativer som potensielt kan føre til sletting av sikkerhetskopier.
Hva er lagt til i v.10
Det vi snakket om før har eksistert i B&R i mange versjoner. Etter å ha forstått disse driftsprinsippene, la oss nå se på hva som er lagt til jubileet "ti".
Daglig oppbevaring
Ovenfor så vi på den "klassiske" lagringspolicyen basert på antall poeng. En alternativ tilnærming er å angi "dager" i stedet for "gjenopprettingspunkter" i samme meny.
Tanken er tydelig fra navnet - oppbevaringen vil lagre et bestemt antall dager, men antall poeng i hver dag spiller ingen rolle. I dette tilfellet må du huske følgende:
- Gjeldende dag er ikke tatt i betraktning ved beregning av tilbakehold
- Dager da oppgaven ikke fungerte i det hele tatt telles også. Dette bør huskes for ikke å miste poengene til de oppgavene som fungerer uregelmessig.
- Gjenopprettingspunktet regnes fra dagen da opprettelsen begynte (dvs. hvis oppgaven begynte å fungere på mandag og avsluttet på tirsdag, så er dette punktet fra mandag)
Ellers er prinsippene for bruk av oppbevaring av oppgaver også bestemt av den valgte sikkerhetskopieringsmetoden. La oss prøve en annen beregningsoppgave ved å bruke samme inkrementelle metode. La oss si at oppbevaringen er satt til 8 dager, oppgaven kjører hver 6. time med full backup på onsdag. Oppgaven fungerer imidlertid ikke på søndag. Jobben går på mandag for første gang. Når vil oppbevaring bli brukt?
svar
Som alltid er det best å tegne et skilt. Jeg vil tillate meg å forenkle oppgaven og vil ikke trekke alle poengene som er opprettet for hver dag, fordi antall poeng per dag spiller ingen rolle her. Det er bare viktig for oss at den første mandagen og på onsdager vil det første punktet være en fullstendig sikkerhetskopi, men på de resterende dagene vil oppgaven ganske enkelt opprette 4 inkrementelle poeng.
Vi gjør det klart at oppbevaringen vil bli brukt ved å slette mandagens fullstendige sikkerhetskopi og dens økning. Når vil dette skje? Når resten av kjeden inneholder 8 dager. Samtidig teller vi ikke dagens dag, men tvert imot teller vi søndagen. Derfor er svaret torsdag den andre uken.
GFS arkivering for vanlige jobber
Før v.10 var lagringsmetoden bestefar-far-sønn (GFS) bare tilgjengelig for sikkerhetskopieringsjobber og tapekopijobber. Nå er den tilgjengelig for vanlig sikkerhetskopiering.
Selv om dette ikke er relatert til det aktuelle emnet, kan jeg ikke la være å si at den nye funksjonaliteten ikke betyr en avvik fra 3-2-1-strategien. Tilstedeværelsen av arkivpunkter i hovedlageret påvirker ikke på noen måte påliteligheten. Det er underforstått at GFS vil bli brukt i forbindelse med et Scale-out-lager for å laste opp disse punktene til S3 og lignende lagringer. Hvis du ikke bruker det, er det bedre å fortsette å lagre primær- og arkivpunkter i forskjellige depoter.
La oss nå se på prinsippene for å lage GFS-poeng. I oppgaveinnstillingene, på Lagringstrinnet, har det dukket opp en spesiell knapp som henter frem følgende meny:
Essensen av GFS kan kokes ned til flere punkter (merk at GFS fungerer annerledes i andre typer oppgaver, men mer om det senere):
- Oppgaven oppretter ikke en separat fullstendig sikkerhetskopi for GFS-punktet. I stedet vil den mest passende fullstendige sikkerhetskopien som er tilgjengelig, brukes. Derfor må oppgaven fungere i inkrementell modus med periodiske full backup, eller en full backup må opprettes manuelt av brukeren.
- Hvis bare én periode er aktivert (for eksempel en uke), vil oppgaven i begynnelsen av GFS-perioden ganske enkelt begynne å vente på en fullstendig sikkerhetskopi og merke den første passende som GFS.
Eksempel: jobben er konfigurert til å lagre en ukentlig GFS ved hjelp av en sikkerhetskopi på onsdag. Oppgaven kjører hver dag, men en full backup er planlagt på fredag. I dette tilfellet vil GFS-perioden begynne på onsdag og oppgaven vil begynne å vente på et passende punkt. Den kommer på fredag og vil merkes med GFS-flagget.
- Hvis flere perioder er inkludert på en gang (for eksempel ukentlig og månedlig), vil B&R bruke en metode som gjør at samme punkt kan brukes som GFS med flere intervaller (for å spare plass). Flagg vil bli tildelt i rekkefølge, og starter med de yngste.
Eksempel: ukentlig GFS er satt til onsdag, og månedlig GFS er satt til siste uke i måneden. Oppgaven kjører hver dag og lager fulle sikkerhetskopier på mandager og fredager.
For enkelhets skyld, la oss begynne å telle fra den nest siste uken i måneden. Denne uken opprettes en fullstendig sikkerhetskopi på mandag, men den vil bli ignorert fordi det ukentlige GFS-intervallet starter på onsdag. Men fredagens full backup er helt egnet for GFS-punktet. Dette systemet er allerede kjent for oss.
La oss nå se på hva som skjer den siste uken i måneden. Det månedlige GFS-intervallet starter på mandag, men mandagens VBK vil ikke merkes som GFS fordi jobben søker å markere én VBK som både månedlig og ukentlig GFS-poeng. I dette tilfellet begynner søket med det ukentlige, fordi det per definisjon også kan bli det månedlige.
Men hvis du bare inkluderer de ukentlige og årlige intervallene, vil de opptre uavhengig av hverandre og kan markere 2 separate VBK-er som tilsvarende GFS-intervaller.
Sikkerhetskopieringsoppgaver
En annen type oppgave som ofte krever avklaring rundt arbeidet. La oss først se på den "klassiske" arbeidsmetoden, uten innovasjoner v.10
Enkel oppbevaringsmetode
Som standard kjører slike jobber i uendelig inkrementell modus. Opprettelsen av poeng bestemmes av to parametere - kopieringsintervallet og ønsket antall gjenopprettingspunkter (det er ingen oppbevaring per dag her). Kopieringsintervallet angis på den første jobbfanen når du oppretter en jobb:
Antall poeng bestemmes litt lenger på fanen Mål
Oppgaven oppretter 1 nytt poeng for hvert intervall (hvor mange poeng som ble opprettet for VM av de opprinnelige oppgavene spiller ingen rolle). På slutten av intervallet avsluttes det nye punktet, og om nødvendig påføres retensjon ved å kombinere VBK og det eldste inkrementet. Denne mekanismen er allerede kjent for oss.
Oppbevaringsmetode ved bruk av GFS
BCJ kan også lagre arkivpunkter. Dette er konfigurert i den samme Target-fanen, rett under innstillingen for antall gjenopprettingspunkter:
GFS-punkter kan opprettes på to måter - syntetisk, ved å bruke data på et sekundært depot, eller ved å simulere en full sikkerhetskopi og lese alle data fra det primære depotet (aktivert av alternativet merket 3). Oppbevaring i begge tilfeller vil være svært forskjellig, så vi vil vurdere dem separat.
Syntetisk GFS
I dette tilfellet opprettes ikke GFS-punktet nøyaktig på den fastsatte dagen. I stedet vil et GFS-punkt opprettes når VIB-en for dagen som GFS-punktet skulle opprettes for, slås sammen med en full sikkerhetskopi. Dette forårsaker noen ganger misforståelser, fordi tiden går og det fortsatt ikke er noe GFS-punkt. Og bare en mektig sjaman fra teknisk støtte kan forutsi hvilken dag punktet vil dukke opp. Faktisk er magi ikke nødvendig - bare se på det angitte antall poeng og synkroniseringsintervallet (hvor mange poeng som opprettes hver dag). Prøv å beregne det selv ved å bruke dette eksemplet: oppgaven er satt til å lagre 7 poeng, synkroniseringsintervallet er 12 timer (dvs. 2 poeng per dag). For øyeblikket er det allerede 7 poeng i kjeden, i dag er det mandag, og opprettelsen av et GFS-punkt er planlagt denne dagen. På hvilken dag vil det bli opprettet?
svar
Her er det bedre å beskrive hvordan kjeden vil endre seg over tid, dag for dag:
Så på mandag er siste inkrement i kjeden merket som GFS, men ingen andre synlige endringer skjer. Hver dag skaper oppgaven 2 nye poeng, og oppbevaring flytter ubønnhørlig kjeden fremover. Til slutt, på torsdag er tiden inne for å bruke oppbevaring på selve inkrementet. Denne økten vil ta lengre tid enn vanlig - fordi oppgaven vil "pakke ut" de nødvendige blokkene fra kjeden og skape et nytt komplett punkt. Fra dette øyeblikket vil det allerede være 8 poeng i kjeden - 7 i hovedkjeden + GFS.
Opprette GFS-punkter med alternativet "Les hele punktet".
Ovenfor sa jeg at BCJ opererer i uendelig inkrementell modus. Nå skal vi se på det eneste unntaket fra denne regelen. Når alternativet "Les hele punktet" er aktivert, vil GFS-punktet opprettes nøyaktig på den planlagte dagen. Selve oppgaven vil fungere i inkrementell modus med periodiske fulle sikkerhetskopier, som vi diskuterte ovenfor. Retensjon vil også bli brukt ved å fjerne den eldste delen av kjeden. Men i dette tilfellet vil bare inkrementene bli slettet, og den fullstendige sikkerhetskopien vil bli stående som et GFS-punkt. Følgelig blir ikke punkter merket med GFS-flagg tatt i betraktning ved beregning av retensjon.
La oss si at oppgaven er satt til å lagre 7 poeng og opprette et ukentlig GFS-punkt på mandag. I dette tilfellet vil oppgaven hver mandag faktisk lage en fullstendig sikkerhetskopi og merke den som GFS. Retensjon vil bli brukt når, etter fjerning av inkrementer fra den eldste delen, antall gjenværende inkrementer ikke faller under 7. Slik ser det ut i diagrammet:
Så ved slutten av den andre uken er det totalt 14 poeng i kjeden. I løpet av den andre uken skapte oppgaven 7 poeng. Hvis dette var en enkel oppgave, ville oppbevaring allerede blitt brukt. Men dette er en BCJ med GFS-oppbevaring, så vi teller ikke GFS-poeng, noe som betyr at det bare er 6 av dem. Det vil si at vi ikke kan bruke oppbevaring ennå. I den tredje uken lager vi en annen fullstendig sikkerhetskopi med GFS-flagget. 15 poeng, men igjen teller vi ikke denne. Og til slutt, tirsdag i den tredje uken, oppretter vi en økning. Nå, hvis vi fjerner kjedetilvekstene fra den første uken, vil det totale antallet inkrementer tilfredsstille den etablerte oppbevaringen.
Som nevnt ovenfor, i denne metoden er det svært viktig at fullstendige sikkerhetskopier opprettes regelmessig. La oss si at hvis du angir hovedoppbevaringen i 7 dager, men bare 1 årlig poeng, er det lett å forestille seg at inkrementene vil samle seg mye, mye mer enn 7. I slike tilfeller er det bedre å bruke den syntetiske metoden for å lage GFS.
Og igjen "Fjern slettede elementer"
Dette alternativet er også til stede for BCJ:
Logikken til dette alternativet her er den samme som i vanlige sikkerhetskopieringsoppgaver - hvis en maskin ikke behandles i det angitte antall dager, slettes dataene fra kjeden. For BCJ er imidlertid nytten av dette alternativet objektivt sett høyere, og her er hvorfor.
I normal modus opererer BCJ i en uendelig inkrementell modus, så hvis en maskin på et tidspunkt fjernes fra jobben, vil oppbevaring gradvis slette alle gjenopprettingspunkter til det bare er ett igjen - i VBK. La oss nå forestille oss at oppgaven fortsatt er konfigurert til å lage syntetiske GFS-punkter. Når den tid kommer, vil jobben måtte lage en GFS for alle maskiner i kjeden. Hvis en maskin ikke har noen nye poeng i det hele tatt, vel, du må bruke den som er. Og slik hver gang. Som et resultat kan følgende situasjon oppstå:
Vær oppmerksom på Filer-delen: vi har de viktigste VBK og 2 ukentlige GFS-poeng. Og nå til gjenopprettingspunkter-delen - faktisk inneholder disse filene det samme bildet av maskinen. Naturligvis er det ingen vits i slike GFS-punkter, de tar bare plass.
Denne situasjonen er bare mulig ved bruk av syntetisk GFS. For å forhindre dette, bruk alternativet "Fjern slettede elementer". Bare husk å stille den til et tilstrekkelig antall dager. Teknisk støtte har sett tilfeller der alternativet ble satt til færre dager enn synkroniseringsintervallet – BCJ begynte å gå berserk og slette poeng før de kunne opprettes.
Vær også oppmerksom på at dette alternativet ikke påvirker allerede opprettede GFS-poeng. Hvis du vil rense arkivene, må du gjøre dette manuelt - ved å høyreklikke på maskinen og velge "Slett fra disk" (i vinduet som vises, ikke glem å krysse av i boksen "Fjern GFS full backup") :
Innovasjon v.10 – umiddelbar kopi
Etter å ha behandlet den "klassiske" funksjonaliteten, la oss gå videre til den nye. Det er én innovasjon, men en veldig viktig. Dette er en ny driftsmåte.
Det er ikke noe slikt som et "synkroniseringsintervall"; oppgaven vil hele tiden overvåke om nye punkter har dukket opp og kopiere dem alle, uansett hvor mange det er. Men samtidig forblir jobben inkrementell, det vil si at selv om hovedjobben oppretter en VBK eller VRB, vil disse punktene bli kopiert som VIB. Ellers er det ingen overraskelser i denne modusen - både standard- og GFS-retensjon fungerer i henhold til reglene beskrevet ovenfor (men kun syntetisk GFS er tilgjengelig her).
Diskene snurrer. Funksjoner til depoter med roterte stasjoner
Den konstante trusselen om løsepengevirus har gjort det til en de facto sikkerhetsstandard å ha en kopi av data på et medium der viruset ikke kan nå. Et alternativ er å bruke diskrotasjonslager, der disker brukes én om gangen: mens én disk er tilkoblet og skrivbar, lagres resten på et sikkert sted.
For å lære B&R å jobbe med slike depoter, må du klikke på Avansert-knappen i depotinnstillingene, ved depottrinnet, og velge riktig alternativ:
Etter dette vil VBR forvente at den eksisterende kjeden med jevne mellomrom vil forsvinne fra depotet, noe som betyr diskrotasjon. Avhengig av type depot og type jobb, vil B&R oppføre seg annerledes. Dette kan representeres med følgende tabell:
La oss vurdere hvert alternativ.
Normal oppgave og Windows-depot
Så vi har en oppgave som lagrer kjeder til den første disken. Under rotasjon forsvinner faktisk den opprettede kjeden, og oppgaven må på en eller annen måte overleve dette tapet. Hun finner trøst i å lage en full backup. Dermed betyr hver rotasjon en fullstendig backup. Men hva skjer med punktene på den frakoblede disken? De huskes og tas i betraktning ved beregning av retensjon. Dermed er det angitte antall poeng i en oppgave hvor mange poeng som må beholdes på alle disker. Her er et eksempel:
Jobben kjører i uendelig inkrementell modus og er konfigurert til å lagre 3 gjenopprettingspunkter. Men vi har også en andre disk, og vi roterer den en gang i uken (det kan være flere disker, dette endrer ikke essensen).
I den første uken vil oppgaven lage poeng på den første disken og slå sammen de ekstra. Dermed vil det totale antallet poeng være lik tre:
Deretter kobler vi til den andre stasjonen. Ved oppstart vil B&R legge merke til at disken er byttet ut. Kjeden på den første disken vil forsvinne fra grensesnittet, men informasjon om den vil forbli i databasen. Nå vil oppgaven beholde 3 poeng på den andre disken. Den generelle situasjonen vil være slik:
Til slutt kobler vi til den første stasjonen igjen. Før du oppretter et nytt punkt, vil oppgaven sjekke hva som skjer med oppbevaringen. Og oppbevaringen, jeg minner deg om, er satt til å lagre 3 poeng. I mellomtiden har vi 3 punkter på disk 2 (men den er frakoblet og lagret på et trygt sted der B&R ikke kan nå) og 3 punkter på disk 1 (men denne er tilkoblet). Dette betyr at vi trygt kan fjerne 3 punkter fra disk 1, siden de overskrider oppbevaringen. Deretter oppretter oppgaven en fullstendig sikkerhetskopi igjen, og kjeden vår begynner å se slik ut:
Hvis oppbevaring er konfigurert til å lagre dager i stedet for antall poeng, endres ikke logikken. I tillegg støttes ikke GFS-oppbevaring i det hele tatt når du bruker repositories med diskrotasjon.
Vanlig jobb og nettverkslagring i Linux-depot
Dette alternativet er også mulig, men generelt mindre anbefalt på grunn av restriksjonene. Oppgaven vil reagere på diskrotasjon og forsvinningen av kjeden på samme måte - ved å lage en full backup. Begrensningen skyldes avskjæringsmekanismen.
Her, under rotasjon, blir hele kjeden på den frakoblede disken ganske enkelt slettet fra B&R-databasen. Vær oppmerksom på at fra databasen forblir selve filene på disken. De kan importeres og brukes til utvinning, men det er lett å gjette at slike glemte kjeder før eller siden vil fylle hele depotet.
Løsningen er å legge til DWORD ForceDeleteBackupFiles som angitt på denne siden: . Jobben vil da begynne å slette hele innholdet i jobbmappen eller depotmappen (avhengig av verdien) ved hver rotasjon.
Dette er imidlertid ikke en elegant oppbevaring, men snarere en rengjøring av alt innhold. Dessverre møtte teknisk støtte tilfeller der depotet rett og slett var rotkatalogen til disken, der andre data var lokalisert i tillegg til sikkerhetskopier. Alt dette ble ødelagt under rotasjon.
I tillegg, når ForceDeleteBackupFiles er aktivert, fungerer det for alle typer depoter, det vil si at selv depoter på Windows vil slutte å bruke oppbevaring og begynne å slette innhold. Med andre ord er en lokal disk på Windows det beste valget for et slikt backuplagringssystem.
Sikkerhetskopiering og Windows-depot
Ting blir enda mer interessant med BCJ. Ikke bare har den fullverdig oppbevaring, men det er ikke nødvendig å ta en fullstendig sikkerhetskopi hver gang du bytter disk! Det fungerer slik:
Først begynner B&R å lage poeng på den første platen. La oss si at vi setter oppbevaringen til 3 poeng. Oppgaven vil fungere i uendelig inkrementell modus og slå sammen alt unødvendig (jeg minner deg om at GFS-oppbevaring ikke støttes i dette tilfellet).
Deretter kobler vi til den andre stasjonen. Siden det ikke er noen kjede på den ennå, lager vi en fullstendig sikkerhetskopi, hvoretter vi har en andre kjede med tre punkter:
Endelig er det på tide å koble til den første stasjonen igjen. Og det er her magien begynner, siden oppgaven ikke vil lage en fullstendig sikkerhetskopi, men i stedet vil bare fortsette den inkrementelle kjeden:
Etter dette vil praktisk talt hver disk ha sin egen uavhengige kjede. Derfor betyr oppbevaring her ikke antall poeng på alle disker, men antall poeng på hver disk separat.
Sikkerhetskopiering og Linux-depotnettverkslagring
Nok en gang går all eleganse tapt hvis depotet ikke er på en lokal Windows-stasjon. Dette skriptet fungerer på samme måte som det som er diskutert ovenfor med en enkel oppgave. Med hver rotasjon vil BCJ lage en full backup, og eksisterende punkter vil bli glemt. For å unngå å gå tom for ledig plass, må du bruke DWORD ForceDeleteBackupFiles.
Konklusjon
Så, som et resultat av en så lang tekst, så vi på to typer oppgaver. Selvfølgelig er det mange flere oppgaver, men det vil ikke være mulig å vurdere dem alle i formatet til én artikkel. Hvis du fortsatt har spørsmål etter å ha lest, skriv dem i kommentarfeltet, jeg svarer gjerne personlig.
Kilde: www.habr.com