Salut cititorilor blogului nostru! În parte, ne cunoaștem deja - postările mele în limba engleză au apărut aici în traducerea dragei mele colegi . De data aceasta, am decis să mă adresez direct publicului vorbitor de limba rusă.
Pentru debutul meu, mi-ar plăcea să găsesc o temă interesantă pentru un public cât mai larg, care necesită o analiza detaliată. Daniel Defoe susținea că orice om se confruntă cu moartea și impozitele. Din perspectiva mea, orice inginer de suport se așteaptă la întrebări despre politicile de păstrare a punctelor de restaurare (sau, mai simplu, retenție). Cum funcționează retenția, am început să explic acum 4 ani, când eram inginer junior de prim nivel, continuu să explic și acum, fiind liderul echipei vorbitoare de limbă spaniolă și italiană. Sunt sigur că colegii mei de nivel doi și chiar trei de suport răspund frecvent la aceleași întrebări.
În această lumină, mi-aș dori să scriu un post final, cât mai detaliat, la care utilizatorii vorbitori de rusă să se poată întoarce din nou și din nou ca la un ghid. Momentul este potrivit - recent lansata versiune aniversară 10 a adăugat noi funcționalități la funcționalitatea de bază, care nu s-a schimbat de ani de zile. Postul meu se concentrează în principal pe această versiune — deși cea mai mare parte a ceea ce am scris este valabil și pentru versiunile anterioare, unele dintre funcționalitățile descrise nu le veți găsi acolo. În cele din urmă, privind puțin spre viitor, voi spune că în următoarea versiune așteptăm unele modificări, dar despre asta vom vorbi când va veni timpul. Așadar, să începem.
Sarcini de backup (Backup job)
Pentru început, să analizăm partea care nu a suferit modificări în versiunea 10. Politica de retenție este definită de mai mulți parametri. Să deschidem fereastra de creare a unei noi sarcini și să trecem la tab-ul Storage. Aici vom vedea un parametru care definește numărul dorit de puncte de restaurare:
Totuși, aceasta este doar o parte a ecuației. Numărul real de puncte este determinat și de modul de backup setat pentru sarcină. Pentru a selecta acest parametru, trebuie să faceți clic pe butonul Advanced de pe aceeași tab. Acest lucru va deschide o fereastră nouă cu multe opțiuni. Să le numerotăm și să le analizăm pe rând:
Dacă activi doar opțiunea 1, sarcina va funcționa în modul "incremental nelimitat" (forever forward incremental). Aici nu apar dificultăți – sarcina va păstra numărul stabilit de puncte de restaurare de la backup-ul complet (fișier cu extensia VBK) până la ultimul increment (fișier cu extensia VIB). Când numărul de puncte va depăși valoarea stabilită, cel mai vechi increment va fi combinat cu backup-ul complet. Cu alte cuvinte, dacă sarcina este setată să păstreze 3 puncte, imediat după sesiunea următoare, pe repository vor fi 4 puncte, după care backup-ul complet va fi combinat cu cel mai vechi increment și numărul total de puncte se va întoarce la 3.
De asemenea, retenția pentru modul "invers incremental" (reverse incremental) (opțiunea 2) este extrem de simplă. În acest caz, cel mai recent punct va fi un backup complet, după care va urma o serie de așa-numite rollback-uri (fișiere cu extensia VRB), astfel că pentru aplicarea retenției este suficient să ștergem cel mai vechi rollback. Situația va fi aceeași: imediat după sesiune, numărul punctelor va depăși valoarea stabilită cu 1, după care se va întoarce la valoarea dorită.
Rețineți că cu modul invers incremental se poate activa de asemenea un backup complet periodic (opțiunea 4), dar acest lucru nu va schimba esența. Da, în serie vor apărea puncte complete de restaurare, dar tot așa vom șterge pur și simplu cele mai vechi puncte câte una.
În cele din urmă, ajungem la partea interesantă. Dacă activați backup-ul incremental, dar în plus activați opțiunile 3 sau 4 (sau ambele simultan), sarcina va începe să creeze backup-uri complete periodice prin metoda "activă" sau sintetică. Metoda de creare a backup-ului complet nu este importantă – va conține aceleași date, iar lanțul incremental va fi împărțit în "sub-lanțuri". Această metodă se numește forward incremental și tocmai ea provoacă o parte semnificativă din întrebările clienților noștri.
Retenția este aplicată aici prin eliminarea celei mai vechi părți a lanțului (de la backup complet până la increment). În acest sens, nu vom elimina doar backupul gol sau doar o parte a incrementelor. Întreaga „sub-lanț” este ștearsă complet dintr-o dată. De asemenea, sensul setării numărului de puncte se schimbă – dacă în alte metode acesta reprezintă numărul maxim permis, după care trebuie aplicată retenția, aici această setare definește numărul minim. Cu alte cuvinte, după eliminarea celei mai vechi „sub-lanț”, numărul de puncte din partea rămasă nu ar trebui să scadă sub acest minim.
Voi încerca să ilustrez acest concept grafic. Să presupunem că retenția este setată pe 3 puncte, iar sarcina funcționează în fiecare zi cu un backup complet lunea. Retenția va fi aplicată în acest caz, când numărul total de puncte va ajunge la 10:
De ce 10, când am stabilit 3? Lunea a fost creat un backup complet. De marți până duminică, sarcina a creat incrementi. În cele din urmă, în următoarea luni se creează din nou un backup complet și doar când vor fi create 2 incrementi, întreaga parte veche a lanțului poate fi ștearsă, deoarece numărul rămas de puncte nu va scădea sub cele 3 stabilite.
Dacă ideea este clară, atunci vă propun să încercați să calculați retenția singuri. Să luăm următoarele condiții: sarcina se rulează prima dată joia (firește, se va face un backup complet). Sarcina este setată să creeze backup complet în zilele de miercuri și duminică și să păstreze 8 puncte de restaurare. Când va fi aplicată retenția pentru prima dată?
Pentru a răspunde la această întrebare, vă recomand să luați o bucată de hârtie, să o împărțiți pe zilele săptămânii și să scrieți ce punct se creează în fiecare zi. Răspunsul va deveni evident.
Răspuns
Explicație: pentru a răspunde, este suficient să ne întrebăm „când va fi aplicată retenția”? Răspunsul – când vom putea șterge primele 3 puncte (VBK, VIB, VIB) și restul lanțului nu va scădea sub cele 8 puncte stabilite. Devine clar că vom putea face acest lucru când avem 11 puncte în total, adică duminica din a doua săptămână.
Unii cititori ar putea contesta: „de ce toate acestea, dacă există ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
În cele din urmă, nu am discutat opțiunea „Transformă lanțurile de backup anterioare în rollback-uri” (marcată cu cifra 5). Această opțiune uneori îi confundă pe clienți, care o activează „automată”, dorind să includă pur și simplu un backup sintetic. Între timp, această opțiune activează un mod de backup complet diferit. Fără a intra în detalii, vă voi spune imediat că, în acest stadiu de dezvoltare a produsului, „Transformă lanțurile de backup anterioare în rollback-uri” este o opțiune învechită, și nu pot găsi niciun scenariu în care ar trebui să fie utilizată. Valoarea acesteia este atât de îndoielnică, încât pentru o perioadă, Anton Gostev însuși a lansat un apel prin forum, cerând să-i trimită exemple de utilizare utilă (dacă le aveți, scrieți în comentarii, sunt foarte interesat). Dacă nu se găsesc astfel de exemple (cred că așa va fi), opțiunea va fi eliminată în versiunile următoare.
Sarcina va crea incrementale (VIB) până în ziua în care este programat un backup sintetic complet. În această zi se va crea cu adevărat un VBK, dar toate punctele până la acest VBK se transformă în rollback-uri (VRB). După aceea, sarcina va continua să creeze incrementale către backupul complet până la următorul backup sintetic. În final, se va crea un amestec exploziv de fișiere VBK, VBR și VIB. Retenția este aplicată foarte simplu – prin ștergerea ultimului VBR:
Probleme
Pe lângă înțelegerea efectivă a modului în care funcționează, majoritatea problemelor apărute în utilizarea modului incremental sunt, de obicei, legate de backupul complet. Un backup complet regulat este necesar pentru acest mod, altfel depozitul va acumula puncte până se va umple.
De exemplu, backupul complet poate fi creat prea rar. Să zicem că sarcina este setată să păstreze 10 puncte, iar backupul complet este creat o dată pe lună. Este clar că numărul efectiv de puncte va fi semnificativ mai mare decât cel setat. Sau, sarcina este setată să funcționeze în mod infinit-incremental și să păstreze 50 de puncte. Apoi, cineva a creat din greșeală un backup complet. Totul, de acum înainte, sarcina va aștepta să acumuleze 49 de incrementale la punctul complet, după care va aplica retenția și se va întoarce la modul complet-infinit.
În alte cazuri, un backup complet ar trebui să fie creat regulat, dar dintr-un motiv oarecare, nu se întâmplă acest lucru. Voi detalia aici cea mai comună cauză. Some clienți preferă să folosească opțiunea de programare „run after” și să configureze sarcinile să funcționeze în lanț. Să luăm un exemplu: există 3 sarcini care rulează în fiecare zi și creează un backup complet duminica. Prima sarcină începe la 22:30, iar celelalte pornesc în lanț. Backup-ul incremental durează 10 minute, deci până la 23:00 toate sarcinile se finalizează. Backup-ul complet, pe de altă parte, durează o oră, astfel că duminica se întâmplă următoarele: prima sarcină funcționează de la 22:30 la 23:30. Următoarea de la 23:30 la 00:30. Iar a treia sarcină se va activa luni. Backup-ul complet este programat pentru duminică, așa că în acest caz pur și simplu nu va exista. Sarcina va aștepta un backup complet pentru a aplica retenția. Așadar, fiți atenți când folosiți opțiunea „run after” sau nu o utilizați deloc – pur și simplu setați sarcinile să înceapă simultan și permiteți planificatorului de resurse să își facă treaba.
Opțiunea complicată „Remove deleted items”
După ce parcurgeți setările sarcinii Storage – Advanced – Maintenance, veți da peste opțiunea „remove deleted items data after”, calculată în zile.
Unii clienți se așteaptă ca aceasta să fie retenția. De fapt, este o opțiune complet distinctă, neînțelegerea căreia poate duce la consecințe neașteptate. Totuși, înainte de toate trebuie să explicăm cum B&R reacționează în situațiile în care, pe parcursul sesiunii, doar câteva mașini sunt copiate cu succes.
Să ne imaginăm următorul scenariu: o sarcină de backup incremental infinit, configurată pentru a păstra 6 puncte. În sarcină sunt 2 mașini, una fiind întotdeauna copiată cu succes, iar cealaltă având uneori erori. În cele din urmă, la al șaptelea punct s-a creat următoarea situație:
Este timpul să aplicați retenția, dar la o mașină sunt 7 puncte, iar la cealaltă doar 4. Va fi aplicată retenția în acest caz? Răspunsul este da, va fi. Dacă măcar un obiect a fost copiat, B&R consideră că punctul a fost creat.
O situație similară se poate ivi dacă o anumită mașină nu a fost inclusă în sarcină în timpul unei sesiuni specifice. Asta se întâmplă, de exemplu, atunci când mașinile sunt adăugate în sarcină nu individual, ci în cadrul контейнерів (foldere, stocări), iar o anumită mașină migrează temporar într-un alt container. În acest caz, sarcina va fi considerată reușită, dar în statistică veți găsi un mesaj care vă îndeamnă să acordați atenție faptului că acea mașină nu mai este procesată de sarcină.
Ce se va întâmpla dacă nu se acordă atenție acestui aspect? În cazul modurilor de backup incremental sau decrementat fără sfârșit, numărul punctelor de restaurare pentru „mașina problemă” va scădea cu fiecare sesiune, până când va ajunge la 1, păstrată în VBK. Cu alte cuvinte, chiar dacă mașina nu va fi backupată o perioadă îndelungată, un punct de restaurare tot va rămâne. Situația este diferită dacă sunt activate backupuri complete periodice. Dacă se ignoră semnalele de la B&R, în cele din urmă, ultimul punct poate fi șters împreună cu vechea parte a lanțului.
După ce am înțeles aceste detalii, putem lua în considerare opțiunea "Remove deleted items data after". Aceasta va șterge toate punctele pentru o anumită mașină, dacă această mașină nu este backupată timp de X zile. Rețineți că această setare nu reacționează la erori (am încercat - nu a funcționat). Nu ar trebui să existe măcar o încercare de backup a mașinii. Aparent, opțiunea este utilă și ar trebui să fie întotdeauna activată. Dacă administratorul a șters mașina din sarcină, ar fi logic ca, după un timp, să se curățe de datele inutile și lanțul. Cu toate acestea, setarea necesită disciplină și atenție.
Voi oferi un exemplu din practică: în sarcină au fost adăugate câteva containere, al căror conținut era destul de dinamic. Din cauza lipsei de RAM, serverul B&R a întâmpinat probleme care au rămas neobservate. Sarcina s-a lansat și a încercat să facă backup pentru mașini, cu excepția uneia care nu era prezentă în container la acel moment. Deoarece multe mașini au generat erori, prin default, B&R ar trebui să facă 3 încercări suplimentare pentru a crea backup pentru mașinile „problematice”. Din cauza problemelor constante cu RAM-ul, aceste încercări s-au întins pe parcursul a câteva zile. Nu a fost o a doua încercare de a face backup pentru VM-ul absent (lipsa VM-ului nu este o eroare). În cele din urmă, în timpul uneia dintre încercările de reluare, a fost îndeplinită condiția „Remove deleted items” și toate punctele mașinii au fost șterse.
În această privință, pot spune următoarele: dacă aveți configurate alerte pentru rezultatele sarcinilor, iar chiar mai bine — utilizați integrarea cu Veeam ONE, atunci cel mai probabil nu veți întâmpina astfel de probleme. Dacă, în schimb, verificați serverul B&R o dată pe săptămână pentru a vă asigura că totul funcționează, atunci este mai bine să renunțați la opțiunile care ar putea duce la ștergerea backup-urilor.
Ce s-a adăugat în v.10
Ceea ce am discutat înainte a existat în B&R de multe versiuni. După ce am înțeles aceste principii de funcționare, să vedem ce s-a adăugat în ediția aniversară „zece” .
Retenția zilnică
Anterior, am analizat politica „clasică” de stocare bazată pe numărul de puncte. O abordare alternativă este să setați în același meniu “days” în loc de “restore points”.
Ideea este clară din denumire — retenția va păstra un număr stabilit de zile, iar numărul de puncte din fiecare zi nu contează. Cu toate acestea, trebuie să țineți cont de următoarele:
- Ziua curentă nu este luată în considerare în calculul retenției
- Zilele în care sarcina nu a funcționat deloc, de asemenea, se consideră. Este important să aveți în vedere acest aspect pentru a nu pierde accidental puncte ale acelora sarcini care rulează neregulat.
- Un punct de recuperare se consideră din ziua în care a început crearea sa (adică, dacă sarcina a început să funcționeze luni și s-a terminat marți, atunci acesta este un punct din ziua de luni)
În rest, principiile aplicării retenției sarcinilor sunt determinate de metoda de backup aleasă. Să încercăm o altă sarcină de calcul, folosind aceeași metodă incrementală. Să presupunem că retenția este setată la 8 zile, iar sarcina rulează la fiecare 6 ore cu un backup complet în ziua de miercuri. De asemenea, sarcina nu rulează duminica. Sarcina pornește pentru prima dată luni. Când va fi aplicată retenția?
Răspuns
Ca de obicei, cel mai bine este să desenăm un tabel. Îmi permit să simplific sarcina și nu voi desena toate punctele create în fiecare zi, deoarece numărul de puncte într-o zi nu contează aici. Pentru noi este important doar că în prima zi de luni și în zilele de miercuri primul punct va fi un backup complet, iar în celelalte zile sarcina va crea doar 4 puncte incrementale.
Clarificăm că retenția va fi aplicată prin ștergerea backup-ului complet de luni și a incrementului său. Când se va întâmpla asta? Când restul lanțului va conține 8 zile. De asemenea, nu luăm în considerare ziua curentă, dar duminica este inclusă. Deci, răspunsul este – joia din a doua săptămână.
Arhivarea prin metoda GFS pentru sarcini obișnuite
Până la versiunea v.10, metoda de stocare Grandfather-Father-Son (GFS) era disponibilă doar pentru sarcinile de creare a copiilor de rezervă (Backup copy) și pentru sarcinile de copiere pe bandă magnetică. Acum, aceasta este disponibilă și pentru backup-uri obișnuite.
Deși nu se leagă de subiectul actual, nu pot să nu menționez că noua funcționalitate nu înseamnă abandonarea strategiei 3-2-1. Prezența punctelor de arhivare în principalul depozit nu afectează fiabilitatea acestuia. Se presupune că GFS va fi utilizat împreună cu un depozit extensibil (Scale-out), pentru a descărca aceste puncte în S3 și în alte stocări similare. Dacă nu le folosiți, este mai bine să continuați să stocați punctele primare și cele arhivate în depozite diferite.
Acum să analizăm principiile creării punctelor GFS. În setările sarcinii, la pasul Stocare, a apărut un buton special care deschide următorul meniu:
Esenta GFS poate fi redusă la câteva puncte (rețineți, GFS în alte tipuri de sarcini funcționează diferit, dar despre asta vorbim puțin mai târziu):
- Sarcina nu creează un backup complet separat pentru punctul GFS. În schimb, va fi utilizat cel mai potrivit backup complet disponibil. Prin urmare, sarcina trebuie să funcționeze în modul incremental cu un backup complet periodic, sau backup-ul complet trebuie să fie creat manual de utilizator.
- Dacă este activat un singur interval (de exemplu, săptămânal), atunci la începutul perioadei GFS sarcina va aștepta pur și simplu un backup complet și va marca primul disponibil ca GFS.
Exemplu: sarcina este configurată să păstreze GFS săptămânal, folosind backup-ul din ziua de miercuri. Sarcina rulează în fiecare zi, dar backup-ul complet este programat pentru vineri. În acest caz, perioada GFS va începe miercuri și sarcina va începe să aștepte punctul adecvat. Acesta va apărea vineri și va fi marcat cu un steag GFS.
- Dacă sunt activate simultan mai multe intervale (de exemplu, săptămânal și lunar), atunci B&R va aplica o metodă care permite utilizarea aceluiași punct ca GFS pentru mai multe intervale (pentru economisirea spațiului). Steagurile vor fi atribuite pe rând, începând cu cel mai mic.
Exemplu: GFS săptămânal este stabilit pentru miercuri, iar GFS lunar pentru ultima săptămână a lunii. Sarcina rulează în fiecare zi și creează backup-uri complete în zilele de luni și vineri.
Pentru simplificare, vom începe numărătoarea din penultima săptămână a lunii. În această săptămână se va crea un backup complet în ziua de luni, dar acesta va fi ignorat, deoarece intervalul GFS săptămânal începe miercuri. Cu toate acestea, backup-ul complet din ziua de vineri se potrivește perfect pentru punctul GFS. Acest sistem ne este deja familiar.
Acum să examinăm ce se va întâmpla în ultima săptămână a lunii. Intervalul GFS lunar va începe luni, dar backup-ul VBK din ziua de luni nu va fi marcat ca GFS, deoarece sarcina caută să marcheze un VBK atât ca punct GFS lunar, cât și săptămânal. În acest proces, căutarea începe cu cel săptămânal, deoarece prin definiție acesta poate deveni și lunar.
În schimb, dacă se activează doar intervalele săptămânale și anuale, acestea vor acționa independent una de cealaltă și pot marca 2 VBK separate ca intervale GFS corespunzătoare.
Sarcini de creare a unei copii de rezervă (Backup copy)
Un alt tip de sarcini, adesea necesitând explicații privind funcționarea. Mai întâi, să analizăm metoda „clasică” de operare, fără inovații v.10.
Metoda simplă de retenție
Implicit, aceste sarcini funcționează într-un mod incremental infinit. Crearea de puncte este definită de doi parametri - intervalul de copiere și numărul dorit de puncte de restaurare (nu există retenție pe zile aici). Intervalul de copiere este setat în prima tab, Job, la crearea sarcinii:
Numărul de puncte este definit puțin mai departe în tab-ul Target
Sarcina creează 1 nou punct pentru fiecare interval (cât de multe puncte au fost create pentru VM de sarcinile inițiale, nu contează). La sfârșitul intervalului, noul punct este finalizat și, dacă este necesar, se aplică retenția prin combinarea VBK și celui mai vechi punct incremental. Acest mecanism ne este deja cunoscut.
Metoda de retenție folosind GFS
BCJ poate de asemenea să stocheze puncte arhivă. Acest lucru este configurat pe aceeași tab-ul Target, puțin mai jos de setările numărului de puncte de restaurare:
Punctele GFS pot fi create în două moduri - sintetic, folosind datele de pe un depozit secundar, sau imitând un backup complet și citind toate datele de pe depozitul primar (activată prin opțiunea marcată cu cifra 3). Retenția va varia semnificativ în ambele cazuri, motiv pentru care le vom analiza separat.
GFS sintetic
În acest caz, punctul GFS nu este creat exact în ziua desemnată. În schimb, punctul GFS va fi creat atunci când VIB-ul din ziua în care era programat să fie creat punctul GFS va fi combinat cu backupul complet. Acest lucru cauzează uneori neînțelegeri, deoarece timpul trece, iar punctul GFS tot nu apare. Și doar un vrăjitor puternic din suportul tehnic poate prezice în ce zi va apărea punctul. De fapt, nu este nevoie de magie - este suficient să priviți numărul de puncte setate și intervalul de sincronizare (câte puncte sunt create în fiecare zi). Încercați să calculați singuri de exemplu: sarcina este setată să păstreze 7 puncte, intervalul de sincronizare - 12 ore (adică 2 puncte pe zi). În acest moment, în lanț sunt deja 7 puncte, astăzi fiind luni, iar pentru această zi este programată crearea unui punct GFS. În ce zi va fi creat?
Răspuns
Aici este mai bine să descriem cum se va schimba lanțul dinamic, zi de zi:
Așadar, luni, ultimul increment din lanț este marcat ca GFS, dar nu apar alte schimbări vizibile. Fiecare zi, sarcina creează 2 noi puncte, iar retenția împinge necruțător lanțul înainte. În cele din urmă, joi vine vremea să aplicăm retenția asupra aceluiași increment. Această sesiune va dura mai mult decât de obicei – pentru că sarcina „va extrage” blocurile necesare din lanț și va crea un nou punct complet. De acum încolo, în lanț vor fi deja 8 puncte – 7 în lanțul principal + GFS.
Crearea punctelor GFS cu opțiunea “Citește întregul punct”
Mai sus am spus că BCJ funcționează în mod incremental infinit. Acum vom analiza singura excepție de la această regulă. Când opțiunea “Citește întregul punct” este activată, punctul GFS va fi creat exact în ziua planificată. Sarcina în sine va funcționa în mod incremental cu backupuri complete periodice, pe care le-am discutat mai sus. Retenția va fi aplicată prin ștergerea celei mai vechi părți a lanțului. Totuși, în acest caz, doar incrmentele vor fi șterse, iar backupul complet va fi lăsat ca punct GFS. Prin urmare, în calculul retenției, punctele marcate cu flaguri GFS nu sunt luate în considerare.
Să presupunem că sarcina este setată să păstreze 7 puncte și să creeze un punct GFS săptămânal luni. În acest caz, în fiecare luni, sarcina va crea cu adevărat un backup complet și îl va marca ca GFS. Retenția va fi aplicată atunci când, după ștergerea incrementelor din cea mai veche parte, numărul incrementelor rămase nu va scădea sub 7. Iată cum arată acest lucru în schemă:
Așadar, la sfârșitul celei de-a doua săptămâni, în lanț sunt în total 14 puncte. În timpul celei de-a doua săptămâni, sarcina a creat 7 puncte. Dacă ar fi fost o sarcină simplă, retenția ar fi fost deja aplicată. Dar acesta este BCJ cu retenția GFS, așa că nu numărăm punctele GFS, ceea ce înseamnă că avem doar 6. Prin urmare, nu putem aplica încă retenția. În săptămâna a treia, creăm încă un backup complet cu flagul GFS. 15 puncte, dar acest punct nu-l numărăm din nou. Și, în cele din urmă, marți din săptămâna a treia, creăm un increment. Acum, dacă ștergem incrmentele din lanțul primei săptămâni, numărul total de incrmente va satisface retenția stabilită.
Așa cum s-a menționat anterior, în această metodă este foarte important ca copiile de rezervă complete să fie create în mod regulat. De exemplu, dacă se stabilește o retenție principală de 7 zile, dar doar un singur punct anual, nu este greu de imaginat că se vor acumula mult mai multe incremental decât cele 7. În astfel de cazuri, este mai bine să se utilizeze metoda sintetică de creare a GFS.
Și din nou „Elimină elementele șterse”
Această opțiune este disponibilă și pentru BCJ:
Logica acestei opțiuni este similară cu cea din sarcinile obișnuite de rezervă – dacă mașina nu este procesată un anumit număr de zile, datele sale sunt eliminate din lanț. Totuși, pentru BCJ, utilitatea acestei opțiuni este obiectiv mai mare, și iată de ce.
În modul obișnuit, BCJ funcționează într-un mod infinit incremental, așa că dacă, la un moment dat, mașina este eliminată din sarcină, retenția va șterge treptat toate punctele de restaurare până când va rămâne unul singur – în VBK. Acum să ne imaginăm că sarcina este încă configurată pentru a crea puncte GFS sintetice. Când va veni timpul, sarcina va trebui să creeze GFS pentru toate mașinile din lanț. Dacă pentru o anumită mașină nu există puncte noi – ei bine, va trebui să folosească ceea ce există. Și așa de fiecare dată. În cele din urmă, ar putea apărea o astfel de situație:
Observați secțiunea Files: avem principalul VBK și 2 puncte GFS săptămânale. Acum să ne uităm la secțiunea Puncte de restaurare – de fapt, aceste fișiere conțin aceeași imagine a mașinii. Evident, nu are niciun sens să există astfel de puncte GFS, ele doar ocupă spațiu.
Această situație este posibilă doar în cazul utilizării GFS sintetice. Pentru a evita aceasta, folosiți opțiunea „Elimină elementele șterse”. Dar nu uitați să o setați pe un număr adecvat de zile. Suportul tehnic a văzut cazuri în care opțiunea a fost setată pe un număr mai mic de zile decât intervalul de sincronizare – BCJ a început să devină haotic și să elimine punctele, fără a avea timp să le creeze.
De asemenea, țineți cont că această opțiune nu afectează deja createle puncte GFS. Dacă doriți să curățați arhivele, trebuie să faceți acest lucru manual – făcând clic dreapta pe mașină și alegând „Șterge de pe disc” (în fereastra care apare, nu uitați să bifați „Elimină copia de rezervă completă GFS”):
Noutate v.10 – copie imediată (immediate copy)
După ce am înțeles funcționalitatea „clasică”, să trecem la nou. Noutatea este o singură opțiune, dar foarte importantă. Este vorba despre un nou mod de funcționare.
Nu există un concept precum „interval de sincronizare”, sarcina va monitoriza constant dacă au apărut noi puncte și le va copia pe toate, indiferent de câte sunt. Dar, în același timp, sarcina rămâne incrementală, adică chiar dacă sarcina principală creează VBK sau VRB, aceste puncte vor fi copiate ca VIB. În rest, în acest mod nu sunt surprize – atât reținerea standard, cât și GFS funcționează conform regulilor descrise mai sus (totuși, aici este disponibil doar GFS sintetic).
Se rotesc discurile. Caracteristicile repositoarelor cu rotație a discurilor (rotated drives)
Amenințarea constantă a virușilor criptomani a făcut din de-facto un standard de securitate prezența unei copii a datelor pe un suport la care virusul nu poate ajunge. Una dintre opțiuni este utilizarea repositoarelor cu rotație a discurilor, când discurile sunt utilizate pe rând: în timp ce un disc este conectat și disponibil pentru scriere, celelalte sunt păstrate într-un loc sigur.
Pentru a învăța B&R să funcționeze cu astfel de repositoare, este necesar în setările repositoarelor, la pasul Repository, să facem clic pe butonul Advanced și să selectăm opțiunea corespunzătoare:
După aceasta, VBR va aștepta ca periodic lanțul existent să dispară din repositoar, ceea ce indică rotația discului. În funcție de tipul repositoarului și de tipul sarcinii, B&R se va comporta diferit. Acest lucru poate fi reprezentat printr-un tabel astfel:
Să analizăm fiecare opțiune.
Sarcina obișnuită și repositoarul Windows
Așadar, avem o sarcină care salvează lanțurile pe primul disc. La rotație, lanțul creat dispare de fapt, iar sarcina trebuie să supraviețuiască cumva acestei pierderi. Consolarea constă în crearea unei copii de rezervă complete. Astfel, fiecare rotație înseamnă o copie de rezervă completă. Dar ce se întâmplă cu punctele de pe discul oprit? Acestea sunt memorate și luate în considerare la calcularea reținerii. Astfel, numărul de puncte reprezentat în sarcină este numărul de puncte care trebuie păstrate pe toate discurile. Să dăm un exemplu:
Sarcina funcționează într-un mod infinit-incremental și este configurată să păstreze 3 puncte de restaurare. Dar mai avem un disc secundar, iar o dată pe săptămână efectuăm rotația (pot exista mai multe discuri, acest lucru nu schimbă esența).
În prima săptămână, sarcina va crea puncte pe primul disc și va combina pe cele inutile. Astfel, numărul total de puncte va fi trei:
Apoi, conectăm al doilea disc. La pornirea B&R, se va observa că discul s-a schimbat. Lanțul de pe primul disc va dispărea din interfață, dar informațiile despre acesta vor rămâne în baza de date. Acum, sarcina va păstra 3 puncte pe al doilea disc. Situația generală va fi aceasta:
În final, reconectăm primul disc. Înainte de a crea un nou punct, sarcina va verifica ce se întâmplă cu retenția. Și retenția, vă reamintesc, este setată să păstreze 3 puncte. Între timp, avem 3 puncte pe discul 2 (dar acesta este deconectat și păstrat într-un loc sigur, inaccesibil pentru B&R) și 3 puncte pe discul 1 (acesta este conectat). Asta înseamnă că putem șterge fără îngrijorare cele 3 puncte de pe discul 1, deoarece depășesc retenția. După care sarcina va crea din nou un backup complet, iar lanțul nostru va arăta astfel:
Dacă retenția este setată să păstreze zile în loc de numărul de puncte, logica rămâne neschimbată. În plus, retenția GFS nu este suportată deloc atunci când se utilizează repozitorii cu rotație a discurilor.
Sarcina obișnuită și repozitoriul Linux de stocare în rețea
Această opțiune este de asemenea posibilă, dar în general este mai puțin recomandată din cauza restricțiilor impuse. La rotația discului și dispariția lanțului, sarcina va reacționa la fel – prin crearea unui backup complet. Restricția este legată de mecanismul de retenție tăiat.
Aici, la rotație, întreg lanțul de pe discul deconectat este pur și simplu șters din baza de date B&R. Vă rugăm să observați – din baza de date, fișierele în sine rămân pe disc. Acestea pot fi importate și utilizate pentru recuperare, dar este ușor de dedus că, mai devreme sau mai târziu, aceste lanțuri uitate vor umple întregul repozitoriu.
Soluția constă în adăugarea DWORD ForceDeleteBackupFiles, așa cum este specificat pe această pagină: . După aceasta, sarcina va începe pur și simplu să șteargă tot conținutul folderului sarcinii sau al repozitorului (în funcție de valoare) la fiecare rotație.
Cu toate acestea, aceasta nu este o retenție elegantă, ci mai degrabă o curățare a întregului conținut. Din păcate, echipei de asistență tehnică i s-au raportat cazuri în care ca repozitoriu a fost declarat pur și simplu directorul rădăcină al discului, unde pe lângă backup-uri erau stocate și alte date. Toate acestea au fost distruse la rotație.
În plus, atunci când activezi ForceDeleteBackupFiles, acesta funcționează pentru toate tipurile de depozite, adică chiar și depozitele de pe Windows nu vor mai aplica reținerea și vor începe să ștergă conținutul. Cu alte cuvinte, un disc local pe Windows este cea mai bună alegere pentru un astfel de sistem de stocare a backup-urilor.
Copie de rezervă și depozit Windows
Cu BCJ, lucrurile devin și mai interesante. Nu doar că aici există o reținere completă, dar nu este necesar să faci un backup complet la fiecare schimbare de disc! Funcționează astfel:
Mai întâi, B&R începe să creeze puncte pe primul disc. Să spunem că am setat reținerea la 3 puncte. Sarcina va funcționa într-un mod infinit-incremental și va combina tot ce este în plus (amintesc, reținerea GFS nu este suportată în acest caz).
Apoi, conectăm al doilea disc. Deoarece pe acesta nu există încă o lanț, creăm un backup complet, după care avem un al doilea lanț de trei puncte:
În sfârșit, vine timpul să reconectăm primul disc. Și aici începe magia, deoarece sarcina nu va crea un backup complet, ci va continua pur și simplu lanțul incremental:
După aceasta, practic pe fiecare disc va exista propriul său lanț independent. Așadar, reținerea aici înseamnă nu numărul de puncte de pe toate discurile, ci numărul de puncte pe fiecare disc în parte.
Copie de rezervă și depozit Linux stocare în rețea
Și din nou, toată eleganța dispare dacă depozitul nu este pe un disc local Windows. Acest scenariu funcționează similar cu cel descris mai sus pentru sarcina simplă. La fiecare rotație, BCJ va crea un backup complet, iar punctele existente vor fi uitate. Pentru a nu rămâne fără spațiu liber, trebuie utilizat DWORD ForceDeleteBackupFiles.
Concluzie
Deci, în urma acestui text lung, am analizat două tipuri de sarcini. Desigur, există mult mai multe sarcini, dar nu le putem discuta pe toate în formatul unui singur articol. Dacă după citire mai aveți întrebări, nu ezitați să le lăsați în comentarii, voi fi bucuros să răspund personal.
Sursa: habr.com
