Tere tulemast meie blogi lugejad! Osaliselt oleme juba tuttavad – minu ingliskeelsed postitused on siin ilmunud mu armsa kolleegi tõlkes. . Seekord otsustasin rääkida otse venekeelsele publikule.
Oma debüütpostituseks tahtsin leida teema, mis huvitaks võimalikult suurt auditooriumit ja vajaks põhjalikku käsitlemist. Daniel Defoe väitis, et igaüht ootavad surm ja maksud. Minu poolt võin öelda, et iga tehnilise toe inseneri ees on küsimused taastumispunktide säilitamise poliitikate kohta (või lihtsamalt – säilitamine). Kuidas säilitamine töötab, hakkasin ma seletama 4 aastat tagasi, olles algtase insener, ja jätkan seda ka praegu, olles Hispaania- ja Itaalia keele meeskonna tiimijuht. Olen kindel, et ka minu kolleegid teise ja isegi kolmanda taseme toest vastavad regulaarselt samadele küsimustele.
Selles valguses tahtsin kirjutada lõpliku, võimalikult üksikasjaliku postituse, mille poole venekeelsed kasutajad saaksid pidevalt tagasi pöörduda kui abivahendi. Aeg on sobiv – hiljuti välja antud juubeli kümnes versioon on lisanud uusi võimalusi põhifunktsionaalsusele, mis pole aastaid muutunud. Minu postitus on suunatud eelkõige sellele versioonile — kuigi enamik kirjutatust on õige ka varasemate versioonide kohta, siis osa kirjeldatud funktsionaalsust te seal lihtsalt ei leia. Lõpuks, kui vaadata veidi tulevikku, siis ütlen, et järgmises versioonis oodatakse teatud muudatusi, kuid sellest räägime, kui aeg on käes. Nii et alustame.
Varundamise ülesanded (Backup job)
Alustame sellest osast, mis ei ole muutunud versioonis 10. Säilitamise poliitika määratakse mitme parameetri kaudu. Avame uue ülesande loomise akna ja liigume Storage vahekaardile. Siin näeme parameetrit, mis määrab soovitud taastumispunktide arvu:
Kuid see on vaid osa võrrandist. Tõeline punktide arv määratakse ka ülesande jaoks seadistatud varundusrežiimi järgi. Selle parameetri valimiseks peate klikkima Advanced nupule samal vahekaardil. See avab uue akna, kus on palju valikuid. Numbrime need ja vaatleme järjestikku:
Kui lubada ainult 1. valikut, töötab ülesanne „lõputus inkremendilises“ režiimis (forever forward incremental). Siin ei tekki mingeid raskusi – ülesanne salvestab määratud arvu taastamispunkte täis varundusest (faili laiendiga VBK) kuni viimase inkremendini (faili laiendiga VIB). Kui punktide arv ületab määratud väärtuse, ühendatakse kõige vanem inkremendiga täis varundus. Teisisõnu, kui ülesanne on seadistatud hoidma 3 punkti, siis kohe pärast järgmist seanssi on repos 4 punkti, pärast mida ühendatakse täis varundus kõige vanema inkremendiga ja punktide koguarv naaseb 3-le.
Samuti on „tagasi-inkremeedilise“ (reverse incremental) režiimi jaoks (valik 2) säilitamine äärmiselt lihtne. Kuna sellisel juhul on kõige uueim punkt täis varundus, millele järgneks nii öelda rullimistike ahel (failid laiendiga VRB), piisab, kui lihtsalt kustutada kõige vanem rullimistike. Olukord on sama: kohe pärast seanssi ületab punktide arv määratud väärtuse 1 võrra, pärast mida naaseb see soovitud väärtuse juurde.
Pange tähele, et tagasi-inkremendilise režiimi puhul on võimalik ka perioodilise täis varunduse lubamine (valik 4), kuid see ei muuda sisu. Jah, ahelas ilmuvad täis taastamispunktid, kuid me pääseme ikkagi lihtsalt kõige vanematest punktidest ükshaaval lahti.
Lõpuks jõuame huvitava osa juurde. Kui aktiveerida inkremendiline varundus, kuid lisaks lubada valikud 3 või 4 (või võimaluse korral mõlemad samal ajal), hakkab ülesanne looma perioodilisi täis varundusi „aktiivsel“ või sünteetilisel meetodil. Täis varunduse loomise meetodil pole tähtsust – see sisaldab samu andmeid ja inkremendiline ahel jaguneb „alajaotusteks“. Sellist meetodit nimetatakse forward incremental ja just see tekitab meie klientides märkimisväärse osa küsimustest.
Retention here is applied by removing the oldest part of the chain (from the full backup to the increment). In this case, we will not delete only the empty backup or just part of the increments. The entire "subchain" is removed completely at once. The meaning of the setting for the number of points also changes – while in other methods this is the maximum allowable number after which retention should be applied, here this setting defines the minimum number. In other words, after the removal of the oldest "subchain," the number of points in the remaining part must not fall below this minimum.
I will try to illustrate this concept graphically. Let's assume that retention is set to 3 points, and the job runs every day with a full backup on Monday. Retention will be applied when the total number of points reaches 10:
Why 10 when we've set it to 3? A full backup was created on Monday. From Tuesday to Sunday, the job created increments. Finally, the next Monday a full backup is created again, and only after 2 increments are made can the entire old part of the chain be deleted, because the remaining number of points will not fall below the set 3.
If the idea is clear, I suggest you try to calculate retention on your own. Let's take the following conditions: the job is run for the first time on a Thursday (a full backup will be made, of course). The job is set to create full backups on Wednesdays and Sundays and to keep 8 restore points. When will retention be applied for the first time?
To answer this question, I recommend you take a piece of paper, divide it by days of the week, and write down which point is created each day. The answer will become obvious.
Vastus
Explanation: to answer, simply ask yourself "when will retention be applied?" The answer is – when we can remove the first 3 points (VBK, VIB, VIB) and the remaining chain does not fall below the required 8 points. It becomes clear that we can do this when we have a total of 11 points, i.e., on the Sunday of the second week.
Some readers may argue: "Why all this if there is ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Lõpuks ei ole me arutanud võimalust „Transformeerida varasemaid varukoopiaahelaid tagasisuunamiseks“ (märgitud numbriga 5). See võimalus segadusse ajab mõnikord kliente, kes aktiveerivad selle „automaatne“, soovides lihtsalt lihtsalt sünteetilist varukoopiat. Sellegipoolest aktiveerib see võimalus täiesti erilise varukoopia režiimi. Ilma üksikasjadesse laskumata, ütlen kohe, et toote arengu praegusel etapil on „Transformeerida varasemaid varukoopiaahelaid tagasisuunamiseks“ - vananenud valik ja ma ei suuda välja mõelda ühtegi stsenaariumi, kus seda tuleks kasutada. Selle väärtus on nii kaheldav, et mõnda aega saatis Anton Gostev otsefoorumisse üleskutse saata talle näiteid selle kasulikust kasutamisest (kui teil on, kirjutage kommentaaridesse, see huvitab mind väga). Kui selliseid näiteid ei leita (ma arvan, et nii see läheb), siis eemaldatakse valik järgmistest versioonidest.
Ülesanne loob inkremendi (VIB) kuni päevani, mil on määratud sünteetiline täis varukoopia. Sellisel päeval luuakse tõepoolest VBK, kuid kõik punktid enne seda VBK-d muudetakse tagasisuundumisteks (VRB). Pärast seda jätkab ülesanne inkremendi loomist täis varukoopia juurde kuni järgmise sünteetilise varukoopiani. Tulemuseks on ahelas segu VBK, VBR ja VIB failidest. Retensioon kehtib väga lihtsalt – kustutades viimase VBR:
Probleemid
Lisaks sellele, kuidas see toimib, on enamus probleemidest, mis tekivad inkremenrežiimi kasutamisel, tavaliselt seotud täis varukoopiaga. Regulaarne täis varukoopia on selles režiimis vajalik, vastasel juhul hakkab hoidla koguma punkte, kuni see täitub.
Näiteks võib täis varukoopia luua liiga harva. Oletame, et ülesanne on seatud hoidma 10 punkti, kuid täis varukoopia luuakse kord kuus. On selge, et tegelik punktide arv on siin oluliselt suurem kui seatud. Või on ülesanne üldiselt seatud töötama lõputus inkremenrežiimis ja hoidma 50 punkti. Siis loodab keegi kogemata luua täis varukoopia. Kõik, nüüd ootab ülesanne, kuni täispunkt on kogunud 49 inkremenit, pärast mida rakendatakse retensioon ja naasedakse lõpptäisvarukoopia režiimi.
Teistes olukordades on täielik varukoopia seadistatud regulaarselt, kuid mingil põhjusel seda ei tehta. Räägin siin kõige levinumast põhjendusest. Mõned kliendid eelistavad kasutada "run after" ajastamisvalikut ja seadistada ülesandeid töötama ahelana. Võtame näiteks: on 3 ülesannet, mis käivad igapäevaselt ja teevad täieliku varukoopia pühapäeval. Esimene ülesanne käivitatakse kell 22.30, ülejäänud käivitatakse ahelana. Inkrementaalne varukoopia kestab 10 minutit, seega kell 23.00 lõpetavad kõik ülesanded oma töö. Kuid täielik varukoopia kestab tunni, seega toimub pühapäeval järgmine: esimene ülesanne töötab kell 22.30 kuni 23.30. Järgmine ülesanne kell 23.30 kuni 00.30. Ja kolmas ülesanne käivitatakse juba esmaspäeval. Täielik varukoopia on seadistatud pühapäeval, seega sellisel juhul seda lihtsalt ei toimu. Ülesanne ootab täielikku varukoopiat, et rakendada säilitusaega. Seega olge ettevaatlikud "run after" valiku kasutamisel või ärge kasutage seda üldse – seadistage lihtsalt ülesanded töötama ühel ajal ja laske ressursside planeerijal oma tööd teha.
Raske valik "Eemalda kustutatud objektid"
Seadistustes Storage – Advanced – Maintenance navigeerides võib leida valiku "eemalda kustutatud objektide andmed pärast", mis arvutatakse päevades.
Mõned kliendid eeldavad, et see ongi säilitusaeg. Tegelikult on see täiesti eraldi valik, mille vale arusaamine võib viia ootamatute tagajärgedeni. Kuid kõigepealt tuleb selgitada, kuidas B&R reageerib olukordadele, kui seansi jooksul varundatakse edukalt vaid mõned masinad.
Kujutame ette sellist stsenaariumi: lõputu inkrementaalne ülesanne, seadistatud hoidma 6 punkti. Ülesandes on 2 masinat, üks varundatakse alati edukalt, teine annab mõnikord vigu. Lõpuks 7. punkti juures on tekkinud selline olukord:
Aeg rakendada säilitusaega, kuid ühel masinal on 7 punkti, teisel ainult 4. Kas säilitusaeg rakendub? Vastus – jah, rakendub. Kui vähemalt üks objekt on varundatud, loeb B&R, et punkt on loodud.
Sarnane olukord võib tekkida, kui mõni masin polnud lihtsalt teatud sessiooni ajal ülesande täitmiseks sisse lülitatud. See juhtub näiteks siis, kui masinad on ülesandele lisatud mitte individuaalselt, vaid konteinerite (kaustade, ladustamise) osana ja mõni masin rändab ajutiselt teise konteinerisse. Sellisel juhul loetakse ülesanne edukaks, kuid statistikast leiate sõnumi, mis kutsub tähelepanu juhtima, et selline masin ei ole enam ülesande poolt töödeldud.
Mis juhtub, kui sellele tähelepanu ei pöörata? Lõpmatu inkrementaalse või tagurpidi inkrementaalse režiimi korral vähenevad probleemse masina taastamispunktid iga sessiooniga, kuni saavutatakse 1, mis on salvestatud VBK-sse. Teisisõnu, isegi kui masinat pikka aega ei varundata, jääb siiski üks taastamispunkt. Kui on sisse lülitatud regulaarsed täis varundused, siis on asi teistsugune. Kui ignoreerida B&R signaale, võib viimane punkt koos vanema ahelaga lõpuks kustutada.
Nende detailide mõistmisega võime lõpuks vaadata valikut "Kustuta kustutatud elementide andmed pärast". See eemaldab kõik punktid konkreetse masina jaoks, kui see masin ei varundata X päeva jooksul. Pange tähele, et see seadet ei reageeri vigadele (proovisime - ei õnnestunud). Masina varundamiseks ei tohiks isegi katset olla. Tundub, et valik on kasulik ja seda peaks alati sisse lülitatud hoidma. Kui administraator eemaldab masina ülesandest, siis on loogiline mõne aja möödudes eemaldada kasutud andmed ja ahel. Siiski nõuab see seadistus distsipliini ja tähelepanelikkust.
Tooksin praktikat näiteks: ülesandele lisati mitu konteinerit, mille koostis oli üsna dünaamiline. Puuduliku RAM-i tõttu koges B&R server probleeme, mis jäävad märkamatuks. Ülesanne käivitus ja üritas teha varukoopiaid masinatest, välja arvatud ühest, mis sel ajal konteineris ei olnud. Kuna paljud masinad andsid veateateid, peaks B&R vaikimisi tegema 3 lisakatsed „probleemsete“ masinate varukoopia tegemiseks. Pidevate RAM-i probleemide tõttu venisid need katsed mitmeks päevaks. Puuduva virtuaalmasina varukoopia tegemise korduskatset ei olnud (puuduva virtuaalmasina puudumine ei ole viga). Lõpuks, ühe korduskatse ajal täideti tingimus “Kustuta kustutatud elemendid” ja kõik masina punktid kustutati.
Selle kohta võin öelda järgmist: kui teil on seadistatud ülesannete tulemuste teavitused, ja veel parem — kasutate integratsiooni Veeam ONE-ga, siis tõenäoliselt ei juhtu teiega sellist asja. Kui aga vaatate B&R serverit kord nädalas, et kontrollida, kas kõik töötab, siis peaksite loobuma valikutest, mis võivad potentsiaalselt viia varukoopiate kustutamiseni.
Mis on uues v.10
See, millest me varem rääkisime, eksisteeris B&R-is juba palju versioone. Nüüd, kui oleme need tööpõhimõtted selgeks saanud, vaatame, mis on uues juubeli „kümnes“ versioonis lisandunud.
Igapäevane säilitamine
Ülal oleme arutanud „klassikalist“ salvestuspoliitikat, mis põhineb punktide arvul. Alternatiivne lähenemine on seadistada samas menüüs „päevad“ asemel „taastepunktid“.
Idee on selgesti pealkirjast – säilitamine hoiab määratud arvu päevi, samas ei oma iga päeva punktide arv mingit tähtsust. Siiski peab meeles pidama järgmist:
- Praegust päeva ei arvestata säilitamise arvutamisel
- Päevad, mil ülesanne ei töötanud üldse, loetakse samuti. Seda tuleks silmas pidada, et mitte kogemata kaotada punktid nende ülesannete jaoks, mis töötavad ebaregulaarsetel aegadel.
- Taastepunkt arvestatakse alates päevast, mil selle loomine algas (st kui ülesanne hakkas tööle esmaspäeval ja lõpetas teisipäeval, siis arvestatakse see punkt esmaspäevast)
Muudel juhtudel määravad ülesannete rakendamise põhimõtted valitud varundusmeetodi. Proovime veel üht arvutuse ülesannet, kasutades sama inkrementaalset meetodit. Oletame, et säilitamisperiood on 8 päeva, ülesanne töötab iga 6 tunni järel, tehes kolmapäeval täisvarukoopia. Samas ei toimu ülesanne pühapäeval. Esmakordselt käivitub see esmaspäeval. Millal rakendatakse säilitamine?
Vastus
Kuidas tavaliselt, on parim joonistada tabel. Lubage mul lihtsustada ülesannet ja mitte joonistada kõiki punkte, mis on loodud igal päeval, kuna päeva punktide arv ei ole siin oluline. Meile on oluline ainult see, et esmaspäeval ja kolmapäeviti on esimene punkt täisvarukoopia, ülejäänud päevadel loob ülesanne lihtsalt 4 inkrementaalset punkti.
Mõistame, et säilitamine rakendatakse esmaspäevase täisvarukoopia ja selle inkrementaalse koopia kustutamisega. Millal see juhtub? Kui ülejäänud ahel sisaldab 8 päeva. Siin ei arvestata praegust päeva, kuid pühapäeva arvestame. Seega on vastus – teisipäeval teisel nädalal.
GFS meetodiga arhiveerimine tavalistele ülesannetele
Enne versiooni 10 oli Grandfather-Father-Son (GFS) salvestamismeetod saadaval ainult arhiveerimise ülesannete (Backup copy) ja magnetlintide koopiate loomise ülesannete jaoks. Nüüd on see saadaval ka tavalise varunduse jaoks.
Kuigi see ei ole praeguse teema jaoks asjakohane, ei saa ma vaikida, et uus funktsionaalsus ei tähenda 3-2-1 strateegiast taganemist. Arhiivipunktide kohalolek põhirepos ei mõjuta selle usaldusväärsust. Eeldatakse, et GFS-i kasutatakse koos laiendatava (Scale-out) repoga, et edastada neid punkte S3-tüüpi ja sarnastesse salvestustesse. Kui te neid ei kasuta, on parem jätkata esmase ja arhiveeritud punktide hoidmist erinevates repodes.
Nüüd vaatame GFS-punktide loomise põhimõtteid. Ülesande seadetes, sammu Storage juures, on ilmunud eriline nupp, mis avab järgmise menüü:
GFS-i olemus võib kokku võtta mitme punktiga (pange tähele, et GFS töötab muude ülesannete puhul teisiti, kuid sellest räägime veidi hiljem):
- Ülesanne ei loo eraldi täisvarukoopiat GFS punktile. Selle asemel kasutatakse kõige sobivamat olemasolevat täisvarukoopiat. Seetõttu peaks ülesanne töötama inkrementaalses režiimis koos perioodilise täisvarukoopiate tegemisega või peab täisvarukoopia looma kasutaja käsitsi.
- Kui on sisse lülitatud ainult üks periood (näiteks nädalane), siis GFS perioodi alguses hakkab ülesanne lihtsalt ootama täisvarukoopiat ja märgistab esimese sobiva kui GFS.
Näide: ülesanne on seadistatud hoidma nädalast GFS, kasutades varukoopiat kolmapäeval. Ülesanne töötab iga päev, kuid täisvarukoopia on määratud reedel. Sel juhul algab kolmapäeval GFS periood ja ülesanne hakkab ootama sobivat punkti. See ilmub reedel ja märgitakse GFS lipuga.
- Kui on sisse lülitatud mitu perioodi korraga (näiteks nädalane ja kuine), siis B&R rakendab meetodit, mis võimaldab kasutada ühte ja sama punkti kui GFS mitme intervalli jaoks (ruumi kokkuhoidmiseks). Lipud määratakse järjekorras, alustades madalama tähtsusega.
Näide: nädalane GFS on seadistatud kolmapäevaks, kuid kuine – kuu viimasele nädalale. Ülesanne töötab iga päev ja loob täisvarukoopiad esmaspäeviti ja reedeti.
Lihtsuse huvides alustame arvestust kuu eelviimasest nädalast. Sel nädalal tehakse esmaspäeval täisvarukoopia, kuid seda jäetakse tähelepanuta, kuna nädalane GFS intervall algab kolmapäeval. Kuid reedel tehtud täisvarukoopia sobib täielikult GFS punktiks. See süsteem on meile juba tuttav.
Nüüd vaatame, mis juhtub kuu viimases nädalas. Kuine GFS intervall algab esmaspäeval, kuid esmaspäeva VBK ei märgita kui GFS, kuna ülesanne püüab märkida ühte VBK-d nii kuu- kui ka nädalase GFS punktina. Otsing algab siiski just nädalasest, kuna see suudab olla ka kuine.
Kuid kui lülitada sisse vaid nädalased ja aastased intervallid, siis need toimivad sõltumatult üksteisest ja võivad märkida 2 eraldi VBK-d kui vastavad GFS intervallideks.
Varukoopia loomise ülesanded (Backup copy)
Veel üks ülesannete tüüp, mis sageli vajab selgitusi, kuidas see töötab. Esiteks vaatame «klassikalist» töömeetodit, ilma uuendusteta v.10
Lihtne retentsioonimeetod
Seda ülesandeid käideldakse vaikeväärtuste kohaselt lõpmatul inkrementaalsel režiimil. Punktide loomine määratakse kahe parameetriga – kopeerimistasemega ja soovitud taastamispunktide arvuga (päevade kaupa hoidmine siin puudub). Koopiamäära seadmine toimub töö loomise esimesel vahekaardil.
Punktide arv määratakse natuke edasi vahekaardil Sihtkoht.
Ülesanne loob 1 uue punkti iga kopeerimisintervalli jooksul (kui palju punkte on algse ülesande abil masinale loodud, ei ole tähtis). Intervalli lõpus finaliseeritakse uus punkt ja kui see on vajalik, rakendatakse hoidmine VBK ja kõige vanema inkrementi ühendamise kaudu. See mehhanism on meile juba tuttav.
GFS hoidmise meetod.
BCJ suudab samuti arhiivipunkte hoida. Seda seadistatakse samal vahekaardil Sihtkoht, natuke allapoole taastamispunktide arvu seadistamise.
GFS punkte saab luua kahel viisil – sünteetiliselt, kasutades andmeid teisel hoidlas, või jäljendades täielikku varukoopiat ja lugedes kõik andmed esmase hoidla seest (aktiveeritakse valikuga, mis on märgitud numbriga 3). Hoidmine on mõlemal juhul väga erinev, seega vaatame neid eraldi.
Sünteetiline GFS.
Selles olukorras ei loodud GFS punkti täpselt määratud päeval. Selle asemel luuakse GFS punkt siis, kui selle päeva VIB, millel oli ette nähtud GFS punkti loomine, liidetakse täieliku varukoopiat. See tekitab mõnikord segadust, sest aeg möödub, kuid GFS punkti ikka veel ei ole. Ainult toetuse võimekas šamaan suudab ennustada, millal punkt lõpuks ilmub. Tegelikult pole siin mingit maagijat – piisab vaadata määratud punktide arvu ja sünkroonimisintervalli (kui palju punkte luuakse iga päev). Proovige ise arvutada sellise näite põhjal: ülesanne on määratud hoidma 7 punkti, sünkroonimisintervall on 12 tundi (st 2 punkti päevas). Praegu on ahelas juba 7 punkti, täna on esmaspäev ja selleks päevaks on GFS punkti loomine ette nähtud. Millal see punkti lõpuks luuakse?
Vastus
Siin tasub paremini kirjeldada, kuidas ahel dünaamiliselt päevade kaupa muutub:
Nii, esmaspäeval märgistatakse viimane inkrementaalse ahela punkt kui GFS, kuid mingeid teisi märgatavaid muudatusi ei toimu. Igal päeval loob ülesanne 2 uut punkti ja säilitamine liigub ahelas vankumatult edasi. Lõpuks, neljapäeval on aeg rakendada säilitamine sellele samale inkrementile. See seanss võtab rohkem aega kui tavaliselt – sest ülesanne 'tõmbab' vajalikud plokid ahelast ja loob uue täispunkti. Sellest hetkest alates on ahelas juba 8 punkti – 7 põhiahelas + GFS.
GFS punktide loomine valikuga “Loe kogu punkt”
Ülalpool mainisin, et BCJ töötab lõputu inkrementaalse režiimiga. Nüüd vaatame seda reeglit ühte erandit. Kui valitakse “Loe kogu punkt” valik, siis GFS punkt luuakse täpselt kavandatud päeval. Isegi ülesanne töötab inkrementaalses režiimis, koos perioodiliste täistegevuste varukoopiate loomisega, millest rääkisime eespool. Säilitamine rakendatakse ka vanima osa ahela kustutamisega. Siiski, antud juhul kustutatakse ainult inkrementid, samas kui täistegevuse varukoopia jääb GFS punktina. Vastavalt sellele ei arvestata säilitamise arvutamisel punkte, mis on märgitud GFS lippudega.
Oletame, et ülesanne on seadistatud hoidma 7 punkti ja looma iganädalase GFS punkti esmaspäeval. Sel juhul igal esmaspäeval loob ülesanne tõepoolest täistegevuse varukoopia ja märgistab selle GFS-iga. Säilitamine rakendatakse, kui pärast inkrementide kustutamist vanima osa seest jääb alles jäänud inkrementide arv alla 7. Nii näeb see skeemi järgi välja:
Nii, teise nädala lõpuks on ahelas kokku 14 punkti. Teise nädala jooksul lõi ülesanne 7 punkti. Kui see oleks lihtne ülesanne, oleks säilitamine juba rakendatud. Kuid see on BCJ GFS säilitamisega, seega me ei arvesta GFS punkte ja seega on neid vaid 6. See tähendab, et säilitamist me veel rakendada ei saa. Kolmandal nädalal loome veel ühe täistegevuse varukoopia GFS lipuga. 15 punkti, kuid me ei arvestanud seda jälle. Ja lõpuks, kolmanda nädala teisipäeval loome inkrementi. Nüüd, kui me kustutame esimese nädala ahela inkrementid, rahuldab inkrementide kogus seadistatud säilitamist.
Nagu eespool mainitud, on selle meetodi puhul äärmiselt oluline, et täiskoopiad loodaks regulaarselt. Oletame, et kui põhiretenatsioon on seitsme päeva peal, kuid ainult üks aastane punkt, siis ei ole raske ette kujutada, et inkrementide arv koguneb oluliselt rohkem kui seitse. Sellistes olukordades on parem kasutada sünteetilist GFS loomise meetodit.
Ja jälle “Eemalda kustutatud esemed”
See valik on olemas ka BCJ puhul:
Selle valiku loogika on siin sama nagu tavalistes varukoopiaülesannetes – kui masinat ei töödeldud märgitud arvu päevi, siis kustutatakse selle andmed ahelast. Kuid BCJ puhul on selle valiku kasulikkus objektiivselt kõrgem, ja siin on miks.
Tavapärases režiimis töötab BCJ lõputult inkrementaalselt, seega kui mingil hetkel masin ülesandest eemaldatakse, siis retenatsioon kustutab järk-järgult kõik taastamispunktid, kuni jääb alles üksainus – VBK. Kujutame nüüd ette, et ülesanne on endiselt seadistatud looma sünteetilisi GFS punkte. Kui kätte jõuab aeg, peab ülesanne looma GFS kõigile ahela masinatele. Kui mõnel masinal pole üldse uusi punkte – noh, siis tuleb kasutada olemasolevat. Ja nii iga kord. Lõpuks võib tekkida selline olukord:
Pange tähele sektsiooni Files: meil on peamine VBK ja 2 nädalast GFS punkti. Ja nüüd sektsiooni Restore points – tegelikult nendes failides on üks ja sama masina pilt. Loomulikult pole sellistes GFS punktides mingit mõtet, need võtavad vaid ruumi.
Selline olukord on võimalik ainult sünteetilise GFS kasutamisel. Et seda vältida, kasutage valikut “Eemalda kustutatud esemed”. Ainult ärge unustage seadistada see adekvaatse päevade arvu peale. Toetustelt on nähtud juhtumeid, kui valik on seadistatud väiksemaks päevade arvuks kui sünkroonimisintervall – BCJ on hakanud rahutuks ja kustutama punkte, enne kui need on loodud.
Arvestage ka, et see valik ei puutu juba loodud GFS punkte. Kui soovite arhiive puhastada, tuleb see teha käsitsi – klikates hiire parema nupuga masina peale ja valides “Kustuta kettalt” (avatavas aknas ärge unustage märkida kasti “Eemalda GFS täiskoopiad”):
Uuendus v.10 – kohene koopia (immediate copy)
Pärast „klassikalise“ funktsionaalsuse selgitamist liigume uuele. Uuendus on üks, kuid väga oluline. See on uus töörežiim.
Siin ei eksisteeri mõistet „sünkroniseerimise intervall“, ülesanne jälgib pidevalt, kas uusi punkte on ilmunud, ja kopeerib neid kõiki, olenemata nende arvust. Kuid ülesanne jääb inkrementaalseks, st isegi kui põhihüvitis loob VBK või VRB, kopeeritakse need punktid VIB-ina. Muus osas ei ole selle režiimi puhul üllatusi – nii standardne kui ka GFS-i säilitamine toimib eespool kirjeldatud reeglite järgi (tõsi, siin on saadaval ainult sünteetiline GFS).
Kettad tiirlevad. Kettajõudude rotatsiooni (rotated drives) eripära
Püsiv krüpteerimisviiruste oht on de facto turvastandardiks andmete koopia olemasolu meediasse, kuhu viirus ei pääse. Üks võimalusi on kasutada kettajõude rotatsiooni, kus kettad kasutatakse vaheldumisi: samal ajal kui üks ketas on ühendatud ja kirjutamiseks saadaval, hoitakse teised ohutus kohas.
Kuidas õpetada B&R töötama selliste hoidlate puhul, tuleb hoidla seadetes, sammus Repository, klõpsata nuppu Advanced ja valida vastav valik:
Pärast seda ootab VBR, et olemasolev ahel kaob hoidlast perioodiliselt, mis tähendab ketta rotatsiooni. Olenevalt hoidla tüübist ja ülesande liigist käitub B&R erinevalt. Seda võib kujutada järgnevate tabelitega:
Vaadake iga varianti.
Tavapärane ülesanne ja Windows hoidla
Nii et meil on ülesanne, mis salvestab ahelad esimesele kettale. Kui toimub rotatsioon, kaob loodud ahel tegelikult ning ülesanne peab selle kaotuse kuidagi üle elama. Loht leebub täieliku varukoopia loomisega. Seega tähendab iga rotatsioon täis varukoopiat. Kuid mis juhtub punktidega väljalülitatud kettal? Need salvestatakse ja arvestatakse säilitamise arvestuses. Seega on ülesandes määratud punktide arv see, kui palju punkte tuleb hoida kõikidel ketastel. Toome näite:
Ülesanne töötab lõputult inkrementaalses režiimis ja on seadistatud hoidma 3 taastamispunkti. Kuid meil on ka teine ketas, ja me rotatsiooni kord nädalas (kettad võivad olla rohkem, kuid see ei muuda sisu).
Esmise nädala jooksul ülesanne loob punkte esimesel kettal ja liidab üleliigsed. Seega on punktide koguarv kolm:
Seejärel ühendame teise ketta. B&R käivitamisel märkab see, et ketas on vahetunud. Esimese ketta ahel kaob liidese pöördest, kuid teave selle kohta jääb andmebaasi. Nüüd peab ülesanne hoidma teisel kettal 3 punkti. Üldine olukord on järgmine:
Lõfinally ühendame esimese ketta uuesti. Enne uue punkti loomist kontrollib ülesanne, kuidas on asjad rändemäluga. Ja rändemälu, tuletan meelde, on seadistatud hoidma 3 punkti. Samuti on meil 3 punkti kettal 2 (kuid see on välja lülitatud ja hoitud usaldusväärses kohas, kuhu B&R ei pääse) ja 3 punkti kettal 1 (see on ühendatud). Seetõttu võib julgelt kustutada 3 punkti kettalt 1, kuna need ületavad rändemälu. Pärast seda loob ülesanne uuesti täisvarunduse ja meie ahel hakkab välja nägema nii:
Kui rändemälu on seadistatud hoidma päevi, mitte punktide arvu, siis loogika ei muutu. Lisaks ei toetata GFS rändemälu üldse kettade ringlusega kasutamisel.
Tavaline ülesanne ja Linuxi hoidla, mis on võrgu salvestus
Selline variant on samuti võimalik, kuid seda ei soovitata põhjusel, et kehtivad piirangud. Ketta ringlusele ja ahela kadumisele vastab ülesanne sama – täisvarunduse loomisega. Piirang on seotud kärbitud rändemälu mehhanismiga.
Siin, ketta ringluse korral, kustutatakse kogu ahel lihtsalt B&R andmebaasist. Pange tähele – andmebaasist, failid jäävad kettale. Neid saab importida ja taastamiseks kasutada, kuid ei ole raske aimata, et varem või hiljem täidavad sellised unustatud ahelad kogu hoidla.
Lahendus on DWORD ForceDeleteBackupFiles lisamine, kuidas see on sellel leheküljel näidatud: . Pärast seda hakkab ülesanne igas ringluses lihtsalt kustutama kogu ülesande kausta sisu või hoidla kausta sisu (oleneb väärtusest).
Kahjuks ei ole see elegantsed rändemälu, vaid kõigi sisu puhastamine. Kahjuks on tehnilise toe poole pöördunud juhtudest, kus hoidla all oli lihtsalt kettadraivi juurkataloog ja kus lisaks varundustele olid ka teised andmed. Kõik need hävitati ringluse ajal.
Lisaks, kui ForceDeleteBackupFiles on sisse lülitatud, töötab see kõigi varundusreposiitide tüüpide jaoks, mis tähendab, et isegi Windowsi reposiit lõpetab säilituse rakendamise ja hakkab sisu kustutama. Teisisõnu, Windowsi kohalik ketas on parim valik selleks varundussüsteemiks.
Backup copy ja Windowsi reposiit
BCJ-ga muutub kõik veelgi huvitavamaks. Siin on mitte ainult täielik säilitamine, vaid ka täiendavat täielikku varundust ei pea tegema iga ketta vahetuse korral! See töötab järgmiselt:
Esmalt hakkab B&R looma punkte esimesel kettal. Oletame, et oleme seadnud säilituse kolme punkti peale. Ülesanne töötab lõputult inkreelementaalses režiimis ja ühendab kõik üleliigse (me tuletame meelde, et GFS säilitamine ei ole antud juhul toetatud).
Seejärel ühendame teise ketta. Kuna sellel ei ole veel ahelat, loome täieliku varunduse, pärast mida tekib meil teine ahel, kus on kolm punkti:
Lõpuks on aeg jälle esimest ketast ühendada. Ja siinkohal algab maagia, kuna ülesanne ei loo täielikku varundust, vaid lihtsalt jätkab inkreelementaalahelat:
Pärast seda eksisteerib tegelikult igal kettal oma sõltumatu ahel. Seega tähendab säilitamine siin mitte punktide arvu kõigil ketastel, vaid punktide arvu iga ketta kohta eraldi.
Backup copy ja Linuxi reposiit võrgu salvestamisse
Ja taas, kogu elegants kaob, kui reposiit ei ole Windowsi kohalikel ketastel. See stsenaarium töötab sarnaselt ülaltoodud lihtsa ülesandega. Iga rullimise korral loob BCJ täieliku varunduse, ja olemasolevad punktid unustatakse. Et mitte jääda ilma vabast ruumist, tuleb kasutada DWORD ForceDeleteBackupFiles.
Kokkuvõte
Seega, selle pika teksti tulemusena oleme vaadanud kahte tüüpi ülesannet. Muidugi on ülesandeid palju rohkem, kuid nende kõigi käsitlemine ei ole ühe artikli formaadis võimalik. Kui teil on pärast lugemist küsimusi, kirjutage need kommentaaridesse, vastan meeleldi isiklikult.
Allikas: habr.com
