Hälsningar till våra bloggläsare! Vi är delvis redan bekanta - mina engelskspråkiga inlägg dök upp här översatta av min kära kollega . Den här gången bestämde jag mig för att rikta mig direkt till den rysktalande publiken.
Till min debut ville jag hitta ett ämne som skulle vara intressant för en bredast möjlig publik och som kräver ingående övervägande. Daniel Defoe hävdade att död och skatter väntar varje person. För min del kan jag säga att vilken supporttekniker som helst kommer att ha frågor om lagringspolicyer för återställningspunkter (eller, enklare, lagring). Jag började förklara hur retention fungerar för fyra år sedan, som junioringenjör på första nivån, och jag fortsätter att förklara nu, redan som ledare för ett spansk- och italiensktalande team. Jag är säker på att mina kollegor från andra och till och med tredje stödnivån också regelbundet svarar på samma frågor.
I detta ljus ville jag skriva ett sista, så detaljerat inlägg som möjligt, som rysktalande användare kunde återkomma till om och om igen som en uppslagsbok. Nu är det rätt - den nyligen släppta tioårsjubileumsversionen lade till nya funktioner till den grundläggande funktionaliteten som inte hade förändrats på flera år. Mitt inlägg fokuserar främst på den här versionen – även om det mesta som skrivs är sant för tidigare versioner, så hittar du helt enkelt inte en del av den beskrivna funktionaliteten där. Slutligen, när jag ser lite in i framtiden, kommer jag att säga att vissa förändringar förväntas i nästa version, men vi kommer att berätta om detta när det är dags. Så låt oss börja.
Backup jobb
Låt oss först titta på den del som inte har ändrats i version 10. Retentionspolicyn bestäms av flera parametrar. Låt oss öppna fönstret för att skapa en ny uppgift och gå till fliken Lagring. Här kommer vi att se en parameter som bestämmer det önskade antalet återställningspunkter:
Detta är dock bara en del av ekvationen. Det faktiska antalet poäng bestäms också av det backupläge som är inställt för jobbet. För att välja det här alternativet, klicka på knappen Avancerat på samma flik. Detta öppnar ett nytt fönster med många alternativ. Låt oss numrera dem och överväga dem en efter en:
Om du endast aktiverar alternativ 1 kommer jobbet att köras i läget "för evigt framåt inkrementellt". Det finns inga svårigheter här - uppgiften kommer att lagra det angivna antalet återställningspunkter från en fullständig säkerhetskopia (fil med VBK-tillägget) till det sista steget (fil med VIB-tillägget). När antalet poäng överstiger det inställda värdet kommer det äldsta steget att slås samman med den fullständiga säkerhetskopian. Med andra ord, om uppgiften är inställd på att lagra 3 punkter, kommer det omedelbart efter nästa session att finnas 4 punkter på förvaret, varefter den fullständiga säkerhetskopian kommer att slås samman med det äldsta inkrementet och det totala antalet punkter kommer att återgå till 3.
Retentionen för "reverse incremental"-läget (alternativ 2) är också extremt enkel. Eftersom den nyaste punkten i det här fallet kommer att vara en fullständig säkerhetskopia, följt av en kedja av så kallade rollbacks (filer med VRB-tillägget), räcker det för att tillämpa retention att helt enkelt ta bort den äldsta rollbacken. Situationen kommer att vara densamma: omedelbart efter sessionen kommer antalet poäng att överstiga det inställda värdet med 1, varefter det återgår till önskat värde.
Observera att med det omvända inkrementella läget kan du också aktivera periodiska fullständiga säkerhetskopieringar (alternativ 4), men detta kommer inte att ändra essensen. Ja, fullständiga återställningspunkter kommer att visas i kedjan, men vi kommer fortfarande helt enkelt att ta bort de äldsta punkterna en efter en.
Slutligen kommer vi till 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 den "aktiva" eller syntetiska metoden. Metoden för att skapa en fullständig säkerhetskopia är inte viktig - 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 denna metod som väcker en betydande del av frågorna från våra kunder.
Retention tillämpas här genom att ta bort den äldsta delen av kedjan (från en fullständig säkerhetskopia till en inkrement). Samtidigt kommer vi inte bara att ta bort en fullständig säkerhetskopia eller bara en del av inkrementen. Hela "underkedjan" tas bort helt på en gång. Innebörden av att ställa in antalet poäng ändras också - om det i andra metoder är det högsta tillåtna antalet, varefter retention måste tillämpas, så bestämmer denna inställning det lägsta antalet. Med andra ord, efter att ha tagit bort den äldsta "underkedjan", bör antalet poäng i den återstående delen inte falla under detta minimum.
Jag ska försöka skildra detta koncept grafiskt. Låt oss säga att retentionen är inställd på 3 poäng, uppgiften körs varje dag med en fullständig backup på måndag. Retention i detta fall kommer att tillämpas när det totala antalet poäng når 10:
Varför finns det redan 10 när de lägger upp 3? En fullständig säkerhetskopia skapades på måndagen. Från tisdag till söndag skapade jobbet steg. Slutligen, nästa måndag skapas en fullständig säkerhetskopia igen och först när 2 steg har skapats kan äntligen hela den gamla delen av kedjan raderas, eftersom det återstående antalet poäng inte kommer att falla under uppsättningen 3.
Om tanken är tydlig, så föreslår jag att du försöker beräkna retention själv. Låt oss ta följande villkor: uppgiften lanseras för första gången på torsdag (naturligtvis kommer en fullständig säkerhetskopia att göras). Uppgiften är inställd på att skapa en fullständig säkerhetskopia på onsdagar och söndagar och 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 du tar ett papper, radar upp det efter veckodag och skriver ner vilken punkt som skapas varje dag. Svaret kommer att bli uppenbart
Svar
Förklaring: för att svara, fråga bara dig själv "när kommer retention att tillämpas"? Svaret är när vi kan ta bort de första 3 poängen (VBK, VIB, VIB) och resten av kedjan inte faller under de 8 poäng som krävs. Det blir klart att vi kommer att klara av detta när vi har 11 poäng totalt, det vill säga på söndagen i andra veckan.
Vissa läsare kan invända: "varför göra allt detta om det finns ?. Det råder ingen tvekan om att detta är ett mycket användbart verktyg, och i vissa fall skulle jag använda det, men det har också begränsningar. Först och främst tillåter det dig inte att specificera de initiala villkoren, och i många fall är frågan exakt "vi har en sådan kedja, vad händer om vi ändrar sådana och sådana inställningar?" För det andra saknar verktyget fortfarande en viss tydlighet. När jag visade RPS-sidan för kunderna hittade jag ingen förståelse, men efter att ha målat den som i exemplet (även med samma färg), dag efter dag, blev allt klart.
Slutligen övervägde vi inte alternativet "Omvandla tidigare backup-kedjor till rollbacks" (markerat med nummer 5). Det här alternativet förvirrar ibland klienter som aktiverar det "automatiskt", som helt enkelt vill aktivera en syntetisk säkerhetskopiering. Samtidigt aktiverar det här alternativet ett mycket speciellt säkerhetskopieringsläge. Utan att gå in på detaljer kommer jag genast att säga att i detta skede av produktutvecklingen är "Omvandla tidigare backup-kedjor till rollbacks" ett föråldrat alternativ, och jag kan inte komma på ett enda scenario när det ska användas. Dess värde är så tveksamt att Anton Gostev själv under en tid ringde upp genom forumet och bad att skicka honom exempel på dess användbara användning (om du har dem, skriv i kommentarerna, jag är mycket intresserad). Om det inte finns några (jag tror att det kommer att vara fallet), kommer alternativet att tas bort i framtida versioner.
Uppgiften kommer att skapa inkrement (VIB) tills den dag då en syntetisk fullständig säkerhetskopiering är schemalagd. Den här dagen skapas faktiskt en VBK, men alla punkter före denna VBK omvandlas till rollbacks (VRB). Efter detta fortsätter uppgiften att skapa steg till den fullständiga säkerhetskopian tills nästa syntetiska säkerhetskopia. Som ett resultat skapas en explosiv blandning av VBK-, VBR- och VIB-filer i kedjan. Retention tillämpas mycket enkelt - genom att ta bort den sista VBR:n:
Problem
Förutom att faktiskt förstå hur det fungerar, är de flesta problem som uppstår när du använder inkrementellt läge vanligtvis förknippade med en fullständig säkerhetskopiering. Regelbundna fullständiga säkerhetskopior är nödvändiga för detta läge, annars kommer förvaret att samla poäng tills det är fullt.
Till exempel kan en fullständig säkerhetskopia skapas för sällan. Låt oss säga att uppgiften är inställd på att lagra 10 poäng, och en fullständig säkerhetskopia skapas en gång i månaden. Det är tydligt att det faktiska antalet poäng här kommer att vara betydligt större än det som visas. Eller så är uppgiften i allmänhet inställd på att fungera i oändligt inkrementellt läge och lagra 50 poäng. Då skapade någon av misstag en fullständig säkerhetskopia. Det är det, från och med nu kommer uppgiften att vänta tills hela poängen har samlats på 49 steg, varefter den kommer att tillämpa retention och återgå till oändligt fullt läge.
I andra fall är en fullständig säkerhetskopia inställd på att skapas regelbundet, men av någon anledning gör den det inte. Jag kommer att lista den mest populära anledningen här. Vissa klienter föredrar att använda schemaläggningsalternativet "kör efter" och konfigurera jobb så att de körs i en kedja. Låt oss ta det här exemplet: det finns 3 jobb som körs varje dag och skapar en fullständig säkerhetskopia på söndag. Första uppgiften startar 22.30, resten lanseras i en kedja. En inkrementell säkerhetskopiering tar 10 minuter och därför är alla jobb klara att fungera kl. 23.00. Men en fullständig säkerhetskopiering tar en timme, så på söndag händer följande: den första uppgiften pågår från 22.30 till 23.30. Nästa från 23.30 till 00.30. Men den tredje uppgiften börjar på måndag. En fullständig säkerhetskopia är inställd på söndag, så i det här fallet kommer det helt enkelt inte att hända. Uppgiften väntar på en fullständig säkerhetskopia för att tillämpa kvarhållningen. Så var försiktig när du använder alternativet "kör efter" eller använd det inte alls - ställ bara in jobben att starta samtidigt och låt resursplaneraren göra sitt jobb.
Det svåra alternativet "Ta bort raderade objekt"
Efter att ha gått igenom inställningarna för uppgiften Lagring – Avancerat – Underhåll, kan du stöta på alternativet "ta bort data för raderade objekt efter", som kan räknas i dagar.
Vissa kunder förväntar sig att detta ska vara kvarhållande. Faktum är att detta är ett helt separat alternativ, vars missförstånd kan leda till oväntade konsekvenser. Men först och främst måste vi förklara hur B&R reagerar på situationer där endast ett fåtal maskiner säkerhetskopieras framgångsrikt under en session.
Låt oss föreställa oss detta scenario: ett oändligt inkrementellt jobb konfigurerat för att lagra 6 poäng. Det finns 2 maskiner i uppgiften, den ena säkerhetskopierades alltid framgångsrikt, den andra gav ibland fel. Som ett resultat av den sjunde punkten uppstod följande situation:
Dags att tillämpa retention, men en bil har 7 poäng och den andra endast 4. Kommer retention att tillämpas här? Svaret är ja, det kommer det. Om minst ett objekt har säkerhetskopierats, anser B&R att punkten har skapats.
En liknande situation kan uppstå om någon maskin helt enkelt inte ingick i uppgiften under en viss session. Detta händer till exempel när maskiner läggs till i en uppgift inte individuellt, utan som en del av behållare (mappar, lagring) och någon maskin tillfälligt migrerar till en annan behållare. I det här fallet kommer uppgiften att anses vara framgångsrik, men i statistiken hittar du ett meddelande som ber dig att uppmärksamma att en sådan och en sådan maskin inte längre bearbetas av uppgiften.
Vad händer om du inte uppmärksammar detta? I fallet med oändligt inkrementella eller omvända inkrementella lägen kommer antalet återställningspunkter för "problem"-maskinen att minska med varje session tills den når 1, lagrad i VBK. Med andra ord, även om maskinen inte säkerhetskopieras under en längre tid, kommer en återställningspunkt fortfarande att finnas kvar. Situationen är annorlunda om periodiska fullständiga säkerhetskopieringar är aktiverade. Om du ignorerar signalerna från B&R kan den sista punkten så småningom raderas tillsammans med den gamla delen av kedjan.
Efter att ha förstått dessa detaljer kan du äntligen överväga alternativet "Ta bort data för raderade objekt efter". Det kommer att ta bort alla poäng för en specifik maskin om den maskinen inte säkerhetskopieras på X dagar. Observera att den här inställningen inte svarar på fel (försökte det, men det fungerade inte). Det bör inte ens göras ett försök att säkerhetskopiera maskinen. Det verkar som om alternativet är användbart och bör alltid hållas aktiverat. Om administratören tog bort maskinen från uppgiften, är det efter en tid logiskt att rensa kedjan med onödiga data. Men anpassning kräver disciplin och omsorg.
Låt mig ge dig ett exempel från praktiken: flera behållare lades till uppgiften, vars sammansättning var ganska dynamisk. På grund av bristen på RAM-minne upplevde B&R-servern problem som inte upptäcktes. Uppgiften startade och försökte göra en säkerhetskopia av maskinerna, förutom en som vid den tidpunkten inte fanns i containern. Eftersom många maskiner genererade fel, bör B&R som standard göra ytterligare 3 försök att säkerhetskopiera "problem"-datorerna. På grund av ständiga problem med RAM pågick dessa försök i flera dagar. Det gjordes inga upprepade försök att göra en säkerhetskopia av den saknade virtuella datorn (avsaknaden av en virtuell dator är inte ett fel). Som ett resultat, under ett av de upprepade försöken, uppfylldes villkoret "Ta bort borttagna objekt" och alla punkter på maskinen raderades.
Angående detta kan jag säga följande: om du har aviseringar inställda om uppgiftsresultat, och ännu bättre, använd integration med Veeam ONE, så kommer detta med största sannolikhet inte att hända dig. Om du tittar på B&R-servern en gång i veckan för att kontrollera att allt fungerar, så är det bättre att vägra alternativ som potentiellt kan leda till radering av säkerhetskopior.
Vad har lagts till i v.10
Det vi pratade om tidigare har funnits i B&R i många versioner. Efter att ha förstått dessa operativa principer, låt oss nu titta på vad som har lagts till i jubileet "tio".
Daglig retention
Ovan tittade vi på den "klassiska" lagringspolicyn baserat på antalet poäng. Ett alternativt tillvägagångssätt är att ställa in "dagar" istället för "återställningspunkter" i samma meny.
Tanken framgår tydligt av namnet - retentionen kommer att lagra ett visst antal dagar, men antalet poäng på varje dag spelar ingen roll. I det här fallet måste du komma ihåg följande:
- Den aktuella dagen beaktas inte vid beräkning av retention
- Dagar då uppgiften inte fungerade alls räknas också. Detta bör komma ihåg för att inte av misstag förlora poängen för de uppgifter som fungerar oregelbundet.
- Återställningspunkten räknas från dagen då den började skapas (dvs. om uppgiften började fungera på måndagen och avslutades på tisdag, då är detta punkten från måndagen)
I övrigt bestäms principerna för att använda retention av uppgifter också av den valda backupmetoden. Låt oss prova en annan beräkningsuppgift med samma inkrementella metod. Låt oss säga att lagringen är inställd på 8 dagar, uppgiften körs var 6:e timme med en fullständig säkerhetskopia på onsdag. Uppgiften fungerar dock inte på söndag. Jobbet pågår på måndag för första gången. När kommer retention att tillämpas?
Svar
Som alltid är det bäst att rita en skylt. Jag kommer att tillåta mig själv att förenkla uppgiften och kommer inte att dra alla poäng som skapas för varje dag, eftersom antalet poäng per dag inte spelar någon roll här. Det är bara viktigt för oss att den första måndagen och på onsdagar kommer den första punkten att vara en fullständig backup, men under de återstående dagarna kommer uppgiften helt enkelt att skapa 4 inkrementella poäng.
Vi gör det klart att lagringen kommer att tillämpas genom att ta bort måndagens fullständiga säkerhetskopia och dess ökning. När kommer detta att hända? När resten av kedjan innehåller 8 dagar. Samtidigt räknar vi inte den aktuella dagen, utan tvärtom, vi räknar söndagen. Därför är svaret torsdag den andra veckan.
GFS-arkivering för vanliga jobb
Före v.10 var lagringsmetoden Grandfather-Father-Son (GFS) endast tillgänglig för säkerhetskopieringsjobb och bandkopieringsjobb. Nu är den tillgänglig för regelbunden säkerhetskopiering.
Även om detta inte är relaterat till det aktuella ämnet, kan jag inte låta bli att säga att den nya funktionen inte innebär ett avsteg från 3-2-1-strategin. Förekomsten av arkivpunkter i huvudförvaret påverkar inte på något sätt dess tillförlitlighet. Det är underförstått att GFS kommer att användas tillsammans med ett Scale-out-förråd för att ladda upp dessa punkter till S3 och liknande lagringar. Om du inte använder det är det bättre att fortsätta lagra primära och arkiveringspunkter i olika arkiv.
Låt oss nu titta på principerna för att skapa GFS-poäng. I uppgiftsinställningarna, vid lagringssteget, har en speciell knapp dykt upp som tar fram följande meny:
Kärnan i GFS kan kokas ner till flera punkter (observera att GFS fungerar annorlunda i andra typer av uppgifter, men mer om det senare):
- Uppgiften skapar inte en separat fullständig säkerhetskopia för GFS-punkten. Istället kommer den mest lämpliga fullständiga säkerhetskopian som finns att använda. Därför måste uppgiften fungera i inkrementellt läge med periodiska fullständiga säkerhetskopior, eller så måste en fullständig säkerhetskopia skapas manuellt av användaren.
- Om endast en period är aktiverad (till exempel en vecka), kommer uppgiften i början av GFS-perioden helt enkelt att börja vänta på en fullständig säkerhetskopia och markera den första lämpliga som GFS.
Exempel: jobbet är konfigurerat för att lagra en veckovis GFS med hjälp av en säkerhetskopia på onsdag. Uppgiften körs varje dag, men en fullständig säkerhetskopiering är planerad till fredag. I det här fallet börjar GFS-perioden på onsdag och uppgiften börjar vänta på en lämplig punkt. Den dyker upp på fredag och kommer att märkas med GFS-flaggan.
- Om flera perioder inkluderas på en gång (till exempel veckovis och månadsvis) kommer B&R att använda en metod som gör att samma punkt kan användas som GFS med flera intervall (för att spara utrymme). Flaggor kommer att tilldelas i ordning, med början med den yngsta.
Exempel: veckovis GFS ställs in på onsdag och månads GFS ställs in för den sista veckan i månaden. Uppgiften 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 den näst sista veckan i månaden. Denna vecka kommer en fullständig säkerhetskopia att skapas på måndag, men den kommer att ignoreras eftersom det veckovisa GFS-intervallet börjar på onsdag. Men fredagens fulla backup är helt lämplig för GFS-punkten. Detta system är redan bekant för oss.
Låt oss nu titta på vad som händer den sista veckan i månaden. Det månatliga GFS-intervallet börjar på måndag, men måndagens VBK kommer inte att markeras som GFS eftersom jobbet syftar till att markera en VBK som både månads- och veckovis GFS-poäng. I det här fallet börjar sökningen med den veckovisa, eftersom den per definition också kan bli den månatliga.
Men om du bara inkluderar vecko- och årsintervallen kommer de att agera oberoende av varandra och kan markera 2 separata VBK:er som motsvarande GFS-intervall.
Uppgifter för säkerhetskopiering
En annan typ av uppgift som ofta kräver förtydligande kring arbetet. Låt oss först titta på den "klassiska" arbetsmetoden, utan innovationer v.10
Enkel retentionsmetod
Som standard körs sådana jobb i oändligt inkrementellt läge. Skapandet av punkter bestäms av två parametrar - kopieringsintervallet och det önskade antalet återställningspunkter (det finns ingen kvarhållning per dag här). Kopieringsintervallet ställs in på den första jobbfliken när du skapar ett jobb:
Antalet poäng bestäms lite längre fram på fliken Mål
Uppgiften skapar en ny punkt för varje intervall (hur många poäng som skapades för den virtuella datorn av de ursprungliga uppgifterna spelar ingen roll). I slutet av intervallet slutförs den nya punkten och vid behov appliceras retention genom att kombinera VBK och det äldsta inkrementet. Denna mekanism är redan bekant för oss.
Retentionsmetod med GFS
BCJ kan även lagra arkivpunkter. Detta konfigureras på samma målflik, precis under inställningen för antalet återställningspunkter:
GFS-punkter kan skapas på två sätt - syntetiskt, med hjälp av data på ett sekundärt arkiv, eller genom att simulera en fullständig säkerhetskopia och läsa all data från det primära arkivet (aktiveras av alternativet markerat 3). Retention i båda fallen kommer att vara mycket olika, så vi kommer att överväga dem separat.
Syntetisk GFS
I det här fallet skapas inte GFS-punkten exakt på den utsatta dagen. Istället kommer en GFS-punkt att skapas när VIB för dagen för vilken GFS-punkten var planerad att skapas slås samman med en fullständig säkerhetskopia. Detta orsakar ibland missförstånd, eftersom tiden går och det fortfarande inte finns någon GFS-punkt. Och bara en kraftfull shaman från teknisk support kan förutsäga vilken dag punkten kommer att dyka upp. Faktum är att magi inte behövs - titta bara på det inställda antalet poäng och synkroniseringsintervallet (hur många poäng som skapas varje dag). Försök att beräkna det själv med hjälp av detta exempel: uppgiften är inställd på att lagra 7 poäng, synkroniseringsintervallet är 12 timmar (dvs. 2 poäng per dag). För tillfället finns det redan 7 poäng i kedjan, idag är det måndag och skapandet av en GFS-punkt är planerad till denna dag. Vilken dag kommer den att skapas?
Svar
Här är det bättre att beskriva hur kedjan kommer att förändras över tiden, dag för dag:
Så på måndag är det sista steget i kedjan markerat som GFS, men inga andra synliga förändringar inträffar. Varje dag skapar uppgiften 2 nya poäng, och retention för obönhörligen kedjan framåt. Slutligen, på torsdag är det dags att tillämpa retention på just det inkrementet. Denna session kommer att ta längre tid än vanligt - eftersom uppgiften kommer att "extrahera" de nödvändiga blocken från kedjan och skapa en ny komplett punkt. Från och med detta ögonblick kommer det redan att finnas 8 poäng i kedjan - 7 i huvudkedjan + GFS.
Skapa GFS-punkter med alternativet "Läs hela punkten".
Ovan sa jag att BCJ fungerar i oändligt inkrementellt läge. Nu ska vi titta på det enda undantaget från denna regel. När alternativet "Läs hela punkt" är aktiverat kommer GFS-punkten att skapas exakt på den schemalagda dagen. Själva uppgiften kommer att fungera i inkrementellt läge med periodiska fullständiga säkerhetskopior, som vi diskuterade ovan. Retention kommer också att tillämpas genom att den äldsta delen av kedjan tas bort. Men i det här fallet kommer endast stegen att raderas, och den fullständiga säkerhetskopian kommer att lämnas som en GFS-punkt. Följaktligen beaktas inte punkter markerade med GFS-flaggor vid beräkning av retention.
Låt oss säga att uppgiften är inställd på att lagra 7 poäng och skapa en veckovis GFS-poäng på måndag. I det här fallet kommer uppgiften att skapa en fullständig säkerhetskopia varje måndag och markera den som GFS. Retention kommer att tillämpas när, efter att ha tagit bort inkrement från den äldsta delen, antalet återstående inkrement inte sjunker under 7. Så här ser det ut i diagrammet:
Så i slutet av den andra veckan finns det totalt 14 poäng i kedjan. Under den andra veckan skapade uppgiften 7 poäng. Om detta var en enkel uppgift skulle retention redan ha tillämpats. Men det här är en BCJ med GFS-retention, så vi räknar inte GFS-poäng, vilket betyder att det bara finns 6 av dem. Det vill säga vi kan inte tillämpa retention ännu. Under den tredje veckan skapar vi ytterligare en fullständig säkerhetskopia med GFS-flaggan. 15 poäng, men återigen räknar vi inte den här. Och slutligen, på tisdagen den tredje veckan, skapar vi ett inkrement. Om vi nu tar bort kedjetillskotten från den första veckan kommer det totala antalet inkrement att uppfylla den fastställda retentionen.
Som nämnts ovan, i denna metod är det mycket viktigt att fullständiga säkerhetskopior skapas regelbundet. Låt oss säga att om du ställer in huvudretentionen i 7 dagar, men bara 1 årlig poäng, är det lätt att föreställa sig att ökningarna kommer att ackumuleras mycket, 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"
Det här alternativet finns också för BCJ:
Logiken för detta alternativ här är densamma som i vanliga säkerhetskopieringsuppgifter - om en maskin inte bearbetas under det angivna antalet dagar, raderas dess data från kedjan. Men för BCJ är användbarheten av detta alternativ objektivt sett högre, och här är varför.
I normalt läge arbetar BCJ i ett oändligt inkrementellt läge, så om en maskin vid något tillfälle tas bort från jobbet, kommer retention gradvis att radera alla återställningspunkter tills det bara finns en kvar - i VBK. Låt oss nu föreställa oss att uppgiften fortfarande är konfigurerad för att skapa syntetiska GFS-punkter. När det är dags kommer jobbet att skapa en GFS för alla maskiner i kedjan. Om någon maskin inte har några nya poäng alls, ja, du måste använda den som är. Och så varje gång. Som ett resultat kan följande situation uppstå:
Var uppmärksam på avsnittet Filer: vi har de viktigaste VBK- och 2 GFS-poäng per vecka. Och nu till avsnittet Återställningspunkter - i själva verket innehåller dessa filer samma bild av maskinen. Naturligtvis är det ingen mening med sådana GFS-punkter, de tar bara upp plats.
Denna situation är endast möjlig när man använder syntetisk GFS. För att förhindra detta, använd alternativet "Ta bort borttagna objekt". Kom bara ihåg att ställa in den för ett tillräckligt antal dagar. Teknisk support har sett fall där alternativet satts på färre dagar än synkroniseringsintervallet – BCJ började gå amok och radera punkter innan de kunde skapas.
Observera också att det här alternativet inte påverkar redan skapade GFS-poäng. Om du vill rengöra arkiven måste du göra detta manuellt - genom att högerklicka på maskinen och välja "Ta bort från disk" (glöm inte att markera rutan "Ta bort GFS fullständig säkerhetskopia" i fönstret som visas) :
Innovation v.10 – omedelbar kopia
Efter att ha tagit itu med den "klassiska" funktionen, låt oss gå vidare till den nya. Det finns en innovation, men en mycket viktig sådan. Detta är ett nytt funktionssätt.
Det finns inget sådant som ett "synkroniseringsintervall"; uppgiften kommer ständigt att övervaka om nya punkter har dykt upp och kopiera dem alla, oavsett hur många det finns. Men samtidigt förblir jobbet inkrementellt, det vill säga även om huvudjobbet skapar en VBK eller VRB, kommer dessa punkter att kopieras som VIB. Annars finns det inga överraskningar i det här läget - både standard- och GFS-retention fungerar enligt reglerna som beskrivs ovan (dock är endast syntetisk GFS tillgänglig här).
Diskarna snurrar. Funktioner hos arkiv med roterade enheter
Det ständiga hotet från ransomware-virus har gjort det till en de facto säkerhetsstandard att ha en kopia av data på ett medium dit viruset inte kan nå. Ett alternativ är att använda diskrotationsförråd, där diskarna används en i taget: medan en disk är ansluten och skrivbar, lagras resten på en säker plats.
För att lära B&R att arbeta med sådana förvar måste du klicka på knappen Avancerat i förvarsinställningarna, i steget för förvar, och välja lämpligt alternativ:
Efter detta kommer VBR att förvänta sig att den befintliga kedjan periodvis kommer att försvinna från förvaret, vilket innebär diskrotation. Beroende på typ av förvar och typ av jobb kommer B&R att bete sig annorlunda. Detta kan representeras med följande tabell:
Låt oss överväga varje alternativ.
Normal uppgift och Windows-förråd
Så vi har en uppgift som sparar kedjor till den första disken. Under rotation försvinner faktiskt den skapade kedjan, och uppgiften måste på något sätt överleva denna förlust. Hon finner tröst i att skapa en fullständig backup. Varje rotation innebär alltså en komplett backup. Men vad händer med punkterna på den frånkopplade disken? De kommer ihåg och beaktas vid beräkning av retention. Det inställda antalet poäng i en uppgift är alltså hur många poäng som måste finnas på alla diskar. Här är ett exempel:
Jobbet körs i oändligt inkrementellt läge och är konfigurerat för att lagra 3 återställningspunkter. Men vi har också en andra skiva, och vi roterar den en gång i veckan (det kan finnas fler skivor, detta ändrar inte essensen).
Under den första veckan kommer uppgiften att skapa poäng på den första disken och slå samman de extra. Således kommer det totala antalet poäng att vara lika med tre:
Sedan ansluter vi den andra enheten. Vid uppstart kommer B&R att märka att disken har bytts ut. 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 behålla 3 poäng på den andra skivan. Den allmänna situationen kommer att se ut så här:
Slutligen återansluter vi den första enheten. Innan du skapar en ny punkt kommer uppgiften att kontrollera vad som händer med retentionen. Och retentionen, jag påminner dig, är inställd på att lagra 3 poäng. Samtidigt har vi 3 punkter på skiva 2 (men den är frånkopplad och lagrad på en säker plats där B&R inte kan nå) och 3 punkter på skiva 1 (men den här är ansluten). Detta innebär att vi säkert kan ta bort 3 punkter från disk 1, eftersom de överskrider retentionen. Därefter skapar uppgiften en fullständig säkerhetskopia igen, och vår kedja börjar se ut så här:
Om retention är konfigurerad för att lagra dagar istället för antalet poäng, ändras inte logiken. Dessutom stöds inte GFS-retention alls när man använder arkiv med diskrotation.
Vanligt jobb och nätverkslagring för Linux-förråd
Detta alternativ är också möjligt, men rekommenderas generellt mindre på grund av de begränsningar som införs. Uppgiften kommer att reagera på diskrotation och försvinnandet av kedjan på samma sätt - genom att skapa en fullständig säkerhetskopia. Begränsningen beror på avstängningsmekanismen.
Här, under rotation, raderas helt enkelt hela kedjan på den frånkopplade disken från B&R-databasen. Observera att från databasen finns själva filerna kvar på disken. De kan importeras och användas för återvinning, men det är lätt att gissa att sådana bortglömda kedjor förr eller senare kommer att fylla hela förvaret.
Lösningen är att lägga till DWORD ForceDeleteBackupFiles som anges på denna sida: . Jobbet börjar sedan helt enkelt ta bort hela innehållet i jobbmappen eller arkivmappen (beroende på värdet) vid varje rotation.
Detta är dock inte en elegant retention, utan snarare en rengöring av allt innehåll. Tyvärr stötte teknisk support på fall då förvaret helt enkelt var rotkatalogen på disken, där, förutom säkerhetskopior, andra data fanns. Allt detta förstördes under rotation.
Dessutom, när ForceDeleteBackupFiles är aktiverat, fungerar det för alla typer av förråd, det vill säga, även förråd på Windows kommer att sluta tillämpa kvarhållning och börja radera innehåll. Med andra ord är en lokal disk på Windows det bästa valet för ett sådant backuplagringssystem.
Säkerhetskopiering och Windows-förråd
Saker och ting blir ännu mer intressanta med BCJ. Den har inte bara fullfjädrad retention, utan det finns ingen anledning att göra en fullständig säkerhetskopia varje gång du byter disk! Det fungerar så här:
Först börjar B&R skapa punkter på den första skivan. Låt oss säga att vi sätter retentionen till 3 poäng. Uppgiften kommer att fungera i oändligt inkrementellt läge och slå samman allt onödigt (jag påminner dig om att GFS-retention inte stöds i det här fallet).
Sedan ansluter vi den andra enheten. Eftersom det inte finns någon kedja på den än skapar vi en fullständig backup, varefter vi har en andra kedja med tre punkter:
Äntligen är det dags att återansluta den första enheten. Och det är här magin börjar, eftersom uppgiften inte kommer att skapa en fullständig säkerhetskopia, utan istället kommer att fortsätta den inkrementella kedjan:
Efter detta kommer praktiskt taget varje disk att ha sin egen oberoende kedja. Därför betyder retention här inte antalet poäng på alla diskar, utan antalet poäng på varje disk separat.
Säkerhetskopiering och Linux-repository-nätverkslagring
Återigen går all elegans förlorad om förvaret inte finns på en lokal Windows-enhet. Det här skriptet fungerar på samma sätt som det som diskuterades ovan med en enkel uppgift. Med varje rotation kommer BCJ att skapa en fullständig backup, och befintliga punkter kommer att glömmas. För att undvika att få slut på ledigt utrymme måste du använda DWORD ForceDeleteBackupFiles.
Slutsats
Så, som ett resultat av en så lång text, tittade vi på två typer av uppgifter. Naturligtvis finns det många fler uppgifter, men det kommer inte att vara möjligt att överväga dem alla i formatet av en artikel. Om du efter att ha läst fortfarande har några frågor, skriv dem i kommentarerna, jag svarar gärna personligen.
Källa: will.com