Pozdravljam bralce našega bloga! Deloma smo se že spoznali – moji angleški prispevki so se tu že 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 bila zanimiva čim širšemu občinstvu in bi zahtevala podrobno obravnavo. Daniel Defo je trdil, da nas čakajo smrt in davki. Z moje strani lahko rečem, da podpore inženirjev čakajo vprašanja o politikah shranjevanja točk obnavljanja (ali poenostavljeno – rešitvah). Kako deluje rešitev, sem začel razlagati pred štirimi leti, ko sem bil mlajši inženir prve ravni, še naprej razlagam tudi zdaj, že kot vodja špansko- in italijansko govoreče ekipe. Prepričan sem, da moji sodelavci druge in celo tretje ravni podpore redno odgovarjajo na ista vprašanja.
V tem smislu sem želel napisati zaključen, kar se da podroben prispevek, kamor bi se rusko govoreči uporabniki lahko ponovno vračali kot k priročniku. Trenutno je pravi trenutek – nedavno izdana jubilejna deseta različica je dodala nove možnosti osnovni funkcionalnosti, ki se desetletja ni spremenila. Moj prispevek je predvsem usmerjen na to različico — čeprav je velika večina napisanega resnična tudi za prejšnje različice, ne boste našli nekaterih funkcionalnosti, opisanih tukaj. Na koncu, če malo pogledamo v prihodnost, povem, da pričakujemo nekatere spremembe v naslednji različici, vendar bomo o tem spregovorili, ko bo prišel čas. Torej, začnimo.
Naloge varnostnega kopiranja (Backup job)
Najprej razčistimo tisti del, ki se ni spremenil v različici 10. Politika rešitve se določi z več parametri. Odprimo okno za ustvarjanje nove naloge in preidimo na zavihek Shranjevanje. Tukaj bomo videli parameter, ki določa želeno število točk obnavljanja:
Vendar pa je to le del enačbe. Dejansko število točk je prav tako določeno z načinom varnostnega kopiranja, nastavljenim za nalogo. Za izbiro tega parametra je treba klikniti gumb Napredno na istem zavihku. To bo odprlo novo okno z mnogimi možnostmi. Oštevilčili jih bomo in jih razmislili zaporedno:
Če izberete samo možnost 1, bo opravilo delovalo v "nenehno inkrementalnem" načinu (forever forward incremental). Tu ni nobenih težav – opravilo bo shranjevalo nastavljeno število točk obnovitve od celotnega varnostnega kopiranja (datoteka z razširitvijo VBK) do zadnjega inkrementa (datoteka z razširitvijo VIB). Ko število točk preseže nastavljeno vrednost, se najstarejši inkrement združi s celotnim varnostnim kopiranjem. Drugimi besedami, če je opravilo nastavljeno na shranjevanje 3 točk, bo takoj po naslednji seji na repozitoriju 4 točke, nato pa se bo celotno varnostno kopiranje združilo z najstarejšim inkrementom in skupno število točk bo spet 3.
Prav tako je izjemno preprosto upravljanje z retencijo za "obratno inkrementalno" (reverse incremental) metodo (možnost 2). Ker je v tem primeru najnovejša točka celotno varnostno kopiranje, za katerim sledi veriga t.i. rollbackov (datoteke z razširitvijo VRB), je za uporabo retencije dovolj, da preprosto izbrišete najstarejši rollback. Situacija bo enaka: takoj po seji bo število točk preseglo nastavljeno za 1, nato pa se bo vrnilo na želeno vrednost.
Upoštevajte, da lahko z obratno inkrementalno metodo vključite tudi periodično celotno varnostno kopiranje (možnost 4), vendar to ne spremeni bistva. Da, v verigi bodo pojavile celotne točke obnovitve, vendar bomo še vedno preprosto brišemo najstarejše točke eno po eno.
Končno pridemo do zanimivih delov. Če aktivirate inkrementalno varnostno kopiranje, hkrati pa vključite možnosti 3 ali 4 (ali lahko celo oboje), bo opravilo začelo ustvarjati periodična celotna varnostna kopiranja "aktivno" ali sintetično. Metoda ustvarjanja celotnega varnostnega kopiranja ni pomembna – vsebovala bo iste podatke, inkrementalna veriga pa bo razdeljena na "podverige". Ta metoda se imenuje forward incremental in prav ta metoda povzroča velik del vprašanj naših strank.
Retention is applied here by removing the oldest part of the chain (from a full backup to incremental backups). In this case, we will not delete just the empty backup or only a portion of the increments. The entire "subchain" is removed completely at once. The meaning of the setting for the number of points changes – while in other methods it is the maximum allowable number after which retention must be applied, here this setting defines the minimum number. In other words, after deleting the oldest "subchain", the number of points in the remaining part must not fall below this minimum.
I will try to illustrate this concept graphically. Suppose retention is set to 3 points, and the job 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? On Monday, a full backup was created. From Tuesday to Sunday, the job created increments. Finally, next Monday a full backup is created again, and only when 2 increments are created can the old part of the chain finally be removed, as the remaining number of points will not fall below the set 3.
If the idea is clear, I suggest you try to calculate retention on your own. Let's take the following conditions: the job runs for the first time on Thursday (obviously, a full backup will be made). The job is set to create full backups on Wednesdays and Sundays and to keep 8 recovery points. When will retention be applied for the first time?
To answer this question, I recommend taking a piece of paper, drawing it out by days of the week and writing down which point is created each day. The answer will become obvious.
Odgovor
Explanation: to answer, it is enough to ask oneself "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 the Sunday of the second week.
Some readers may object: "why all this, if there is ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Nazad, 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čki backup. Ipak, ova opcija aktivira potpuno jedinstveni način backup-a. Ne ulazeći u detalje, odmah ću reći da je u trenutnoj fazi razvoja proizvoda "Transform previous backup chains into rollbacks" - opcija zastarela, i ne mogu smisliti nijedan scenario kada bi se trebala koristiti. Njena vrednost je toliko sumnjiva da je Anton Gostev neki vreme tražio primerke njenih korisnih primena kroz forum (ako ih imate, pišite u komentarima, jako me zanima). Ako takvih ne bude (mislim da će tako i biti), opcija će biti uklonjena u narednim verzijama.
Zadatak će kreirati inkremente (VIB) do dana kada je zakazan sintetički potpuni backup. Na taj dan se zaista kreira VBK, ali sve tačke do tog VBK transformišu se u rollback-ove (VRB). Nakon toga, zadatak će nastaviti sa kreiranjem inkremenata ka potpunom backup-u do sledećeg sintetičkog backup-a. Na kraju se u lancu stvara mešavina VBK, VBR i VIB fajlova. Retenzija se primenjuje vrlo jednostavno - brisanjem poslednjeg VBR-a:
Težave
Osim samog razumevanja kako to funkcioniše, većina problema koja se javlja prilikom korišćenja inkrementalnog režima obično je povezana sa potpunim backup-om. Redovni potpuni backup je neophodan ovom režimu, inače će repozitorijum gomilati tačke dok se ne napuni.
Na primer, potpuni backup se može kreirati previše retko. Recimo, zadatak je postavljen da čuva 10 tačaka, a potpuni backup se pravi jednom mesečno. Jasno je da će stvarni broj tačaka ovde biti znatno veći od postavljenog. Ili je zadatak potpuno postavljen da radi u beskonačno-inkrementalnom režimu i čuva 50 tačaka. Tada je neko slučajno napravio potpuni backup. Sve, od sada će zadatak čekati dok puna tačka ne nagomila 49 inkremenata, nakon čega će primeniti retenciju i vratiti se u beskonačno-puni režim.
V drugih primerih se polno varnostno kopiranje nastavi, da se izvaja redno, vendar tega iz kakšnega razloga ne počne. Tukaj bom opisal najpogostejši razlog. Nekateri stranke raje uporabljajo možnost načrtovanja "run after" in nastavijo naloge, da delujejo v verigi. Vzemimo tak primer: obstajajo 3 naloge, ki delujejo vsak dan in ustvarjajo polno varnostno kopijo ob nedeljah. Prva naloga se prižge ob 22.30, ostale se začnejo zaporedno. Inkrementalno varnostno kopiranje traja 10 minut, zato do 23.00 vse naloge končajo delo. Polno varnostno kopiranje pa traja eno uro, zato se v nedeljo zgodi naslednje: prva naloga deluje od 22.30 do 23.30. Naslednja od 23.30 do 00.30. Tretja naloga pa se prižge že v ponedeljek. Polno varnostno kopiranje je nastavljeno za nedeljo, zato v tem primeru ne bo prisotno. Naloga bo čakala na polno varnostno kopiranje, da bi uporabila retenzijo. Zato bodite previdni pri uporabi možnosti "run after" ali je ne uporabljajte sploh – preprosto nastavite naloge, da se zaženejo ob istem času in dovolite, da načrtovalnik virov opravi svoje delo.
Zahtevna možnost "Remove deleted items"
Ko greste skozi nastavitve naloge Shranjevanje – Napredno – Vzdrževanje, lahko naletite na možnost "remove deleted items data after", ki se meri v dneh.
Nekateri stranke pričakujejo, da je to zagotovo retenzija. V resnici pa je to povsem ločena možnost, katere ne 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 nekaj naprav.
Predstavljajte si takšen scenarij: neskončna inkrementalna naloga, nastavljena za shranjevanje 6 točk. V nalogi sta 2 napravi, ena vedno uspešno varnostno kopira, druga pa občasno povzroča napake. Tako se je ob sedmi točki oblikovala takšna situacija:
Čas je za uporabo retenzije, vendar ima ena naprava 7 točk, druga pa samo 4. Ali bo tukaj uporavljena retenzija? Odgovor je – ja, 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čeno sejo. To se zgodi na primer, kadar so naprave dodane v nalogo ne posamezno, ampak v sklopih (mape, shrambe), in se določena naprava začasno preseli v drug sklop. V tem primeru se naloga šteje za uspešno zaključeno, vendar boste v statistiki našli sporočilo, ki poziva k pozornosti, da določena naprava ne obdeluje več naloge.
Kaj se zgodi, če na to ne bomo opozarjali? V primeru neskončno inkrementalnih ali obratno inkrementalnih načinov se bo število točk obnovitve "problematične" naprave zmanjšalo z vsako sejo, dokler ne doseže 1, shranjene v VBK. Z drugimi besedami, čeprav naprava ne bo imela varnostnih kopij dolgo časa, bo ena točka obnovitve še vedno ostala. Drugače pa je, če so vključene periodične popolne varnostne kopije. Če ignoriramo signale iz B&R, lahko na koncu zadnja točka izgine skupaj s starim delom verige.
Ko so te podrobnosti pojasnjene, lahko končno obravnavamo možnost "Remove deleted items data after". Ta bo izbrisala vse točke za določeno napravo, če ta naprava ni varnostno kopirana v X dneh. Upoštevajte, da ta nastavitev ne reagira na napake (poskusili smo - ni uspelo). Ne sme biti niti poskusa varnostnega kopiranja naprave. Zdi se, da je ta možnost koristna in jo je vedno smiselno imeti vključeno. Če administrator izbriše napravo iz naloge, je smiselno, da po določenem času očistimo nepotrebne podatke in verigo. Vendar pa nastavitev zahteva disciplino in pozornost.
Дам практический пример: в задание были добавлены несколько контейнеров, состав которых менялся. Из-за нехватки ОЗУ сервер B&R столкнулся с проблемами, которые остались незамеченными. Задание запустилось и попыталось сделать резервную копию машин, за исключением одной, которая не была в контейнере на тот момент. Поскольку многие машины выдали ошибки, по умолчанию B&R должен был сделать 3 дополнительные попытки резервного копирования «проблемных» машин. Из-за постоянных проблем с ОЗУ эти попытки затянулись на несколько дней. Повторной попытки сделать резервную копию отсутствующей виртуальной машины не было (отсутствие ВМ не считается ошибкой). В итоге, во время одной из повторных попыток сработало условие “Удалить удаленные элементы”, и все точки машины были удалены.
На этот счет могу сказать следующее: если у вас настроены уведомления о результатах заданий, а еще лучше — используется интеграция с Veeam ONE, то, скорее всего, такого не произойдет. Если же вы заглядываете на сервер B&R раз в неделю, чтобы проверить, что все работает, то от опций, которые могут привести к удалению резервных копий, лучше отказаться.
Что нового в версии 10
То, о чем мы говорили ранее, существовало в B&R на протяжении многих версий. Поняв эти принципы работы, давайте теперь посмотрим, что добавлено в юбилейной «десятке».
Ежедневное хранилище
Выше мы рассматривали «классическую» политику хранения, основанную на количестве точек. Альтернативный подход – установить в том же меню “дни” вместо “точек восстановления”.
Идея ясна из названия – ретеншен будет хранить установленное количество дней, количество же точек в каждом дне не имеет значения. Однако нужно помнить следующее:
- Текущий день не учитывается при расчете ретеншена.
- Дни, когда задание не работало совсем, также учитываются. Это следует помнить, чтобы случайно не потерять точки тех заданий, которые работают нерегулярно.
- Точка восстановления считается с того дня, когда началось ее создание (т.е. если задание начало работать в понедельник, а закончилось во вторник, то это точка считается с понедельника).
V ostalem se principi uporabe retentiona nalog še vedno določajo izbrana metoda varovanja podatkov. Poglejmo še eno nalogo za izračun, pri čemer bomo uporabili enak inkrementalni pristop. Recimo, da je retention nastavljen na 8 dni, naloga deluje vsakih 6 ur s polnim varovanjem v sredo. Pri tem naloga ne deluje v nedeljo. Naloga se prvič zažene v ponedeljek. Kdaj bo retention uporabljen?
Odgovor
Kot običajno, je najbolje narisati tabelo. Dovolite mi, 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 le, da bo prvi ponedeljek in ob sredah prva točka polno varovanje, medtem ko bodo v preostalih dneh naloge preprosto ustvarile 4 inkrementalne točke.
Ugotavljamo, da bo retention uporabljen z odstranitvijo ponedeljkovega polnega varovanja in njegovega inkrementa. Kdaj se to zgodi? Ko bo preostali del verige vseboval 8 dni. Pri tem ne upoštevamo današnjega dne, nedeljo pa štejejo. 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 le za naloge kopiranja arhivskih varnostnih kopij (Backup copy) in naloge kopiranja na magnetne trakove. Zdaj pa je na voljo tudi za običajno varovanje podatkov.
Čeprav to ni neposredno povezano s trenutno temo, ne morem ne omeniti, da nova funkcionalnost ne pomeni odklona od strategije 3-2-1. Prisotnost arhivskih točk v glavnem skladišču ne vpliva na njegovo zanesljivost. Predpostavlja se, da bo GFS uporabljen skupaj z razširljivim skladiščem (Scale-out), za prenos teh točk v S3 in podobne shranjevalne sisteme. Če jih ne uporabljate, je bolje, da še naprej shranjujete primarne in arhivske točke v različnih skladiščih.
Zdaj poglejmo principe ustvarjanja GFS točk. V nastavitvah naloge, na koraku Storage, se je pojavila posebna gumb, ki odpre naslednje meni:
Osnovo GFS lahko strnemo v nekaj točk (uporabite pozornost, GFS v drugih vrstah nalog deluje drugače, vendar o tem malo kasneje):
- Naloga ne ustvarja ločenega popolnega varnostnega kopiranja za GFS točko. Namesto tega bo uporabljeno najbolj primerno popolno varnostno kopiranje med obstoječimi. 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 samo en časovni interval (na primer tedenski), bo naloga na začetku GFS intervala preprosto čakala na popolno varnostno kopijo in označila prvo primerno kot GFS.
Primer: naloga je nastavljena, da hrani tedenski GFS, z varnostno kopijo v sredo. Naloga deluje vsak dan, a je popolno varnostno kopiranje določeno za petek. V tem primeru se v sredo začne GFS obdobje in naloga začne čakati na primerno točko. Ta bo na voljo v petek in bo označena z oznako GFS.
- Če so vključeni takoj 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). Oznake bodo dodeljene zaporedno, začenši z mlajšim.
Primer: tedenski GFS je nastavljen na sredo, mesečni pa na zadnji teden meseca. Naloga deluje vsak dan in ustvari polne varnostne kopije ob ponedeljkih in petkih.
Za enostavnost začnimo šteti od predzadnjega tedna meseca. V tem tednu bo ob ponedeljku ustvarjeno popolno varnostno kopiranje, a bo to spregledano, ker tedenski GFS interval začne v sredo. Še vedno pa petkovo popolno varnostno kopiranje popolnoma ustreza GFS točki. Ta sistem je že znan.
Zdaj si poglejmo, kaj se bo zgodilo v zadnjem tednu meseca. Mesečni GFS interval se začne ob ponedeljku, a ponedeljkova VBK ne bo označena kot GFS, ker naloga poskuša označiti en VBK tako za mesečno kot tedensko GFS točko. Iskanje začne pri tedenskem, ker ta po definiciji lahko postane tudi mesečna.
Pri tem, če vključimo samo tedenske in letne intervale, bosta ti delovala neodvisno drug od drugega in lahko označita 2 ločeni VBK kot ustrezna GFS intervala.
Naloge za ustvarjanje varnostne kopije (Backup copy)
Še en tip nalog, ki pogosto zahteva razjasnitev delovanja. Na začetku razjasnimo 'klasično' metodo dela, brez novosti v v.10
Preprost način zadrževanja
Privzeto takšna opravila delujejo v neskončnem inkrementalnem načinu. Ustvarjanje točk se določa z dvema parametroma – intervalom kopiranja in želenim številom točk za obnovitev (retencija po dnevih tukaj ni prisotna). Interval kopiranja se nastavi na prvi zavihku Job pri ustvarjanju naloge:
Število točk pa se določi nekoliko kasneje na zavihku Target
Naloga ustvari 1 novo točko za vsak interval (količina točk, ustvarjenih za VM s prvotnimi nalogami, ni pomembna). Na koncu intervala se nova točka zaključi in, če je potrebno, se uporabi retencija s kombiniranjem VBK in najstarejšega inkrementa. Ta mehanizem že dobro poznamo.
Metoda retencije z uporabo GFS
BCJ prav tako zna shraniti arhivne točke. To se nastavi na istem zavihku Target, nekoliko nižje od nastavitev količine točk za obnovitev:
GFS točke se lahko ustvarjajo na dva načina – sintetično, z uporabo podatkov na sekundarnem repozitoriju, ali pa simulirajo popoln varnostni kopiji in preberejo vse podatke iz primarnega repozitorija (aktivira se z možnostjo, označeno s številko 3). Retencija se v obeh primerih močno razlikuje, zato jih bomo obravnavali ločeno.
Sintetični GFS
V tem primeru GFS točka ne bo ustvarjena točno na določen dan. Namesto tega bo GFS točka ustvarjena, ko bo VIB tistega dne, na katerega je bila predvidena ustvaritev GFS točke, združen s popolnim varnostnim kopiranjem. To včasih povzroča nelagodje, saj čas mineva, GFS točke pa ni. In le mogočni šaman iz tehnične podpore lahko napove, kdaj bo točka vendarle nastala. V resnici magija ni potrebna – dovolj je, da si ogledate nastavljene število točk in interval sinhronizacije (koliko točk se ustvari vsak dan). Poskusite sami izračunati na tem primeru: naloga je nastavljena na hranjenje 7 točk, interval sinhronizacije – 12 ur (torej 2 točki na dan). Trenutno je v verigi že 7 točk, danes je ponedeljek, in na ta dan je predvidena ustvaritev GFS točke. Kdaj bo točka ustvarjena?
Odgovor
Tukaj je bolje opisati, kako se bo veriga spreminjala v dinamiki, po dneh:
Torej, v ponedeljek se zadnji inkrement v verigi označi kot GFS, vendar ni nobenih drugih vidnih sprememb. Vsak dan naloga ustvari 2 novi točki, in retenzija neizprosno premika verigo naprej. Končno, v četrtek nastopi čas, da se uporabi retenzija na istem incrementu. Ta seja bo trajala dlje kot običajno – ker naloga 'izvleče' potrebne bloke iz verige in ustvari novo polno 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 celotno točko'
Zgoraj sem omenil, da BCJ deluje v neskončnem inkrementalnem načinu. Zdaj bomo obravnavali edino izjemo od tega pravila. Ko je omogočena možnost 'Preberi celotno točko', bo GFS točka ustvarjena točno na načrtovani dan. Sama naloga pa bo delovala v inkrementalnem načinu s periodičnimi polnimi varnostnimi kopijami, ki smo jih obravnavali prej. Retenzija se bo tudi uporabila z odstranitvijo najstarejšega dela verige. Vendar pa bodo v tem primeru odstranjeni le inkrementi, medtem ko bo polna varnostna kopija ostala kot GFS točka. Zato pri izračunu retenzije točk, označenih z GFS oznakami, ne upoštevamo.
Recimo, da je naloga nastavljena, da hrani 7 točk in ustvari tedensko GFS točko v ponedeljek. V tem primeru bo naloga resnično ustvarila polno varnostno kopijo vsak ponedeljek in jo označila kot GFS. Retenzija se bo uporabila, ko po odstranitvi inkrementov iz najstarejšega dela število preostalih inkrementov ne pade pod 7. Tako to izgleda v shemi:
Torej, do konca drugega tedna bo v verigi skupaj 14 točk. Med drugim tednom je naloga ustvarila 7 točk. Če bi bila to preprosta naloga, bi bila retenzija že uporabljena. Ampak to je BCJ z GFS retenzijo, zato GFS točk ne upoštevamo, torej jih je le 6. To pomeni, da retenzije še ne moremo uporabiti. V tretjem tednu ustvarimo še eno polno varnostno kopijo z GFS oznako. 15 točk, vendar te spet ne upoštevamo. In končno, v torek tretjega tedna ustvarimo inkrement. Zdaj, če odstranimo inkremente verige prvega tedna, bo skupno število inkrementov ustrezalo nastavljeni retenziji.
Kot je bilo omenjeno zgoraj, je pri tej metodi zelo pomembno, da se popolni varnostni kopiji ustvarjajo redno. Recimo, da je osnovna zadrževanje nastavljeno na 7 dni, vendar le 1 letna točka, ni težko domisliti, da bi se nakopičilo veliko več inkrementov, kot je 7. V takih primerih je bolje uporabiti sintetično metodo ustvarjanja GFS.
In spet “Remove deleted items”
Ta možnost je prav tako prisotna za BCJ:
Logika te možnosti je tukaj enaka tisti v običajnih varnostnih kopijah – če stroj ni obdelan določeno število dni, se njegovi podatki odstranijo iz verige. Vendar pa je za BCJ uporabnost te možnosti objektivno večja, in to je razlog.
V običajnem načinu BCJ deluje v neomejenem inkrementalnem načinu, zato, če se nekega trenutka stroj odstrani iz naloge, zadrževanje postopoma odstrani vse točke obnovitve, dokler ne ostane le ena – v VBK. Zdaj si predstavljajmo, da je naloga še vedno nastavljena za ustvarjanje sintetičnih GFS točk. Ko bo prišel čas, bo naloga morala ustvariti GFS za vse stroje v verigi. Če za katerikoli stroj sploh ni novih točk – no, bo treba uporabiti tisto, kar je. In tako vsakokrat. Na koncu se lahko pojavi takšna situacija:
Pozorite na sekcijo Datoteke: imamo glavni VBK in 2 tedenski GFS točki. In zdaj na sekcijo Točke obnovitve – v teh datotekah je dejansko isti slika stroja. Seveda, ni smisla v takšnih GFS točkah, le zasedajo prostor.
Takšna situacija je možna le pri uporabi sintetičnega GFS. Da bi to preprečili, uporabite možnost “Remove deleted items”. Samo ne pozabite jo nastaviti na ustrezno število dni. Podpora je videla primere, ko so možnost nastavili na manj dni, kot je interval sinhronizacije – BCJ je začela divjati in odstranjevati točke, preden so jih uspele 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 – desni klik na stroj in izberite “Delete from disk” (v oknu, ki se odpre, ne pozabite označiti “Remove GFS full backup”):
Novost v v.10 – takojšnja kopija (immediate copy)
Ko smo se seznanili s ‘klasično’ funkcionalnostjo, preidimo na novo. Novost je ena, vendar zelo pomembna. To je nov način delovanja.
Tukaj ni takega pojma kot "interval sinhronizacije", naloga bo nenehno spremljala, ali so se pojavile nove točke, in jih kopirala vse, ne glede na to, koliko jih je. Toda naloga ostaja inkrementalna, kar pomeni, da tudi če glavna naloga ustvari VBK ali VRB, bodo te točke kopirane kot VIB. Drugače v tem načinu ni nobenih presenečenj – tako standardno kot GFS zadrževanje deluje po pravilih, opisanih zgoraj (res pa je, da je tukaj na voljo le sintetično GFS).
Vrteči diski. Značilnosti repozitorijev z rotacijo diskov (rotated drives)
Stalna grožnja virusov-šifrantov je dejansko postavila standard varnosti v obstoj kopije podatkov na mediju, do katerega virus ne more priti. Ena od možnosti je uporaba repozitorijev z rotacijo diskov, kjer se diski uporabljajo izmenično: medtem ko je en disk priključen in dostopen za pisanje, se ostali shranjujejo na varnem mestu.
Da bi naučili B&R delati s takšnimi repozitoriji, je treba v nastavitvah repozitorija, na koraku Repository, klikniti gumb Advanced in izbrati ustrezno možnost:
Po tem bo VBR pričakoval, da bo obstoječa veriga občasno izginila iz repozitorija, kar pomeni rotacijo diska. Odvisno od vrste repozitorija in vrste naloge, se bo B&R obnašal različno. To si lahko predstavimo s to tabelo:
Oglejmo si vsako možnost.
Običajna naloga in Windows repozitorij
Torej, imamo nalogo, ki shranjuje verige na prvi disk. Ob rotaciji se ustvarjena veriga dejansko zbriše, zato mora naloga somehow preživeti to izgubo. Utolažbo najde v ustvarjanju popolnega varnostnega kopiranja. Tako vsaka rotacija pomeni popolno varnostno kopiranje. Toda kaj se zgodi s točkami na izklopljenem disku? Te se zapomnijo in upoštevajo pri izračunu zadrževanja. Tako je določeno število točk v nalogi to, koliko točk je treba imeti na vseh diskih. Poglejmo primer:
Naloga deluje v neskončno-inkrementalnem načinu in je nastavljena za shranjevanje 3 točk okrevanja. Toda imamo še drugi disk, in enkrat na teden izvajamo rotacijo (diskov je lahko tudi več, to ne spremeni bistva).
V prvem tednu bo naloga ustvarila 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, toda informacije o njej bodo ostale v bazi. Zdaj bo naloga ohranjala 3 točke na drugem disku. Skupna situacija bo taka:
Nazadnje ponovno povežemo prvi disk. Pred ustvarjanjem nove točke bo naloga preverila, kakšno je stanje z retenzijami. Kot opomnik, je retenzija nastavljena na 3 točke. Medtem imamo 3 točke na disku 2 (vendar je ta izklopljen in shranjen na varnem mestu, kamor B&R ne more dostopati) in 3 točke na disku 1 (ta pa je povezan). Torej lahko brez skrbi izbrišemo 3 točke z diska 1, saj presega retenzijo. Po tem naloga ponovno ustvari popoln varnostni kopijo, in naša veriga začne izgledati tako:
Če je retenzija nastavljena na shranjevanje dni namesto števila točk, se logika ne spremeni. Poleg tega GFS retenzija sploh ni podprta pri uporabi skladišč z rotacijo diskov.
Običajna naloga in Linux repozitorij omrežno shranjevanje
Taka možnost je tudi mogoča, vendar je na splošno manj priporočljiva zaradi nalaganih omejitev. Ob rotaciji diska in izginotju verige bo naloga reagirala na enak način – z ustvarjanjem popolne varnostne kopije. Omejitev je povezana z omejenim mehanizmom retenzije.
Tukaj se pri rotaciji cela veriga na izklopljenem disku preprosto izbriše iz baze podatkov B&R. Upoštevajte – iz baze podatkov, sami datoteki ob tem ostajajo na disku. Te lahko uvozimo in uporabimo za obnovitev, vendar je lahko jasno, da bodo prej ali slej take pozabljene verige zapolnile celoten repozitorij.
Rešitev je v dodajanju DWORD ForceDeleteBackupFiles kot je navedeno na tej strani: . Po tem bo naloga preprosto začela brisati vsebino mape naloge ali mape repozitorija (odvisno od vrednosti) ob vsaki rotaciji.
Vendar to ni eleganten mehanizem retenzije, temveč preprosto čiščenje vsebine. Na žalost so v tehnični podpori naleteli na primere, kjer je bila kot repozitorij navedena preprosto korenska mapa diska, kjer so poleg varnostnih kopij ležali tudi drugi podatki. Vse to je bilo uničeno pri rotaciji.
Poleg tega, ko je omogočen ForceDeleteBackupFiles, deluje za vse tipe skladišč, torej celo skladišča na Windows prenehajo uporabljati zadrževanje in začnejo brisati vsebino. Z drugimi besedami, lokalni disk na Windows je najboljša izbira za tak sistem shranjevanja varnostnih kopij.
Kopija varnostne kopije in Windows skladišče
Pri BCJ je vse še bolj zanimivo. Ni samo to, da imamo popolno zadrževanje, ampak ni potrebno, da vsakokrat, ko zamenjamo disk, naredimo popolno varnostno kopijo! Deluje tole:
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čnem inkrementalnem načinu in združevala vse nepotrebno (spomnim, 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 čemer dobimo drugo verigo treh točk:
Nazadnje je prišel čas, da ponovno priključimo prvi disk. In tu se začne magija, saj naloga ne bo ustvarila popolne varnostne kopije, temveč bo preprosto nadaljevala z inkrementalno verigo:
Po tem bo dejansko na vsakem disku obstajala neodvisna veriga. Zato zadrževanje tukaj ne pomeni števila točk na vseh diskih, ampak število točk na vsakem disku posebej.
Kopija varnostne kopije in Linux skladišče omrežno shranjevanje
In ponovno, vsa eleganca izgine, če skladišče ni na lokalnem disku Windows. Ta scenarij deluje podobno kot zgoraj obravnavana enostavna naloga. Pri vsaki rotaciji bo BCJ ustvarjal popolno varnostno kopijo, obstoječe točke pa bodo pozabljene. Da ne ostanete brez prostega prostora, je potrebno uporabiti DWORD ForceDeleteBackupFiles.
Zaključek
Torej, rezultati te dolge razprave so, da smo obravnavali dva tipa naloge. Seveda, nalog je veliko več, vendar vseh v formatu enega članka ne moremo obravnavati. Če imate po branju kakršnakoli vprašanja, jih prosim napišite v komentarje, z veseljem bom odgovoril osebno.
Izvor: habr.com
