Pozdravljam čitatelje našeg bloga! Djelomično smo već upoznati – moji postovi na engleskom jeziku su se ovdje pojavili u prijevodu moje drage kolegice . Ovaj put sam odlučio obratiti se ruskoj javnosti izravno.
Za svoj debi želio sam pronaći temu koja bi bila zanimljiva što širem spektru publike i zahtijevala detaljno razmatranje. Daniel Defoe je tvrdi da svakog čovjeka čekaju smrt i porezi. S svoje strane mogu reći da svakog inženjera podrške čekaju pitanja o politikama čuvanja točaka oporavka (ili jednostavnije - retenšenu). Kako funkcionira retenšna politika, počeo sam objašnjavati prije 4 godine kao mlađi inženjer prve razine i nastavim objašnjavati i sada, kao tim vođa hispano- i italijansko govoreće ekipe. Siguran sam da moji kolege iz druge i čak treće razine podrške također redovito odgovaraju na ista pitanja.
U tom svjetlu, želio sam napisati konačni, što detaljniji post, kojem bi ruski korisnici mogli ponovno pristupati iznova i iznova kao referentnom vodiču. Trenutak je pogodan – nedavno je objavljena jubilejna deseta verzija koja je dodala nove mogućnosti osnovnoj funkcionalnosti koja se nije mijenjala godinama. Moj post je prvenstveno usmjeren na ovu verziju — iako je velika većina onoga što je napisano točna i za prethodne verzije, neka od opisanih funkcionalnosti jednostavno nećete pronaći. Na kraju, gledajući malo u budućnost, reći ću da se u sljedećoj verziji očekuju određene promjene, ali o tome ćemo govoriti kada dođe vrijeme. Dakle, krenimo.

Zadaci sigurnosnog kopiranja (Backup job)
Za početak, razmotrit ćemo onaj dio koji nije pretrpio promjene u verziji 10. Politika retenšena određuje se nekoliko parametarima. Otvorimo prozor za kreiranje novog zadatka i pređimo na karticu Storage. Ovdje ćemo vidjeti parametar koji određuje željeni broj točaka oporavka:

Međutim, to je samo dio jednadžbe. Stvarni broj točaka također se određuje načinom sigurnosnog kopiranja postavljenim za zadatak. Da biste odabrali ovaj parametar, trebate kliknuti na gumb Advanced na istoj kartici. To će otvoriti novi prozor s mnogo opcija. Numerirat ćemo ih i razmotriti redom:

Ako uključite samo opciju 1, zadatak će raditi u "neprekidnom inkrementalnom" režimu (forever forward incremental). Ovdje nema nikakvih poteškoća – zadatak će čuvati postavljeni broj tačaka oporavka od pune sigurnosne kopije (datoteka s ekstenzijom VBK) do posljednjeg inkrementa (datoteka s ekstenzijom VIB). Kada broj tačaka premaši postavljenu vrijednost, najstariji inkrement će biti spojen s punom sigurnosnom kopijom. Drugim riječima, ako je zadatak postavljen da čuva 3 tačke, odmah nakon još jedne sesije na repozitoriju će biti 4 tačke, nakon čega će se puna sigurnosna kopija spojiti s najstarijim inkrementom i ukupni broj tačaka će se vratiti na 3.

Također je izuzetno jednostavan retention za "obrnuto-inkrementalni" (reverse incremental) režim (opcija 2). Budući da će u ovom slučaju najnovija tačka biti puna sigurnosna kopija, iza koje će se povlačiti lanac takozvanih rollback-ova (datoteke s ekstenzijom VRB), za primjenu retention-a dovoljno je jednostavno obrisati najstariji rollback. Situacija će biti ista: odmah nakon sesije broj tačaka će preći postavljen broj za 1, nakon čega će se vratiti na potrebnu vrijednost.

