Hej læsere af vores blog! Til dels er vi allerede bekendt - mine engelsksprogede indlæg dukkede op her i oversættelsen af min kære kollega . Denne gang besluttede jeg at henvende mig direkte til det russisktalende publikum.
Til min debut ønskede jeg at finde et emne, der ville være interessant for det bredest mulige publikum og kræve detaljeret overvejelse. Daniel Defoe hævdede, at død og skatter venter enhver person. For mit vedkommende kan jeg sige, at enhver supporttekniker venter på spørgsmål om politikkerne for lagring af gendannelsespunkter (eller i enklere vendinger, opbevaring). Jeg begyndte at forklare, hvordan fastholdelse fungerer for 4 år siden som niveau XNUMX junioringeniør, og jeg fortsætter med at forklare nu som leder af det spansk- og italiensktalende team. Jeg er sikker på, at mine kolleger fra andet og endda tredje supportniveau også regelmæssigt svarer på de samme spørgsmål.
I dette lys ønskede jeg at skrive et sidste, så detaljeret indlæg som muligt, som russisktalende brugere kunne vende tilbage til igen og igen som opslagsbog. Øjeblikket er rigtigt - den nyligt udgivne tiårsjubilæumsversion tilføjede nye funktioner til den grundlæggende funktionalitet, som ikke havde ændret sig i årevis. Mit indlæg er primært fokuseret på denne version – selvom det meste af det skrevet er sandt for tidligere versioner, så finder du simpelthen ikke noget af den beskrevne funktionalitet der. Til sidst, ser jeg lidt ud i fremtiden, vil jeg sige, at der forventes nogle ændringer i næste version, men det fortæller vi om, når tiden kommer. Så lad os komme i gang.
Backup job
Lad os først se på den del, der ikke er ændret i version 10. Opbevaringspolitikken bestemmes af flere parametre. Lad os åbne vinduet for at oprette en ny opgave og gå til fanen Lager. Her vil vi se en parameter, der bestemmer det ønskede antal gendannelsespunkter:
Dette er dog kun en del af ligningen. Det faktiske antal point bestemmes også af den backup-tilstand, der er indstillet for jobbet. For at vælge denne mulighed skal du klikke på knappen Avanceret på samme fane. Dette åbner et nyt vindue med mange muligheder. Lad os nummerere dem og overveje dem én efter én:
Hvis kun mulighed 1 er aktiveret, vil jobbet køre i "uendeligt trinvis" tilstand (for evigt trinvis fremad). Der er ingen vanskeligheder her - opgaven vil gemme det indstillede antal gendannelsespunkter fra en fuld sikkerhedskopi (fil med VBK-udvidelsen) til det sidste trin (fil med VIB-udvidelsen). Når antallet af point overstiger den indstillede værdi, vil det ældste trin blive flettet sammen med den fulde backup. Med andre ord, hvis opgaven er sat til at gemme 3 punkter, så vil der umiddelbart efter næste session være 4 punkter på depotet, hvorefter den fulde backup vil blive flettet sammen med den ældste stigning, og det samlede antal punkter vil vende tilbage til 3.
Også ekstremt enkel er fastholdelsen for "omvendt inkrementel" (omvendt inkremental) tilstand (mulighed 2). Da det nyeste punkt i dette tilfælde vil være en fuld backup, efterfulgt af en kæde af såkaldte rollbacks (filer med VRB-udvidelsen), for at anvende tilbageholdelsen, er det nok blot at slette den ældste rollback. Situationen vil være den samme: umiddelbart efter sessionen vil antallet af point overstige den indstillede værdi med 1, hvorefter det vender tilbage til den ønskede værdi.
Bemærk, at med omvendt inkrementel tilstand kan du også aktivere periodiske fuld sikkerhedskopiering (mulighed 4), men dette ændrer ikke essensen. Ja, fulde gendannelsespunkter vises i kæden, men vi sletter stadig bare de ældste punkter et ad gangen.
Til sidst kommer vi til den interessante del. Hvis du aktiverer trinvis sikkerhedskopiering, men også aktiverer mulighed 3 eller 4 (eller begge på samme tid), vil opgaven begynde at oprette periodiske fulde sikkerhedskopier ved hjælp af den "aktive" eller syntetiske metode. Metoden til at oprette en fuld backup er ikke vigtig - den vil indeholde de samme data, og den trinvise kæde vil blive opdelt i "underkæder". Denne metode kaldes forward incremental, og det er ham, der forårsager en væsentlig del af spørgsmålene fra vores kunder.
Retention anvendes her ved at slette den ældste del af kæden (fra en fuld backup til en stigning). Samtidig sletter vi ikke kun en hul sikkerhedskopi eller kun en del af trinene. Hele "underkæden" fjernes helt på én gang. Betydningen af at sætte antallet af point ændres også - hvis dette i andre metoder er det maksimalt tilladte antal, hvorefter der skal anvendes tilbageholdelse, så bestemmer denne indstilling her minimumsantallet. Med andre ord, efter sletning af den ældste "underkæde", bør antallet af point i den resterende del ikke falde under dette minimum.
Jeg vil forsøge at skildre dette koncept grafisk. Lad os sige, at tilbageholdelsen er sat til 3 point, opgaven kører hver dag med en fuld backup på mandag. I dette tilfælde vil tilbageholdelsen blive anvendt, når det samlede antal point når 10:
Hvorfor allerede 10, når de sætter 3 op? Mandag blev der lavet en fuld backup. Fra tirsdag til søndag skabte jobbet stigninger. Endelig, næste mandag, oprettes en fuld backup igen, og først når der er oprettet 2 inkrementer, kan hele den gamle del af kæden endelig slettes, fordi det resterende antal point ikke kommer under sættet 3.
Hvis ideen er klar, så foreslår jeg, at du selv prøver at beregne fastholdelsen. Lad os tage følgende betingelser: opgaven lanceres for første gang på torsdag (naturligvis vil der blive lavet en fuld backup). Opgaven er sat til at oprette en fuld backup onsdag og søndag og gemme 8 gendannelsespunkter. Hvornår vil tilbageholdelsen blive anvendt første gang?
For at besvare dette spørgsmål anbefaler jeg, at du tager et ark papir, tegner det efter ugedag og skriver ned, hvilket punkt der oprettes hver dag. Svaret vil blive indlysende
Svar
Forklaring: For at svare skal du bare spørge dig selv "hvornår vil tilbageholdelse blive anvendt"? Svaret er, hvornår vi kan fjerne de første 3 point (VBK, VIB, VIB), og resten af kæden ikke falder under de påkrævede 8 point. Det bliver klart, at det kan vi, når vi har 11 point i alt, altså på søndag i anden uge.
Nogle læsere kan indvende: "hvorfor alt dette, hvis der er ? Det er uden tvivl et meget nyttigt værktøj, og i nogle tilfælde ville jeg bruge det, men det har også begrænsninger. Først og fremmest tillader det dig ikke at specificere de oprindelige betingelser, og i mange tilfælde er spørgsmålet præcist "vi har sådan en kæde, hvad vil der ske, hvis vi ændrer sådanne og sådanne indstillinger?". For det andet mangler værktøjet stadig noget i synlighed. Ved at vise RPS-siden til kunderne fandt jeg ingen forståelse, men efter at have malet den som i eksemplet (selv ved at bruge den samme Paint), dag efter dag, blev alt klart.
Endelig har vi ikke overvejet muligheden "Transform tidligere backup-kæder til rollbacks" (markeret med nummer 5). Denne mulighed forvirrer nogle gange kunder, der aktiverer den "on the fly", og ønsker at aktivere en simpel syntetisk backup. I mellemtiden aktiverer denne mulighed en meget speciel sikkerhedskopieringstilstand. Uden at gå i detaljer, vil jeg med det samme sige, at på dette stadium af produktudviklingen er "Transformer tidligere backup-kæder til rollbacks" en forældet mulighed, og jeg kan ikke komme i tanke om et enkelt scenarie, hvornår det skal bruges. Dens værdi er så tvivlsom, at Anton Gostev i nogen tid selv sendte et opkald gennem forummet og bad ham om at sende ham eksempler på dets nyttige brug (hvis du har nogen, skriv i kommentarerne, jeg er meget interesseret). Hvis der ikke er nogen (det tror jeg de vil), så vil muligheden blive fjernet i fremtidige versioner.
Jobbet vil skabe trin (VIB) indtil den dag, hvor den syntetiske fuld backup er planlagt. På denne dag er VBK faktisk oprettet, men alle punkter før denne VBK omdannes til rollbacks (VRB). Derefter fortsætter jobbet med at skabe trin til den fulde backup indtil den næste syntetiske backup. Som følge heraf skabes en eksplosiv blanding af VBK-, VBR- og VIB-filer i kæden. Retension påføres meget enkelt - ved at fjerne den sidste VBR:
Problemer
Bortset fra rent faktisk at forstå, hvordan det virker, er de fleste af de problemer, der opstår ved brug af inkrementel tilstand, normalt forbundet med en fuld backup. En regelmæssig fuld backup er nødvendig for denne tilstand, ellers vil depotet akkumulere point, indtil det løber over.
For eksempel kan en fuld backup oprettes for sjældent. Lad os sige, at opgaven er indstillet til at gemme 10 point, og en fuld backup oprettes en gang om måneden. Det er klart, at det faktiske antal point her vil være meget større end det fastsatte. Eller opgaven er generelt indstillet til at arbejde i en uendelig-inkrementel tilstand og lagre 50 point. Så oprettede nogen ved et uheld en fuld sikkerhedskopi. Det er det, fra nu af vil opgaven vente, indtil det fulde point akkumulerer 49 trin, hvorefter det vil anvende tilbageholdelsen og vende tilbage til uendelig-fuld tilstand.
I andre tilfælde er en fuld sikkerhedskopi indstillet til at blive oprettet regelmæssigt, men af en eller anden grund ikke. Jeg vil liste den mest populære årsag her. Nogle kunder foretrækker at bruge "kør efter"-planlægningsmuligheden og konfigurere job til at køre i en kæde. Lad os tage dette eksempel: Der er 3 jobs, der kører hver dag og opretter en fuld backup om søndagen. Første opgave starter klokken 22.30, resten sættes i gang i en kæde. En trinvis backup tager 10 minutter, og derfor afslutter alle opgaver deres arbejde inden kl. 23.00. Men en fuld backup tager en time, så søndag sker følgende: den første opgave løber fra 22.30 til 23.30. Den næste er fra 23.30 til 00.30. Men den tredje opgave lanceres på mandag. En fuld backup er konfigureret til søndag, så i dette tilfælde bliver det simpelthen ikke. Opgaven venter på en fuld sikkerhedskopi for at anvende tilbageholdelsen. Så vær forsigtig, når du bruger muligheden "kør efter" eller lad være med at bruge den overhovedet - indstil bare jobs til at starte på samme tid, og lad ressourceplanlæggeren gøre sit arbejde.
Den svære mulighed "Fjern slettede elementer"
Når du går gennem indstillingerne for Opbevaring - Avanceret - Vedligeholdelsesopgave, kan du falde over muligheden "fjern slettede emnedata efter", beregnet i dage.
Nogle kunder forventer, at dette er fastholdelse. Faktisk er dette en helt separat mulighed, hvis misforståelse kan føre til uventede konsekvenser. Men først og fremmest skal jeg forklare, hvordan B&R reagerer på situationer, hvor kun nogle få maskiner bliver sikkerhedskopieret med succes under sessionen.
Lad os forestille os dette scenarie: et uendeligt trinvist job konfigureret til at gemme 6 point. Der er 2 maskiner i opgaven, den ene sikkerhedskopierede altid med succes, den anden gav nogle gange fejl. Som følge heraf opstod følgende situation ved det syvende punkt:
Det er tid til at anvende retentionen, men den ene maskine har 7 point, og den anden kun 4. Vil retentionen blive anvendt her? Svaret er ja, det vil det. Hvis mindst ét objekt er blevet sikkerhedskopieret, vurderer B&R, at punktet er oprettet.
En lignende situation kan opstå, hvis en eller anden maskine simpelthen ikke var inkluderet i opgaven under en bestemt session. Dette sker for eksempel, når maskiner føjes til opgaven ikke individuelt, men som en del af containere (mapper, lagre), og nogle maskiner midlertidigt migrerer til en anden container. Jobbet vil så blive betragtet som vellykket, men du vil finde en besked i statistikken, der fortæller dig, at du skal være opmærksom på, at sådan en maskine ikke længere behandles af jobbet.
Hvad vil der ske, hvis du ikke er opmærksom på det? I tilfælde af uendelig-inkrementale eller omvendt-inkrementale tilstande, vil antallet af gendannelsespunkter på "problem"-maskinen falde med hver session, indtil den når 1 gemt i VBK. Med andre ord, selvom maskinen ikke er sikkerhedskopieret i lang tid, vil der stadig være ét gendannelsespunkt. Dette er ikke tilfældet, hvis periodiske fuld sikkerhedskopiering er aktiveret. Hvis signaler fra B&R ignoreres, kan det sidste punkt i sidste ende blive slettet sammen med den gamle del af kæden.
Efter at have forstået disse detaljer, kan vi endelig overveje muligheden "Fjern slettede emnedata efter". Det vil slette alle point for en bestemt maskine, hvis denne maskine ikke er sikkerhedskopieret i X dage. Bemærk venligst, at denne indstilling ikke reagerer på fejl (forsøgt - virkede ikke). Der bør ikke engang være et forsøg på at tage backup af maskinen. Det ser ud til, at indstillingen er nyttig og altid bør holdes aktiveret. Hvis administratoren fjernede maskinen fra opgaven, er det logisk at rydde kæden for unødvendige data efter et stykke tid. Men tuning kræver disciplin og omhu.
Lad mig give dig et eksempel fra praksis: flere beholdere blev tilføjet til opgaven, hvis sammensætning var ret dynamisk. På grund af manglen på RAM oplevede B&R-serveren problemer, der ikke blev bemærket. Opgaven startede og forsøgte at lave en backup af maskinerne, bortset fra en, som på det tidspunkt ikke var til stede i containeren. Da mange maskiner har genereret fejl, skal B&R som standard gøre 3 ekstra forsøg på at tage backup af "problem" maskiner. På grund af konstante problemer med RAM, trak disse forsøg ud i flere dage. Der var ikke noget andet forsøg på at sikkerhedskopiere den manglende VM (fraværet af en VM er ikke en fejl). Som et resultat blev betingelsen "Fjern slettede elementer" opfyldt under et af de gentagne forsøg, og alle punkter på maskinen blev slettet.
Ved denne lejlighed kan jeg sige følgende: Hvis du har meddelelser om resultaterne af opgaver, der er sat op, og endnu bedre, integration med Veeam ONE bliver brugt, så vil det højst sandsynligt ikke ske for dig. Hvis du kigger på B&R-serveren en gang om ugen for at kontrollere, at alt fungerer, så er det bedre at afvise muligheder, der potentielt kan føre til sletning af sikkerhedskopier.
Hvad er nyt i v.10
Det, vi har talt om før, har eksisteret hos B&R i mange versioner. Efter at have forstået disse arbejdsprincipper, lad os nu se, hvad der blev tilføjet i jubilæet "top ti".
Daglig fastholdelse
Ovenfor overvejede vi den "klassiske" opbevaringspolitik baseret på antallet af point. En alternativ tilgang er at indstille "dage" i stedet for "gendannelsespunkter" i den samme menu.
Ideen fremgår tydeligt af navnet - tilbageholdelsen vil gemme det indstillede antal dage, antallet af point på hver dag er ligegyldigt. Når du gør det, skal du huske følgende:
- Den aktuelle dag tages ikke i betragtning ved beregningen af tilbageholdelsen
- Dage, hvor opgaven slet ikke fungerede, tælles også med. Dette skal huskes, så du ikke ved et uheld mister pointene for de opgaver, der fungerer uregelmæssigt.
- Gendannelsespunktet tælles fra den dag, hvor det blev oprettet (dvs. hvis opgaven startede mandag og sluttede tirsdag, så er dette et punkt fra mandag)
Ellers er principperne for anvendelse af retention af opgaver også bestemt af den valgte backup-metode. Lad os prøve en anden beregningsopgave ved hjælp af den samme inkrementelle metode. Lad os sige, at tilbageholdelsen er sat til 8 dage, opgaven kører hver 6. time med en fuld backup om onsdagen. I dette tilfælde fungerer opgaven ikke om søndagen. Jobbet kører på mandag for første gang. Hvornår vil tilbageholdelsen blive anvendt?
Svar
Som sædvanlig er det bedst at tegne et skilt. Jeg vil tillade mig at forenkle opgaven og vil ikke trække alle de point, der er oprettet for hver dag, fordi antallet af point pr. dag er ligegyldigt her. Det er kun vigtigt for os, at den første mandag og om onsdagen vil det første punkt være en fuld backup, de andre dage vil opgaven blot oprette 4 inkrementelle point.
Vi gør det klart, at tilbageholdelsen vil blive anvendt ved at slette mandagens fulde backup og dens stigning. Hvornår vil dette ske? Når resten af kæden indeholder 8 dage. Samtidig tæller vi ikke den aktuelle dag, men tværtimod tæller vi søndagen. Derfor er svaret torsdag i anden uge.
GFS arkivering til almindelige jobs
Før v.10 var lagringsmetoden Grandfather-Father-Son (GFS) kun tilgængelig for sikkerhedskopieringsjob og båndkopijob. Nu er den også tilgængelig for en almindelig backup.
Selvom dette ikke er relateret til det aktuelle emne, kan jeg ikke sige, at den nye funktionalitet ikke betyder en afvigelse fra 3-2-1 strategien. Tilstedeværelsen af arkivpunkter i hovedlageret påvirker ikke dets pålidelighed på nogen måde. Det er underforstået, at GFS vil blive brugt sammen med et scale-out depot til at sende disse punkter til S3 og lignende lagre. Hvis du ikke bruger det, så er det bedre at fortsætte med at gemme primære og arkiveringspunkter i forskellige depoter.
Lad os nu se på principperne for at skabe GFS-point. I opgaveindstillingerne, på lagertrinnet, er der dukket en speciel knap op, der kalder følgende menu:
Essensen af GFS kan reduceres til flere punkter (bemærk, at GFS fungerer anderledes i andre typer opgaver, men mere om det senere):
- Opgaven opretter ikke en separat fuld backup for GFS-punktet. I stedet vil den bedst egnede komplette backup blive brugt. Derfor skal opgaven arbejde i inkrementel tilstand med periodiske fuld backup, eller en fuld backup skal oprettes manuelt af brugeren.
- Hvis kun én periode er aktiveret (for eksempel en ugentlig periode), vil opgaven i begyndelsen af GFS-perioden blot begynde at vente på en fuld backup og markere den første passende som GFS.
Eksempel: Et job er konfigureret til at gemme en ugentlig GFS ved hjælp af en onsdag backup. Opgaven kører hver dag, men den fulde backup er planlagt til fredag. I dette tilfælde starter GFS-perioden onsdag, og opgaven vil begynde at vente på et passende punkt. Den vises på fredag og vil være markeret med GFS-flaget.
- Hvis flere perioder er aktiveret på én gang (for eksempel ugentligt og månedligt), vil B&R anvende en metode, der tillader, at det samme punkt bruges som GFS med flere intervaller (for at spare plads). Flagene vil blive tildelt på skift, begyndende med de yngste.
Eksempel: ugentlig GFS er indstillet til onsdag, og månedlig GFS er indstillet til den sidste uge i måneden. Jobbet kører hver dag og laver fuld backup mandag og fredag.
Lad os for nemheds skyld begynde at tælle fra den næstsidste uge i måneden. I denne uge oprettes en fuld sikkerhedskopi på mandag, men den vil blive ignoreret, fordi det ugentlige GFS-interval starter på onsdag. Men fredagens fulde backup er fuldstændig velegnet til GFS-punktet. Dette system er allerede kendt for os.
Overvej nu, hvad der vil ske i den sidste uge af måneden. Det månedlige GFS-interval starter på mandag, men mandagens VBK vil ikke blive mærket som GFS, fordi jobbet søger at mærke én VBK som både et månedligt og et ugentligt GFS-punkt. Samtidig begynder søgningen med den ugentlige, derfor kan den per definition også blive en månedlig.
Men hvis kun ugentlige og årlige intervaller er aktiveret, vil de fungere uafhængigt af hinanden og kan markere 2 separate VBK'er som tilsvarende GFS-intervaller.
Backup kopijob
En anden type opgave, der ofte kræver afklaring på jobbet. Til at begynde med, lad os analysere den "klassiske" arbejdsmetode, uden innovationer v.10
Simpel tilbageholdelsesmetode
Som standard kører sådanne job i uendelig-inkrementel tilstand. Oprettelse af punkter bestemmes af to parametre - kopieringsintervallet og det ønskede antal gendannelsespunkter (der er ingen retention om dagen her). Kopieringsintervallet indstilles på den første Job-fane, når du opretter et job:
Antallet af point bestemmes lidt længere på fanen Target
Opgaven opretter 1 nyt punkt for hvert interval (hvor mange point der blev oprettet til VM'en af de oprindelige opgaver er ligegyldigt). Ved afslutningen af intervallet afsluttes det nye punkt, og om nødvendigt påføres retention ved at kombinere VBK og det ældste tilvækst. Denne mekanisme er allerede bekendt for os.
Retentionsmetode ved hjælp af GFS
BCJ kan også gemme arkiverede punkter. Dette er konfigureret på den samme fane Target, lige under antallet af gendannelsespunkter:
GFS-punkter kan oprettes på to måder - syntetisk ved at bruge data på et sekundært lager eller ved at simulere en fuld backup og læse alle data fra det primære lager (aktiveret af indstillingen markeret 3). Opbevaring vil i begge tilfælde være meget forskellig, så vi vil overveje dem separat.
Syntetisk GFS
I dette tilfælde oprettes GFS-punktet ikke nøjagtigt på den aftalte dag. I stedet oprettes et GFS-punkt, når VIB'et på den dag, hvor GFS-punktet var planlagt til at blive oprettet, flettes med den fulde backup. Dette forårsager nogle gange misforståelser, fordi tiden går, men der er stadig ikke noget GFS-punkt. Og kun en magtfuld shaman fra teknisk support kan forudsige, hvilken dag prikken stadig vil dukke op. Faktisk er magi ikke nødvendig - se bare på det indstillede antal point og synkroniseringsintervallet (hvor mange point der oprettes hver dag). Prøv selv at beregne det ved hjælp af dette eksempel: opgaven er indstillet til at gemme 7 point, synkroniseringsintervallet er 12 timer (dvs. 2 point pr. dag). I øjeblikket er der allerede 7 point i kæden, i dag er det mandag, og oprettelsen af et GFS-punkt er planlagt til denne dag. Hvilken dag vil det blive skabt?
Svar
Her er det bedre at beskrive, hvordan kæden vil ændre sig i dynamik om dagen:
Så på mandag er den sidste stigning i kæden markeret som GFS, men der sker ingen andre synlige ændringer. Hver dag skaber opgaven 2 nye point, og fastholdelsen flytter kæden ubønhørligt fremad. Endelig, på torsdag, er det tid til at anvende tilbageholdelsen på den samme stigning. Denne session vil tage længere tid end normalt - fordi opgaven vil "trække" de nødvendige blokke fra kæden og skabe et nyt fuld point. Fra nu af vil der være 8 point i kæden - 7 i hovedkæden + GFS.
Oprettelse af GFS-punkter med muligheden "Læs hele punktet".
Ovenfor sagde jeg, at BCJ fungerer i uendelig-inkrementel tilstand. Nu vil vi analysere den eneste undtagelse fra denne regel. Hvis du aktiverer muligheden "Læs hele punktet", vil GFS-punktet blive oprettet nøjagtigt på den planlagte dag. Selve opgaven vil fungere i trinvis tilstand med periodiske fuld sikkerhedskopiering, som vi diskuterede ovenfor. Fastholdelsen vil også blive anvendt ved at fjerne den ældste del af kæden. Men i dette tilfælde vil kun trin blive slettet, og den fulde backup vil blive efterladt som et GFS-punkt. Punkter markeret med GFS-flag tages derfor ikke i betragtning ved beregning af tilbageholdelsen.
Antag, at opgaven er indstillet til at gemme 7 point og oprette et ugentlig GFS-punkt på mandag. I dette tilfælde vil jobbet hver mandag faktisk oprette en fuld sikkerhedskopi og markere den som GFS. Tilbageholdelsen vil blive anvendt, når antallet af resterende inkrementer efter sletning af trin fra den ældste del ikke falder under 7. Sådan ser det ud på diagrammet:
Så ved udgangen af anden uge er der i alt 14 point i kæden. I løbet af den anden uge skabte opgaven 7 point. Hvis dette var en simpel opgave, ville tilbageholdelse allerede være blevet anvendt. Men dette er en BCJ med GFS-retention, så vi tæller ikke GFS-point, hvilket betyder, at der kun er 6 af dem. Det vil sige, at vi ikke kan anvende retention endnu. I den tredje uge laver vi endnu en fuld backup med GFS-flaget. 15 point, men igen tæller vi ikke denne. Og til sidst, tirsdag i den tredje uge, opretter vi en stigning. Hvis vi nu fjerner kædestigningerne fra den første uge, vil det samlede antal trin opfylde den etablerede fastholdelse.
Som nævnt ovenfor er det i denne metode meget vigtigt, at der regelmæssigt oprettes fuld backup. For eksempel, hvis du indstiller hovedretentionen til 7 dage, men kun 1 årligt point, er det let at forestille sig, at stigningerne vil akkumulere meget, meget mere end 7. I sådanne tilfælde er det bedre at bruge den syntetiske metode til at skabe GFS.
Og igen "Fjern slettede elementer"
Denne mulighed er også til stede for BCJ:
Logikken i denne mulighed her er den samme som i almindelige sikkerhedskopieringsopgaver - hvis maskinen ikke behandles i det angivne antal dage, slettes dens data fra kæden. Men for BCJ er denne mulighed objektivt set mere nyttig, og her er hvorfor.
I normal tilstand fungerer BCJ i en uendelig-inkrementel tilstand, så hvis maskinen på et tidspunkt fjernes fra opgaven, så vil tilbageholdelsen gradvist slette alle gendannelsespunkter, indtil der kun er ét tilbage - i VBK. Lad os nu forestille os, at jobbet også er konfigureret til at skabe syntetiske GFS-punkter. Når tiden kommer, skal jobbet oprette en GFS for alle maskinerne i kæden. Hvis en eller anden maskine slet ikke har nye point - ja, så skal du bruge den, der er. Og sådan hver gang. Som følge heraf kan følgende situation opstå:
Vær opmærksom på Filer sektionen: vi har de vigtigste VBK og 2 ugentlige GFS point. Og nu til afsnittet Gendannelsespunkter - faktisk indeholder disse filer det samme billede af maskinen. Naturligvis er der ingen mening i sådanne GFS-punkter, de fylder kun.
Denne situation er kun mulig ved brug af syntetisk GFS. For at forhindre dette skal du bruge indstillingen "Fjern slettede elementer". Bare husk at indstille den til et passende antal dage. Teknisk support har set tilfælde, hvor muligheden var sat til færre dage end synkroniseringsintervallet - BCJ begyndte at gå amok og slette punkter, før de kunne oprettes.
Bemærk også, at denne mulighed ikke påvirker eksisterende GFS-punkter. Hvis du vil rense arkiverne, skal du gøre det manuelt - ved at højreklikke på maskinen og vælge "Slet fra disk" (i det vindue, der vises, skal du ikke glemme at markere afkrydsningsfeltet "Fjern GFS fuld backup") :
Innovation v.10 - øjeblikkelig kopi (øjeblikkelig kopi)
Efter at have behandlet den "klassiske" funktionalitet, lad os gå videre til den nye. Innovation er én, men meget vigtig. Dette er en ny funktionsmåde.
Der er ikke noget, der hedder et "synkroniseringsinterval", opgaven vil konstant overvåge, om der er dukket nye punkter op og kopiere dem alle, uanset hvor mange der er. Jobbet forbliver dog inkrementelt, hvilket betyder, at selvom hovedjobbet opretter en VBK eller VRB, vil disse punkter blive kopieret som en VIB. Ellers er der ingen overraskelser i denne tilstand - både standard- og GFS-retention fungerer i henhold til reglerne beskrevet ovenfor (selvom kun syntetisk GFS er tilgængelig her).
Diske snurrer. Funktioner i Rotated Drives Repositories
Den konstante trussel fra ransomware-virus har gjort det til de facto sikkerhedsstandard at have en kopi af dataene på et medie, hvor virussen ikke kan nå. En mulighed er at bruge diskroterende arkiver, hvor diske bruges på skift: mens en disk er tilsluttet og skrivbar, opbevares resten et sikkert sted.
For at lære B&R at arbejde med sådanne depoter skal du i lagerindstillingerne, ved lagertrinnet, klikke på knappen Avanceret og vælge den relevante mulighed:
Herefter vil VBR forvente, at den eksisterende kæde periodisk vil forsvinde fra depotet, hvilket betyder diskrotation. Afhængigt af typen af depot og type job, vil B&R opføre sig anderledes. Dette kan repræsenteres med følgende tabel:
Lad os overveje hver mulighed.
Normal Job og Windows Repository
Så vi har en opgave, der gemmer kæder til den første disk. Under rotation forsvinder den oprettede kæde faktisk, og opgaven skal på en eller anden måde overleve dette tab. Det finder trøst i at skabe en fuld backup. Hver rotation betyder således en fuld backup. Men hvad sker der med prikkerne på et afbrudt drev? De huskes og tages i betragtning ved beregning af tilbageholdelsen. Det indstillede antal point i opgaven er således, hvor mange point der skal beholdes på alle diske. Her er et eksempel:
Jobbet kører i uendelig trinvis tilstand og er konfigureret til at gemme 3 gendannelsespunkter. Men vi har også en anden disk, og vi roterer den en gang om ugen (der kan være flere diske, dette ændrer ikke essensen).
I den første uge vil opgaven skabe point på den første disk og flette de ekstra. Det samlede antal point vil således være tre:
Derefter forbinder vi den anden disk. Ved opstart vil B&R bemærke, at drevet er ændret. Kæden på den første disk forsvinder fra grænsefladen, men information om den forbliver i databasen. Jobbet vil nu indeholde 3 prikker på den anden disk. Den generelle situation vil være sådan:
Til sidst sætter vi det første drev på igen. Inden du opretter et nyt punkt, vil opgaven tjekke, hvad der er med tilbageholdelsen. Og tilbageholdelsen, jeg minder dig om, er indstillet til at gemme 3 point. I mellemtiden har vi 3 point på disk 2 (men den er offline og gemt et sikkert sted, hvor B&R ikke kan nå) og 3 point på disk 1 (men denne er tilsluttet). Så du kan sikkert fjerne 3 punkter fra disk 1, da de overstiger tilbageholdelsen. Derefter opretter opgaven en fuld backup igen, og vores kæde begynder at se sådan ud:
Hvis tilbageholdelsen er konfigureret til at gemme dage i stedet for antallet af point, ændres logikken ikke. Desuden understøttes GFS-retention slet ikke, når du bruger repositories med diskrotation.
Normal Job og Linux Repository Network Storage
Denne mulighed er også mulig, men er generelt mindre anbefalet på grund af de pålagte begrænsninger. Opgaven vil reagere på diskrotation og forsvinden af kæden på samme måde - ved at oprette en fuld backup. Begrænsningen er forbundet med den trunkerede tilbageholdelsesmekanisme.
Her bliver hele kæden på den afbrudte disk under rotation blot slettet fra B&R-databasen. Vær opmærksom - fra databasen forbliver selve filerne på disken. De kan importeres og bruges til nyttiggørelse, men det er ikke svært at gætte på, at sådanne glemte kæder før eller siden vil fylde hele depotet.
Løsningen er at tilføje DWORD ForceDeleteBackupFiles som angivet på denne side: . Derefter begynder jobbet simpelthen at slette alt indholdet af jobmappen eller lagermappen (afhængigt af værdien) ved hver rotation.
Dette er dog ikke en elegant fastholdelse, men derimod en udrensning af alt indhold. Desværre har teknisk support stødt på tilfælde, hvor lageret blot var rodmappen på disken, hvor der udover sikkerhedskopier var andre data. Alt dette blev ødelagt under rotationen.
Derudover, når ForceDeleteBackupFiles er aktiveret, virker det for alle typer arkiver, det vil sige, at selv arkiver på Windows stopper med at anvende opbevaring og begynder at slette indhold. Med andre ord er en lokal disk på Windows det bedste valg til et sådant backup-lagersystem.
Sikkerhedskopiering og Windows-lager
Med BCJ bliver tingene endnu mere interessante. Ikke alene er der en fuldgyldig opbevaring, men der er ingen grund til at lave en fuld sikkerhedskopi, hver gang du skifter disk! Det fungerer sådan her:
Først begynder B&R at lave prikker på den første disk. Lad os sige, at vi sætter tilbageholdelsen til 3 point. Opgaven vil arbejde i en uendelig trinvis tilstand og flette alt overflødigt (jeg minder dig om, at GFS-retention ikke understøttes i dette tilfælde).
Derefter forbinder vi den anden disk. Da der ikke er nogen kæde på den endnu, opretter vi en fuld backup, hvorefter vi har en anden kæde med tre punkter:
Endelig er det tid til at tilslutte det første drev igen. Og det er her, magien kommer ind, da opgaven ikke vil skabe en fuld backup, men i stedet bare fortsætte den inkrementelle kæde:
Derefter vil hver disk faktisk have sin egen uafhængige kæde. Derfor betyder retention her ikke antallet af point på alle diske, men antallet af point på hver disk separat.
Sikkerhedskopiering og netværksopbevaring i Linux-depot
Igen går al elegance tabt, hvis depotet ikke er på et lokalt Windows-drev. Dette script fungerer på samme måde som den simple opgave ovenfor. Ved hver rotation vil BCJ oprette en fuld backup, og eksisterende punkter vil blive glemt. For ikke at stå uden ledig plads, skal du bruge DWORD ForceDeleteBackupFiles.
Konklusion
Så som et resultat af en så lang tekst har vi overvejet to typer opgaver. Selvfølgelig er der mange flere opgaver, men det vil ikke være muligt at overveje dem alle i formatet af én artikel. Hvis du efter at have læst stadig har spørgsmål, så skriv dem i kommentarerne, jeg svarer gerne personligt.
Kilde: www.habr.com