Pozdravljam bralce našega bloga! Delno smo si že znani – moji angleško pisani prispevki so se tukaj pojavljali v prevodu moje drage kolegice. . Tokrat sem se odločil, da se neposredno obrnem na rusko govorečo publiko.
Za svoj debi sem želel najti temo, ki bi zanimala široko občinstvo in zahtevala podrobno obravnavo. Daniel Defo je trdil, da vsakega človeka čakajo smrt in davki. S svoje strani lahko rečem, da vsak tehnični inženir pričakuje vprašanja o pravilnikih o shranjevanju točk obnovitve (ali poenostavljeno – retenciji). Kako deluje retencija, sem začel razlagati pred 4 leti, ko sem bil mlajši inženir prve ravni, in še vedno jo razlagam zdaj, ko sem že vodja hispansko in italijansko govoreče ekipe. Prepričan sem, da moji kolegi iz druge in celo tretje ravni podpore redno odgovarjajo na ista vprašanja.
V tem kontekstu me je zamikalo napisati končen, kar se da podroben prispevek, ki bi se ga rusko govoreči uporabniki lahko znova in znova vračali kot k priročniku. Čas je primeren – nedavno izdana jubilejna deseta različica je dodala nove možnosti osnovni funkcionalnosti, ki se ni spremenila že leta. Moj prispevek je predvsem usmerjen na to različico – čeprav je večina napisanega pravilna tudi za prejšnje različice, boste nekaterih opisanih funkcionalnosti preprosto ne našli. Nazadnje, če malo pogledamo v prihodnost, naj povem, da se v naslednji različici pričakujejo nekatere spremembe, o tem pa bomo govorili, ko bo prišel čas. Torej, začnimo.
Opravljanje varnostnih kopij (Backup job)
Najprej bomo obravnavali tisti del, ki se ni spremenil v različici 10. Politiko retencije določajo več parametrov. Odprimo okno za ustvarjanje novega opravila in pojdimo na zavihek Shranjevanje. Tukaj bomo videli parameter, ki določa želeno število točk obnovitve:
Vendar pa je to le del enačbe. Dejanska številka točk je prav tako določena z načinom varnostnih kopij, nastavljenim za nalogo. Da izberete ta parameter, morate klikniti gumb Napredno na istem zavihku. To odpre novo okno z mnogimi možnostmi. Številčimo jih in jih preučimo zaporedoma:
Če aktivirate samo opcijo 1, bo naloga delovala v "neprekinjenem inkrementalnem" načinu (forever forward incremental). Tu ni nikakršnih zapletov – naloga bo shranjevala nastavljeno število točk obnovitve od celotne varnostne kopije (datoteka s končnico VBK) do zadnjega inkrementa (datoteka s končnico VIB). Ko število točk preseže nastavljeno vrednost, se najstarejši inkrement združi s celotno varnostno kopijo. Z drugimi besedami, če je naloga nastavljena na shranjevanje 3 točk, bo takoj po naslednji seji v repozitoriju 4 točke, nato se bo celotna varnostna kopija združila z najstarejšim inkrementom in skupno število točk se bo vrnilo na 3.
Tudi retencija za "obratno inkrementalno" (reverse incremental) stanje (opcija 2) je izjemno preprosta. Ker je v tem primeru najnovejša točka celotna varnostna kopija, za katero sledi veriga tako imenovanih rollbakov (datoteke s končnico VRB), je za uporabo retencije dovolj, da preprosto izbrišemo najstarejši rollbak. Situacija bo enaka: takoj po seji bo število točk preseglo nastavljeno za 1, nato se bo vrnilo na želeno vrednost.
Upoštevajte, da je mogoče pri obratno inkrementalnem načinu vključiti tudi periodično celotno varnostno kopijo (opcija 4), vendar to ne spremeni bistva. Da, v verigi se bodo pojavile celotne točke obnovitve, vendar bomo še naprej preprosto brisali najstarejše točke eno po eno.
Nazadnje pridemo do zanimivega dela. Če aktivirate inkrementalno varnostno kopijo, hkrati pa vključite možnosti 3 ali 4 (ali pa obe hkrati), bo naloga začela ustvarjati periodične celotne varnostne kopije na "aktiven" ali sintetičen način. Metoda ustvarjanja celotne varnostne kopije ni pomembna – vsebovala bo iste podatke, inkrementalna veriga pa bo razdeljena na "podverige". Takšna metoda se imenuje forward incremental in prav ta povzroča znaten del vprašanj naših strank.
Retencija se ovde primenjuje brisanjem najstarijeg dela lanca (od punog backup-a do inkrementa). Pri tome nećemo brisati samo prazni backup ili samo deo inkremenata. Celi "podlanac" se uklanja kompletno odjednom. Menja se i smisao podešavanja broja tačaka – dok je u drugim metodama to maksimalan dozvoljeni broj, posle kojeg treba primeniti retenciju, ovde ovo podešavanje definiše minimalni broj. Drugim rečima, nakon brisanja najstarijeg "podlanca", broj tačaka u preostalom delu ne sme pasti ispod ovog minimuma.
Pokušaću da grafički prikažem ovu koncept. Recimo da je retencija postavljena na 3 tačke, a zadatak se pokreće svaki dan sa punim backup-om u ponedeljak. Retencija će se primeniti kada ukupni broj tačaka dostigne 10:
Zašto čak 10, kada je postavljeno 3? U ponedeljak je napravljen puni backup. Od utorka do nedelje zadatak je pravio inkremenate. Konačno, sledećeg ponedeljka ponovo se pravi puni backup i tek kada su stvorena 2 inkrementa, može se obrisati cela stara deo lanca, jer preostali broj tačaka ne može pasti ispod postavljenih 3.
Ako je ideja jasna, predlažem da pokušate sami da izračunate retenciju. Uzećemo sledeće uslove: zadatak se pokreće prvi put u četvrtak (naravno, biće napravljen puni backup). Zadatak je postavljen da pravi pun backup svake srede i nedelje i čuva 8 tačaka obnavljanja. Kada će se retencija prvi put primeniti?
Da biste odgovorili na ovo pitanje, preporučujem da uzmete papir, podelite ga po danima u nedelji i zapišete koja tačka se stvara svakog dana. Odgovor će biti očigledan.
Odgovor
Objašnjenje: da biste odgovorili, dovoljno je pitati se "kada će se primeniti retencija"? Odgovor – kada možemo obrisati prva 3 tačke (VBK, VIB, VIB) a preostala lanac ne padne ispod postavljenih 8 tačaka. Postaje jasno da ćemo to moći učiniti kada budemo imali ukupno 11 tačaka, tj. u nedelju druge nedelje.
Neki čitaoci mogu prigovarati: "zašto sve ovo, kada postoji ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Nazad, nismo razmotrili 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 rezervnu kopiju. U međuvremenu, ova opcija aktivira jedinstveni režim rezervne kopije. Nepotrebno je objašnjavati, odmah ću reći da je u trenutnoj fazi razvoja proizvoda "Transform previous backup chains into rollbacks" - zastarjela opcija, i ne mogu smisliti nijedan scenarij u kojem bi je trebalo koristiti. Njena vrednost je toliko sumnjiva da je neko vreme Anton Gostev pozivao putem foruma da mu pošalju primere njene korisnosti (ako ih imate, pišite u komentarima, veoma sam zainteresovan). Ako ih ne bude (mislim da neće), opcija će biti uklonjena u narednim verzijama.
Zadatak će kreirati inkremente (VIB) do dana kada je zakazana sintetička puna rezervna kopija. Tog dana se zapravo kreira VBK, ali sve tačke do tog VBK se transformišu u rolbeke (VRB). Nakon toga, zadatak će nastaviti da stvara inkremente ka punoj rezervnoj kopiji do sledeće sintetičke rezervne kopije. Na kraju se u lancu stvara mešavina VBK, VBR i VIB fajlova. Retenšn se primenjuje vrlo jednostavno – brisanjem poslednjeg VBR:
Težave
Pored samog razumevanja kako to funkcioniše, većina problema koji se javljaju prilikom korišćenja inkrementalnog režima obično je povezana sa punom rezervnom kopijom. Redovno puna rezervna kopija je neophodna ovom režimu, inače će repozitorijum gomilati tačke dok se ne prepuniti.
Na primer, puna rezervna kopija može se praviti previše retko. Recimo, zadatak je postavljen da čuva 10 tačaka, a puna rezervna kopija se stvara jednom mesečno. Jasno je da će stvarni broj tačaka ovde 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 stvorio punu rezervnu kopiju. Sve, od sada će zadatak čekati dok puna tačka ne skupi 49 inkremenata, nakon čega će primeniti retenšn i vratiti se u beskonačno-puni režim.
V drugih primerih se popoln varnostni kopija nastavi na redno ustvarjanje, vendar iz nekega razloga to ne poteka. Tukaj bom opisal najpogostejši razlog. Nekateri klienti raje uporabljajo možnost urnika "run after" in konfigurirajo naloge, da delujejo v verigi. Vzemimo tak primer: imamo 3 naloge, ki delujejo vsak dan in ustvarjajo popoln varnostni kopijo ob nedeljah. Prva naloga se začne ob 22.30, ostale se zaženejo v verigi. Inkrementalni varnostni kopija traja 10 minut, zato do 23.00 vse naloge končajo. Popolni varnostni kopija pa traja eno uro, zato se ob nedelji zgodi to: prva naloga dela od 22.30 do 23.30. Naslednja od 23.30 do 00.30. Tretja naloga se zažene že v ponedeljek. Popolni varnostni kopija je nastavljen na nedeljo, zato v tem primeru ne bo na voljo. Naloga bo čakala na popolni varnostni kopijo, da uporabi zadrževanje. Zato bodite previdni pri uporabi možnosti "run after" ali je sploh ne uporabljajte – preprosto nastavite naloge, da se začnejo istočasno in pustite, da razporejevalnik virov opravi svoje delo.
Zahtevna možnost "Remove deleted items"
Če ste preučili nastavitve naloge Shranjevanje – Napredno – Vzdrževanje, lahko naletite na možnost "remove deleted items data after", ki se izračuna v dnevih.
Nekateri klienti pričakujejo, da je to zadrževanje. V resnici pa gre za povsem ločeno možnost, ki jo razumevanje lahko privede do nepričakovanih posledic. Vendar pa je najprej treba razložiti, kako B&R reagira na situacije, ko se med sejo uspešno varnostno kopirajo le nekatere naprave.
Predstavljamo si takšen scenarij: neskončno-incrementalna naloga, nastavljena za shranjevanje 6 točk. V nalogi sta 2 napravi, ena se vedno uspešno kopira, druga pa občasno povzroča napake. Na koncu do sedme točke nastane taka situacija:
Čas je za uporabo zadrževanja, vendar ima ena naprava 7 točk, druga pa le 4. Ali bo zadrževanje tukaj uporabljeno? Odgovor je – da, bo. Če je bila vsaj ena enota varnostno kopirana, B&R šteje, da je bila točka ustvarjena.
Podobna situacija se lahko zgodi, če določena naprava preprosto ni bila vključena v nalogo med določenim sejanjem. To se zgodi, na primer, ko so naprave dodane v nalogo neindividualno, temveč kot del vsebnikov (mape, skladišča), in neka naprava začasno migrira v drug vsebnik. V takem primeru se bo naloga štela za uspešno, vendar boste v statistiki našli sporočilo, ki vas opozarja, da se določena naprava več ne obdeluje v nalogi.
Kaj se zgodi, če tega ne upoštevamo? V primeru neskončne inkrementalne ali obratno inkrementalne metode se bo število točk obnovitve 'problematične' naprave z vsakim sejanjem zmanjševalo, dokler ne doseže 1, shranjene v VBK. Z drugimi besedami, tudi če naprava dolgo ne bo varnostno kopirana, bo ena točka obnovitve še vedno ostala. Drugače je, če so vključene občasne popolne varnostne kopije. Če ignorirate signale iz B&R, lahko na koncu zadnjo točko izbrišete skupaj s starim delom verige.
Ko razumemo te podrobnosti, lahko končno obravnavamo možnost 'Remove deleted items data after'. Ta bo izbrisala vse točke za določeno napravo, če ta naprava ne bo varnostno kopirana v X dneh. Upoštevajte, da ta nastavitev ne reagira na napake (poskusili smo - ni šlo). Ne bi smelo biti niti poskusa varnostnega kopiranja naprave. Zdi se, da je ta možnost uporabna in bi jo morali vedno imeti vklopljeno. Če je administrator izbrisal napravo iz naloge, je logično, da jo po nekem času očistimo od odvečnih podatkov in verige. Vendar nastavitev zahteva discipline in pozornost.
Пример из практики: в задании были добавлены несколько контейнеров, чей состав оказался довольно динамичным. Из-за недостатка ОЗУ сервер B&R столкнулся с проблемами, которые остались незамеченными. Задание запустилось и попыталось создать бэкап всех машин, кроме одной, которая на тот момент отсутствовала в контейнере. Поскольку многие машины выдали ошибки, по умолчанию B&R должен был сделать три дополнительные попытки сохранить бэкап «проблемных» машин. Вследствие постоянных проблем с ОЗУ, эти попытки затянулись на несколько дней. Повторной попытки создать бэкап отсутствующей ВМ не было (отсутствие ВМ — это не ошибка). В итоге, во время одной из повторных попыток было выполнено условие “Удалить удаленные элементы” и все точки машины были удалены.
По этому вопросу могу сказать следующее: если у вас настроены оповещения о результатах заданий, а еще лучше — используется интеграция с Veeam ONE, то, вероятно, с вами этого не произойдет. Если же вы проверяете сервер B&R раз в неделю, чтобы удостовериться, что все работает, то лучше отказаться от опций, которые могут привести к удалению бэкапов.
Что добавлено в v.10
То, о чем мы говорили ранее, существовало в B&R на протяжении многих версий. Теперь, усвоив эти принципы работы, давайте посмотрим, что нового в юбилейной «десяточке».
Ежедневное хранение
Мы уже рассматривали «классическую» политику хранения, основанную на количестве точек. Альтернативный подход — установить в том же меню “дни” вместо “точек восстановления”.
Идея ясна из названия — хранение будет поддерживать установленное количество дней, а количество точек в каждом дне не имеет значения. При этом нужно учитывать следующее:
- Текущий день не считается при расчете хранения
- Дни, когда задание не работало совершенно, также учитываются. Это стоит помнить, чтобы случайно не потерять точки тех заданий, которые работают нерегулярно.
- Точка восстановления считается с того дня, когда началось ее создание (т. е. если задание начало работать в понедельник и закончилось во вторник, то эта точка считается с понедельника)
V ostalem so načeli uporabe retenzije nalog še vedno določajo izbrana metoda varnostnega kopiranja. Poskusimo z novo nalogo za izračun, pri čemer uporabimo enak inkrementalni način. Recimo, da je retenzija nastavljena na 8 dni, naloga pa deluje vsake 6 ur s popolnim varnostnim kopiranjem ob sredah. Naloga ne deluje v nedeljo. Prvič se naloga zažene v ponedeljek. Kdaj bo uporabljena retenzija?
Odgovor
Kot vedno je najbolje narisati tabelo. Dovolite, da poenostavim nalogo in ne bom risal vseh točk, ustvarjenih vsak dan, saj število točk na dan tukaj ni pomembno. Pomembno nam je samo, da bo prva točka ob prvem ponedeljku in ob sredah popolno varnostno kopiranje, v ostalih dneh pa bo naloga preprosto ustvarila 4 inkrementalne točke.
Ugotavljamo, da bo retenzija uporabljena z izbrisom ponedeljkovega popolnega varnostnega kopiranja in njegovega inkrementa. Kdaj se bo to zgodilo? Ko bo preostali del verige vseboval 8 dni. Pri tem ne šteješ današnjega dne, nedelja pa se šteje. Zato je odgovor – v četrtek drugega tedna.
Arhiviranje z metodo GFS za običajne naloge
Do v.10 je bila metoda shranjevanja Grandfather-Father-Son (GFS) na voljo samo za naloge ustvarjanja varnostnih kopij (Backup copy) in naloge kopiranja na magnetne trakove. Zdaj pa je na voljo tudi za običajno varnostno kopiranje.
Čeprav to ne sodi v trenutne teme, ne morem, da ne bi omenil, da nova funkcionalnost ne pomeni odstopanja od strategije 3-2-1. Prisotnost arhivskih točk v glavnem repozitoriju nikakor ne vpliva na njegovo zanesljivost. Predvideva se, da se bo GFS uporabljal skupaj z razširljivim (Scale-out) repozitorijem, za prenos teh točk v S3 in podobne shranjevanja. Če jih ne uporabljate, je bolje, da nadaljujete s shranjevanjem primarnih in arhivskih točk na različnih repozitorijih.
Zdaj si oglejmo načela ustvarjanja GFS točk. V nastavitvah naloge, v koraku Shranjevanje, je pojavila posebna gumb, ki kliče naslednje meni:
Bistvo GFS lahko strnemo v več točk (uporabite pozornost, GFS v drugih vrstah nalog deluje drugače, a o tem kasneje):
- Zadanie ne ustvarja ločenega popolnega varnostnega kopiranja za GFS točko. Namesto tega bo uporabljen najprimernejši popoln backup iz razpoložljivih. Zato mora naloga delovati v inkrementalnem načinu s periodičnim popolnim varnostnim kopiranjem, ali pa mora uporabnik ročno ustvariti popolno varnostno kopijo.
- Če je vključen le en obdobje (na primer tedensko), bo naloga na začetek GFS obdobja preprosto začela čakati na popolno varnostno kopijo in označila prvo primerno kot GFS.
Primer: naloga je nastavljena, da shranjuje tedenski GFS, z uporabo varnostne kopije v sredo. Naloga deluje vsak dan, vendar je popoln backup načrtovan za petek. V tem primeru se bo v sredo začelo GFS obdobje in naloga bo začela čakati na primerno točko. Ta se bo pojavila v petek in bo označena z zastavico GFS.
- Če je hkrati vključenih več obdobij (na primer tedensko in mesečno), bo B&R uporabil metodo, ki omogoča uporabo iste točke kot GFS za več intervalov (za varčevanje s prostorom). Zastavice bodo dodeljene zaporedno, začenši z mlajšimi.
Primer: tedenski GFS je nastavljen na sredo, mesečni pa na zadnji teden meseca. Naloga deluje vsak dan in ustvarja popolne varnostne kopije ob ponedeljkih in petkih.
Za poenostavitev začnimo štetje s predzadnjim tednom meseca. V tem tednu bo v ponedeljek ustvarjena popolna varnostna kopija, vendar bo prezrta, ker tedensko GFS obdobje začne v sredo. Vendar bo petkova popolna varnostna kopija popolnoma primerna za GFS točko. Ta sistem nam je že znan.
Zdaj poglejmo, kaj se bo zgodilo v zadnjem tednu meseca. Mesečno GFS obdobje se začne v ponedeljek, vendar ponedeljkov VBK ne bo označen kot GFS, ker naloga želi označiti en VBK tako kot mesečno kot tedensko GFS točko. Pri tem se začne iskanje natančno od tedenske, ker ta po definiciji lahko postane tudi mesečna.
Če pa vključimo le tedenske in letne intervale, bodo delovali neodvisno drug od drugega in lahko označijo 2 ločeni VBK kot ustrezna GFS intervala.
Naloge za ustvarjanje arhivske kopije (Backup copy)
Še en tip nalog, ki pogosto zahteva pojasnila o delovanju. Za začetek razčlenimo 'klasično' metodo dela, brez novosti v v.10.
Preprost način ohranjanja.
Privzeto so taka zadachi delujejo v neskončnem inkrementalnem načinu. Ustvarjanje točk je določeno z dvema parametroma – intervalom kopiranja in želenim številom točk za obnovitev (tu ni retencije po dnevih). Interval kopiranja se nastavi na prvi zavihek Job ob ustvarjanju naloge:
Število točk pa je določeno nekoliko naprej na zavihku Target
Naloga ustvari 1 novo točko za vsak interval (koliko točk je bilo ustvarjenih za VM z izvorno nalogo, nima vrednosti). Na koncu intervala se nova točka finalizira in, če je to potrebno, se uporabi retencija z združevanjem VBK in najstarejšega inkrementa. Ta mehanizem nam je že znan.
Metoda retencije z uporabo GFS
BCJ tudi zna hraniti arhivske točke. To se nastavi na istem zavihku Target, nekoliko nižje od nastavitev števila točk za obnovitev:
GFS točke se lahko ustvarjajo na dva načina – sintetično, z uporabo podatkov na sekundarnem repozitoriju, ali pa s posnemanjem celotnega varnostnega kopiranja in branjem vseh podatkov iz primarnega repozitorija (aktivira se z opcijo, označeno s številko 3). Retencija v obeh primerih se bo močno razlikovala, zato ju bomo obravnavali ločeno.
Sintetični GFS
V tem primeru GFS točka ni ustvarjena točno na določen dan. Namesto tega bo GFS točka ustvarjena, ko bo VIB tistega dne, na katerega je bilo načrtovano ustvarjanje GFS točke, združen s celotnim varnostnim kopiranjem. To včasih povzroča zmedo, saj čas mineva, GFS točke pa še ni. In samo mogočni šaman iz tehnične podpore lahko napove, katerega dne bo točka dejansko ustvarjena. V resnici magija ni potrebna – dovolj je, da pogledate na določeno število točk in interval sinhronizacije (koliko točk se ustvari vsak dan). Poskusite izračunati sami na takem primeru: naloga je nastavljena za shranjevanje 7 točk, interval sinhronizacije – 12 ur (tj. 2 točki na dan). Trenutno je v verigi že 7 točk, danes je ponedeljek in za ta dan je načrtovano ustvarjanje GFS točke. Kdaj bo ta točka ustvarjena?
Odgovor
Tukaj je bolje opisati, kako se bo veriga spreminjala v dinamiki, po dnevih:
Torej, v ponedeljek je zadnji inkrement v verigi označen kot GFS, vendar se ne zgodijo nobene druge vidne spremembe. Vsak dan naloga ustvari 2 novi točki, in zadrževanje neomejeno premika verigo naprej. Končno, v četrtek pride čas, da se zadrževanje uporabi na istem inkrementu. Ta seja bo trajala dlje kot običajno – ker bo naloga "izvlekla" potrebne bloke iz verige in ustvarila novo popolno točko. Od tega trenutka bo v verigi že 8 točk – 7 v osnovni verigi + GFS.
Ustvarjanje GFS točk z možnostjo “Preberi celo točko”
Zgoraj sem povedal, da BCJ deluje v neskončno inkrementalnem načinu. Zdaj bomo razmislili o edini izjavi iz tega pravila. Ko je izbrana možnost “Preberi celo točko”, bo GFS točka ustvarjena točno na načrtovan dan. Naloga pa bo delovala v inkrementalnem načinu z občasnimi popolnimi varnostnimi kopijami, ki smo jih obravnavali zgoraj. Zadrževanje se bo prav tako uporabilo z brisanjem najstarejšega dela verige. Vendar pa bodo v tem primeru odstranjeni samo inkrementi, medtem ko bo popolna varnostna kopija ostala kot GFS točka. Tako se pri izračunu zadrževanja ne upoštevajo točke, označene z GFS oznakami.
Recimo, da je naloga nastavljena za shranjevanje 7 točk in ustvarjanje tedenske GFS točke v ponedeljek. V tem primeru bo naloga v ponedeljek dejansko ustvarila popolno varnostno kopijo in jo označila kot GFS. Zadrževanje se bo uporabilo, ko se po brisanju inkrementov iz najstarejšega dela število preostalih inkrementov ne bo znižalo pod 7. Tako to izgleda na shemi:
Torej, do konca drugega tedna bo v verigi skupno 14 točk. V drugem tednu je naloga ustvarila 7 točk. Če bi šlo za preprosto nalogo, bi se zadrževanje že uporabilo. Toda to je BCJ z GFS zadrževanjem, zato GFS točk ne upoštevamo, kar pomeni, da jih je le 6. To pomeni, da zadrževanja še ne moremo uporabiti. V tretjem tednu ustvarimo še eno popolno varnostno kopijo z GFS oznako. 15 točk, toda te zopet ne upoštevamo. In nazadnje, v torek tretjega tedna ustvarimo inkrement. Zdaj, če izbrišemo inkremente verige prvega tedna, bo skupno število inkrementov zadovoljilo nastavljeno zadrževanje.
Kot sem že omenil, je v tej metodi zelo pomembno, da se popolni varnostni kopiji redno ustvarjajo. Recimo, če je glavni retention nastavljen na 7 dni, vendar le na 1 letno točko, ni težko predstavljati, da bo inkrementov nastalo veliko, veliko več kot 7. V takih primerih je bolje uporabiti sintetično metodo ustvarjanja GFS.
Še enkrat „Odstrani izbrisane elemente“
Ta opcija je prisotna tudi za BCJ:
Logika te opcije je tukaj enaka kot pri običajnih nalogah za varnostno kopiranje – če naprava ni obdelovana določeno število dni, se njeni podatki izbrišejo iz verige. Vendar pa je objektivna korist te možnosti za BCJ večja in to je razlog.
V običajnem načinu BCJ deluje v neskončno inkrementalnem načinu, zato, če se v nekem trenutku naprava izbriše iz naloge, bo retention postopoma izbrisal vse točke obnovitve, dokler ne ostane le ena – v VBK. Zdaj si zamislimo, da je naloga še vedno nastavljena za ustvarjanje sintetičnih GFS točk. Ko pride čas, bo naloga morala ustvariti GFS za vse naprave v verigi. Če ima katera naprava povsem nove točke – no, uporabiti bo treba tisto, kar je na voljo. In tako vsakič. Na koncu lahko nastane taka situacija:
Upoštevajte odsek Files: imamo osnovni VBK in 2 tedenski GFS točki. In zdaj poglejmo odsek Restore points – v teh datotekah se dejansko nahaja ista slika naprave. Seveda, takšne GFS točke nimajo nobenega smisla, le zasedajo prostor.
Takšna situacija je možna le pri uporabi sintetičnega GFS. Da se to ne bi zgodilo, uporabite opcijo „Odstrani izbrisane elemente“. Ne pozabite jo nastaviti na ustrezno število dni. Tehnička podpora je videla primere, ko so opcijo nastavili na manj dni kot je interval sinhronizacije – BCJ je začel divjati in brisati točke, preden jih je uspel ustvariti.
Upoštevajte tudi, da ta opcija ne vpliva na že ustvarjene GFS točke. Če želite očistiti arhive, to morate storiti ročno – s klikom desne miške na napravo in izbiro „Izbriši z diska“ (v pojavnem oknu ne pozabite označiti „Odstrani GFS polno varnostno kopijo“):
Novost v v.10 – takojšnja kopija (immediate copy)
Po razumevanju „klasične“ funkcionalnosti preidimo na novost. Novost je ena, a zelo pomembna. To je nov način delovanja.
Tu ni obstaja izraz "interval sinhronizacije"; naloga bo nenehno spremljala, ali so se pojavile nove točke, in jih kopirala vse, ne glede na število. Vendar naloga ostaja inkrementalna, kar pomeni, da tudi če glavna naloga ustvari VBK ali VRB, bodo te točke kopirane kot VIB. V vseh drugih pogledih v tem načinu ni presenečenj – tako standardna kot GFS ohranjanja delujeta po pravilih, opisanih zgoraj (vendar je tukaj na voljo samo sintetični GFS).
Diski se vrti. Značilnosti repozitorijev z rotacijo diskov (rotated drives)
Neprekinjena grožnja virusov-šifrantov je de facto standard varnosti uvedla, da imajo podatki kopijo na nosilcu, do katerega virus ne more priti. Ena od možnosti je uporaba repozitorijev z rotacijo diskov, ko se diski uporabljajo izmenično: medtem ko je en disk priključen in dostopen za pisanje, drugi shranjujejo na varnem mestu.
Za učenje B&R o takih repozitorijih je treba v nastavitvah repozitorija, na koraku Repository, klikniti gumb Advanced in izbrati ustrezno možnost:
Po tem bo VBR pričakoval, da bo občasno obstoječa veriga izginila z repozitorija, kar pomeni rotacijo diska. Glede na tip repozitorija in vrsto naloge se bo B&R obnašal različno. To lahko predstavimo s takšno tabelo:
Poglejmo vsako možnost.
Običajna naloga in Windows repozitorij
Torej imamo nalogo, ki shranjuje verige na prvi disk. Pri rotaciji ustvarjena veriga dejansko izgine, naloga pa se mora na nek način spoprijeti s to izgubo. Tolažbo najde v ustvarjanju popolnega varnostnega kopiranja. Tako vsaka rotacija pomeni popolno varnostno kopijo. Kaj pa se zgodi s točkami na izklopljenem disku? Te se zabeležijo in upoštevajo pri izračunu ohranjanja. Tako število točk, določenih v nalogi, predstavlja, koliko točk je potrebno obdržati na vseh diskih. Prikazujemo primer:
Naloga deluje v neskončnem inkrementalnem načinu in je nastavljena na shranjevanje 3 točk obnove. Imamo še en disk in enkrat na teden izvajamo rotacijo (diskov je lahko več, kar ne spremeni bistva).
V prvem tednu bo naloga ustvarjala točke na prvem disku in združila odvečne. Tako bo skupno število točk enako trem:
Nato povežemo drugi disk. Ob zagonu B&R bo opazil, da se je disk spremenil. Veriga na prvem disku bo izginila iz vmesnika, vendar bo informacija o njej ostala v bazi. Zdaj bo naloga ohranjala 3 točke na drugem disku. Skupna situacija bo naslednja:
Nazadnje ponovno povežemo prvi disk. Pred ustvarjanjem nove točke bo naloga preverila, kako je s shranjevanjem. Shranjevanje je, kot spominjam, nastavljeno na ohranitev 3 točk. Medtem pa imamo 3 točke na disku 2 (a ta je izklopljen in shranjen na varnem mestu, kamor B&R ne more dostopati) in 3 točke na disku 1 (ta pa je povezan). To pomeni, da lahko brez skrbi izbrišemo 3 točke z diska 1, saj presega shranjevanje. Po tem naloga ponovno ustvari popoln varnostni kopijo in naša veriga začne izgledati tako:
Če je shranjevanje nastavljeno za ohranjanje dni namesto števila točk, se logika ne spremeni. Poleg tega GFS shranjevanje sploh ni podprto pri uporabi repozitorijev z rotacijo diskov.
Navadna naloga in Linux repozitorij omrežno shranjevanje
Ta možnost je tudi možna, vendar je na splošno manj priporočljiva zaradi nalaganih omejitev. Naloga se na rotacijo diska in izginotje verige odzove na enak način – z ustvarjanjem popolne varnostne kopije. Omejitev pa je povezana z omejenim mehanizmom shranjevanja.
Tukaj se pri rotaciji cela veriga na izklopljenem disku preprosto izbriše iz baze podatkov B&R. Upoštevajte – iz baze podatkov, sami datoteki pa ostanejo na disku. Te lahko uvozite in uporabite za obnovitev, vendar ni težko uganiti, da bodo prej ali slej te pozabljene verige zapolnile celoten repozitorij.
Rešitev je v dodajanju DWORD ForceDeleteBackupFiles, kot je navedeno na tej strani: . Po tem bo naloga začela preprosto brisati vsebino mape naloge ali mape repozitorija (odvisno od vrednosti) pri vsaki rotaciji.
Vendar to ni eleganten način shranjevanja, temveč preprosto čiščenje vsebine. Na žalost so se tehniki pri podpori srečali s primeri, ko je bil kot repozitorij naveden preprosto korenski katalog diska, kjer poleg varnostnih kopij ležali tudi drugi podatki. Vse to je bilo uničeno pri rotaciji.
Poleg tega, ko je aktivirana možnost ForceDeleteBackupFiles, deluje za vse vrste repozitorijev, kar pomeni, da celo repozitoriji v sistemu Windows prenehajo uporabljati zadrževanje in začnejo odstranjevati vsebino. Z drugimi besedami, lokalni disk v sistemu Windows je najboljša izbira za tovrstni sistem shranjevanja varnostnih kopij.
Varnostna kopija in repozitorij Windows
S BCJ pa postane še bolj zanimivo. Ne le, da je tukaj popolno zadrževanje, temveč tudi ni treba izvajati popolne varnostne kopije pri vsakem preklopu diska! Deluje tako:
Najprej B&R začne ustvarjati točke na prvem disku. Recimo, da smo nastavili zadrževanje na 3 točke. Naloga bo delovala v neskončno inkrementalnem načinu in združila vse ostalo (spominjam vas, da GFS zadrževanje v tem primeru ni podprto).
Nato priključimo drugi disk. Ker na njem še ni verige, ustvarimo popolno varnostno kopijo, po kateri se pojavi druga veriga treh točk:
Končno je čas, da ponovno priključimo prvi disk. In tukaj se začne čarovnija, saj naloga ne bo ustvarila popolne varnostne kopije, ampak bo preprosto nadaljevala z inkrementalno verigo:
Po tem bo dejansko na vsakem disku obstajala svoja neodvisna veriga. Zato tu zadrževanje ne pomeni števila točk na vseh diskih, ampak število točk na chaque disku posebej.
Varnostna kopija in repozitorij Linux omrežno shranjevanje
In spet, vsa eleganca izgine, če repozitorij ni na lokalnem disku Windows. Ta scenarij deluje podobno kot prej obravnavana preprosta naloga. Pri vsakem kroženju BCJ bo ustvaril popolno varnostno kopijo, preostale točke pa bodo pozabljene. Da ne ostanete brez prostega prostora, je treba uporabiti DWORD ForceDeleteBackupFiles.
Zaključek
Torej, kot rezultat tega dolgega besedila smo obravnavali dva tipa nalog. Seveda je nalog še veliko več, vendar vseh ni mogoče obravnavati v formatu enega članka. Če imate po branju kakšna vprašanja, jih prosim napišite v komentarje, z veseljem bom odgovoril osebno.
Izvor: habr.com
