Hej läsare av vår blogg! Delvis är vi redan bekanta – mina engelskspråkiga inlägg har här översatts av min kära kollega. . Denna gång ville jag nå ut till den rysktalande publiken direkt.
Till min debut ville jag hitta ett ämne som är intressant för en så bred publik som möjligt och som kräver en detaljerad genomgång. Daniel Defoe hävdade att varje människa står inför döden och skatter. Från min sida kan jag säga att varje supportingenjör ställs inför frågor om policys för lagring av återställningspunkter (eller enklare sagt – retention). Jag började förklara hur retention fungerar för fyra år sedan, när jag var junior nivå 1-ingenjör, och fortsätter att förklara det nu, redan som teamledare för den spansktalande och italiensktalande gruppen. Jag är säker på att mina kollegor på nivå två och till och med nivå tre också regelbundet får samma frågor.
I detta ljus ville jag skriva ett slutgiltigt, så detaljerat inlägg som möjligt, dit rysktalande användare kan återkomma gång på gång som en handbok. Tidpunkten är lämplig – den nyligen släppta jubileumsversionen 10 har tillfört nya funktioner till en grundläggande funktionalitet som varit oförändrad i åratal. Mitt inlägg riktar sig framför allt till denna version – även om det mesta av vad som skrivits är giltigt för tidigare versioner, kommer du inte hitta vissa av de beskrivna funktionerna där. Slutligen, med en liten blick in i framtiden, vill jag säga att vissa förändringar förväntas i nästa version, men vi kommer att berätta mer när tiden är inne. Låt oss börja.
Backup-jobb (Backup job)
Låt oss först gå igenom den del som inte har förändrats i version 10. Retentionspolicyn bestäms av flera parametrar. Vi öppnar fönstret för att skapa ett nytt jobb och går till fliken Storage. Här ser vi en parameter som bestämmer det önskade antalet återställningspunkter:
Men detta är bara en del av ekvationen. Det faktiska antalet punkter bestäms också av backup-läget som är inställt för jobbet. För att välja denna parameter måste du klicka på knappen Advanced på samma flik. Detta öppnar ett nytt fönster med många alternativ. Vi numrerar dem och går igenom dem en efter en:
Om endast alternativ 1 aktiveras kommer uppgiften att fungera i "oändligt inkrementellt" läge (forever forward incremental). Det uppstår inga svårigheter här – uppgiften kommer att lagra det angivna antalet återställningspunkter från den fullständiga säkerhetskopian (fil med filändelsen VBK) till den senaste inkrementet (fil med filändelsen VIB). När antalet punkter överstiger det angivna värdet kommer den äldsta inkrementet att slås samman med den fullständiga säkerhetskopian. Med andra ord, om uppgiften är inställd på att lagra 3 punkter, så kommer det direkt efter nästa session på lagringsplatsen att finnas 4 punkter, efter vilket den fullständiga säkerhetskopian slås samman med den äldsta inkrement, och det totala antalet punkter kommer att återgå till 3.
Retention för "backward incremental" (alternativ 2) är också mycket enkel. Eftersom i detta fall den nyaste punkten kommer att vara en fullständig säkerhetskopia, som följs av en kedja av så kallade rollbackar (filer med filändelsen VRB), är det tillräckligt att helt enkelt ta bort den äldsta rollbacken för att tillämpa retention. Situationen kommer att vara densamma: direkt efter sessionen kommer antalet punkter att överskrida det angivna med 1, och sedan återgå till det önskade värdet.
Observera att med det bakåt-inkrementella läget kan man också aktivera periodiska fullständiga säkerhetskopior (alternativ 4), men detta förändrar inte kärnan i saken. Ja, i kedjan kommer det att finnas fullständiga återställningspunkter, men vi kommer fortfarande bara att ta bort de äldsta punkterna en i taget.
Slutligen närmar vi oss den intressanta delen. Om du aktiverar inkrementell säkerhetskopiering, men dessutom aktiverar alternativ 3 eller 4 (eller båda samtidigt), kommer uppgiften att börja skapa periodiska fullständiga säkerhetskopior med "aktiv" eller syntetisk metod. Metoden för att skapa den fullständiga säkerhetskopian spelar ingen roll – den kommer att innehålla samma data, och den inkrementella kedjan kommer att delas upp i "underkedjor". Denna metod kallas forward incremental, och det är just den som väcker en betydande del av frågorna från våra kunder.
Retention här tillämpas genom att ta bort den äldsta delen av kedjan (från en fullständig backup till inkrement). Vi kommer alltså inte att ta bort bara en tom backup eller bara en del av inkrementen. Hela "underkedjan" tas bort helt på en gång. Meningen med inställningen av antal punkter förändras – medan det i andra metoder handlar om maxantalet punkter efter vilket retention ska tillämpas, definierar denna inställning det minimiantal som krävs. Med andra ord, efter att den äldsta "underkedjan" har tagits bort, får inte antalet punkter i den återstående delen falla under detta minimum.
Jag ska försöka visualisera detta koncept grafiskt. Anta att retention är inställt på 3 punkter, uppgiften körs varje dag med en fullständig backup på måndagar. Retention kommer i så fall att tillämpas när det totala antalet punkter når 10:
Varför så många som 10 när vi har ställt in 3? En fullständig backup skapades på måndagen. Från tisdagen till söndagen skapade uppgiften inkrement. Slutligen, den följande måndagen skapas en ny fullständig backup och först när 2 inkrement skapats kan den gamla delen av kedjan tas bort, eftersom det återstående antalet punkter inte får falla under de inställda 3.
Om idén är förståelig, föreslår jag att ni försöker räkna ut retention själva. Låt oss ta följande förutsättningar: uppgiften körs för första gången på torsdag (naturligtvis kommer en fullständig backup att göras). Uppsättningen är att skapa fullständiga backuper på onsdagar och söndagar och att lagra 8 återställningspunkter. När kommer retention att tillämpas för första gången?
För att svara på denna fråga rekommenderar jag att ni tar ett papper, ritar upp det efter veckodagar och skriver vilken punkt som skapas varje dag. Svaret kommer att bli uppenbart.
Svar
Förklaring: för att svara är det tillräckligt att fråga sig själv "när kommer retention att tillämpas?" Svaret – när vi kan ta bort de 3 första punkterna (VBK, VIB, VIB) och den återstående kedjan inte faller under de angivna 8 punkterna. Det blir tydligt att vi kan göra detta när vi har 11 punkter totalt, det vill säga på söndag den andra veckan.
Vissa läsare kan invända: "Varför allt detta när det finns ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Till slut har vi inte diskuterat alternativet 'Transform previous backup chains into rollbacks' (markerat med siffran 5). Detta alternativ förvirrar ibland kunder som aktiverar det 'automatiskt', i önskan om att helt enkelt inkludera en syntetisk backup. Under tiden aktiverar detta alternativ ett helt speciellt backup-läge. Utan att gå in på detaljer kan jag säga att i detta skede av produktens utveckling är 'Transform previous backup chains into rollbacks' – ett föråldrat alternativ, och jag kan inte komma på ett enda scenario där det skulle användas. Dess värde är så tveksamt att Anton Gostev själv en gång bad via forumet om exempel på dess användning (om du har sådana, skriv gärna i kommentarerna, jag är mycket nyfiken). Om det inte dyker upp några (vilket jag tror inte kommer att hända), kommer alternativet att tas bort i kommande versioner.
Uppgiften kommer att skapa inkrement (VIB) fram till den dag då en syntetisk fullbackup är schemalagd. På den dagen skapas faktiskt en VBK, men alla punkter fram till denna VBK omvandlas till rollbacks (VRB). Efter det kommer uppgiften att fortsätta skapa inkrement till den fulla backuppen fram till nästa syntetiska backup. Resultatet blir en explosiv blandning av VBK, VBR och VIB-filer. Retention tillämpas mycket enkelt – genom att ta bort den senaste VBR:
Problem
Bortsett från att förstå hur det fungerar, är de flesta problemen som uppstår vid användning av inkrementalt läge vanligtvis relaterade till den fullständiga backupen. En regelbunden fullständig backup är nödvändig för detta läge, annars kommer lagret att samla punkter tills det blir överfullt.
Till exempel kan en fullständig backup skapas för sällan. Låt oss säga att uppgiften är inställd på att lagra 10 punkter, men en fullständig backup skapas en gång i månaden. Det är uppenbart att det faktiska antalet punkter här kommer att vara betydligt större än det angivna. Eller så är uppgiften inställd på att arbeta i en oändlig inkrementell cykel och lagra 50 punkter. Sedan skapade någon av misstag en fullständig backup. Då kommer uppgiften att vänta tills den fullständiga punkten har samlat 49 inkrement, innan retention tillämpas och den återgår till oändligt fullt läge.
I andra fall ställs en fullständig backup in för att skapas regelbundet, men av någon anledning genomförs detta inte. Här beskriver jag den mest populära orsaken. Vissa kunder föredrar att använda schemaläggningsalternativet "run after" och ställa in uppgifter att köras i en kedja. Låt oss ta ett exempel: det finns 3 uppgifter som körs varje dag och skapar en fullständig backup på söndagar. Den första uppgiften startar kl. 22.30, de andra startar i kedjan. Den inkrementella backupen tar 10 minuter, och därför är alla uppgifter klara till kl. 23.00. Men den fullständiga backupen tar en timme, så på söndagar händer följande: den första uppgiften arbetar från kl. 22.30 till 23.30. Den nästa från 23.30 till 00.30. Och den tredje uppgiften startar redan på måndag. Den fullständiga backupen är inställd på söndag, så i det här fallet kommer den helt enkelt inte att finnas. Uppgiften kommer att vänta på den fullständiga backupen för att tillämpa retention. Så var försiktig när du använder alternativet "run after" eller använd det överhuvudtaget – ställ bara in uppgifterna att starta samtidigt och låt resursplaneraren göra sitt jobb.
Svårhanterat alternativ "Remove deleted items"
Genom att gå till inställningarna för uppgiften Storage – Advanced – Maintenance kan man snubbla över alternativet "remove deleted items data after", vilket anges i dagar.
Vissa kunder förväntar sig att detta är retention. I själva verket är det ett helt separat alternativ, vars missförståelse kan leda till oväntade konsekvenser. Men först och främst måste man förklara hur B&R reagerar på situationer där endast några maskiner lyckas backas upp under sessionens gång.
Låt oss föreställa oss följande scenario: en oändligt inkrementell uppgift, inställd på att lagra 6 punkter. I uppgiften finns 2 maskiner, en som alltid har backats upp framgångsrikt, den andra som ibland har gett fel. Till slut, vid den sjunde punkten, har vi den här situationen:
Tid att tillämpa retention, men en maskin har 7 punkter, medan den andra har endast 4. Kommer retention här att tillämpas? Svaret är – ja, det kommer att göras. Om minst ett objekt har backats upp, anser B&R att punkten har skapats.
En liknande situation kan uppstå om en viss maskin helt enkelt inte inkluderades i uppdraget under en specifik session. Detta kan hända, till exempel, när maskiner läggs till i uppdraget inte individuellt, utan i form av containrar (mappar, lagringsenheter) och en viss maskin tillfälligt migrerar till en annan container. I sådana fall kommer uppdraget att anses ha lyckats, men i statistiken kommer du att hitta ett meddelande som uppmanar dig att vara uppmärksam på att den specifika maskinen inte längre bearbetas av uppdraget.
Vad händer om man ignorerar detta? I fallet med oändligt inkrementella eller omvänt inkrementella lägen kommer antalet återställningspunkter för den "problematiska" maskinen att minska med varje session, tills det når 1, som sparas i VBK. Med andra ord, även om maskinen inte gör säkerhetskopior under en lång tid, kommer en återställningspunkt fortfarande att finnas kvar. Det ligger annorlunda till om periodiska fullständiga säkerhetskopior är aktiverade. Om man ignorerar signalerna från B&R, kan till slut den senaste punkten tas bort tillsammans med den gamla delen av kedjan.
När dessa detaljer är klargjorda kan vi äntligen överväga alternativet "Ta bort data för raderade objekt efter". Det kommer att ta bort alla punkter för en viss maskin om denna maskin inte säkerhetskopieras inom X dagar. Observera att denna inställning inte reagerar på fel (försök - lyckades inte). Det ska inte ens göras ett försök att säkerhetskopiera maskinen. Det verkar som om detta alternativ är användbart och alltid bör hållas aktiverat. Om administratören har raderat maskinen från uppdraget, är det logiskt att rensa bort onödiga data och kedjan efter en tid. Men inställningen kräver disciplin och uppmärksamhet.
Jag ska ge ett praktiskt exempel: i uppdraget lades flera containrar till, vars sammansättning var ganska dynamisk. På grund av brist på RAM hade B&R-servern problem som förblev obemärkta. Uppdraget startade och försökte ta en backup av maskinerna, förutom en som vid det tillfället inte var närvarande i containern. Eftersom många maskiner gav fel, skulle B&R som standard göra 3 ytterligare försök att ta backup av de "problematiska" maskinerna. På grund av de ständiga problemen med RAM drog dessa försök ut på flera dagar. Det gjordes inget nytt försök att ta backup av den saknade VM:n (bristen på VM är inget fel). Som ett resultat av detta genomfördes under ett av de återkommande försöken villkoret "Ta bort raderade objekt" och alla punkter för maskinen raderades.
Angående detta kan jag säga följande: om du har konfigurerat aviseringar för uppdragsresultat, och ännu bättre - använder integration med Veeam ONE, så kommer detta sannolikt inte att hända dig. Om du å sin sida kollar B&R-servern en gång i veckan för att se att allt fungerar, är det bättre att avstå från alternativ som potentiellt kan leda till radering av backups.
Vad som har lagts till i v.10
Det vi diskuterade tidigare har funnits i B&R under många versioner. När vi nu har förstått dessa arbetsprinciper, låt oss titta på vad som lagts till i den jubileum "tio".
Daglig retention
Ovan har vi diskuterat den "klassiska" lagringspolitiken baserad på antalet punkter. Ett alternativt tillvägagångssätt är att ställa in "dagar" istället för "återställningspunkter" i samma meny.
Idén är tydlig från namnet - retentionen kommer att hålla ett angivet antal dagar, medan antalet punkter varje dag inte spelar någon roll. Det är också viktigt att komma ihåg följande:
- Den aktuella dagen räknas inte med i retentionberäkningen
- Dagar då uppdraget inte fungerade alls räknas också. Det här bör beaktas för att inte av misstag förlora punkter för de uppdrag som arbetar oregelbundet.
- Återställningspunkten räknas från den dag den började skapas (d.v.s. om uppdraget började köra på måndag och slutade på tisdag, så är det här en punkt från måndag)
I övrigt bestäms principerna för tillämpningen av retention av uppgifter fortfarande av den valda backupmetoden. Låt oss försöka med ytterligare en uppgift för beräkning, med samma inkrementella metod. Anta att retention är inställt på 8 dagar, uppgiften körs var sjätte timme med en fullständig backup på onsdagar. Under tiden körs inte uppgiften på söndagar. Uppgiften körs första gången måndag. När kommer retention att tillämpas?
Svar
Som vanligt är det bäst att rita en tabell. Jag tillåter mig att förenkla uppgiften och kommer inte att rita alla punkter som skapats varje dag, eftersom antalet punkter per dag här inte spelar någon roll. Det viktiga är att på första måndagen och onsdagar kommer den första punkten att vara en fullständig backup, medan uppgiften bara kommer att skapa 4 inkrementella punkter på övriga dagar.
Vi klargör att retention kommer att tillämpas genom att ta bort måndagens fulla backup och dess inkrement. När kommer detta att hända? När den kvarvarande delen av kedjan innehåller 8 dagar. Observera att vi inte räknar med den aktuella dagen, utan söndag räknas tvärtom. Därför är svaret - på torsdag vecka två.
Arkivering med GFS-metoden för vanliga uppgifter
Fram till v.10 var Grandfather-Father-Son (GFS) lagringsmetoden endast tillgänglig för skapande av backupkopior (Backup copy) och uppgifter för kopiering på magnetband. Nu är den även tillgänglig för vanlig backup.
Även om det inte relaterar till det aktuella ämnet kan jag inte låta bli att säga att den nya funktionen inte innebär att man avviker från 3-2-1-strategin. Närvaro av arkivpunkter i huvudsakligt förråd påverkar inte dess tillförlitlighet. Det förutsätts att GFS kommer att användas tillsammans med ett skalbart (Scale-out) förråd för att överföra dessa punkter till S3 och liknande lagringslösningar. Om du inte använder dem är det bättre att fortsätta lagra primära och arkivpunkter på olika förråd.
Nu ska vi se på principerna för att skapa GFS-punkter. I inställningarna för uppgiften, på steget Lagring, finns nu en speciell knapp som öppnar följande meny:
Kärnan i GFS kan sammanfattas i några punkter (observera att GFS fungerar annorlunda i andra typer av uppgifter, men det kommer vi att ta upp senare):
- Uppgiften skapar inte en separat fullständig säkerhetskopia för GFS-punkten. Istället kommer den att använda den mest lämpliga fullständiga säkerhetskopian som finns. Därför måste uppgiften köras i inkrementellt läge med periodisk fullständig säkerhetskopia, eller så måste en fullständig säkerhetskopia skapas manuellt av användaren.
- Om endast en period är aktiverad (till exempel veckovis) börjar uppgiften helt enkelt vänta på en fullständig säkerhetskopia i början av GFS-perioden och markerar den första passande som GFS.
Exempel: uppgiften är inställd på att lagra en veckovis GFS med backup på onsdagar. Uppsatsen körs varje dag, men den fulla säkerhetskopian är schemalagd till fredagar. I detta fall börjar GFS-perioden på onsdag och uppgiften börjar vänta på en lämplig punkt. Den kommer att finnas på fredag och markeras med en GFS-flagg.
- Om flera perioder är aktiverade samtidigt (till exempel veckovis och månadsvis) kommer B&R att tillämpa en metod som gör att samma punkt kan användas som GFS för flera intervall (för att spara utrymme). Flaggor kommer att tilldelas i tur och ordning, med början från den yngsta.
Exempel: den veckovisa GFS:n är inställd på onsdag, medan den månadsvisa är på den sista veckan i månaden. Uppsatsen körs varje dag och skapar fullständiga säkerhetskopior på måndagar och fredagar.
För enkelhetens skull börjar vi räkna från näst sista veckan i månaden. Under denna vecka kommer en fullständig säkerhetskopiering att skapas på måndag, men den kommer att ignoreras, eftersom den veckovisa GFS-perioden börjar på onsdag. Men fredagens fulla säkerhetskopiering är helt lämplig för GFS-punkten. Detta system är vi redan bekanta med.
Nu ser vi vad som händer under den sista veckan i månaden. Den månadsvisa GFS-perioden börjar på måndag, men måndagens VBK kommer inte att markeras som GFS, eftersom uppgiften strävar efter att märka en VBK både som månadens och veckans GFS-punkt. I detta fall börjar sökningen just med veckan, eftersom den definition av GFS kan bli månadsvis.
Om endast veckovisa och årliga intervall aktiveras, kommer de att fungera oberoende av varandra och kan markera 2 separata VBK som motsvarande GFS-intervall.
Uppgifter för att skapa säkerhetskopior (Backup copy)
En annan typ av uppgifter som ofta kräver förtydliganden om hur de fungerar. Först låt oss gå igenom den "klassiska" arbetsmetoden, utan nyheterna i v.10
En enkel metod för retention
Som standard körs sådana uppgifter i ett oändligt inkrementellt läge. Skapandet av punkter definieras av två parametrar – kopieringsintervall och det önskade antalet återställningspunkter (det finns ingen retention i dagar här). Kopieringsintervallet ställs in på den första fliken Job vid skapandet av uppgiften:
Antalet punkter bestäms lite längre ner på fliken Target
Uppgiften skapar 1 ny punkt för varje intervall (hur många punkter som skapades för VM av de ursprungliga uppgifterna spelar ingen roll). I slutet av intervallet slutförs den nya punkten och, om det behövs, tillämpas retention genom att kombinera VBK och den äldsta inkrementen. Denna mekanism är vi redan bekanta med.
Retentionmetod med hjälp av GFS
BCJ kan också lagra arkiverade punkter. Detta ställs in på samma flik Target, lite längre ner i inställningarna för antal återställningspunkter:
GFS-punkter kan skapas på två sätt – syntetiskt, med hjälp av data från den sekundära lagringsplatsen, eller genom att imitera en fullständig säkerhetskopia och läsa all data från den primära lagringsplatsen (aktiveras med alternativet märkt med siffran 3). Retentionen kommer att skilja sig avsevärt i båda fallen, så vi kommer att betrakta dem separat.
Syntetisk GFS
I det här fallet skapas GFS-punkten inte exakt på den utsatta dagen. Istället kommer GFS-punkten att skapas när VIB:n för den dag då skapandet av GFS-punkten var planerat kombineras med den fullständiga säkerhetskopian. Detta kan ibland orsaka missförstånd, eftersom tiden går men GFS-punkten fortfarande saknas. Endast en mäktig shaman från supporten kan förutse vilken dag punkten faktiskt kommer att dyka upp. Egentligen behövs ingen magi – det räcker att titta på det angivna antalet punkter och synkroniseringsintervallet (hur många punkter som skapas varje dag). Försök att räkna själv på ett sådant exempel: uppgiften ställdes in för att lagra 7 punkter, synkroniseringsintervallet – 12 timmar (dvs. 2 punkter per dag). För närvarande finns det redan 7 punkter i kedjan, idag är det måndag, och för denna dag är skapandet av GFS-punkten planerat. Vilken dag kommer den att skapas?
Svar
Här är det bättre att beskriva hur kedjan kommer att förändras dynamiskt, dag för dag:
Så, på måndag markeras den sista inkrementet i kedjan som GFS, men inga andra synliga förändringar sker. Varje dag skapar uppgiften 2 nya punkter, och retentionen rör oförtrutet kedjan framåt. Till slut, på torsdag, kommer tiden för att tillämpa retention på just den inkrementet. Den här sessionen kommer att ta längre tid än vanligt – eftersom uppgiften "hämtar" de nödvändiga blocken från kedjan och skapar en ny fullständig punkt. Från det ögonblicket kommer det att finnas 8 punkter i kedjan – 7 i den huvudsakliga kedjan + GFS.
Skapa GFS-punkter med alternativet “Läs hela punkt”
Som jag nämnde ovan arbetar BCJ i ett oändligt inkrementellt läge. Nu kommer vi att gå igenom det enda undantaget från denna regel. När alternativet “Läs hela punkt” är aktiverat kommer GFS-punkten att skapas exakt på det planerade datumet. Själva uppgiften kommer att fungera i inkrementellt läge med periodiska fullständiga säkerhetskopior, som vi diskuterade ovan. Retentionen kommer också att tillämpas genom att ta bort den äldsta delen av kedjan. Men i detta fall kommer endast inkrementen att tas bort, och den fullständiga säkerhetskopian kommer att lämnas som en GFS-punkt. Därför tas punkter som markerats med GFS-flaggor inte med i beräkningen av retentionen.
Anta att uppgiften är inställd på att lagra 7 punkter och skapa en veckovis GFS-punkt på måndag. I så fall kommer uppgiften varje måndag verkligen att skapa en fullständig säkerhetskopia och markera den som GFS. Retentionen kommer att tillämpas när antalet kvarvarande inkrementene, efter att ha tagit bort dem från den äldsta delen, inte faller under 7. Så här ser det ut i diagrammet:
Så, i slutet av den andra veckan finns det totalt 14 punkter i kedjan. Under den andra veckan skapade uppgiften 7 punkter. Om detta hade varit en enkel uppgift skulle retentionen redan ha tillämpats. Men detta är BCJ med GFS-retention, så vi räknar inte GFS-punkterna, vilket innebär att det endast finns 6. Det vill säga att vi kan inte tillämpa retentionen ännu. Under den tredje veckan skapar vi en till fullständig säkerhetskopia med GFS-flaggan. 15 punkter, men denna räknar vi inte igen. Och slutligen, på tisdagen den tredje veckan skapar vi ett inkrement. Nu, om vi tar bort inkrementen från den första veckans kedja, kommer det totala antalet inkrementer att uppfylla den inställda retentionen.
Som nämnts tidigare är det här metoden där det är mycket viktigt att fullständiga säkerhetskopior skapas regelbundet. Låt oss säga att om vi sätter huvudbevarandet på 7 dagar, men bara 1 årlig punkt, är det lätt att föreställa sig att inkrementen kommer att samlas på sig mycket mer än 7. I sådana fall är det bättre att använda den syntetiska metoden för att skapa GFS.
Och igen “Ta bort raderade objekt”
Detta alternativ finns också för BCJ:
Logiken i detta alternativ är densamma som i vanliga säkerhetskopieringsuppgifter – om maskinen inte behandlas under angiven tidsperiod tas dess data bort från kedjan. Men för BCJ är nyttan av detta alternativ objektivt högre, och så här är det.
I vanligt läge arbetar BCJ i en oändligt inkrementell cykel, så om en maskin tas bort från uppgiften vid något tillfälle, kommer bevarandet gradvis att ta bort alla återställningspunkter tills endast en kvarstår – i VBK. Låt oss nu anta att uppgiften fortfarande är inställd på att skapa syntetiska GFS-punkter. När tiden kommer måste uppgiften skapa GFS för alla maskiner i kedjan. Om en maskin inte har några nya punkter – ja, då får vi använda den som finns. Och så varje gång. Slutligen kan en sådan situation uppstå:
Observera sektionen Filer: vi har en huvud-VBK och 2 veckovisa GFS-punkter. Och nu till sektionen Återställningspunkter – i dessa filer ligger faktiskt samma bild av maskinen. Naturligtvis har sådana GFS-punkter ingen mening, de tar bara upp plats.
En sådan situation kan endast uppstå vid användning av syntetisk GFS. För att förhindra detta, använd alternativet “Ta bort raderade objekt”. Glöm bara inte att ställa in det på ett rimligt antal dagar. Tekniskt stöd har sett fall där alternativet har ställts in på färre dagar än synkroniseringsintervallet – BCJ har börjat agera okontrollerat och ta bort punkter innan de har skapats.
Tänk också på att detta alternativ inte påverkar redan skapade GFS-punkter. Om du vill rensa arkiven måste detta göras manuellt – genom att högerklicka på maskinen och välja “Ta bort från disk” (i det framträdande fönstret, kom ihåg att kryssa i rutan “Ta bort GFS fullständig säkerhetskopiering”):
Nyhet v.10 – omedelbar kopia (immediate copy)
Efter att ha behandlat den "klassiska" funktionaliteten går vi vidare till det nya. Det finns en nyhet, men den är mycket viktig. Det är – ett nytt arbetsläge.
Det finns inget begrepp som "synkroniseringsintervall" här, uppgiften kommer kontinuerligt att övervaka om nya punkter har dykt upp och kopiera dem alla, oavsett hur många de är. Men uppgiften förblir inkrementell, vilket innebär att även om den primära uppgiften skapar en VBK eller VRB, kommer dessa punkter att kopieras som VIB. I övrigt finns det inga överraskningar i detta läge – både standard och GFS retention fungerar enligt reglerna som beskrivits ovan (även om endast syntetisk GFS är tillgänglig här).
Disken snurrar. Egenskaper hos arkiv med roterande diskar.
Den ständiga hotet från kryptovirus har gjort det till ett de facto säkerhetsstandard att ha en kopia av data på ett medium som viruset inte kan nå. Ett av alternativen är att använda arkiv med roterande diskar, där diskarna används i tur och ordning: medan en disk är ansluten och tillgänglig för skrivning, förvaras de andra på en säker plats.
För att utbilda B&R att arbeta med sådana arkiv måste du i arkivinställningarna, på steget Repository, klicka på knappen Advanced och välja motsvarande alternativ:
Efter detta kommer VBR att förvänta sig att den befintliga kedjan periodiskt försvinner från arkivet, vilket innebär rotation av disken. Beroende på typen av arkiv och uppgiftsart kommer B&R att bete sig på olika sätt. Detta kan illustreras med en sådan tabell:
Låt oss titta på varje alternativ.
Vanlig uppgift och Windows-arkiv.
Så vi har en uppgift som sparar kedjor på den första disken. Vid rotation försvinner den skapade kedjan faktiskt, och uppgiften måste på något sätt överleva denna förlust. Den hittar tröst i att skapa en fullständig säkerhetskopia. Så varje rotation innebär en fullständig säkerhetskopia. Men vad händer med punkterna på den frånkopplade disken? De kommer att minnas och beaktas vid beräkningen av retention. Så det angivna antalet punkter i uppgiften är hur många punkter som behöver hållas på alla diskar. Låt oss ta ett exempel:
Uppgiften körs i oändligt inkrementellt läge och är inställd på att lagra 3 återställningspunkter. Men vi har också en andra disk, och vi roterar en gång i veckan (det kan finnas fler diskar, vilket inte ändrar essensen).
Under den första veckan kommer uppgiften att skapa återställningspunkter på den första disken och sammanfoga överflödiga. På så sätt kommer det totala antalet punkter att vara tre:
Därefter ansluter vi den andra disken. När B&R startar kommer den att märka att disken har växlat. Kedjan på den första disken försvinner från gränssnittet, men information om den kommer att finnas kvar i databasen. Nu kommer uppgiften att hålla 3 punkter på den andra disken. Den totala situationen kommer att se ut så här:
Slutligen ansluter vi den första disken igen. Innan en ny punkt skapas kontrollerar uppgiften hur det ser ut med retentionen. Och retentionen, påminner jag om, är inställd på att lagra 3 punkter. Under tiden har vi 3 punkter på disk 2 (men den är avstängd och förvaras på en säker plats som B&R inte kan nå) och 3 punkter på disk 1 (den här är ansluten). Således kan vi lugnt ta bort 3 punkter från disk 1, eftersom de överskrider retentionen. Efter det skapar uppgiften en fullständig säkerhetskopia igen, och vår kedja börjar se ut så här:
Om retentionen är inställd på att lagra dagar istället för antal punkter, ändras logiken inte. Dessutom stöds inte GFS-retention alls när man använder repositorier med rotationsdiskar.
Vanlig uppgift och Linux-repositori nätverkslagring
Denna variant är också möjlig, men generellt mindre rekommenderad på grund av de begränsningar som är pålagda. Vid diskrotation och försvinnande av kedjan kommer uppgiften att reagera på samma sätt – genom att skapa en fullständig säkerhetskopia. Begränsningen är relaterad till det avskurna retentionmekanismen.
Här, vid rotation, tas hela kedjan på den avstängda disken helt bort från databasen B&R. Observera – från databasen, själva filerna förblir kvar på disken. De kan importeras och användas för återställning, men det är inte svårt att gissa att dessa bortglömda kedjor så småningom kommer att fylla hela repositoriet.
Lösningen ligger i att lägga till DWORD ForceDeleteBackupFiles som anges på den här sidan: . Efter detta kommer uppgiften att börja radera allt innehåll i uppdragets mapp eller repository-mappen (beroende på värdet) vid varje rotation.
Detta är dock ingen elegant retention, utan en ren städning av allt innehåll. Tyvärr har teknisk support stött på fall där roten av disken har angetts som repository, där det utöver säkerhetskopior också låg annan data. Allt detta förstördes vid rotation.
Dessutom, när ForceDeleteBackupFiles är aktiverat fungerar det för alla typer av arkiv, vilket innebär att även arkiv på Windows slutar tillämpa retention och börjar radera innehållet. Med andra ord, en lokal hårddisk på Windows är det bästa valet för ett sådant backup-lagringssystem.
Backup copy och Windows-arkiv
Med BCJ blir det ännu mer intressant. Det är inte bara så att det finns fullständig retention, men det krävs ingen fullständig backup vid varje diskbyte! Så här fungerar det:
Först börjar B&R skapa punkter på den första disken. Låt oss säga att vi sätter retention på 3 punkter. Uppdraget kommer att köras i en oändlig inkrementell loop och sammanfoga allt överflödigt (kom ihåg att GFS-retention inte stöds i det här fallet).
Därefter ansluter vi den andra disken. Eftersom det ännu inte finns någon kedja på den, så skapar vi en fullständig backup, efter vilket vi får en andra kedja av tre punkter:
Till slut är det dags att åter ansluta den första disken. Och här börjar magin, eftersom uppdraget inte kommer att skapa en fullständig backup, utan istället bara fortsätter den inkrementella kedjan:
Efter detta kommer det i praktiken att finnas en oberoende kedja på varje disk. Därför betyder retention här inte antalet punkter på alla diskar, utan antalet punkter på varje disk individuellt.
Backup copy och Linux-repositoriet nätverkslagring
Återigen försvinner all elegans om arkivet inte ligger på en lokal Windows-disk. Det här scenariot fungerar på samma sätt som det som diskuterades ovan med det enkla uppdraget. Vid varje rotation kommer BCJ att skapa en fullständig backup, och de befintliga punkterna kommer att glömmas bort. För att inte stå utan ledigt utrymme, måste DWORD ForceDeleteBackupFiles användas.
Slutsats
Så i slutet av denna långa text har vi diskuterat två typer av uppdrag. Naturligtvis finns det mycket fler uppdrag, men vi kan inte gå igenom alla i formatet av en artikel. Om du har några frågor efter att ha läst, skriv dem i kommentarerna, jag svarar gärna personligen.
Källa: habr.com