Imajte na umu da se s obrnutim inkrementalnim režimom može također uključiti periodična puna sigurnosna kopija (opcija 4), ali to neće promijeniti suštinu. Da, u lancu će se pojaviti pune tačke oporavka, ali mi ćemo i dalje jednostavno brisati najstarije tačke jednu po jednu.
Na kraju, dolazimo do zanimljivog dijela. Ako aktivirate inkrementalnu sigurnosnu kopiju, ali dodatno uključite opcije 3 ili 4 (ili oboje istovremeno), zadatak će početi stvarati periodične pune sigurnosne kopije "aktivnim" ili sintetičkim metodom. Metoda stvaranja pune sigurnosne kopije nije važna – ona će sadržavati iste podatke, a inkrementalni lanac će biti podijeljen na "podlanac". Ova metoda se naziva forward incremental, i upravo ona izaziva značajan dio pitanja od naših klijenata.
Retention here is applied by removing the oldest part of the chain (from a full backup to the increment). We will not delete just the empty backup or only part of the increments. The entire "sub-chain" is removed completely at once. The meaning of the setting for the number of points also changes – while in other methods this is the maximum allowable number after which retention needs to be applied, here this setting defines the minimum number. In other words, after removing the oldest "sub-chain", the number of points in the remaining part must not fall below this minimum.
I will try to represent this concept graphically. Let’s say retention is set to 3 points, the task runs every day with a full backup on Monday. In this case, retention will be applied when the total number of points reaches 10:

Why 10, when we set 3? A full backup was created on Monday. From Tuesday to Sunday, the task created increments. Finally, next Monday a full backup is created again and only when 2 increments are created can the whole old part of the chain be deleted because the remaining number of points will not fall below the set 3.
If the idea is clear, I suggest you try to calculate retention yourself. Let’s take these conditions: the task is launched for the first time on Thursday (naturally, a full backup will be made). The task is set to create a full backup on Wednesdays and Sundays and keep 8 restore points. When will retention be applied for the first time?
To answer this question, I recommend you take a piece of paper, divide it by days of the week, and write down which point is created each day. The answer will become obvious.
Odgovor

Explanation: to answer, it’s enough to ask yourself "when will retention be applied"? The answer is – when we can delete the first 3 points (VBK, VIB, VIB) and the remaining chain does not fall below the required 8 points. It becomes clear that we can do this when we have a total of 11 points, i.e. on Sunday of the second week.
Some readers may object: "why all this, if there is ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Na kraju, nismo razmatrali opciju "Transform previous backup chains into rollbacks" (označena brojem 5). Ova opcija ponekad zbunjuje klijente koji je aktiviraju "automatski", želeći jednostavno uključiti sintetičku sigurnosnu kopiju. U međuvremenu, ova opcija aktivira sasvim poseban režim sigurnosne kopije. Ne ulazim u pojedinosti, odmah ću reći da je u ovom trenutku razvoja proizvoda "Transform previous backup chains into rollbacks" opcija zastarjela, i ne mogu smisliti nijedan scenarij u kojem bi je trebalo koristiti. Njena vrijednost je toliko sumnjiva da je neko vrijeme sam Anton Gostev uputio poziv na forumu, moleći da mu pošalju primjere njene korisne upotrebe (ako ih imate, pišite u komentarima, veoma me zanima). Ako ne bude pronađen nijedan primjer (mislim da hoće), opcija će biti uklonjena u narednim verzijama.
Zadatak će stvarati inkrementalne (VIB) sigurnosne kopije do dana kada je zakazana sintetička potpuna sigurnosna kopija. Na taj dan se zaista stvara VBK, ali sve tačke do ovog VBK se transformiraju u rollback-ove (VRB). Nakon toga, zadatak će nastaviti stvarati inkrementalne sigurnosne kopije ka punom backupu do sljedećeg sintetičkog backup-a. Na kraju se u lancu stvara mješavina VBK, VBR i VIB datoteka. Retencija se primjenjuje vrlo jednostavno – brisanjem posljednjeg VBR-a:

