Velkommen til læserne af vores blog! På en måde kender vi allerede hinanden – mine engelsksprogede indlæg har været her oversat af min kære kollega. . Denne gang har jeg besluttet at henvende mig direkte til det russisktalende publikum.
Til min debut ønskede jeg at finde et emne, der ville interessere så bred en målgruppe som muligt og kræve en detaljeret gennemgang. Daniel Defoe hævdede, at enhver person konfronteres med død og skatter. Her fra mit perspektiv kan jeg sige, at enhver supportingeniør konfronteres med spørgsmål om politikker for opbevaring af gendannelsespunkter (eller hvis man vil, retention). Hvordan retention fungerer, begyndte jeg at forklare for 4 år siden, da jeg var junior ingeniør på første niveau, og jeg fortsætter med at forklare det nu, hvor jeg er teamlead for det spansktalende og italiensktalende team. Jeg er sikker på, at mine kolleger på andet og endda tredje supportniveau også regelmæssigt svarer på de samme spørgsmål.
I denne forbindelse ville jeg skrive et endeligt, så detaljeret indlæg som muligt, som russisktalende brugere kunne vende tilbage til som en vejledning. Øjeblikket er passende – den for nylig udgivne jubilæums tiende version har tilføjet nye funktioner til den grundlæggende funktionalitet, som ikke har ændret sig i årevis. Mit indlæg er primært rettet mod denne version — selvom det meste af det skrevne også gælder for tidligere versioner, vil du ikke finde noget af den beskrevne funktionalitet der. Endelig, når vi kigger lidt ind i fremtiden, vil jeg sige, at nogle ændringer forventes i næste version, men vi vil fortælle om det, når tiden er inde. Lad os komme i gang.
Backup-opgaver (Backup job)
Til at begynde med vil vi se på den del, der ikke har ændret sig i version 10. Retention-politikken defineres af flere parametre. Lad os åbne vinduet for oprettelse af en ny opgave og gå til fanen Storage. Her vil vi se en parameter, der definerer det ønskede antal gendannelsespunkter:
Men dette er kun en del af ligningen. Det faktiske antal punkter bestemmes også af backup-tilstanden, som er indstillet for opgaven. For at vælge denne parameter skal du klikke på knappen Advanced på samme fane. Dette åbner et nyt vindue med mange muligheder. Lad os nummerere dem og gennemgå dem en ad gangen:
Hvis kun mulighed 1 aktiveres, vil opgaven køre i "uendeligt inkrementelt" mode (forever forward incremental). Her opstår der ingen vanskeligheder - opgaven vil gemme det indstillede antal gendannelsespunkter fra det fulde backup (fil med filtypen VBK) til den seneste inkrement (fil med filtypen VIB). Når antallet af punkter overskrider den indstillede værdi, vil den ældste inkrement blive fusioneret med den fulde backup. Med andre ord, hvis opgaven er indstillet til at gemme 3 punkter, vil der umiddelbart efter den næste session være 4 punkter i arkivet, hvorefter den fulde backup vil blive fusioneret med den ældste inkrement, og det samlede antal punkter vil vende tilbage til 3.
Retention er også meget enkel for den "omvendt inkrementale" (reverse incremental) tilstand (mulighed 2). I dette tilfælde vil det nyeste punkt være den fulde backup, efterfulgt af en kæde af såkaldte rollback-filer (filer med filtypen VRB), så det er nok at slette den ældste rollback for at anvende retention. Situationen vil være den samme: umiddelbart efter sessionen vil antallet af punkter overstige den indstillede med 1, hvorefter det vil vende tilbage til den ønskede værdi.
Bemærk, at der også kan aktiveres en periodisk fuld backup med den omvendt inkrementale mode (mulighed 4), men det ændrer ikke essensen. Ja, der vil komme fulde gendannelsespunkter i kæden, men vi vil stadigf bare slette de ældste punkter én ad gangen.
Endelig nærmer vi os den interessante del. Hvis du aktiverer inkrementel backup, men derudover aktiverer mulighederne 3 eller 4 (eller begge på én gang), vil opgaven begynde at oprette periodiske fulde backups ved hjælp af "aktiv" eller syntetisk metode. Metoden til at oprette den fulde backup er ikke vigtig - den vil indeholde de samme data, og den inkrementelle kæde vil blive opdelt i "underskaber". Denne metode kaldes forward incremental, og det er netop den, der giver anledning til en betydelig del af spørgsmålene fra vores kunder.
Retention anvendes her ved at fjerne den ældste del af kæden (fra den fulde backup til inkrementet). Vi vil ikke kun fjerne en tom backup eller kun en del af inkrementerne. Hele "underkæden" fjernes fuldstændigt på én gang. Betydningen af indstillingen for antallet af punkter ændres – hvis det i andre metoder er det maksimalt tilladte antal, hvorefter der skal anvendes retention, så definerer denne indstilling det minimale antal. Med andre ord, efter fjernelsen af den ældste "underkæde", må antallet af punkter i den tilbageværende del ikke falde under dette minimum.
Jeg vil forsøge at illustrere dette koncept grafisk. Antag, at retention er indstillet til 3 punkter, og opgaven kører hver dag med en fuld backup om mandagen. Retention vil i dette tilfælde blive anvendt, når det samlede antal punkter når 10:
Hvorfor 10, når der er indstillet 3? En fuld backup blev oprettet om mandagen. Fra tirsdag til søndag skabte opgaven inkrementer. Endelig, om den følgende mandag, oprettes igen en fuld backup, og kun når der er oprettet 2 inkrementer, kan hele den gamle del af kæden fjernes, fordi det resterende antal punkter ikke vil falde under de indstillede 3.
Hvis ideen er klar, så foreslår jeg, at du prøver at beregne retention selv. Lad os tage følgende forhold: opgaven kører første gang på en torsdag (selvfølgelig vil der blive lavet en fuld backup). Opgaven er indstillet til at lave en fuld backup om onsdagen og søndagen og opbevare 8 gendannelsespunkter. Hvornår vil retention blive anvendt første gang?
For at besvare dette spørgsmål anbefaler jeg, at du tager et stykke papir, tegner det op efter ugedage og skriver ned, hvilket punkt der oprettes hver dag. Svaret vil være åbenlyst.
Svar
Forklaring: For at besvare spørgsmålet er det nok at spørge sig selv "hvornår vil retention blive anvendt"? Svaret er – når vi kan fjerne de første 3 punkter (VBK, VIB, VIB) og den resterende kæde ikke falder under de 8 punkter. Det bliver klart, at vi kan gøre det, når vi har i alt 11 punkter, dvs. om søndagen i den anden uge.
Nogle læsere kan indvende: "hvorfor alt dette, hvis der er ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Endelig har vi ikke sagt noget om muligheden "Transform previous backup chains into rollbacks" (markeret med nummer 5). Denne mulighed forvirrer nogle gange kunder, der aktiverer den "automatisk" i ønsket om blot at inkludere en syntetisk backup. Men denne mulighed aktiverer en helt særlig backup-tilstand. Uden at dykke ned i detaljerne vil jeg hurtigt sige, at i denne fase af produktets udvikling er "Transform previous backup chains into rollbacks" en forældet mulighed, og jeg kan ikke komme i tanke om et eneste scenarie, hvor den burde anvendes. Dens værdi er så tvivlsom, at Anton Gostev for nogle tid siden efterlyste eksempler på dens nyttige anvendelse via forumet (hvis du har eksempler, så skriv i kommentarerne, det interesserer mig meget). Hvis der ikke findes sådanne (jeg tror, der ikke gør), vil muligheden blive fjernet i de næste versioner.
Opgaven vil skabe inkrementer (VIB) indtil den dag, hvor den syntetiske fulde backup er planlagt. På denne dag oprettes der faktisk en VBK, men alle punkter før denne VBK transformeres til rollbacks (VRB). Herefter vil opgaven fortsætte med at skabe inkrementer til den fulde backup indtil den næste syntetiske backup. Som resultat skabes der en blanding af VBK, VBR og VIB-filer i kæden. Retentionen anvendes meget enkelt - ved at slette den seneste VBR:
Problemer
Udover selve forståelsen af, hvordan det fungerer, er de fleste problemer, der opstår ved brug af inkremental tilstand, normalt relateret til den fulde backup. En regelmæssig fuld backup er nødvendig for denne tilstand, ellers vil opbevaringsstedet samle punkter, indtil det er fyldt.
For eksempel kan den fulde backup blive oprettet for sjældent. Lad os sige, at opgaven er indstillet til at opbevare 10 punkter, men en fuld backup oprettes en gang om måneden. Det er klart, at det faktiske antal punkter her vil være betydeligt større end det indstillede. Eller opgaven er i det hele taget sat til at køre i en uendeligt inkrementel tilstand og opbevare 50 punkter. Så skaber nogen ved et uheld en fuld backup. Sådan, nu vil opgaven vente, indtil den fulde punkt har samlet 49 inkrementer, hvorefter den anvender retention og vender tilbage til den uendelige fulde tilstand.
I andre tilfælde er den fulde backup indstillet til at blive udført regelmæssigt, men af en eller anden grund sker det ikke. Jeg vil her beskrive den mest populære årsag. Nogle kunder foretrækker at bruge indstillingen 'run after' og indstille opgaver til at arbejde i en kæde. Lad os tage dette eksempel: der er 3 opgaver, der kører hver dag og skaber en fuld backup om søndagen. Den første opgave starter kl. 22.30, og de andre starter i rækkefølge. Den inkrementelle backup tager 10 minutter, og derfor er alle opgaver afsluttet senest kl. 23.00. Men den fulde backup tager en time, så om søndagen sker følgende: den første opgave kører fra 22.30 til 23.30. Den næste fra 23.30 til 00.30. Og den tredje opgave starter først om mandagen. Den fulde backup er planlagt til søndag, så i dette tilfælde vil den simpelthen ikke blive udført. Opgaven vil vente på, at den fulde backup anvendes for at kunne anvende retention. Så vær opmærksom ved brug af indstillingen 'run after' eller undgå helt at bruge den – indstil blot opgaverne til at starte samtidig og lad ressourcestyringsværktøjet gøre sit arbejde.
Den komplekse mulighed 'Remove deleted items'
Ved at gå ind under opgaveindstillingerne Storage – Advanced – Maintenance kan man finde muligheden 'remove deleted items data after', målt i dage.
Nogle kunder forventer, at dette er retention. Faktisk er det en helt separat mulighed, hvis misforståelse kan føre til uventede konsekvenser. Først og fremmest er det nødvendigt at forklare, hvordan B&R reagerer i situationer, hvor kun et par maskiner sikkerhedskopieres succesfuldt i løbet af sessionen.
Lad os forestille os et scenarie: en uendeligt inkrementel opgave, der er indstillet til at gemme 6 punkter. Opgaven har 2 maskiner, den ene sikkerhedskopieres altid succesfuldt, den anden giver nogle gange fejl. Som resultat, ved den syvende punkt, er situationen sådan her:
Tid til at anvende retention, men den ene maskine har 7 punkter, mens den anden kun har 4. Vil retentionen blive anvendt her? Svaret er ja, det vil den. Hvis blot én objekt er blevet sikkerhedskopieret, anser B&R det for at punktet er oprettet.
En lignende situation kan opstå, hvis en maskine simpelthen ikke blev inkluderet i opgaven under en bestemt session. Dette sker for eksempel, når maskiner tilføjes til opgaven ikke individuelt, men som en del af containere (mapper, lagre), og en given maskine midlertidigt migrerer til en anden container. I sådanne tilfælde vil opgaven blive betragtet som succesfuld, men i statistikken vil du finde en meddelelse, der opfordrer til at være opmærksom på, at den pågældende maskine ikke længere behandles af opgaven.
Hvad sker der, hvis man ignorerer dette? I tilfælde af uendeligt inkrementelle eller tilbagegående inkrementelle tilstande vil antallet af gendannelsespunkter for den "problematiske" maskine falde med hver session, indtil det når 1, som er gemt i VBK. Med andre ord, selvom maskinen ikke bliver sikkerhedskopieret i lang tid, vil der stadig være ét gendannelsespunkt tilbage. Situationen er anderledes, hvis der er inkluderet periodiske fulde sikkerhedskopier. Hvis man ignorerer signalerne fra B&R, kan det ende med, at det sidste punkt bliver slettet sammen med den gamle del af kæden.
Når disse detaljer er forstået, kan man endelig se på muligheden "Fjern data for slettede genstande efter". Den vil slette alle punkter for en bestemt maskine, hvis denne maskine ikke bliver sikkerhedskopieret i løbet af X dage. Vær opmærksom på, at denne indstilling ikke reagerer på fejl (forsøgt – det lykkedes ikke). Der bør ikke engang være et forsøg på at tage backup af maskinen. Det virker tilsyneladende som en nyttig mulighed, og den bør altid være tændt. Hvis en administrator har slettet maskinen fra opgaven, er det logisk at rydde op i unødvendige data og kæden efter et stykke tid. Men indstillingen kræver disciplin og opmærksomhed.
Jeg vil give et praktisk eksempel: i opgaven blev der tilføjet flere containere, hvis sammensætning var ret dynamisk. På grund af mangel på RAM havde B&R serveren problemer, som forblev uopdaget. Opgaven blev startet og forsøgte at tage backup af maskinerne, undtagen en, som på det tidspunkt ikke var til stede i containeren. Da mange maskiner gav fejl, skulle B&R som standard gøre 3 ekstra forsøg på at tage backup af de "problematiske" maskiner. På grund af konstante problemer med RAM, strakte disse forsøg sig over flere dage. Der blev ikke gjort noget forsøg på at tage backup af den manglende VM (manglen på VM er ikke en fejl). I sidste ende, under et af de gentagne forsøg, blev betingelsen “Fjern slettede elementer” udført, og alle punkter fra maskinen blev slettet.
På dette punkt kan jeg sige følgende: hvis du har indstillet notifikationer for opgave resultater, og endnu bedre - bruger integration med Veeam ONE, så vil du sandsynligvis ikke opleve dette. Hvis du derimod tjekker B&R serveren en gang om ugen for at sikre, at alt fungerer, så er det bedre at undgå de muligheder, der potentielt kan føre til sletning af back-ups.
Hvad er blevet tilføjet i v.10
Det, vi talte om tidligere, har eksisteret i B&R i mange versioner. Efter at have forstået disse arbejdsprincipper, lad os nu se på, hvad der er blevet tilføjet i den jubilæums "tiende" version.
Daglig opbevaring
Vi har tidligere set på den "klassiske" opbevaringspolitik, der er baseret på antal punkter. En alternativ tilgang er at indstille “dage” i stedet for “gendannelsespunkter” i samme menu.
Ideen er tydelig fra navnet - retention vil opbevare det fastsatte antal dage, mens antallet af punkter hver dag ikke har nogen betydning. Det skal dog bemærkes:
- Den nuværende dag tælles ikke med i beregningen af retention
- Dage, hvor opgaven slet ikke har kørt, tælles også. Det er vigtigt at huske på for ikke at miste punkter af de opgaver, der kører uregelmæssigt.
- Et gendannelsespunkt betragtes fra den dag, hvor dets oprettelse begyndte (dvs. hvis opgaven begyndte at køre om mandagen og sluttede om tirsdagen, så er dette punkt fra mandag)
I øvrigt bestemmes principperne for anvendelse af retention af opgaverne på samme måde af den valgte backupmetode. Lad os prøve endnu en opgave med beregning, ved hjælp af den samme inkrementelle metode. Lad os sige, at retention er indstillet til 8 dage, opgaven kører hver 6. time med en fuld backup om onsdagen. Opgaven kører dog ikke om søndagen. Opgaven startet første gang mandag. Hvornår vil retention blive anvendt?
Svar
Som sædvanligt er det bedst at lave en tabel. Jeg vil forenkle opgaven og ikke tegne alle punkter, der er oprettet hver dag, da antallet af punkter pr. dag ikke er vigtigt. Vi skal bare vide, at den første mandag og om onsdagen vil det første punkt være en fuld backup, mens opgaven på de andre dage blot vil oprette 4 inkrementelle punkter.
Vi indser, at retention vil blive anvendt ved at slette den mandag fulde backup og dens inkrement. Hvornår vil dette ske? Når den resterende del af kæden indeholder 8 dage. Vi tæller ikke den nuværende dag, men vi tæller søndag, omvendt. Derfor er svaret – torsdag i den anden uge.
Arkivering ved hjælp af GFS-metoden til almindelige opgaver
Indtil v.10 var Grandfather-Father-Son (GFS) opbevaringsmetoden kun tilgængelig for opgaver til oprettelse af backupkopier og opgaver til kopiering til bånd. Nu er den dog også tilgængelig for almindelig backup.
Selvom det ikke direkte relaterer til det nuværende emne, kan jeg ikke lade være med at nævne, at den nye funktionalitet ikke betyder et farvel til 3-2-1 strategien. Tilstedeværelsen af arkivpunkter i det primære repository påvirker overhovedet ikke dets pålidelighed. Det antages, at GFS vil blive brugt sammen med en skalerbar repository, til at laste disse punkter op til S3 og lignende lagringssystemer. Hvis du ikke bruger dem, er det bedre at fortsætte med at opbevare primære og arkivpunkter på forskellige repositories.
Lad os nu se på principperne for oprettelse af GFS punkter. I opgaveindstillingerne, på trin Storage, er der tilføjet en speciel knap, som åbner følgende menu:
Essensen af GFS kan opsummeres i flere punkter (vær opmærksom på, at GFS fungerer anderledes i andre typer opgaver, men mere om det senere):
- Opgaven opretter ikke et separat fuldt backup til GFS-punktet. I stedet vil den mest passende fulde backup fra de tilgængelige blive brugt. Derfor skal opgaven køre i inkrementel tilstand med periodisk fuld backup, eller også skal en fuld backup oprettes manuelt af brugeren.
- Hvis der kun er aktiveret én periode (for eksempel ugentlig), vil opgaven blot begynde at vente på den fulde backup ved begyndelsen af GFS-perioden og markere den første passende som GFS.
Eksempel: Opgaven er indstillet til at gemme ugentlig GFS ved at bruge backupen fra onsdag. Opgaven kører hver dag, men den fulde backup er planlagt til fredag. I dette tilfælde vil GFS-perioden starte på onsdag, og opgaven vil begynde at vente på det passende punkt. Det vil blive tilgængeligt på fredag og blive markeret med GFS-flaget.
- Hvis der er aktiveret flere perioder (for eksempel ugentlig og månedlig), vil B&R anvende en metode, der tillader at bruge det samme punkt som GFS for flere intervaller (for at spare plads). Flagene vil blive tildelt sekventielt, startende fra den laveste.
Eksempel: Ugentlig GFS er indstillet til onsdag, mens den månedlige er planlagt til den sidste uge i måneden. Opgaven kører hver dag og opretter fulde backups om mandagen og fredagen.
For enkelheds skyld starter vi optællingen fra den næstsidste uge i måneden. I denne uge vil der blive oprettet en fuld backup om mandagen, men den vil blive ignoreret, fordi den ugentlige GFS-periode starter om onsdagen. Derimod er den fredags fulde backup helt passende til GFS-punktet. Dette system er vi allerede fortrolige med.
Lad os nu se på, hvad der vil ske i den sidste uge i måneden. Den månedlige GFS-periode starter om mandagen, men mandags VBK vil ikke blive markeret som GFS, fordi opgaven stræber efter at markere én VBK som både månedlig og ugentlig GFS-punkt. Søgningen starter med den ugentlige, fordi den per definition også kan blive månedlig.
Hvis kun de ugentlige og årlige intervaller er aktiveret, vil de fungere uafhængigt af hinanden og kan markere to separate VBK som tilsvarende GFS-intervaller.
Opgaver til oprettelse af backupkopier (Backup copy)
En anden type opgaver, der ofte kræver forklaring på, hvordan de fungerer. Lad os først gennemgå den "klassiske" metode uden innovationer fra v.10.
En simpel retention metode
Som standard kører sådanne opgaver i en uendelig inkrementel tilstand. Oprettelsen af punkter bestemmes af to parametre – kopiintervallet og det ønskede antal gendannelsespunkter (der er ikke noget retention i dage her). Kopiintervallet indstilles på den første fane Job ved oprettelsen af opgaven:
Antallet af punkter bestemmes lidt længere nede på fanen Target
Opgaven opretter 1 nyt punkt for hvert interval (det antal punkter, der er blevet oprettet for VM af de oprindelige opgaver, har ingen betydning). Til slutningen af intervallet bliver det nye punkt afsluttet, og hvis nødvendigt anvendes retention ved at kombinere VBK og den ældste inkrement. Denne mekanisme er vi allerede bekendt med.
Retention metoden med GFS
BCJ kan også gemme arkivpunkter. Dette indstilles på den samme fanen Target, lidt under indstillingen for antallet af gendannelsespunkter:
GFS punkter kan oprettes på to måder – syntetisk, ved at bruge data fra det sekundære lager, eller ved at simulere en fuld backup og læse alle data fra det primære lagersystem (aktiveres med indstillingen markeret som nummer 3). Retentionen vil i begge tilfælde være meget forskellig, så lad os se nærmere på dem hver for sig.
Syntetisk GFS
I dette tilfælde oprettes GFS punktet ikke præcist på den udpegede dag. I stedet vil GFS punktet blive oprettet, når VIB for den dag, hvor oprettelsen af GFS punktet var planlagt, bliver kombineret med den fulde backup. Dette kan nogle gange føre til misforståelser, da tiden går, men GFS punktet stadig ikke er der. Kun den mægtige shaman fra teknisk support kan forudsige, hvilken dag punket endelig vil dukke op. Faktisk er der ikke brug for magi – det er nok at se på det angivne antal punkter og synchroniseringsintervallet (hvor mange punkter der oprettes hver dag). Prøv selv at regne ud i dette eksempel: opgaven er indstillet til at gemme 7 punkter, synchroniseringsintervallet er 12 timer (dvs. 2 punkter om dagen). I øjeblikket er der allerede 7 punkter i kæden, i dag er det mandag, og oprettelsen af GFS punktet er planlagt til denne dag. Hvornår vil det blive oprettet?
Svar
Her er det bedst at beskrive, hvordan kæden vil ændre sig dynamisk, dag for dag:
Så i mandag markereres den sidste inkrement i kæden som GFS, men der sker ingen andre synlige ændringer. Hver dag opretter opgaven 2 nye punkter, og retention skubber nådesløst kæden frem. Endelig, på torsdag, er det tid til at anvende retention på selve inkrementet. Denne session vil tage længere tid end normalt - fordi opgaven "udtrækker" de nødvendige blokke fra kæden og opretter et nyt komplet punkt. Fra dette tidspunkt vil der være 8 punkter i kæden - 7 i hovedkæden + GFS.
Oprettelse af GFS punkter med indstillingen “Læs hele punktet”
Som nævnt før, fungerer BCJ i en uendelig inkrementel tilstand. Nu vil vi se på det eneste undtagelse fra denne regel. Når indstillingen “Læs hele punktet” er aktiveret, vil GFS punktet blive oprettet præcist på den planlagte dag. Selve opgaven vil fungere i inkrementel tilstand med periodiske fulde sikkerhedskopier, som vi tidligere har drøftet. Retention vil også blive anvendt ved at slette den ældste del af kæden. I dette tilfælde vil kun inkrementer blive slettet, mens den fulde sikkerhedskopi vil blive efterladt som et GFS punkt. Derfor vil punkter markeret med GFS-flag ikke blive taget i betragtning ved beregningen af retention.
Lad os antage, at opgaven er indstillet til at opbevare 7 punkter og oprette et ugentligt GFS punkt om mandagen. I dette tilfælde vil opgaven faktisk oprette en fuld sikkerhedskopi hver mandag og markere den som GFS. Retention vil blive anvendt, når antallet af resterende inkrementer efter sletning af inkrementerne fra den ældste del ikke falder under 7. Sådan ser det ud på skemaet:
Så ved slutningen af den anden uge er der i alt 14 punkter i kæden. I løbet af den anden uge har opgaven oprettet 7 punkter. Hvis dette var en simpel opgave, ville retention allerede være blevet anvendt. Men dette er BCJ med GFS retention, så vi tæller ikke GFS punkter, og derfor er der kun 6. Det vil sige, at vi endnu ikke kan anvende retention. I den tredje uge opretter vi endnu en fuld sikkerhedskopi med GFS flag. 15 punkter, men vi tæller denne igen ikke. Endelig, tirsdag i den tredje uge skaber vi et inkrement. Nu, hvis vi sletter inkrementerne fra den første uges kæde, vil det samlede antal inkrementer opfylde den fastsatte retention.
Som nævnt ovenfor er det meget vigtigt, at komplette sikkerhedskopier oprettes regelmæssigt i denne metode. Lad os sige, at hvis den primære opbevaring sættes til 7 dage, men kun 1 årlig punkt, er det ikke svært at forestille sig, at der vil samle sig langt flere inkrementer, end der er plads til på 7 dage. I sådanne tilfælde er det bedre at bruge den syntetiske metode til at oprette GFS.
Og igen "Fjern slettede elementer"
Denne mulighed er også tilgængelig for BCJ:
Logikken bag denne mulighed er den samme som i normale sikkerhedskopieringsopgaver – hvis maskinen ikke er blevet behandlet i det angivne antal dage, slettes dens data fra kæden. Men for BCJ er nyttigheden af denne mulighed objektivt højere, og her er hvorfor.
I normal tilstand fungerer BCJ i en uendelig inkrementel tilstand, så hvis en maskine på et tidspunkt fjernes fra opgaven, vil opbevaringen gradvist slette alle restorationspunkter, indtil der kun er én tilbage – i VBK. Lad os forestille os, at opgaven stadig er indstillet til at oprette syntetiske GFS-punkter. Når tiden kommer, skal opgaven oprette GFS for alle maskiner i kæden. Hvis en maskine slet ikke har nye punkter – ja, så må vi bruge den, der er tilgængelig. Og sådan vil det være hver gang. Resultatet kan blive:
Bemærk sektionen Filer: vi har den primære VBK og 2 ugentlige GFS-punkter. Og nu til sektionen Gendannelsespunkter – i disse filer ligger der faktisk det samme billede af maskinen. Der er naturligvis ikke nogen mening i sådanne GFS-punkter, de optager kun plads.
Denne situation er kun mulig ved brug af syntetisk GFS. For at undgå dette, skal du bruge muligheden "Fjern slettede elementer". Husk bare at indstille den til et passende antal dage. Teknisk support har set tilfælde, hvor muligheden blev indstillet til et kortere antal dage end synkroniseringsintervallet – BCJ begyndte at gå amok og slette punkter, før de havde mulighed for at blive oprettet.
Bemærk også, at denne mulighed ikke påvirker allerede oprettede GFS-punkter. Hvis du ønsker at rense arkiverne, skal dette gøres manuelt – ved at højreklikke på maskinen og vælge "Slet fra disk" (i det fremkomne vindue, husk at sætte flueben ved "Fjern GFS fuld sikkerhedskopi"):
Nyhed v.10 – øjeblikkelig kopi (immediate copy)
Når vi har forstået den "klassiske" funktionalitet, lad os gå videre til det nye. Der er én nyhed, men den er meget vigtig. Det er en ny driftsmåde.
Der er ikke noget, der hedder "synkroniseringsinterval", opgaven vil konstant overvåge, om der er nye punkter, og kopiere dem alle, uanset hvor mange der er. Men opgaven forbliver inkrementel, så selv hvis hovedopgaven skaber en VBK eller VRB, vil disse punkter blive kopieret som VIB. Udover dette er der ingen overraskelser i denne tilstand – både standard og GFS retention fungerer efter de beskrevne regler ovenfor (dog er kun syntetisk GFS tilgængelig her).
Diskene snurrer. Egenskaber ved repositiver med roterende diske (rotated drives)
Den konstante trussel fra ransomware har gjort det til de facto standard at have en sikkerhedskopi af data på et medie, som en virus ikke kan nå. En af mulighederne er at bruge repositiver med roterende diske, hvor diskene bruges skiftevis: mens den ene disk er tilsluttet og tilgængelig for skrivning, opbevares de andre et sikkert sted.
For at lære B&R at arbejde med sådanne repositiver, skal du i indstillingerne for repositivet, på trin Repository, klikke på knappen Advanced og vælge den relevante mulighed:
Derefter vil VBR forvente, at den eksisterende kæde periodisk forsvinder fra repositivet, hvilket betyder diskrotation. Afhængig af typen af repositiv og opgavetype vil B&R opføre sig forskelligt. Dette kan repræsenteres med følgende tabel:
Lad os se på hver mulighed.
Standardopgave og Windows-repositiv
Så vi har en opgave, der gemmer kæder på den første disk. Ved rotation forsvinder den oprettede kæde faktisk, og opgaven skal på en eller anden måde overleve dette tab. Den finder trøst i oprettelsen af en fuld backup. Så hver rotation betyder en fuld backup. Men hvad sker der med punkterne på den frakoblede disk? De huskes og tages med i beregningen af retention. Så det angivne antal punkter i opgaven er det antal punkter, der skal opbevares på alle diske. Lad os give et eksempel:
Opgaven kører i uendelig inkrementel tilstand og er indstillet til at gemme 3 gendannelsespunkter. Men vi har også en anden disk, og vi roterer en gang om ugen (der kan være flere diske, men det ændrer ikke essensen).
I den første uge vil opgaven oprette punkter på den første disk og kombinere de overskydende. På denne måde vil det samlede antal punkter være tre:
Derefter tilslutter vi den anden disk. Ved opstart af B&R vil det registrere, at disken er blevet ændret. Kæden på den første disk forsvinder fra grænsefladen, men oplysningerne om den forbliver i databasen. Nu vil opgaven holde 3 punkter på den anden disk. Den samlede situation vil være sådan:
Endelig tilslutter vi igen den første disk. Før der oprettes et nyt punkt, vil opgaven kontrollere, hvad der er med retention. Og retention, skal jeg minde om, er indstillet til at opbevare 3 punkter. Imens har vi 3 punkter på disk 2 (men den er frakoblet og opbevares et sikkert sted, som B&R ikke kan nå) og 3 punkter på disk 1 (denne er tilkoblet). Det betyder, at vi trygt kan slette 3 punkter fra disk 1, da de overstiger retention. Derefter opretter opgaven igen et komplet backup, og vores kæde begynder at se sådan ud:
Hvis retention er indstillet til at opbevare dage i stedet for antal punkter, ændrer logikken sig ikke. Desuden understøttes GFS-retention slet ikke ved brug af opbevaringssteder med diskrotation.
Normale opgaver og Linux-repositorier netværkslager
Denne mulighed er også mulig, men 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 komplet backup. Begrænsningen er relateret til det beskårne mekanisme for retention.
Her ved rotation slettes hele kæden på den frakoblede disk blot fra B&R-databasen. Vær opmærksom – fra databasen, selve filerne forbliver på disken. De kan importeres og bruges til gendannelse, men det er ikke svært at gætte, at sådanne glemte kæder en dag vil fylde hele opbevaringsstedet.
Løsningen er at tilføje DWORD ForceDeleteBackupFiles som angivet på denne side: . Derefter begynder opgaven simpelthen at slette alt indholdet i opgavens mappe eller opbevaringsmappen (afhængigt af værdien) ved hver rotation.
Men dette er ikke en elegant retention, men netop en rensning af alt indholdet. Desværre er der i teknisk support set tilfælde, hvor opbevaringsstedet blot var angivet som rodmappen på disken, hvorudover backups også lå andre data. Alt dette blev ødelagt ved rotation.
Desuden, når ForceDeleteBackupFiles er aktiveret, fungerer det for alle typer af lager, dvs. selv lager på Windows vil stoppe med at anvende retention og begynde at slette indholdet. Med andre ord er en lokal disk på Windows det bedste valg til et sådan backup-lagringssystem.
Backup-kopi og Windows arkiv
Med BCJ bliver det endnu mere interessant. Ikke blot er der en fuld retention, men det kræver ikke at lave en fuld backup ved hver skift af disk! Det fungerer sådan her:
Først starter B&R med at oprette punkter på den første disk. Lad os sige, vi har indstillet retention på 3 punkter. Opgaven vil køre i en uendelig inkrementel tilstand og kombinere alt unødvendigt (jeg minder om, at GFS-retention ikke understøttes i dette tilfælde).
Derefter tilslutter vi den anden disk. Da der endnu ikke er nogen kæde på den, laver vi en fuld backup, hvorefter vi får en anden kæde af tre punkter:
Endelig er det tid til igen at tilslutte den første disk. Og her begynder magien, da opgaven ikke vil oprette en fuld backup, men i stedet blot fortsætter den inkrementelle kæde:
Efter dette vil der faktisk eksistere en uafhængig kæde på hver disk. Derfor betyder retention her ikke antallet af punkter på alle diske, men antallet af punkter på hver disk enkeltvis.
Backup-kopi og Linux arkiv netværkslager
Atter en gang forsvinder al elegance, hvis arkivet ikke er på en lokal Windows-disk. Dette scenarie fungerer på samme måde som det tidligere betragtede med en simpel opgave. Ved hver rotation vil BCJ skabe en fuld backup, og de eksisterende punkter vil blive glemt. For ikke at løbe tør for plads skal DWORD ForceDeleteBackupFiles anvendes.
Konklusion
Således har vi i denne lange tekst undersøgt to typer af opgaver. Selvfølgelig er der mange flere opgaver, men vi kan ikke dække dem alle i rammerne af én artikel. Hvis du har spørgsmål efter at have læst, så skriv dem i kommentarfeltet, jeg vil være glad for at svare personligt.
Kilde: habr.com
