Përshëndetje lexuesve të blogut tonë! Disi jemi tashmë të njohur – postimet e mia në anglisht kanë qenë këtu në përkthimin e koleges time të shtrenjtë. . Këtë herë kam vendosur t'i drejtohem publikut shqipfolës direkt.
Për debutimin tim doja të gjeja një temë që të ishte interesante për një audiencë sa më të gjerë dhe që kërkonte shqyrtim të detajuar. Daniel Defo thoshte se çdo njeri e pret vdekja dhe taksat. Nga ana ime mund të them se çdo inxhinier mbështetjeje e pret pyetje për politikat e ruajtjes së pikave të rikthimit (ose ndryshe – retenshën). Si funksionon retensha, fillova ta shpjegoj 4 vjet më parë, duke qenë inxhinier i ri i nivelit të parë, vazhdoj ta shpjegoj edhe tani, duke qenë tashmë lider i ekipit spanjoll dhe italian. Jam i sigurt që kolegët e mi të nivelit të dytë dhe madje edhe të tretë të mbështetjes përgjigjen rregullisht ndaj të njëjtave pyetje.
Në këtë dritë, dëshiroja të shkruaja një postim përfundimtar, sa më të detajuar, në të cilin përdoruesit shqipfolës mund të kthehen përsëri dhe përsëri si një udhëzues. Momenti është i përshtatshëm – sapo është lëshuar versioni jubilant i dhjetë që ka shtuar mundësi të reja në funksionalitetin bazë, që nuk ka ndryshuar për vite. Postimi im është orientuar kryesisht ndaj këtij versioni – megjithatë, shumica e asaj që është shkruar është e vërtetë edhe për versionet e mëparshme, disa nga funksionalitetet e përshkruara nuk do t'i gjeni atje. Së fundi, duke shikuar pak në të ardhmen, them se në versionin e ardhshëm priten disa ndryshime, por për këtë ne do të flasim kur të vijë koha. Pra, le të fillojmë.
Detyrat e kopjimit rezervë (Backup job)
Për të filluar, le të shqyrtojmë atë pjesë që nuk është ndryshuar në versionin 10. Politika e retenshës përcaktohet nga disa parametra. Do të hapim dritaren për krijimin e një detyre të re dhe do të shkojmë në skedën Storage. Këtu do të shohim parametrin që përcakton numrin e dëshiruar të pikave të rikthimit:
Megjithatë, kjo është vetëm një pjesë e ekuacionit. Numri real i pikave përcaktohet gjithashtu nga mënyra e kopjimit, e cila është vendosur për detyrën. Për të zgjedhur këtë parametr, duhet të klikoni mbi butonin Advanced në të njëjtën skedë. Kjo do të hapë një dritare të re me shumë mundësi. Do t'i numërojmë ato dhe do t'i shqyrtojmë një nga një:
Nëse aktivizohet vetëm opsioni 1, detyra do të funksionojë në modalitetin "incremental të pafund" (forever forward incremental). Nuk ka asnjë vështirësi këtu - detyra do të ruajë numrin e caktuar të pikave të rikuperimit nga kopja e plotë (skedari me zgjerim VBK) deri në inkrementin e fundit (skedari me zgjerim VIB). Kur numri i pikave të kalojë vlerën e caktuar, inkrementi më i vjetër do të bashkohet me kopjen e plotë. Me fjalë të tjera, nëse detyra është vendosur të ruajë 3 pika, menjëherë pas seancës së radhës do të ketë 4 pika në repositor, pas së cilës kopja e plotë do të bashkohet me inkrementin më të vjetër dhe numri total i pikave do të kthehet në 3.
Po ashtu, retention për modalitetin "reverse incremental" (opsioni 2) është jashtëzakonisht i thjeshtë. Meqenëse në këtë rast pika më e re do të jetë kopja e plotë, e cila do të ndjekë një zinxhir të ashtuquajtur "rollback" (skedarët me zgjerim VRB), për të aplikuar retention është mjaft të eleminosh rollback-un më të vjetër. Situata do të jetë e njëjtë: menjëherë pas seancës numri i pikave do të kalojë vlerën e caktuar me 1, pas së cilës do të kthehet në vlerën e kërkuar.
Kujdes, që me modalitetin reverse incremental mund të aktivizohet gjithashtu një kopje e plotë periodike (opsioni 4), por kjo nuk do ta ndryshojë thelbin. Po, në zinxhir do të shfaqen pikë të plota rikuperimi, por ne do të vazhdojmë të fshijmë pikët më të vjetra një nga një.
Në fund, po i afrohemi pjesës interesante. Nëse aktivizoni kopjen inkrementale, por gjithashtu aktivizoni opsionet 3 ose 4 (madje mund të aktivizoni të dyja njëkohësisht), detyra do të fillojë të krijojë kopje të plota periodike "aktive" ose me metodën sintetike. Metoda e krijimit të kopjes së plotë nuk është e rëndësishme - ajo do të përmbajë të njëjtat të dhëna, dhe zinxhiri inkremental do të ndahet në "podzinqira". Kjo metodë quhet forward incremental, dhe kjo është ajo që shkakton një pjesë të madhe të pyetjeve nga ana e klientëve tanë.
Retenshioni aplikohet këtu duke fshirë pjesën më të vjetër të zinxhirit (nga backup-i i plotë deri te inkrementi). Në këtë mënyrë, ne nuk do të fshijmë vetëm backup-in e zbrazët ose vetëm një pjesë të inkrementeve. I gjithë "nënzinxhiri" fshihet plotësisht në një herë. Ndryshon gjithashtu kuptimi i parametrit të numrit të pikave – nëse në metoda të tjera kjo është numri maksimal i lejuar, pas të cilit duhet të aplikohet retenshioni, këtu ky parametër përcakton numrin minimal. Me fjalë të tjera, pas fshirjes së "nënzinxhirit" më të vjetër, numri i pikave në pjesën e mbetur nuk duhet të bjerë nën këtë minimum.
Do të përpiqem ta ilustroj këtë koncept grafikisht. Supozoni se retenshioni është vendosur në 3 pika, dhe detyra funksionon çdo ditë me një backup të plotë të ditës hënë. Në këtë rast, retenshioni do të aplikohet kur numri total i pikave arrin 10:
Pse 10, kur vendosëm 3? Një backup i plotë u krijua të hënën. Nga e martë në të diel, detyra krijonte inkremente. Finalmente, të hënën tjetër krijohet përsëri një backup i plotë dhe vetëm kur krijohen 2 inkremente, mund të fshihet e gjithë pjesa e vjetër e zinxhirit, sepse numri i mbetur i pikave nuk do të bjerë nën 3 të vendosura.
Nëse ideja është e qartë, ju ftoj të provoni të llogaritni retenshionin vetë. Të supozojmë këto kushte: detyra fillon për herë të parë të enjten (sigurisht, do të bëhet një backup i plotë). Detyra është vendosur të krijojë një backup të plotë të mërkurave dhe të dielave dhe të ruajë 8 pika rikuperimi. Kur do të aplikohet retenshioni për herë të parë?
Për të përgjigjur në këtë pyetje, ju rekomandoj të merrni një letër, ta ndani sipas ditëve të javës dhe të shkruani se cila pikë krijohet çdo ditë. Përgjigja do të bëhet e qartë.
Përgjigje
Shpjegim: për të përgjigjur, mjafton të pyesni veten "kur do të aplikohet retenshioni"? Përgjigja është - kur mund të fshijmë 3 pikat e para (VBK, VIB, VIB) dhe zinxhiri i mbetur nuk do të bjerë nën 8 pika të vendosura. Bëhet e qartë se ne do të mund të bëjmë këtë kur kemi 11 pika në total, pra të dielën e javës së dytë.
Disa lexues mund të kundërshtojnë: "pse gjithë kjo, nëse ka ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Në fund, ne nuk e shqyrtuam opsionin "Transform previous backup chains into rollbacks" (i shënuar me numrin 5). Ky opsion nganjëherë i ngatërrohet klientëve që e aktivizojnë atë "automatikisht", duke dëshiruar të përfshijnë thjesht një backup sintetik. Megjithatë, ky opsion aktivizon një mod të veçantë backup-i. Pa hyrë në detaje, do të thosha se në këtë fazë të zhvillimit të produktit, "Transform previous backup chains into rollbacks" është një opsion i tejkaluar, dhe nuk mund të imagjinoj asnjë skenar ku do të ishte e nevojshme ta përdorim atë. Vlera e saj është aq e diskutueshme, saqë për një kohë të gjatë Anton Gostev kërkoi në forum për të dërguar shembuj të përdorimit të saj të dobishëm (nëse i keni, ju lutem shkruani në komentet, më intereson shumë). Nëse nuk do të gjendet asnjë (mendoj se kështu do të jetë), atëherë opsioni do të hiqet në versionet e ardhshme.
Detyra do të krijojë inkremente (VIB) deri në ditën kur është caktuar një backup sintetik i plotë. Në këtë ditë krijohet rëndomtë një VBK, por të gjithë piket deri në këtë VBK transformohen në rollbacks (VRB). Pas kësaj, detyra do të vazhdojë të krijojë inkremente për backup-in e plotë deri në backup-in e ardhshëm sintetik. Në përfundim, krijohet një përzierje e bërë nga skedarët VBK, VBR dhe VIB. Retensioni aplikohet shumë thjeshtë – duke fshirë VBR-në e fundit:
Problemet
Përveç se të kuptoni si funksionon kjo, shumica e problemeve që ndodhin gjatë përdorimit të modit inkremental zakonisht lidhen me backup-in e plotë. Një backup i rregullt i plotë është i nevojshëm për këtë mod, përndryshe repozitori do të mbledhë pika derisa të mbushet.
Për shembull, backup-i i plotë mund të krijohet shumë rrallë. Le të themi, detyra është vendosur të ruajë 10 pika, ndërsa një backup i plotë krijohet një herë në muaj. Është e qartë se numri real i pikave këtu do të jetë ndjeshëm më i madh se ai i vendosur. Ose detyra është vendosur të punojë në modin inkremental të pafund dhe të ruajë 50 pika. Pastaj dikush papritur krijoi një backup të plotë. Tani, detyra do të presë deri sa pika e plotë të grumbullojë 49 inkremente, pas së cilës do të aplikohet retensioni dhe do të kthehet në modin e plotë të pafund.
Në raste të tjera, backup-i i plotë është planifikuar të krijohet rregullisht, por për ndonjë arsye, kjo nuk ndodh. Do ta shpjegoj këtu shkakun më të zakonshëm. Disa klientë preferojnë të përdorin mundësinë e planifikimit "run after" dhe të programojnë detyra për të punuar në zinxhir. Të marrim një shembull: ka 3 detyra që punojnë çdo ditë dhe krijojnë një backup të plotë të dielën. Detyra e parë fillon në 22:30, të tjerat fillojnë në zinxhir. Backup-i incremental zë 10 minuta, kështu që deri në 23:00 të gjitha detyrat përfundojnë punën. Ndërsa backup-i i plotë zë një orë, prandaj të dielën ndodh e siguiente: detyra e parë punon nga 22:30 deri në 23:30. Tjetër nga 23:30 deri në 00:30. Dhe detyra e tretë fillon vetëm të hënën. Backup-i i plotë është planifikuar për të dielën, prandaj në këtë rast nuk do të ketë thjesht. Detyra do të presë që backup-i i plotë të aplikohet për të zbatuar retencën. Prandaj, jini të kujdesshëm kur përdorni mundësinë "run after" ose mos e përdorni fare – thjesht planifikoni detyrat të fillojnë në të njëjtën kohë dhe lejoni planifikuesin e burimeve të bëjë punën e tij.
Mundësi e komplikuar "Remove deleted items"
Duke kaluar përmes cilësimeve të detyrës Storage – Advanced – Maintenance, mund të gjeni mundësinë "remove deleted items data after", e cila llogaritet në ditë.
Disa klientë presin që kjo të jetë retenca. Në të vërtetë, kjo është një mundësi krejtësisht e veçantë, mungesa e kuptimit të së cilës mund të sjellë pasoja të papritura. Sidoqoftë, së pari duhet shpjeguar se si B&R reagon në situatat kur gjatë seancës me sukses backupohen vetëm disa makina.
Të imagjinojmë një skenar: një detyrë incremental e pafund, e cila është planifikuar të mbajë 6 pika. Në detyrë janë 2 makina, njëra gjithmonë ka përfunduar me sukses backup, tjetra ndonjëherë ka dhënë gabime. Në përfundim, në pikën e shtatë ka arritur një situatë të tillë:
Koha për të aplikuar retencën, por një makinë ka 7 pika, ndërsa tjetra vetëm 4. A do të aplikohet këtu retenca? Përgjigjja – po, do të aplikohet. Nëse së paku një objekt është backupuar, B&R e konsideron se pika është krijuar.
Një situatë e ngjashme mund të ndodhë nëse ndonjë makinë thjesht nuk u përfshi në detyrë gjatë një seance të caktuar. Kjo ndodh, për shembull, kur makinat janë shtuar në detyrë jo individualisht, por si pjesë e konteinerëve (dosjeve, ruajtjeve) dhe ndonjë makinë migron përkohësisht në një konteiner tjetër. Në këtë rast, detyra do të konsiderohet e suksesshme, por në statistika do të gjeni një mesazh që ju thotë të merrni parasysh se makina e tillë nuk po përpunon më detyrën.
Çfarë do të ndodhë nëse nuk i kushtoni vëmendje këtyre? Në rastin e modifikimeve të pafundme ose të përmbysura, numri i pikave të rikuperimit për makinën "problem" do të ulet me çdo seancë, derisa të arrijë në 1, e ruajtur në VBK. Me fjalë të tjera, edhe nëse makina nuk do të bëhet backup për një kohë të gjatë, një pikë rikuperimi do të mbetet gjithsesi. Gjërat qëndrojnë ndryshe nëse janë aktivizuar 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.
Pas kuptimit të këtyre detajeve, tani mund të shqyrtojmë opsionin "Shkarko të dhënat e elementeve të fshira pas". Ai do të fshijë të gjitha pikat për një makinë të caktuar, nëse kjo makinë nuk bëhet backup për X ditë. Vini re se kjo cilësim nuk reagon ndaj gabimeve (provoni – nuk funksionoi). Nuk duhet të ketë as një përpjekje për të bërë backup të makinës. Duket se opsioni është i dobishëm dhe gjithmonë duhet mbajtur aktiv. Nëse administratori e ka fshirë makinën nga detyra, është logjike të pastrohet nga të dhënat e panevojshme dhe zinxhiri pas një kohe. Megjithatë, cilësimi kërkon disiplinë dhe vëmendje.
Të jap një shembull nga praktika: në detyrë u shtuan disa kontejnerë, 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ë mbetën të pa vërejtura. Detyra u aktivizua dhe përpiqej të bënte një backup të makinave, përveç një, e cila në atë kohë nuk ishte e pranishme në kontejner. Meqenëse shumë makina dhanë gabime, sipas të dhënave, B&R duhet të bënte 3 përpjekje shtesë për të bërë backup të makinave 'problem', dhe për shkak të problemeve të vazhdueshme me RAM-in, këto përpjekje zgjatën disa ditë. Nuk pati një përpjekje të dytë për të bërë backup të VM-së së munguar (mungesa e VM-së nuk është një gabim). Në fund, gjatë një prej përpjekjeve të përsëritura u realizua kushti “Fshij artikujt e fshirë” dhe të gjithë pikët e makinës u fshin.
Në lidhje me këtë, mund të them se: nëse keni konfigurime njoftimesh për rezultatet e detyrave, e madhe më mirë – përdoren integrimet me Veeam ONE, atëherë me siguri kjo nuk do t'ju ndodhë. Nëse megjithatë e kontrolloni serverin B&R një herë në javë, për të kontroluar që gjithçka funksionon, është më mirë të heqni dorë nga opsionet që potencialisht mund të çojnë në fshirjen e backup-eve.
Çfarë është shtuar në v.10
Ajo që diskutuam më parë ka ekzistuar në B&R për shumë versione. Pas kuptimit të këtyre parimeve të funksionimit, le të shohim tani se çfarë është shtuar në jubileun 'dhjetë'.
Ruajtja ditore
Më sipër diskutuam politikën 'klasike' të ruajtjes, të bazuar në numrin e pikëve. Qasja alternative – të vendosni në të njëjtin menu “ditët” në vend të “pikave të rikuperimit”.
Ideja është e qartë nga emri – ruajtja do të mbajë një sasi të caktuar ditësh, ndërsa numri i pikëve në çdo ditë nuk ka rëndësi. Por duhet të keni parasysh se:
- Dita aktuale nuk përfshihet në llogaritjen e ruajtjes
- Ditët kur detyra nuk ka punuar fare, gjithashtu llogariten. Kjo duhet marrë parasysh për të mos humbur rastësisht pikët e atyre detyrave që funksionojnë në mënyrë të parregullt.
- Pika e rikuperimit konsiderohet nga dita kur filloi krijimi i saj (dmth. nëse detyra filloi të punojë të hënën dhe përfundoi të martën, atëherë kjo është një pikë nga e hëna)
Në të tjera, parimet e aplikimit të retenzionit për detyrat përsëri përcaktohen nga metoda e zgjedhur e backup-it. Le të provojmë një detyrë tjetër për llogaritje, duke përdorur të njëjtën metodë inkrementale. Të themi se retenzioni është caktuar për 8 ditë, detyra punon çdo 6 orë me një backup të plotë të mërkurën. Ndërkohë, detyra nuk punon të dielën. Detyra fillon për herë të parë të hënën. Kur do të aplikohet retenzioni?
Përgjigje
Si zakonisht, është më mirë të vizatoni një tabelë. Do të lejohem ta thjeshtoj detyrën dhe nuk do të vizatoj të gjitha pikët, të krijuara çdo ditë, sepse numri i pikëve në ditë këtu nuk ka rëndësi. Ajo që na intereson është se të hënën e parë dhe çdo të mërkurë, pika e parë do të jetë një backup i plotë, ndërsa në ditët e tjera detyra do të krijojë thjesht 4 pika inkrementale.
E kuptojmë se retenzioni do të aplikohet duke fshirë backup-in e plotë të hënës dhe inkrementin e tij. Kur do të ndodhë kjo? Kur pjesa tjetër e zinxhirit do të përmbajë 8 ditë. Në këtë rast, nuk e kemi në konsideratë ditën aktuale, por të dielën, përkundrazi, e kemi në konsideratë. Prandaj, përgjigja është: të enjten e javës së dytë.
Arkivimi përmes metodës GFS për detyrat e zakonshme
Derisa në versionin v.10, metoda e ruajtjes Grandfather-Father-Son (GFS) ishte e disponueshme vetëm për detyrat e krijimit të kopjeve rezervë (Backup copy) dhe detyrat e kopjimit në kasetë. Tani, ajo është e disponueshme gjithashtu për backup-et e zakonshme.
Megjithëse kjo nuk i përket temës aktuale, nuk mund të mos përmend se funksionaliteti i ri nuk do të thotë braktisje të strategjisë 3-2-1. Prania e pikave arkivuese në depot kryesore nuk ka asnjë ndikim në besueshmërinë e saj. Supozohet se GFS do të përdoret së bashku me depo të shkallëzueshme (Scale-out), për të ngarkuar këto pika në S3 dhe depo të ngjashme. Nëse nuk i përdorni ato, më mirë të vazhdoni të ruani pikët fillestare dhe arkivike në depo të ndryshme.
Tani le të shqyrtojmë parimet e krijimit të pikave GFS. Në cilësimet e detyrës, në hapin Storage, është shfaqur një buton i veçantë që thërret menynë e mëposhtme:
Thelbi i GFS mund të reduktohet në disa pika (vini re, GFS në lloje të tjera detyrash funksionon ndryshe, por për këtë do të flasim më vonë):
- Detyra nuk krijon një kopje të plotë të veçantë për pikën GFS. Në vend të kësaj, do të përdoret një kopje e plotë më e përshtatshme nga ato që ekzistojnë. Prandaj, detyra duhet të punojë në një mod të inkrementimit me një kopje të plotë periodike, ose një kopje e plotë duhet të krijohet manualisht nga përdoruesi.
- Nëse është aktivizuar vetëm një periudhë (p.sh., javore), atëherë në fillim të periudhës GFS, detyra thjesht do të fillojë të presë një kopje të plotë dhe do ta shënojë të parën të përshtatshme si GFS.
Shembuj: Detyra është konfiguruar të ruajë GFS javore, duke përdorur kopjen të mërkurën. Detyra punon çdo ditë, por kopja e plotë është caktuar të premten. Në këtë rast, në mërkurë 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 (p.sh., javore dhe mujore), atëherë B&R do të aplikojë një metodë që lejon përdorimin e të njëjtës pikë si GFS për disa intervale (për të kursyer hapësirë). Flamujt do të caktohen njëpasnjëshëm, duke filluar nga ai më i vogli.
Shembuj: GFS javore është caktuar të mërkurën, ndërsa ajo mujore në javën e fundit të muajit. Detyra punon çdo ditë dhe krijon kopje të plota të hënave dhe të premteve.
Për thjeshtësi, le të fillojmë numërimin nga java e fundit e muajit. Në këtë javë do të krijohet një kopje e plotë të hënën, por ajo do të injorohet, sepse intervali GFS javore fillon të mërkurën. Ndërsa kopja e plotë e të premtes është krejtësisht e përshtatshme për pikën GFS. Kjo sistem na është tashmë njohur.
Tani le të shohim se çfarë do të ndodhë në javën e fundit të muajit. Intervali GFS mujor do të fillojë të hënën, por VBK i hënës nuk do të shënohet si GFS, sepse detyra përpiqet të shënojë një VBK si pikë GFS si mujore ashtu edhe javore. Në këtë rast, kërkimi fillon për gjetjen e javoreve, sepse ajo gjithashtu mund të bëhet mjeshtër.
Nëse aktivizohen vetëm intervalet javore dhe vjetore, ato do të veprojnë pavarësisht nga njëra-tjetra dhe mund të shënojnë dy VBK të veçantë si intervalet e përshtatshme GFS.
Detyrat për krijimin e kopjeve rezervë (Backup copy)
Një tjetër lloj detyrash, shpesh kërkon shpjegime mbi funksionimin. Së pari, le të shqyrtojmë metodën 'klasike' të punës, pa novacione v.10
Metoda e thjeshtë e mbajtjes
Në parazgjedhje, këto detyra funksionojnë në një mënyrë të pafundme inkrementale. Krijimi i pikave përcaktohet nga dy parametra – intervali i kopjimit dhe numri i dëshiruar i pikave të rikthimit (nuk ka ruajtje sipas ditëve këtu). Intervali i kopjimit punohet në skedën e parë Job gjatë krijimit të detyrës:
Numri i pikave përcaktohet pak më poshtë në skedën Target.
Detyra krijon 1 pikë të re për çdo interval (sa pikë janë krijuar për VM nga detyrat origjinale, nuk ka rëndësi). Në fund të intervalit, pika e re përfundohet dhe, nëse është e nevojshme, aplikohet ruajtja duke bashkuar VBK dhe inkrementin më të vjetër. Ky mekanizëm na është njohur tashmë.
Metoda e ruajtjes me përdorimin e GFS.
BCJ gjithashtu mund të ruajë pikë arkivore. Kjo konfigurohet në të njëjtën skedë Target, pak më poshtë konfigurimit të numrit të pikave të rikthimit:
Pikat GFS mund të krijohen në dy mënyra – sintetikisht, duke përdorur të dhënat në repositorin e dytë, ose duke imituar një backup të plotë dhe duke lexuar të gjitha të dhënat nga repositori primar (aktivehet me opsionin e shënuar me numër 3). Ruajtja në të dy rastet do të ndryshojë dukshëm, prandaj do t'i shqyrtojmë ato veçmas.
GFS sintetik.
Në këtë rast, pika GFS nuk krijohet saktësisht në ditën e paracaktuar. Në vend të kësaj, pika GFS do të krijohet kur VIB-ja e asaj dite, për të cilën ishte caktuar krijimi i pikës GFS, do të bashkohet me backup-in e plotë. Kjo ndonjëherë shkakton keqkuptime, për shkak se koha ecën, por pika GFS nuk është akoma krijuar. Vetëm një shaman i fuqishëm nga mbështetja teknike mund të parashikojë në cilën ditë do të shfaqet pika. Në të vërtetë, magia nuk është e nevojshme – mjafton të shikoni numrin e paracaktuar të pikave dhe intervalin e sinkronizimit (sa pika krijohen çdo ditë). Provoni ta llogarisni vetë duke përdorur këtë shembull: detyra është e vendosur të ruajë 7 pika, intervali i sinkronizimit – 12 orë (dmth, 2 pika në ditë). Aktualisht, në zinxhirin e pikave janë tashmë 7 pikë, 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ërgjigje
Këtu është më mirë të shpjegohet se si do të ndryshojë zinxhiri në dinamikë, ditë për ditë:
Pra të hënë, incrementi 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 ruajtja ndihmon në lëvizjen e pandërprerë të zinxhirit përpara. Përfundimisht, të enjten vjen koha për të aplikuar ruajtjen në atë increment. Kjo seancë do të marrë më shumë kohë se zakonisht – sepse detyra "do të nxjerrë" blloqet e nevojshme nga zinxhiri dhe do të krijojë një pikë të re të plotë. Që nga ky moment, në zinxhir do të ketë 8 pika – 7 në zinxhirin kryesor + GFS.
Krijimi i pikave GFS me opsionin “Lexo të gjithë pikën”
Më sipër thashë se BCJ punon në një modalitet të pafund-incremental. Tani do të shqyrtojmë përjashtimin e vetme nga kjo rregull. Kur aktivizohet opsioni “Lexo të gjithë pikën”, pika GFS do të krijohet pikërisht në ditën e planifikuar. Detyra vetë do të punojë në modalitet incremental me backup-e të plota periodike, të cilat i kemi shqyrtuar më parë. Ruajtja gjithashtu do të aplikohet duke fshirë pjesën më të vjetër të zinxhirit. Megjithatë, në këtë rast do të fshihen vetëm incrementet, ndërsa backup-i i plotë do të mbetet si pika GFS. Prandaj, në llogaritjen e ruajtjes, pika të shënuara me flamuj GFS nuk janë të përfshira.
Supozoni se detyra është vendosur për të mbajtur 7 pika dhe për të krijuar një pikë të plotë GFS në të hënë. Në këtë rast, çdo të hënë detyra me të vërtetë do të krijojë një backup të plotë dhe do ta shënojë atë si GFS. Ruajtja do të aplikohet, kur pas fshirjes së incrementëve nga pjesa më e vjetër, numri i incrementëve të mbetur nuk bie nën 7. Ja se si duket në skemë:
Kështu, në fund të javës së dytë, në zinxhir do të jenë gjithsej 14 pika. Gjatë javës së dytë, detyra krijoi 7 pika. Sikur të ishte një detyrë e thjeshtë, ruajtja do të ishte aplikruar tashmë. Por është BCJ me ruajtjen GFS, prandaj pikët GFS nuk i llogarisim, dhe kështu kemi vetëm 6. Kështu që ruajtjen nuk mund ta aplikojmë ende. Në javën e tretë krijojmë një tjetër backup të plotë me flamurin GFS. 15 pika, por këtë sërish nuk e llogarisim. Dhe, përfundimisht, të martën e javës së tretë krijojmë një increment. Tani, nëse fshijmë incrementet e zinxhirit nga java e parë, numri total i incrementëve do të përmbushë ruajtjen e vendosur.
Siç u tha më lart, në këtë metodë është shumë e rëndësishme që kopjet e plota të krijohen rregullisht. Të themi, nëse vendosim një ruajtje të qendrore për 7 ditë, por vetëm një pikë vjetore, nuk është e vështirë të imagjinojmë se inkrementet do të akumulojnë shumë, shumë më tepër se 7. Në këto raste është më mirë të përdorim metodën sintetike për krijimin e GFS.
Dhe përsëri “Hiq artikujt e fshirë”
Kjo opsion është gjithashtu e pranishme për BCJ:
Logjika e këtij opsioni këtu është e njëjtë me atë të detyrave të zakonshme të backup-it – nëse makina nuk trajtohet për një numër të caktuar ditësh, të dhënat e saj do të fshihen nga zinxhiri. Sidoqoftë, për BCJ, dobitë e këtij opsioni janë objektivisht më të larta, dhe ja pse.
Në modin e zakonshëm, BCJ funksionon në modin e papërfunduar-incremental, kështu që nëse në një moment makina hiqet nga detyra, ruajtja gradualisht do të fshijë të gjitha pikët e rikuperimit, derisa të mbetet vetëm një – në VBK. Tani imagjinoni se detyra është akoma e konfiguruar për të krijuar pikë sintetike GFS. Kur të vijë koha, detyra do të krijojë GFS për të gjitha makinat në zinxhir. Nëse për ndonjë makinë nuk ka pikë të reja – ah mirë, do të duhet të përdorim atë që është. Dhe kështu me radhë. Në fund mund të ndodhë kjo situatë:
Kujdesi me seksionin Files: kemi VBK-në kryesore dhe 2 pikë GFS javore. Tani shikoni seksionin e Pika të rikuperimit – në të vërtetë, në këto skedarë ndodhet e njëjta imazh e makinës. Natyrisht, nuk ka asnjë kuptim në këtë pikë GFS, ato vetëm zënë hapësirë.
Kjo situatë është e mundur vetëm me përdorimin e GFS sintetike. Për të evituar këtë, përdorni opsionin “Hiq artikujt e fshirë”. Por mos harroni ta vendosni për një numër të arsyeshëm ditësh. Mbështetje teknike ka parë raste kur opsioni është vendosur për më pak ditë se intervali i sinkronizimit – BCJ fillonte të çmendej dhe të fshinte pikët, pa pasur mundësinë t'i krijonte ato.
Gjithashtu, mbani parasysh se ky opsion nuk prek pikët GFS të krijuara 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 e shfaqur mos harroni të vini shenjën “Hiq kopjen e plotë GFS”):
Noviteti v.10 – kopja e menjëhershme (immediate copy)
Pas shqyrtimit të funksionalitetit "klasik", do të kalojmë te e reja. Ka një novitet, por shumë të rëndësishme. Ky është një mod i ri i funksionimit.
Nuk ka një koncept të tillë si «intervali i sinkronizimit», detyra do të vazhdojë të kontrollojë nëse janë shfaqur pika të reja dhe do t'i kopjojë ato të gjitha, pa marrë parasysh numrin e tyre. Por megjithatë, detyra mbetet inkrementale, domethënë edhe nëse detyra kryesore krijon VBK ose VRB, këto pika do të kopjohen si VIB. Në çdo rast, në këtë mod është pa surpriza – si ruajtja standarde ashtu edhe GFS funksionojnë sipas rregullave të përshkruara më sipër (pavarësisht se këtu është i disponueshëm vetëm GFS sintetik).
Disket po rrotullohen. Veçoritë e depozitave me rotacion disku (rotated drives)
Kërcënimi i vazhdueshëm nga viruset-kriptues ka bërë që të ketë një standard de-fakto për sigurinë për ekzistencën e një kopjeje të dhënash në një medium, në të cilin virusi nuk mund të arrijë. Një nga opsionet është përdorimi i depozitave me rotacion disku, ku disket përdoren me turne: ndërsa një disk është i lidhur dhe i aksesueshëm për shkrim, të tjerët 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 në butonin Advanced dhe të zgjidhni opsionin përkatës:
Pas kësaj, VBR do të pret që periodikisht zinxhiri ekzistues të zhduket nga depozita, gjë që do të thotë rotacion disku. Në varësi të llojit të depozitës dhe llojit të detyrës, B&R do të sillet ndryshe. Këtë mund ta paraqesim me një tabelë të tillë:
Le të shqyrtojmë çdo opsion.
Detyra e zakonshme dhe depozita Windows
Kështu, kemi një detyrë që ruan zinxhirët në diskun e parë. Me rotacionin, zinxhiri i krijuar në fakt zhduket, dhe detyra duhet ta përballojë këtë humbje. Ngushëllimi e gjen në krijimin e një kopjeje të plotë. Kështu, çdo rotacion do të thotë një kopje të plotë. Por çfarë ndodh me pikat në diskun e shkëputur? Ato ruhen dhe merren parasysh për llogaritjen e ruajtjes. Kështu, numri i caktuar i pikave në detyrë është sasia e pikave që nevojitet të mbahen në të gjitha disqet. Të japim një shembull:
Detyra punon në mënyrë inkrementale të pafund dhe është e konfigurueshme për të ruajtur 3 pika rikuperimi. Por ne gjithashtu kemi një disk të dytë dhe një herë në javë bëjmë rotacion (disket mund të jenë më shumë, kjo nuk e ndryshon thelbin).
Gjatë javës së parë, detyra do të krijojë pika në diskun e parë dhe do të bashkojë ato që janë të tepruara. Në këtë mënyrë, numri total i pikave do të jetë tre:
Më pas, ne lidhim diskun e dytë. Kur të fillojmë B&R, ai do të vërejë se disku ka ndryshuar. Lidhja në diskun e parë do të zhduket nga ndërfaqja, por informacioni lidhur me të do të mbetet në bazën e të dhënave. Tani detyra do të mbajë 3 pika në diskun e dytë. Situata totale do të jetë kështu:
Së fundi, ne lidhim përsëri diskun e parë. Para se të krijojmë një pikë të re, detyra do të kontrollojë se çfarë ndodh me ruajtjen. Dhe ruajtja, thënë shkurt, është caktuar për të mbajtur 3 pika. Ndërkohë, kemi 3 pika në diskin 2 (por ai është i shkëputur dhe ruhet në një vend të sigurt, ku B&R nuk mund të arrijë) dhe 3 pika në diskin 1 (ndërsa ky është i lidhur). Kështu, mund të fshihet me siguri 3 pika nga disku 1, pasi ato e kalojnë ruajtjen. Pas kësaj, detyra krijon përsëri një backup të plotë, dhe zinxhiri ynë fillon të duket kështu:
Nëse ruajtja është caktuar për të mbajtur ditë në vend që numrin e pikave, logjika nuk ndryshon. Për më tepër, ruajtja GFS nuk mbështetet fare kur përdoren depo me rotacion disku.
Detyra e zakonshme dhe depo Linux ruajtje rrjet
Ky variant është gjithashtu i mundshëm, por në përgjithësi është më pak i rekomanduar për shkak të kufizimeve që vendosen. Me rotacionin e diskut dhe zhdukjen e zinxhirit, detyra do të reagojë po ashtu – duke krijuar një backup të plotë. Kufizimi lidhet me mekanizmin e prerë të ruajtjes.
Këtu, gjatë rotacionit, i gjithë zinxhiri në diskun e shkëputur thjesht përjashtohet nga baza e të dhënave të B&R. Vini re – nga baza e të dhënave, skedarët aktualisht mbeten në disk. Ato 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ë depo.
Zgjidhja është në shtimin e DWORD ForceDeleteBackupFiles siç është e përshkruar 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ë depo (në varësi të vlerës) në çdo rotacion.
Megjithatë, kjo nuk është një ruajtje elegante, por pikërisht një pastrim i gjithë përmbajtjes. Fatkeqësisht, mbështetjes teknike i janë paraqitur raste kur si depo ishte caktuar thjesht katësi i rrënjës së diskut, ku përveç backup-ëve ndodheshin edhe të dhëna të tjera. Të gjitha këto u shkatërruan gjatë rotacionit.
Për më tepër, nga aktivizimi i ForceDeleteBackupFiles funksionon për të gjitha llojet e repo-ve, që do të thotë që madje repo-t në Windows do të ndalojnë së aplikuari retenshin dhe do të fillojnë të fshijnë përmbajtjen. Në fjalë të tjera, disku lokal në Windows është zgjidhja më e mirë për një sistem të tillë ruajtjeje për kopje rezervë.
Kopja rezervë dhe repo Windows
Me BCJ gjithçka bëhet edhe më interesante. Jo vetëm që këtu ka një retensh të plotë, por nuk kërkohet të bëni një kopje rezervë të plotë me çdo ndryshim disku! Funksionon kështu:
Së pari, B&R fillon të krijojë pika në diskun e parë. Le të themi se kemi vendosur retenshin në 3 pika. Detyra do të funksionojë në mënyrë të pafundme-incrementale dhe do të bashkojë gjithçka të tepërt (kujtoj, GFS retensh në këtë rast nuk mbështetet).
Pastaj lidhim diskun e dytë. Duke qenë se atje nuk ka një zinxhir, krijojmë një kopje rezervë të plotë, pas së cilës kemi një zinxhir të dytë me tre pika:
Së fundmi, vjen koha për të lidhur sërish diskun e parë. Dhe këtu fillon magia, sepse detyra nuk do të krijojë një kopje rezervë të plotë, por në vend të kësaj do të vazhdojë thjesht zinxhirin incrementale:
Pas kësaj në fakt në çdo disk do të ekzistojë një zinxhir i pavarur. Prandaj, retenshi këtu do të thotë jo numri i pikave në të gjithë diskët, por numri i pikave në secilin disk veçmas.
Kopja rezervë dhe repo Linux - ruajtjeje rrjeti
Dhe po, tërë eleganca humbet nëse repo-ja nuk është në diskun lokal Windows. Ky skenar funksionon 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ë kopje rezervë të plotë, dhe piketat ekzistuese do të harrohen. Për të mos mbetur pa hapësirë, duhet të përdorni DWORD ForceDeleteBackupFiles.
Përfundim
Pra, si rezultat i një teksti kaq të gjatë, kemi shqyrtuar dy lloje detyrash. Sigurisht, ka shumë më shumë detyra, por nuk do të mund ta shqyrtojmë të gjitha në formatin e një artikulli. Nëse pas leximit keni ndonjë pyetje, mos hezitoni të shkruani në koment, do të kem kënaqësinë të përgjigjem personalisht.
Burimi: habr.com