Problemi
Osim samog razumijevanja kako to radi, većina problema koji se javljaju pri korištenju inkrementalnog režima obično je povezana s punim backup-om. Redovan puni backup je potreban ovom režimu, inače će repozitorij gomilati tačke dok se ne prepuniti.
Na primjer, puni backup se može stvarati previše rijetko. Recimo, zadatak je postavljen da čuva 10 tačaka, a puni backup se stvara jednom mjesečno. Jasno je da će stvarni broj tačaka ovdje biti znatno veći od postavljenog. Ili je zadatak uopšte postavljen da radi u beskonačno-inkrementalnom režimu i čuva 50 tačaka. Tada je neko slučajno napravio puni backup. Sve, od sada će zadatak čekati da puna tačka prikupi 49 inkremenata, nakon čega će primijeniti retenciju i vratiti se u beskonačno-puni režim.
U drugim slučajevima, puni backup se redovito postavlja, ali iz nekog razloga to ne funkcionira. Ovdje ću opisati najpopularniji razlog. Neki klijenti preferiraju koristiti opciju „run after“ i postavljati zadatke da rade u lancu. Uzmimo za primjer: postoje 3 zadatka koja se izvršavaju svaki dan i stvaraju puni backup u nedjelju. Prvi zadatak se pokreće u 22:30, a ostali se pokreću u lancu. Inkremetalni backup traje 10 minuta, stoga do 23:00 svi zadaci završavaju. Međutim, puni backup traje sat vremena, pa se u nedjelju događa sljedeće: prvi zadatak radi od 22:30 do 23:30. Sljedeći traje od 23:30 do 00:30. A treći zadatak se pokreće već u ponedjeljak. Puni backup je postavljen za nedjelju, pa u tom slučaju jednostavno neće biti. Zadatak će čekati puni backup da primijeni zadržavanje. Stoga, budite oprezni prilikom korištenja opcije „run after“ ili je u potpunosti nemojte koristiti – jednostavno postavite zadatke da započnu u isto vreme i dopustite planeru resursa da obavi svoj posao.
Zahtevna opcija „Remove deleted items“
Prolaskom kroz postavke zadatka Storage – Advanced – Maintenance, možete naići na opciju „remove deleted items data after“, koja se mjeri u danima.

Neki klijenti očekuju da je to zadržavanje. U stvarnosti, to je potpuno odvojena opcija, čije nerazumijevanje može dovesti do neočekivanih posljedica. Međutim, prije svega, potrebno je objasniti kako B&R reagira na situacije kada se tijekom sesije uspješno backupira samo nekoliko mašina.
Zamislimo sljedeći scenarij: beskonačno-incremental zadatak, postavljen da čuva 6 tačaka. U zadatku su 2 mašine, jedna se uvijek backupira uspješno, dok druga ponekad ima greške. Na kraju, do sedme tačke došlo je do situacije:

Vrijeme je da se primijeni zadržavanje, ali jedna mašina ima 7 tačaka, a druga samo 4. Hoće li se ovdje primijeniti zadržavanje? Odgovor – da, bit će. Ako je barem jedan objekt bio backupiran, B&R smatra da je tačka stvorena.
Slična situacija može nastati ako neka mašina jednostavno nije uključena u zadatak tijekom određene sesije. To se događa, primjerice, kada su mašine dodane u zadatak ne individualno, već unutar kontejnera (mapa, skladišta), a neka mašina privremeno migrira u drugi kontejner. U takvom slučaju, zadatak će se smatrati uspješnim, ali u statistici ćete pronaći poruku koja poziva da obratite pažnju da ta i ta mašina više ne obrađuje zadatak.
![]()
Što će se dogoditi ako se na to ne obratite pažnju? U slučaju beskonačnog inkrementalnog ili obrnutog inkrementalnog moda, broj točaka oporavka „problematične” mašine smanjivat će se s svakom sesijom, sve dok ne dosegne 1, pohranjenu u VBK. Drugim riječima, čak i ako se mašina ne sigurnosno kopira duže vrijeme, jedna točka oporavka će ostati. Situacija je drugačija s aktivnim povremenim punim sigurnosnim kopijama. Ako se ignorišu signali od B&R, na kraju će se posljednja točka možda izbrisati zajedno sa starim dijelom lanca.
Nakon što se razjasne ovi detalji, konačno se može razmotriti opcija “Remove deleted items data after”. Ona će izbrisati sve točke za određenu mašinu, ako ta mašina ne bude sigurnosno kopirana tijekom X dana. Imajte na umu da ova postavka ne reagira na greške (pokušali smo – nije uspjelo). Ne bi trebala biti niti jedna pokušaj sigurnosnog kopiranja mašine. Naizgled, opcija je korisna i uvijek je trebate držati uključenom. Ako administrator ukloni mašinu iz zadatka, logično je s vremenom očistiti nepotrebne podatke i lanac. Međutim, postavka zahtijeva disciplinu i pažljivost.
Dati ću primjer iz prakse: u zadatak su dodani neki kontejneri, čiji je sastav bio prilično dinamičan. Zbog nedostatka RAM-a, B&R server imao je probleme koji su ostali neprimećeni. Zadatak je pokrenut i pokušao je napraviti backup mašina, osim jedne koja u tom trenutku nije bila prisutna u kontejneru. Budući da su mnoge mašine izdale greške, prema defaultnim postavkama, B&R bi trebao napraviti 3 dodatne pokušaje da napravi backup „problematičnih“ mašina. Zbog stalnih problema s RAM-om, ti su pokušaji trajali nekoliko dana. Nije bilo ponovnog pokušaja da se napravi backup nedostajuće VM (nedostatak VM nije greška). Na kraju, tokom jednog od ponovljenih pokušaja, uslov “Remove deleted items” je izvršen i sve tačke mašine su obrisane.
O ovome mogu reći sljedeće: ako imate podešene obavijesti o ishodima zadataka, a još bolje – koristite integraciju s Veeam ONE, vjerojatno se to s vama neće dogoditi. Ako pak provjeravate B&R server svake nedjelje, kako biste bili sigurni da sve radi, bolje je odustati od opcija koje potencijalno mogu dovesti do brisanja backup-a.
Što je dodano u v.10
Ono o čemu smo do sada govorili, postojalo je u B&R-u kroz mnogo verzija. Razumjevši ove principe rada, pogledajmo sada što je dodano u jubilarnoj „desetki“.
Dnevna retencija
Gore smo razmatrali „klasičnu“ politiku zadržavanja, koja se temelji na broju tačaka. Alternativni pristup – postaviti u istom izborniku “days” umjesto “restore points”.

