Përshëndetje, lexues të blogs tonë! Në njëfarë mënyre, ne jemi tashmë të njohur – postimet e mia në anglisht kanë qenë këtu përmes përkthimit nga kolegu im të dashur. . Këtë herë kam vendosur të drejtohem drejtpërdrejt ndaj publikut rusishtfolës.
Për debutimin tim, doja të gjeja një temë që të ishte interesante për një audiencë sa më të gjerë dhe që të kërkonte shqyrtim të detajuar. Daniel Defo thoshte se çdo njeri pritet nga vdekja dhe taksat. Nga ana ime, mund të them se çdo inxhinier mbështetjeje përballet me pyetje për politikat e ruajtjes së pikave të rikuperimit (ose, më thjesht, retensin). Si funksionon retensioni, kam filluar ta shpjegoj 4 vjet më parë, duke qenë një inxhinier i ri niveli të parë, dhe vazhdoj ta shpjegoj edhe tani, duke qenë tashmë lider i ekipit spanjoll dhe italishtfolës. Jam i sigurt se kolegët e mi nga niveli i dytë dhe madje edhe i tretë i mbështetjes përgjigjen gjithashtu rregullisht për të njëjtat pyetje.
Në këtë kontekst, më erdhi dëshira të shkruaj një postim përfundimtar, sa më të detajuar, në të cilin përdoruesit rusishtfolës mund të rikthehen përsëri e përsëri si në një manual. Moment i përshtatshëm – për versionin e 10-të, që sapo doli, u shtuan mundësi të reja në funksionalitetin bazë, që ka mbetur i pandryshuar për vite me radhë. Postimi im është orientuar kryesisht në këtë version—ndonëse pjesa më e madhe e asaj që kam shkruar është e saktë edhe për versionet e mëparshme, disa nga funksionalitetet e përshkruara atje thjesht nuk do t'i gjeni. Në fund, duke shikuar pak në të ardhmen, do të them se në versionin e ardhshëm pritet të ketë disa ndryshime, por për këtë ne do të flasim kur të vijë koha. Le ta fillojmë.
Detyrat e kopjimit rezervë (Backup job)
Për të filluar, le të shqyrtojmë atë pjesë që nuk ka pësuar ndryshime në versionin 10. Politika e retensionit përcaktohet nga disa parametra. Të hapim dritaren për krijimin e një detyre të re dhe të kalojmë te karta Storage. Këtu do të shohim një parameter që përcakton numrin e dëshiruar të pikave të rikuperimit:
Megjithatë, kjo është vetëm një pjesë e ekuacionit. Numri real i pikave përcaktohet gjithashtu nga regjimi i kopjimit të vendosur për detyrën. Për të zgjedhur këtë parameter, duhet të klikoni mbi butonin Advanced në të njëjtën kartë. Kjo do të hapë një dritare të re me shumë opsione. Le të numërojmë ato dhe t'i shqyrtojmë ato një nga një:
Nëse aktivizoni vetëm opsionin 1, detyra do të punojë në modin "përherë përparësor incremental" (forever forward incremental). Këtu nuk ka asnjë vështirësi – detyra do të mbajë numrin e caktuar të pikave të rikuperimit nga backup-i i plotë (skedari me shtesë VBK) deri tek inkrementi i fundit (skedari me shtesë VIB). Kur numri i pikave të kalojë vlerën e caktuar, inkrementi më i vjetër do të bashkohet me backup-in e plotë. Në fjalë të tjera, nëse detyra është e caktuar të ruajë 3 pika, menjëherë pas sesionit të ardhshëm, do të ketë 4 pika në repository, pas së cilës backup-i i plotë do të bashkohet me inkrementin më të vjetër dhe numri total i pikave do të kthehet në 3.
Po ashtu, edhe retensioni për regjimin "përmbysës incremental" (reverse incremental) është jashtëzakonisht i thjeshtë (opsioni 2). Duke qenë se në këtë rast pika më e re do të jetë backup-i i plotë, pas të cilit do të ndjekë një zinxhir i ashtuquajtur i rrotullimeve (skedarët me shtesë VRB), atëherë për të aplikuar retensionin mjafton thjesht të fshini rrotullimin më të vjetër. Situata do të jetë e njëjtë: menjëherë pas sesionit numri i pikave do të kalojë vlerën e vendosur për 1, pas së cilës do të kthehet në vlerën e kërkuar.
Vini re se me regjimin përmbysës incremental mund të aktivizoni gjithashtu një backup të plotë periodik (opsioni 4), por kjo nuk do të ndryshojë thelbin. Po, në zinxhir do të shfaqen pika të plota rikuperimi, por ne do të vazhdojmë thjesht të fshijmë pikët më të vjetra një nga një.
Së fundi, po i qasemi pjesës interesante. Nëse aktivizoni backup-in incremental, por gjithashtu aktivizoni opsionet 3 ose 4 (apo mund t'i aktivizoni të dyja njëkohësisht), detyra do të fillojë të krijojë backup-e të plota periodike "aktive" ose me metodë sintetike. Metoda e krijimit të backup-it të plotë nuk ka rëndësi – ai do të përmbajë të njëjtat të dhëna, dhe zinxhiri incremental do të ndahet në "nënzinxhirë". Kjo metodë quhet forward incremental, dhe pikërisht kjo shkakton një pjesë të konsiderueshme të pyetjeve nga klientët tanë.
Retensoni këtu aplikohet duke hequr pjesën më të vjetër të zinxhirit (nga backup-i i plotë deri te incrementi). Në këtë rast, ne nuk do të heqim vetëm backup-in e paplotë ose vetëm një pjesë të inkrementëve. E gjithë "nënzgjidhja" hiqet krejtësisht njëherësh. Ndryshon dhe kuptimi i cilësimit të numrit të pikave – nëse në metodat e tjera ky është numri maksimal i lejueshëm, pas së cilës duhet aplikuar retensioni, këtu ky cilësim përcakton numrin minimal. Me fjalë të tjera, pas heqjes së nënzgjidhjes më të vjetër, numri i pikave në pjesën e mbetur nuk duhet të bie nën këtë minimum.
Do të përpiqem ta ilustroj këtë koncept grafikisht. Le të themi se retensioni është caktuar në 3 pika, detyra punon çdo ditë me një backup të plotë të hënën. Retensioni në këtë rast do të aplikohet kur numri total i pikave arrin në 10:
Pse 10, kur vendosëm 3? Një backup i plotë u krijua të hënën. Nga e martë deri të dielën, detyra krijoi inkrementë. Në fund, të hënën tjetër krijohet përsëri një backup i plotë dhe vetëm kur krijohen 2 inkrementë, krejtësisht e gjithë pjesa e vjetër e zinxhirit mund të hiqet, sepse numri i mbetur i pikave nuk do të bjerë poshtë caktimit prej 3.
Nëse ideja është e qartë, sugjeroj që ta provoni të llogaritni retensinoni vetë. Le të marrim këto kushte: detyra fillon për herë të parë të premten (sigurisht, do të bëhet një backup i plotë). Detyra është caktuar të krijojë një backup të plotë çdo të mërkurë dhe të dielë dhe të ruajë 8 pika rikuperimi. Kur do të aplikohet retensioni për herë të parë?
Për të përgjigjur në këtë pyetje, ju rekomandoj të merrni një fletë letre, ta ndiheni sipas ditëve të javës dhe të shkruani se cila pikë krijohet çdo ditë. Pëgjigjja do të bëhet e qartë.
Përgjigja
Sqarimi: për të përgjigjur mjafton të pyesni veten "kur do të aplikohet retensioni"? Përgjigja është – kur do të mund të heqim 3 pikat e para (VBK, VIB, VIB) dhe zinxhiri i mbetur nuk do të bjerë poshtë pikave të caktuara 8. Bëhet e qartë se ne do ta bëjmë këtë kur të kemi 11 pika gjithsej, dmth. të dielën e javës së dytë.
Disa lexues mund të kundërshtojnë: "pse e gjithë kjo, nëse ka ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Më në fund, nuk e kemi shqyrtuar opsionin “Transform previous backup chains into rollbacks” (i shënuar me numrin 5). Ky opsion ndonjëherë ngatërron klientët që e aktivizojnë atë "në automat", duke dëshiruar të përfshijnë thjesht një backup sintetik. Ndërkohë, ky opsion aktivizon një mod të veçantë backup-i. Pa u thelluar në detaje, do të thosha se në këtë fazë të zhvillimit të produktit “Transform previous backup chains into rollbacks” – është një opsion i vjetëruar, dhe nuk mund të përmend një skenar në të cilin duhet të përdoret. Vlera e tij është aq e dyshimtë, saqë një kohë të caktuar Anton Gostev hodhi një thirrje përmes forumit, duke kërkuar shembuj të përdorimit të tij të dobishëm (nëse i keni, shkruani në komentet, më intereson shumë). Nëse nuk do të gjenden të tillë (mendoj se kështu do të ndodhë), atëherë opsioni do të hiqet në versionet e ardhshme.
Detyra do të krijojë inkrementë (VIB) deri në ditën kur caktuar një backup të plotë sintetik. Në këtë ditë do të krijohet vërtet një VBK, por të gjitha pikat deri në këtë VBK transformohen në rollbacks (VRB). Pas kësaj, detyra do të vazhdojë të krijojë inkrementë për backup-in e plotë deri në backup-in e ardhshëm sintetik. Në fund në zinxhir krijohet një përzierje e çuditshme e skedarëve VBK, VBR dhe VIB. Retensioni aplikohet shumë thjeshtë – duke hequr VBR-në e fundit:
Problemet
Përveç vetë kuptimit të si funksionon, shumica e problemeve që ndodhin gjatë përdorimit të modit inkremental zakonisht lidhen me backup-in e plotë. Një backup i plotë i rregullt është i nevojshëm për këtë mod, përndryshe repo do të vazhdojë të mbledhë pika derisa të mbushet.
Për shembull, një backup i plotë mund të krijohet shumë rrallë. Le të themi, detyra është caktuar të ruajë 10 pika, ndërsa një backup i plotë krijohet një herë në muaj. Është e qartë se numri aktual i pikave do të jetë shumë më i madh se ai i caktuar. Ose ndoshta detyra ka qenë caktuar të funksionojë në një modalitet përjetësisht inkremental dhe të ruajë 50 pika. Pastaj dikush aksidentalisht ka krijuar një backup të plotë. Tani, detyra do të presë derisa pika e plotë të akumulojë 49 inkrementë, pas së cilës do të aplikojë retensioni dhe do të kthehet në modalitetin e plotë të pafund.
Në raste të tjera, kopjimi i plotë është caktuar të krijohet rregullisht, por për një arsye të caktuar nuk ndodh. Do të përshkruaj këtu shkakun më të zakonshëm. Disa klientë preferojnë të përdorin opsionin “run after” dhe ta konfigurjnë detyrën për të punuar në zinxhir. Marim një shembull: ka 3 detyra që punojnë çdo ditë dhe krijojnë një kopje të plotë të së dielës. Detyra e parë starton në orën 22.30, dhe të tjerat starton në zinxhir. Kopjimi inkremental zgjat 10 minuta, kështu që deri në orën 23.00 të gjitha detyrat përfundojnë punën. Ndërsa, kopjimi i plotë zgjat një orë, kështu që të dielën ndodh e kundërta: detyra e parë punon nga 22.30 deri në 23.30. Tjetra nga 23.30 deri në 00.30. Dhe dëtyra e tretë fillon ngjashëm me të hënën. Kopjimi i plotë është caktuar për të dielën, prandaj në këtë rast nuk do të ketë. Detyra do të presë një kopje të plotë për të aplikuar ruajtjen. Prandaj, të jeni të kujdesshëm kur përdorni opsionin “run after” apo mos e përdorni fare – thjesht caktoni detyrat të fillojnë në të njëjtin kohë dhe lejoni burimin e planifikuesit të kryejë punën e tij.
Opsioni i ndërlikuar “Remove deleted items”
Duke kaluar nëpër cilësimet e detyrës Storage – Advanced – Maintenance, mund të hasni opsionin “remove deleted items data after”, i llogaritur në ditë.
Disa klientë presin që kjo të jetë ruajtja. Në të vërtetë, kjo është një opsion krejtësisht i veçantë, moskuptimi i të cilit mund të sjellë pasojat e papritura. Megjithatë, në radhë të parë duhet të shpjegohet se si B&R reagon në situatat kur gjatë sesionit kopjohen me sukses vetëm disa makina.
Le të paraqesim një skenar të tillë: një detyrë e pafundme e inkrementit, e caktuar të ruajë 6 pika. Në detyrë ka 2 makina, njëra gjithmonë kopjohet me sukses, ndërsa tjetra ndonjëherë ka dhënë gabime. Në fund, deri në pikën e shtatë, ka ndodhur një situatë e tillë:
Koha për të aplikuar ruajtjen, por një makinë ka 7 pika, ndërsa tjetra vetëm 4. A do të aplikohet ruajtja këtu? Përgjigja është – po, do të aplikohet. Nëse edhe një objekt është kopjuar, B&R e konsideron se pika është krijuar.
Një situatë e ngjashme mund të ndodhi nëse ndonjë makinë thjesht nuk është përfshirë në detyrë gjatë një seance të caktuar. Kjo ndodh, për shembull, kur makinat janë shtuar në detyrë jo individualisht, por si pjesë e kontejnerëve (dosjeve, depozita) dhe ndonjë makinë migron përkohësisht në një kontejner tjetër. Në këtë rast, detyra do të konsiderohet e suksesshme, por në statistikë do të gjeni një mesazh që e nxjerr në pah se një makinë e tillë më nuk po përpunohet nga detyra.
Çfarë do të ndodhë nëse nuk i kushtoni vëmendje kësaj? Në rastin e modit të pafund-incremental ose të rikthimit-incremental, numri i pikave të rikthimit të "makinës problematike" do të zvogëlohet me çdo seancë deri sa të arrijë 1, e ruajtur në VBK. Me fjalë të tjera, edhe nëse makina nuk do të bëjë backup për një kohë të gjatë, një pikë rikthimi do të mbetet ende. Situata është ndryshe nëse janë të aktivizuara backup-et e plota periodike. Nëse injoroni sinjalet nga B&R, përfundimisht pika e fundit mund të fshihet së bashku me pjesën e vjetër të zinxhirit.
Duke kuptuar këto detaje, më në fund mund të shqyrtojmë opsionin "Hiq të dhënat e artikujve të fshiër pas". Ky opsion do të fshijë të gjitha pikat për një makinë të caktuar, nëse kjo makinë nuk bëhet backup për një periudhë X ditësh. Kini parasysh se ky sistem nuk reagon ndaj gabimeve (provuan - nuk arritën). Nuk duhet të ketë asnjë përpjekje për të bërë backup të makinës. Duke e parë kështu, opsioni duket i dobishëm dhe gjithmonë duhet të jetë aktivizuar. Nëse administratori ka fshirë makinën nga detyra, atëherë është logjike që pas një kohe të pastrohen të dhënat e panevojshme dhe zinxhiri. Megjithatë, konfigurimi kërkon disiplinë dhe kujdes.
Më lejoni të jap një shembull nga praktika: një detyrë përfshinte disa konteinerë, përbërja e të cilëve ishte mjaft dinamike. Për shkak të mungesës së RAM-it, serveri B&R kishte probleme që kaluan pa u vënë re. Detyra u ekzekutua dhe përpiqej të bënte një backup të makinave, përveç një, e cila në atë moment nuk ishte e pranishme në konteiner. Duke qenë se shumë makina dhanë gabime, sipas parashikimeve B&R duhej të bënte 3 përpjekje të tjera për të bërë backup të makinave "problemore". Për shkak të problemeve të vazhdueshme me RAM-in, këto përpjekje u shtrinë për disa ditë. Nuk kishte një përpjekje të dytë për të bërë backup të VM-së së munguar (mungesa e VM-së nuk është gabim). Si rezultat, gjatë një prej përpjekjeve të përsëritura u përmbush kushti "Remove deleted items" dhe të gjitha pikat e makinës u hoqën.
Në lidhje me këtë, mund të themi se nëse keni vendosur njoftime për rezultatet e detyrave, dhe madje më mirë - nëse përdorni integrimin me Veeam ONE, atëherë ndoshta kjo nuk do t'ju ndodhë. Nëse ju vizitoni serverin B&R një herë në javë për të kontrolluar se gjithçka funksionon, është më mirë të shmangni opsionet që potencialisht mund të çojnë në fshirjen e backup-eve.
Çfarë është shtuar në v.10
Ajo për të cilën folëm më parë ka ekzistuar në B&R për shumë versione. Tani që kuptuam këto principe të funksionimit, le të shohim se çfarë është shtuar në 'dhjetë' jubilar.
Ruajtja ditore
Më sipër, e diskutuam politikën 'klasike' të ruajtjes, e cila është e bazuar në numrin e pikave. Një qasje alternative është të vendosni në të njëjtin menu 'ditë' në vend të 'pikave të rikthimit'.
Ideja është e qartë nga emri - ruajtja do të mbajë numrin e caktuar të ditëve, ndërsa numri i pikave në çdo ditë nuk ka rëndësi. Në këtë rast, është e rëndësishme të mbani parasysh:
- Dita aktuale nuk përfshihet në llogaritjen e ruajtjes.
- Ditet kur detyra nuk ka funksionuar fare gjithashtu merren parasysh. Ky është një fakt që duhet të keni parasysh për të mos humbur rastësisht pikët e atyre detyrave që funksionojnë jo rregullisht.
- Një pikë rikthimi llogaritet nga dita kur filloi krijimi i saj (p.sh., nëse detyra filloi të funksionojë të hënën dhe përfundoi të martën, atëherë kjo është një pikë nga e hëna).
Në aspektin tjetër, parimet e aplikimit të ruajtjes nga detyrat përsëri përcaktohen nga metoda e zgjedhur të backup-it. Le të provojmë një tjetër detyrë për llogaritje, duke përdorur të njëjtën metodë inkrementale. Le të themi se ruajtja është vendosur për 8 ditë, detyra punon çdo 6 orë me një backup të plotë të hënën. Ndërkohë, detyra nuk punon të dielën. Detyra fillon të hënën për herë të parë. Kur do të aplikohet ruajtja?
Përgjigja
Si zakonisht, është më së miri të vizatoni një tabelë. Unë do të lejoj veten ta thjeshtoj problemin dhe nuk do të vizatoj të gjitha pikët e krijuara për çdo ditë, pasi numri i pikave në ditë këtu nuk ka rëndësi. Ajo që na intereson është se të hënën e parë dhe të mërkurën e parë, pika e parë do të jetë një backup i plotë, ndërsa në ditët e tjera, detyra do të krijojë vetëm 4 pika inkrementale.
Ne kuptojmë se ruajtja do të aplikohet duke fshirë backup-in e plotë të hënës së parë dhe inkrementin e saj. Kur do të ndodhë kjo? Kur pjesa e mbetur e zinxhirit do të përmbajë 8 ditë. Në këtë rast, nuk e llogarisim ditën aktuale, por e dielën, përkundrazi, e llogarisim. Prandaj, përgjigjja është - të enjten e javës së dytë.
Arkivimi me metodën GFS për detyrat e zakonshme
Deri në v.10, metoda e ruajtjes Grandfather-Father-Son (GFS) ishte e disponueshme vetëm për detyrat e krijimit të kopjave arkivore (Backup copy) dhe detyrat e kopjimit në kaseta. Tani ajo është e disponueshme edhe për backup-et e zakonshme.
Megjithëse kjo nuk i përket temës aktuale, nuk mund të mos them se funksionaliteti i ri nuk do të thotë një largim nga strategjia 3-2-1. Prania e pikave arkivore në depozitën kryesore nuk ndikon aspak në besueshmërinë e saj. Nënkuptohet se GFS do të përdoret së bashku me depozitën e zgjerueshme (Scale-out), për të dërguar këto pika në S3 dhe ruajtje të ngjashme. Nëse nuk i përdorni, është më mirë të vazhdoni të ruani pikat fillestare dhe arkivore në depozita të ndryshme.
Tani le të shqyrtojmë parimet e krijimit të pikave GFS. Në cilësimet e detyrës, në hapin Storage, ka një buton të veçantë që thërret menunë e mëposhtme:
Këtu, thelbi i GFS mund të përmblidhet në disa pika (vini re se GFS në lloje të tjera detyrash funksionon ndryshe, por për këtë do të flasim më vonë):
- Detyra nuk krijon një backup të plotë të veçantë për pikën GFS. Në vend të kësaj, do të përdoret backup-i më i përshtatshëm nga ata që janë të disponueshëm. Prandaj, detyra duhet të punojë në modalitetin inkremental me backup të plotë të rregullt, ose backup-i i plotë duhet të krijohet manualisht nga përdoruesi.
- Nëse është i activizuar vetëm një periudhë (p.sh., javore), atëherë në fillim të periudhës GFS, detyra do të fillojë të presë një backup të plotë dhe do ta shënojë atë të parë të përshtatshëm si GFS.
Shembull: detyra është e vendosur për të ruajtur GFS javore, duke përdorur backup-in e të mërkurës. Detyra punon çdo ditë, por backup-i i plotë është caktuar për të premten. Në këtë rast, të mërkurën do të fillojë periudha GFS dhe detyra do të fillojë të presë pikën e përshtatshme. Ajo do të shfaqet të premten dhe do të shënohet me flamurin GFS.
- Nëse janë aktivizuar disa periudha menjëherë (p.sh., javore dhe mujore), atëherë B&R do të zbatojë një metodë që lejon përdorimin e të njëjtës pikë si GFS për disa intervale (për qëllime kursimi hapësire). Flamujt do të caktohen njëri pas tjetrit, duke filluar nga më të rinjtë.
Shembuj: GFS javore është caktuar për të mërkurën, ndërsa ai mujor - për javën e fundit të muajit. Detyra funksionon çdo ditë dhe krijon kopje rezervë të plota të hënave dhe premteve.
Për thjeshtësi, le të fillojmë llogaritjen nga java e parafundit të muajit. Në këtë javë do të krijohet një kopje rezervë e plotë të hënën, por ajo do të injorohet, sepse intervali javor GFS fillon të mërkurën. Megjithatë, kopja e plotë e premtes është plotësisht e përshtatshme për pikën GFS. Ky sistem është tashmë i njohur për ne.
Tani le të shohim se çfarë do të ndodhë në javën e fundit të muajit. Intervali mujor GFS do të fillojë të hënën, por kopja VBK e hënës nuk do të markohet si GFS, sepse detyra përpiqet të markojë një VBK si pikën GFS mujore dhe javore. Në këtë rast, kërkimi fillon me atë javore, sepse ajo gjithsesi mund të bëhet edhe mujore.
Nëse aktivizoni vetëm intervalet javore dhe vjetore, ato do të veprojnë pavarësisht njëri-tjetrit dhe mund të markojnë 2 VBK dallueshëm si intervale të GFS.
Detyrat për krijimin e kopjës së arkivave (Backup copy)
Një tjetër tip detyrash, që shpesh kërkon shpjegime për funksionimin e tij. Fillimisht, le të shqyrtojmë metodën «klasike» të funksionimit, pa risitë e v.10.
Metoda e thjeshtë e mbajtjes
Në mënyrë standarde, këto detyra funksionojnë në një mod me inkrementale të pafund. Krijimi i pikave përcaktohet nga dy parametra - intervali i kopjimit dhe numri i dëshiruar i pikave të rikuperimit (nuk ka mbajtje sipas ditëve këtu). Intervali i kopjimit caktuar në faqen e parë të Detyrës gjatë krijimit të saj:
Numri i pikave përcaktohet më tej në faqen Target.
Detyra krijon 1 pikë të re për çdo interval (sa pika janë krijuar për VM nga detyrat fillestare, nuk ka rëndësi). Në fund të intervalit, pika e re finalizohet dhe, nëse është e nevojshme, aplikohet mbajtja duke bashkuar VBK dhe inkrementin më të vjetër. Ky mekanizëm na është tashmë i njohur.
Metoda e mbajtjes duke përdorur GFS
BCJ gjithashtu mund të ruajë pikët e arkivave. Kjo konfigurohet në të njëjtën faqen Target, pak më poshtë nga vendosja e numrit të pikave të rikuperimit:
Pikat GFS mund të krijohen në dy mënyra - sintetike, duke përdorur të dhënat në depozitat sekondare, ose duke imituar një kopje të plotë dhe duke lexuar të gjithë të dhënat nga depozita primare (aktivizohet nga opsioni, i shënuar me numrin 3). Mbajtja në të dy rastet do të ndryshojë ndjeshëm, prandaj le të shqyrtojmë ato veçmas.
GFS sintetike
Në këtë rast, pika GFS nuk krijohet saktësisht në ditën e caktuar. Në vend të kësaj, pika GFS do të krijohet kur VIB i atij ditë, për të cilin është caktuar krijimi i pikës GFS, bashkohet me kopjen e plotë. Kjo ndonjëherë shkakton keqkuptime, sepse koha kalon, por pika GFS ende nuk është. Vetëm një shaman i fuqishëm nga mbështetja mund të parashikojë se në cilën ditë pika do të shfaqet. Në fakt, nuk nevojitet magji - mjafton të shihni numrin e caktuar të pikave dhe intervalin e sinkronizimit (sa pika krijohen çdo ditë). Provoni të llogaritni vetë me një shembull të tillë: detyra caktuar të ruajë 7 pika, intervali i sinkronizimit - 12 orë (dmth 2 pika në ditë). Aktualisht, në zinxhirin janë gjithsej 7 pika, sot është e hënë dhe për këtë ditë është caktuar krijimi i pikës GFS. Në cilën ditë do të krijohet ajo?
Përgjigja
Këtu është më mirë të përshkruhet se si zinxhiri do të ndryshojë në dinamikë, për ditë:
Kështu, të hënën inkrementi i fundit në zinxhir shënohet si GFS, por nuk ka asnjë ndryshim tjetër të dukshëm. Çdo ditë, detyra krijon 2 pika të reja dhe mbajtja pa mëshirë e lë zinçhirin përpara. Më në fund, të enjten vjen koha për të aplikuar mbajtjen në atij inkrementi. Kjo seancë do të zgjasë më shumë se zakonisht - sepse detyra «do të nxjerrë» bloket e nevojshme nga zinxhiri dhe do të krijojë një pikë të re të plotë. Që nga ky moment, në zinxhir do të ketë gjithsej 8 pika - 7 në zinxhirin kryesor + GFS.
Krijimi i pikave GFS me opsionin “Lexo tërë pikën”
Më lart thashë se BCJ punon në një mod të pafundshëm. Tani do të shqyrtojmë përjashtimin e vetëm nga kjo rregull. Kur aktivizohet opsioni “Lexo tërë pikën”, pika GFS do të krijohet saktësisht në ditën e caktuar. Detyra vetë do të funksionojë në mod inkremental me kopje rezervë të plota periodike, të cilat kemi shqyrtuar më lart. Mbajtja gjithashtu do të zbatohet duke fshirë pjesën më të vjetër të zinxhirit. Megjithatë, në këtë rast do të fshihen vetëm inkrementet, ndërsa kopja e plotë do të lihet si pikë GFS. Prandaj, në llogaritjen e mbajtjes, nuk merren parasysh pikët e shënuara me flamuj GFS.
Supozoni se ka detyra, që të ruajë 7 pika dhe të krijojë një pikë GFS javore të hënën. Në këtë rast, çdo të hënë detyra do të krijojë në të vërtetë një kopje të plotë rezervë dhe do ta shënojë atë si GFS. Retensioni do të aplikohet kur pas fshirjes së inkrementëve nga pjesa më e vjetër, numri i inkrementëve të mbetur nuk bie nën 7. Ja si duket në diagram:
Pra, deri në fund të javës së dytë, në zinxhir ka gjithsej 14 pika. Gjatë javës së dytë, detyra krijoi 7 pika. Nëse do të ishte një detyrë e thjeshtë, retensioni do të ishin aplikuar tashmë. Por kjo është BCJ me retension GFS, prandaj ne nuk i numërojmë pikat GFS dhe, kështu, ato janë vetëm 6. Kjo do të thotë që ne ende nuk mund të aplikojmë retensionin. Në javën e tretë krijojmë një kopje të plotë rezervë tjetër me flamurin GFS. 15 pika, por këtë herë ne përsëri nuk e numërojmë. Dhe, në fund, të martën e javës së tretë krijojmë një inkrement. Tani, nëse fshijmë inkrementët e zinxhirit të javës së parë, numri total i inkrementëve do të përmbushë retensionin e vendosur.
Siç është përmendur më lart, në këtë metodë është shumë e rëndësishme që kopjet e plota rezervë të krijohen rregullisht. Le të themi, nëse vendosni retensionin kryesor për 7 ditë, por vetëm 1 pikë vjetore, nuk është e vështirë të imagjinosh se inkrementët do të grumbullohen shumë, shumë më tepër se 7. Në këto raste, është më mirë të përdorni metodën sintetike të krijimit të GFS.
Dhe përsëri “Fshij artikujt e fshirë”
Kjo opsion është gjithashtu e pranishme për BCJ:
Logjika e këtij opsioni këtu është e njëjtë me ato në detyrat e zakonshme të rezervës – nëse makina nuk përpunon një numër të caktuar ditësh, të dhënat e saj fshihen nga zinxhiri. Megjithatë, për BCJ, dobia e këtij opsioni është objektivisht më e lartë, dhe ja pse.
Në mënyrë të zakonshme, BCJ funksionon në një regjim të pafund inkremental, prandaj nëse në ndonjë moment makina fshihet nga detyra, retensioni gradualisht do të fshijë të gjitha pikat e rikuperimit, derisa të mbetet vetëm një e vetme – në VBK. Tani le të imagjinojmë se detyra është ende e konfiguruar për të krijuar pika sintetike GFS. Kur të vijë koha, detyra do të duhet të krijojë GFS për të gjitha makinat në zinxhir. Nëse ndonjë makinë nuk ka pikë të reja fare – çfarë të bëjmë, do të duhet të përdorim atë që është. Dhe kështu çdo herë. Në fund mund të ndodhë një situatë e tillë:
Vini re seksionin e Skedarëve: kemi VBK-në kryesore dhe 2 pika GFS javore. Dhe tani në seksionin e Pikave të Rikuperimit – në të vërtetë këto skedarë kanë të njëjtin imazh të makinës. Sigurisht, nuk ka asnjë kuptim në këto pika GFS, ato vetëm zënë vend.
Kjo situatë është e mundur vetëm me përdorimin e GFS sintetike. Për ta parandaluar këtë, përdorni opsionin “Fshij artikujt e fshirë”. Vetëm mos harroni ta vendosni atë në një numër adekuat ditësh. Mbështetje teknike ka parë raste kur opsioni është vendosur për një numër më të vogël ditësh sesa intervali i sinkronizimit – BCJ filloi të çmendet dhe fshiu pikat pa i krijuar ato.
Kujtohuni gjithashtu se ky opsion nuk prek pikat GFS që janë krijuar tashmë. Nëse dëshironi të pastroni arkivat, duhet ta bëni këtë manualisht – duke klikuar me të djathtën mbi makinën dhe duke zgjedhur “Fshi nga disku” (në dritaren që shfaqet, mos harroni të vendosni shenjën “Fshij kopjen e plotë GFS”):
Noviteti v.10 – kopja e menjëhershme (immediate copy)
Pas trajtimit të funksionalitetit «klasik», le të kalojmë në të rejat. Ka një novitet, por shumë të rëndësishëm. Ky është – një mod për punë të re.
Këtu nuk ka një koncept të tillë si «intervali i sinkronizimit», detyra do të ndjekë vazhdimisht nëse kanë dalë pika të reja, dhe do të kopjojë të gjitha ato, sa do që të jenë. Por, megjithatë, detyra mbetet inkrementale, pra, edhe nëse detyra kryesore krijon VBK ose VRB, këto pika do të kopjohen si VIB. Në tërësi, në këtë regjim nuk ka surpriza – si retensioni standard ashtu edhe GFS funksionojnë sipas rregullave të përshkruara më lart (në të vërtetë, këtu është i aksesueshëm vetëm GFS sintetik).
Disku po rrotullohet. Karakteristikat e depozitave me rrotullim disku (rotated drives)
Kërcënimi i vazhdueshëm i viruseve-kriptex e ka bërë standardin e sigurisë të ketë një kopje të dhënash në një medium, në të cilin virusi nuk mund të arrijë. Një nga opsionet është përdorimi i depozitave me rrotullim disku, kur diskët përdoren njëri pas tjetrit: ndërsa një disk është i lidhur dhe i disponueshëm për shkrim, diskët e tjerë ruhen në një vend të sigurt.
Për të mësuar B&R të punojë me këto depozita, është e nevojshme në cilësimet e depozitës, në hapin Repository, të klikoni mbi butonin Advanced dhe të zgjidhni opsionin përkatës:
Pas kësaj, VBR do të presë që periodikisht zinxhiri ekzistues të zhduket nga depozita, që do të thotë rrotullimin e diskut. Në varësi të llojit të depozitës dhe llojit të detyrës, B&R do të sillet ndryshe. Kjo mund të paraqitet me këtë tavolinë:
Të shqyrtojmë secilën mundësi.
Detyra e zakonshme dhe repozitori Windows
Pra, kemi një detyrë që ruan zinxhirët në diskun e parë. Gjatë rotacionit, zinxhiri i krijuar në të vërtetë zhduket, dhe detyra duhet të gjejë një mënyrë për të përballuar këtë humbje. Ngushëllimi i saj gjendet në krijimin e një kopjeje të plotë rezervë. Kështu, çdo rotacion do të thotë një kopje të plotë rezervë. Por çfarë ndodh me pikat në diskun e çaktivizuar? Ato ruhen dhe merren parasysh në llogaritjen e ruajtjes. Pra, numri i caktuar i pikave në detyrë është ajo që nevojitet të ruhet në të gjitha diskët. Le të japim një shembull:
Detyra punon në modin përjetësisht-incremental dhe është e konfigurueshme për të ruajtur 3 pika rikuperimi. Por kemi edhe një disk të dytë, dhe çdo javë bëjmë rotacion (diskë mund të jenë edhe më shumë, kjo nuk e ndryshon esencialisht).
Në javën e parë, detyra do të krijojë pika në diskun e parë dhe do të bashkojë të tepërta. Kështu, numri total i pikave do të jetë tre:
Më pas, ne lidhim diskun e dytë. Kur të startojmë B&R, do të vërë re që disku është ndryshuar. Zinxhiri në diskun e parë do të zhduket nga ndërfaqja, por informacioni rreth tij do të mbetet në bazë. Tani detyra do të ruajë 3 pika në diskun e dytë. Situata e përgjithshme do të jetë kjo:
Përfundimisht, ne lidhi përsëri diskun e parë. Para se të krijojmë një pikë të re, detyra do të kontrollojë se çfarë ndodhet me ruajtjen. Dhe ruajtja, të cilën e kujtoj, është caktuar për të ruajtur 3 pika. Ndërkohë kemi 3 pika në diskun 2 (por ai është çaktivizuar dhe ruhet në një vend të sigurt, ku B&R nuk mund të arrijë) dhe 3 pika në diskun 1 (që është i lidhur). Kështu, mund të fshijmë me siguri 3 pika nga disku 1, pasi ato përmbushin ruajtjen. Pas kësaj, detyra krijon përsëri një kopje të plotë rezervë, dhe zinxhiri ynë fillon të duket kështu:
Nëse ruajtja është caktuar për të mbajtur ditë në vend të numrit të pikave, logjika nuk ndryshon. Për më tepër, ruajtja GFS nuk mbështetet fare kur përdoren repozitorë me rotacion diskësh.
Detyra e zakonshme dhe repozitori Linux storage rrjetor
Një mundësi e tillë është gjithashtu e mundur, por në përgjithësi është më pak e rekomanduar për shkak të kufizimeve të vendosura. Një detyrë do të reagojë në rotacionin e disku dhe zhdukjen e zinxhirit ashtu siç – duke krijuar një kopje të plotë rezervë. Por kufizimi është i lidhur me mekanizmin e prerë të ruajtjes.
Këtu, gjatë rotacionit, e gjithë zinxhiri në diskun e çaktivizuar thjesht fshihet nga baza e të dhënave B&R. Vini re – nga baza e të dhënave, skedarët vetë mbeten në disk. Ata mund të importohen dhe përdoren për rikuperim, por nuk është e vështirë të kuptohet se herët apo vonë, këto zinxhirë të harruar do të mbushin të gjithë repozitorin.
Zgjidhja është në shtimin e DWORD ForceDeleteBackupFiles siç është e specifikuar në këtë faqe: . Pas kësaj, detyra do të fillojë thjesht të fshijë të gjithë përmbajtjen e dosjes së detyrës ose dosjes së repozitorit (varianti varion në bazë të vlerës) në çdo rotacion.
Megjithatë, kjo nuk është një ruajtje elegante, por thjesht pastrimi i përmbajtjes së të gjithë skedarëve. Fatkeqësisht, stafi i mbështetjes teknike ka hasur raste kur si repozitor ishte caktuar thjesht ruta më e lartë e diskut, ku përveç kopjeve rezervë ndodheshin gjithashtu të dhëna të tjera. E gjithë kjo u shkatërrua gjatë rotacionit.
Për më tepër, kur është aktivizuar ForceDeleteBackupFiles, ajo funksionon për të gjithashtu llojet e repozitorëve, duke përfshirë edhe repozitorët në Windows, të cilat do të ndalojnë përdorimin e ruajtjes dhe do të fillojnë të fshijnë përmbajtjen. Në fjalë të tjera, disku lokal në Windows është zgjedhja më e mirë për një sistem storage rezervash të tillë.
Kopja rezervë dhe repozitori Windows
Me BCJ gjërat bëhen edhe më interesante. Jo vetëm që këtu ka një ruajtje të plotë, por nuk është e nevojshme të bëni një kopje të plotë rezervë në çdo ndryshim disku! Kjo funksionon kështu:
Së pari, B&R fillon të krijojë pika në diskun e parë. Le të themi se ne kemi caktuar ruajtje për 3 pika. Detyra do të punojë në modin përjetësisht-incremental dhe do të bashkojë gjithçka të tepërt (kujtoj, ruajtja GFS në këtë rast nuk mbështetet).
Më pas ne lidhim diskun e dytë. Duke qenë se atij akoma nuk i ka asnjë zinxhir, krijojmë një kopje të plotë rezervë, pas së cilës kemi një zinxhir të dytë me tre pika:
Përfundimisht, vjen koha për të lidhur përsëri diskun e parë. Dhe këtu fillon magia, pasi detyra nuk do të krijojë një kopje të plotë rezervë, por në vend të kësaj do të vazhdojë thjesht zinxhirin incremental:
Pas kësaj, në fakt në çdo disk do të ekzistojë një zinxhir i pavarur. Pra, ruajtja këtu nënkupton jo numrin e pikave në të gjithë diskët, por numrin e pikave në secilin disk veç e veç.
Kopja rezervë dhe repozitori Linux storage rrjetor
Dhe gjithë eleganca humbet përsëri nëse depozita nuk është në diskun lokal të Windows. Ky skenar punon në mënyrë të ngjashme me atë të shqyrtuar më sipër me një detyrë të thjeshtë. Me çdo rotacion, BCJ do të krijojë një backup të plotë, dhe piketat ekzistuese do të harrohen. Për të mos mbetur pa hapësirë, duhet të përdorni DWORD ForceDeleteBackupFiles.
Përfundimi
Pra, si rezultat i një teksti të tillë të gjatë, ne shqyrtuam dy lloje detyrash. Sigurisht, ka shumë më shumë detyra, por nuk mund t'i shqyrtojmë të gjitha në formatin e një artikelit. Nëse pas leximit keni ndonjë pyetje, ju lutem, shkruani ato në komente, do të jem i lumtur t'u përgjigjem personalisht.
Burimi: habr.com