Ideja je jasna iz naziva – retencija će čuvati postavljeni broj dana, dok broj tačaka u svakom danu nije bitan. Pri tome treba imati na umu sljedeće:
- Trenutni dan se ne uzima u obzir prilikom izračuna retencije
- Dani kada zadatak nije radio uopće, također se računaju. To treba imati na umu, kako ne biste slučajno izgubili tačke onih zadataka koji rade neredovno.
- Tačka za vraćanje računa od dana kada je počela njena izrada (tj. ako je zadatak počeo raditi u ponedjeljak, a završio u utorak, to je tačka od ponedjeljka)
Na ostalom, principi primjene retention-a zadatka i dalje se određuju odabranom metodom backupa. Pokušajmo s još jednim zadatkom za izračun, koristeći istu inkrementalnu metodu. Recimo da je retention postavljen na 8 dana, a zadatak se izvodi svaka 6 sati s punim backupom u srijedu. Pritom zadatak ne radi nedjeljom. Zadatak započinje u ponedjeljak prvi put. Kada će se primijeniti retention?
Odgovor
Kao i obično, najbolje je nacrtati tablicu. Dopustit ću si pojednostaviti zadatak i neću crtati sve točke stvorene svakog dana, jer broj točaka po danu ovdje nije bitan. Važno nam je samo da će u prvi ponedjeljak i srijedom prva točka biti puni backup, dok će na ostale dane zadatak jednostavno stvarati 4 inkrementalne točke.

Razumijemo da će retention biti primijenjen brisanjem ponedjeljkog punog backupa i njegovog inkrementa. Kada će to biti? Kada preostali dio lanca bude sadržavao 8 dana. Pri tome ne računamo trenutni dan, ali nedjelju računamo. Stoga je odgovor – u četvrtak druge sedmice.
Arhiviranje metodom GFS za obične zadatke
Do v.10, metoda čuvanja Grandfather-Father-Son (GFS) bila je dostupna samo za zadatke stvaranja arhivskih kopija (Backup copy) i zadatke kopiranja na magnetsku traku. Sada je dostupna i za običan backup.
Iako to nije direktno povezano s trenutnom temom, ne mogu a da ne kažem da nova funkcionalnost ne znači odstupanje od strategije 3-2-1. Prisutnost arhivskih točaka u glavnom repozitoriju nikako ne utječe na njegovu pouzdanost. Podrazumijeva se da će GFS biti korišten zajedno s proširivim (Scale-out) repozitorijem, za slanje tih točaka u S3 i slične pohrane. Ako ih ne koristite, najbolje je nastaviti čuvati primarne i arhivske točke na različitim repozitorijima.
Sada razmotrimo principe stvaranja GFS točaka. U postavkama zadatka, na koraku Storage, pojavila se posebna tipka koja pokreće sljedeći izbornik:

Suština GFS može se svesti na nekoliko točaka (napominjemo, GFS u drugim vrstama zadataka funkcioniše drugačije, ali o tome malo kasnije):
- Zadatak ne stvara zasebnu punu sigurnosnu kopiju za GFS točku. Umjesto toga, upotrijebit će se najprikladnija puna sigurnosna kopija koja je dostupna. Stoga bi zadatak trebao raditi u inkrementalnom režimu s povremenim punim sigurnosnim kopiranjem, ili bi punu sigurnosnu kopiju trebao stvoriti korisnik ručno.
- Ako je uključen samo jedan period (na primjer, tjedni), tada će na početku GFS perioda zadatak jednostavno početi čekati punu sigurnosnu kopiju i označiti prvu prikladnu kao GFS.
Primjer: zadatak je postavljen da pohranjuje tjedni GFS, koristeći sigurnosnu kopiju u srijedu. Zadatak se izvršava svaki dan, ali puna sigurnosna kopija je zakazana za petak. U ovom slučaju, u srijedu započinje GFS period i zadatak počinje čekati prikladnu točku. Pojavit će se u petak i bit će označena oznakom GFS.

- Ako su uključeni više perioda (na primjer, tjedni i mjesečni), tada će B&R primijeniti metodu koja omogućava korištenje iste točke kao GFS za više intervala (radi štednje prostora). Oznake će biti dodijeljene redom, počevši od najnižeg.
Primjer: tjedni GFS postavljen je na srijedu, a mjesečni na posljednji tjedan mjeseca. Zadatak se izvodi svaki dan i stvara pune sigurnosne kopije ponedjeljkom i petkom.
Radi jednostavnosti, započnimo s pretposljednjim tjednom mjeseca. U tom tjednu će biti stvorena puna sigurnosna kopija u ponedjeljak, ali će biti ignorirana jer tjedni GFS interval počinje u srijedu. Međutim, petkom stvorena puna sigurnosna kopija potpuno odgovara GFS točki. Ovaj sustav nam je već poznat.

Sada razmotrimo što će se dogoditi u posljednjem tjednu mjeseca. Mjesečni GFS interval započet će u ponedjeljak, ali ponedjeljkom stvorena VBK neće biti označena kao GFS, jer zadatak nastoji označiti jedan VBK i kao mjesečnu i kao tjednu GFS točku. Pri tome počinje traženje upravo s tjedne, jer ona po definiciji može postati i mjesečna.

Ako se istodobno uključe samo tjedni i godišnji intervali, tada će djelovati neovisno jedni o drugima i mogu označiti 2 odvojena VBK kao odgovarajuće GFS intervale.
Zadaci za izradu sigurnosnih kopija (Backup copy)
Još jedna vrsta zadataka, koja često zahtijeva objašnjenja o funkcionalnosti. Za početak, razmotrimo „klasičnu“ metodu rada, bez novina v.10
Jednostavna metoda zadržavanja
Po defaultu takvi zadaci rade u beskonačnom inkrementalnom režimu. Kreiranje točaka određuje se s dva parametra – intervalom kopiranja i željenim brojem točaka za vraćanje (retencija po danima ovdje nije prisutna). Interval kopiranja postavlja se na prvoj kartici Job prilikom kreiranja zadatka:

Broj točaka određuje se malo dalje na kartici Target

Zadatak stvara 1 novu točku za svaki interval (broj točaka koje su stvorene za VM izvornih zadataka nema nikakvog značaja). Na kraju intervala nova točka se finalizira i, ako je potrebno, primjenjuje se retencija spajanjem VBK i najstarijeg inkrementa. Ovaj mehanizam nam je već poznat.
Metoda retencije s korištenjem GFS
BCJ također može pohranjivati arhivske točke. Ovo se postavlja na istoj kartici Target, malo ispod postavki broja točaka vraćanja:

GFS točke mogu se stvarati na dva načina – sintetički, korištenjem podataka sa sekundarnog repozitorija, ili imitirajući puni backup i čitajući sve podatke iz primarnog repozitorija (aktivira se opcijom označenom brojem 3). Retencija u oba slučaja će se značajno razlikovati, stoga ćemo ih razmotriti odvojeno.
Sintetički GFS
U ovom slučaju GFS točka ne stvara se točno na odabrani dan. Umjesto toga, GFS točka će se stvoriti kada se VIB tog dana, na koji je bila planirana izrada GFS točke, spoji s punim backupom. Ovo ponekad izaziva nerazumijevanje, jer vrijeme prolazi, a GFS točke nema. I samo moćni šaman iz tehničke podrške može predvidjeti na koji dan će točka na kraju biti stvorena. U stvarnosti, magija nije potrebna – dovoljno je pogledati postavljeni broj točaka i interval sinkronizacije (koliki broj točaka se stvara svaki dan). Pokušajte sami izračunati na sljedećem primjeru: zadatak je postavljen za pohranu 7 točaka, interval sinkronizacije – 12 sati (tj. 2 točke dnevno). Trenutno u lancu već ima 7 točaka, danas je ponedjeljak, i za danas je planirana izrada GFS točke. Na koji dan će ona biti stvorena?
Odgovor
Ovdje je bolje opisati kako će se lanac mijenjati u dinamici, po danima:

Dakle, u ponedjeljak posljednji inkrement u lancu označava se kao GFS, ali ne dolazi do drugih vidljivih promjena. Svakog dana zadatak stvara 2 nove točke, a retention neumoljivo gura lanac naprijed. Konačno, u četvrtak dolazi vrijeme za primjenu retentiona na taj isti inkrement. Ova sesija će trajati duže nego obično – jer će zadatak "izvući" potrebne blokove iz lanca i stvoriti novu kompletnu točku. Od tog trenutka u lancu će biti već 8 točaka – 7 u glavnom lancu + GFS.
Stvaranje GFS točaka s opcijom “Read entire point”
Rekao sam da BCJ radi u beskonačno-incrementalnom modu. Sada ćemo razmotriti jedinu iznimku od ovog pravila. Kada se aktivira opcija “Read entire point”, GFS točka će se stvoriti točno na planirani dan. Sam zadatak će raditi u incrementalnom režimu s povremenim punim backupima, koji smo razmatrali ranije. Retention će se također primijeniti uklanjanjem najstarijeg dijela lanca. Međutim, u ovom slučaju bit će uklonjeni samo inkrementi, dok će kompletan backup ostati kao GFS točka. Stoga, prilikom izračuna retentiona ne uzimaju se u obzir točke označene GFS oznakama.
Pretpostavimo da je zadatak postavljen na pohranjivanje 7 točaka i stvaranje tjedne GFS točke u ponedjeljak. U tom slučaju, svakog ponedjeljka zadatak će zaista stvarati potpuni backup i označavati ga kao GFS. Retention će se primijeniti kada nakon uklanjanja inkrementa iz najstarijeg dijela broj preostalih inkrementa ne padne ispod 7. Tako to izgleda na dijagramu:

Dakle, do kraja drugog tjedna u lancu je ukupno 14 točaka. Tijekom drugog tjedna zadatak je stvorio 7 točaka. Da je to bio običan zadatak, retention bi već bio primijenjen. No, to je BCJ s GFS retentionom, pa GFS točke ne računamo, što znači da ih ima samo 6. Drugim riječima, retention još ne možemo primijeniti. U trećem tjednu stvaramo još jedan potpuni backup s GFS oznakom. 15 točaka, ali ovu opet ne računamo. I konačno, u utorak trećeg tjedna stvaramo inkrement. Sada, ako uklonimo inkrementne točke prvog tjedna, ukupni broj inkremenata zadovoljit će uspostavljeni retention.
Kao što je već spomenuto, u ovoj metodi je vrlo važno da se potpuni back-upi redovito stvaraju. Recimo, ako postavite osnovnu reteniciju na 7 dana, ali samo jednu godišnju točku, lako je zamisliti da će se inkrementi akumulirati znatno više od 7. U takvim slučajevima je bolje koristiti sintetičku metodu stvaranja GFS-a.
I ponovo “Remove deleted items”
Ova opcija također postoji i za BCJ:

Logika ove opcije ovdje je ista kao i u uobičajenim zadacima back-upa – ako mašina ne radi određeni broj dana, njezini se podaci uklanjaju iz lanca. Međutim, za BCJ korisnost ove opcije je objektivno veća, i evo zašto.
U uobičajenom režimu, BCJ radi u beskonačno-inkrementalnom režimu, tako da, ako se u nekom trenutku mašina ukloni iz zadatka, retenicija će postupno ukloniti sve točke oporavka, sve dok ne ostane samo jedna – u VBK. Sada zamislite da je zadatak još uvijek podešen za stvaranje sintetičkih GFS točaka. Kada dođe vrijeme, zadatak će morati stvoriti GFS za sve mašine u lancu. Ako za neku mašinu uopće nema novih točaka – pa, morat ćemo koristiti onu koja postoji. I tako svaki put. Na kraju može nastati ovakva situacija:

Obratite pažnju na odjeljak Files: imamo glavni VBK i 2 tjedne GFS točke. A sada na odjeljak Restore points – u tim datotekama zapravo leži isti slikovni zapis mašine. Naravno, nema smisla u takvim GFS točkama, samo zauzimaju prostor.
Ova situacija moguća je samo uz korištenje sintetičkog GFS-a. Da to spriječite, koristite opciju “Remove deleted items”. Samo ne zaboravite postaviti je na odgovarajući broj dana. Tehnička podrška je vidjela slučajeve kada su ovu opciju postavljali na kraći broj dana od intervala sinkronizacije – BCJ je počela ludovati i brisati točke prije nego što ih je uspjela stvoriti.
Imajte na umu da ova opcija ne pogađa već stvorene GFS točke. Ako želite očistiti arhive, to morate učiniti ručno – desnim klikom na mašinu i odabirom “Delete from disk” (u prozoru koji se pojavi, ne zaboravite označiti kućicu “Remove GFS full backup”):

Novost v.10 – trenutna kopija (immediate copy)
Nakon što smo se upoznali s „klasičnom“ funkcionalnošću, prelazimo na novu. Ima jedna novost, ali vrlo važna. To je novi način rada.

Ovdje ne postoji pojam "interval sinkronizacije", zadatak će neprekidno pratiti ne pojavljuju li se nove točke i kopirati ih sve, bez obzira na njihov broj. Međutim, zadatak ostaje inkrementalan, što znači da, čak i ako glavni zadatak stvara VBK ili VRB, te točke bit će kopirane kao VIB. Inače, u ovom režimu nema iznenađenja – i standardne i GFS retenzije rade prema pravilima opisanima iznad (iako je ovdje dostupan samo sintetički GFS).
Diskovi se okreću. Značajke repozitorija s rotacijom diskova.
Stalna prijetnja ransomware virusima učinila je de facto standardom sigurnosti imati kopiju podataka na mediju do kojeg virus ne može doći. Jedna od opcija je korištenje repozitorija s rotacijom diskova, gdje se diskovi koriste naizmjenično: dok je jedan disk priključen i dostupan za pisanje, ostali se čuvaju na sigurnom mjestu.
Da bi se naučilo B&R raditi s takvim repozitorijima, potrebno je u postavkama repozitorija, na koraku Repository, kliknuti na gumb Advanced i odabrati odgovarajuću opciju:

Nakon toga, VBR će očekivati da će povremeno postojeći lanac nestati iz repozitorija, što znači rotaciju diska. Ovisno o vrsti repozitorija i tipu zadatka, B&R će se različito ponašati. To možemo prikazati ovakvom tablicom:

Razmotrimo svaku opciju.
Obični zadatak i Windows repozitorij.
Dakle, imamo zadatak koji čuva lance na prvom disku. Prilikom rotacije, stvoreni lanac zapravo nestaje i zadatak se mora nekako nositi s tim gubitkom. Tješiti se može stvaranjem potpunog sigurnosnog kopiranja. Na taj način, svaka rotacija znači potpuno sigurnosno kopiranje. No što se događa s točkama na isključenom disku? One se pamte i uzimaju u obzir prilikom izračuna retenzije. Tako je postavljeni broj točaka u zadatku onoliko točaka koliko treba zadržati na svim diskovima. Uzmimo primjer:
Zadatak radi u beskonačno-inkrementalnom režimu i podešen je za pohranu 3 točke oporavka. No, imamo još jedan disk, i jednom tjedno vršimo rotaciju (diskova može biti više, to ne mijenja suštinu).
U prvom tjednu zadatak će kreirati točke na prvom disku i spajati suvišne. Tako će ukupni broj točaka biti tri:

Zatim povezujemo drugi disk. Kada se B&R pokrene, primijetit će da je disk zamijenjen. Lanac na prvom disku nestat će iz sučelja, ali će informacije o njemu ostati u bazi. Sada zadatak će zadržati 3 točke na drugom disku. Ukupna situacija bit će sljedeća:

Na kraju ponovo povezujemo prvi disk. Prije nego što stvorimo novu točku, zadatak će provjeriti stanje s retention-om. A retention, podsjećam, postavljen je da zadrži 3 točke. U međuvremenu imamo 3 točke na disku 2 (ali je on isključen i pohranjen na sigurnom mjestu, do kojeg B&R ne može doći) i 3 točke na disku 1 (a ovaj je priključen). To znači da se možemo mirno riješiti 3 točke s diska 1, jer premašuju retention. Nakon toga zadatak ponovno stvara cjelovitu sigurnosnu kopiju, a naš lanac počinje izgledati ovako:

Ako je retention postavljen da čuva dane umjesto broja točaka, logika se ne mijenja. Osim toga, GFS retention se uopće ne podržava prilikom korištenja repozitorija s rotacijom diskova.
Uobičajeni zadatak i Linux repozitorij mrežno pohranjivanje.
Ova opcija je također moguća, ali u cjelini manje preporučena zbog nametnutih ograničenja. Na rotaciju diska i nestanak lanca zadatak će reagirati na isti način – stvaranjem cjelovite sigurnosne kopije. Ograničenje se odnosi na skraćeni mehanizam retention-a.
Kod rotacije cijeli lanac na isključenom disku jednostavno se briše iz baze podataka B&R. Imajte na umu – iz baze podataka, sami datoteke ostaju na disku. Mogu se uvesti i koristiti za vraćanje, ali nije teško pogoditi da će prilično brzo takvi zaboravljeni lanci ispuniti cijeli repozitorij.
Rješenje je dodavanje DWORD ForceDeleteBackupFiles kao što je navedeno na ovoj stranici: . Nakon toga zadatak će jednostavno početi brisati sve sadržaje mape zadatka ili mape repozitorija (ovisno o vrijednosti) pri svakoj rotaciji.
Međutim, ovo nije elegantan retention, već upravo čišćenje cijelog sadržaja. Nažalost, tehnička podrška susrela se s slučajevima kada je kao repozitorij bio naveden samo korijenski katalog diska, gdje su osim sigurnosnih kopija bile smještene i druge podatke. Sve to je uništeno prilikom rotacije.
Osim toga, kada je omogućena opcija ForceDeleteBackupFiles, radi za sve tipove repozitorija, što znači da će čak i repozitoriji na Windows-u prestati primjenjivati zadržavanje i početi brisati sadržaj. Drugim riječima, lokalni disk na Windows-u je najbolji izbor za ovakav sistem skladištenja backup-a.
Backup copy i Windows repozitorij
Sa BCJ-om sve postaje još zanimljivije. Osim toga, ovdje postoji potpuni sistem zadržavanja, ali nije potrebno raditi pun backup prilikom svake promjene diska! Ovo radi na sljedeći način:
Prvo B&R počinje stvarati točke na prvom disku. Recimo, postavili smo zadržavanje na 3 točke. Zadatak će raditi u beskonačno-incrementalnom režimu i spajati sve suvišne (podsjećam, GFS zadržavanje u ovom slučaju nije podržano).

Zatim povezuje drugi disk. Pošto na njemu još nema lanca, stvaramo puni backup, nakon čega imamo drugi lanac sa tri točke:

Na kraju, dolazi vrijeme da se ponovo poveže prvi disk. I tu počinje magija, jer zadatak neće stvoriti puni backup, već će jednostavno nastaviti incrementalan lanac:

Nakon toga, na svakom disku zapravo će postojati svoj neovisni lanac. Stoga zadržavanje ovdje ne znači broj točki na svim diskovima, već broj točki na svakom disku zasebno.
Backup copy i Linux repozitorij, mrežno skladište
I ponovo, cijela elegancija nestaje ako repozitorij nije na lokalnom disku Windows. Ovaj scenarij radi slično onome razmotrenom ranije s jednostavnim zadatkom. Prilikom svake rotacije BCJ će stvarati puni backup, a postojeće točke će biti zaboravljene. Da ne ostanete bez slobodnog prostora, potrebno je koristiti DWORD ForceDeleteBackupFiles.
Zaključak
Dakle, kao rezultat ovog dugog teksta razmotrili smo dva tipa zadataka. Naravno, postoji mnogo više zadataka, ali nije moguće obraditi ih sve u formatu jednog članka. Ako imate bilo kakva pitanja nakon čitanja, pišite ih u komentarima, rado ću odgovoriti osobno.
Izvor: habr.com
