Tere tulemast meie blogi lugejad! Osa meist on juba tuttav – minu ingliskeelsed postitused on siin ilmunud kallis kolleegi tõlkes . Seekord otsustasin otse venekeelse publiku poole pöörduda.
Oma debüüdiks tahtsin leida teema, mis oleks huvitav võimalikult laiale publikule ja vajaks põhjalikku käsitlemist. Daniel Defoe väitis, et igaüht ootavad surm ja maksud. Minu poolt võin kinnitada, et iga tehnilise toe inseneri hüüded keerlevad taastamispunktide säilitamise poliitikate (või lihtsamalt öeldes – retenții) ümber. Kuidas retenți töötab, hakkasin ma selgitama 4 aastat tagasi, olles esimese taseme noor insener, ja jätkan seda veel nüüd, olles hispaania- ja itaalia keelt kõneleva meeskonna tiimijuht. Olen kindel, et minu kolleegid teiselt ja isegi kolmandalt tasemelt pakuvad samuti regulaarselt vastuseid samadele küsimustele.
Selles valguses soovis ma kirjutada lõplikku, põhjalikku postitust, kuhu venekeelsed kasutajad saavad korduvalt tagasi pöörduda kui teejuhti. Hetk on sobiv - hiljuti välja antud juubeli kümnes versioon on lisanud uusi funktsioone põhifunktsionaalsusele, mis ei ole aastaid muutunud. Minu postitus keskendub eeskätt sellele versioonile - kuigi enamik kirjutatust on tõene ka varasemate versioonide puhul, ei leia te mõningaid seal kirjeldatud funktsioone. Vaadates natuke tulevikku, võin öelda, et järgmises versioonis oodatakse mõned muudatused, kuid sellest räägime, kui aeg on õige. Nüüd aga alustame.
Varundustöö (Backup job)
Alustame osast, mis versioonis 10 muutumatuks on jäänud. Tegevuste säilitamise poliitika määratakse mitmete parameetrite alusel. Avame uue töö tegemise akna ja liigume kaardile Storage. Siin näeme parameetrit, mis määratleb soovitud taastamispunktide arvu:
Kuid see on vaid osa valemist. Tegelik punktide arv määratakse ka varukoopia režiimi järgi, mis on määratud ülesande jaoks. Selle parameetri valimiseks tuleb klõpsata vahekaardil nuppul Advanced. See avab uue akna mitme valikuga. Loetleme need ja vaatame neid järjestikku:
Kui aktiveerida ainult valik 1, töötab ülesanne 'lõputu inkrementaalse' režiimis (forever forward incremental). Siin ei teki mingeid raskusi – ülesanne salvestab määratud arvu taastamispunkte täisvarukoopiadest (fail laiendiga VBK) kuni viimase inkrementini (fail laiendiga VIB). Kui punktide arv ületab määratud väärtuse, ühendatakse vanim inkrement täisvarukoopiaga. Teisisõnu, kui ülesanne on seatud salvestama 3 punkti, on pärast järjekordset sessiooni salvestatud 4 punkti, pärast mida ühendatakse täisvarukoopia vanima inkrementiga ja punktide koguarv naaseb 3-le.
Samuti on „tagurpidi inkrementaalne“ (reverse incremental) režiimi jaoks äärmiselt lihtne hoidmine (valik 2). Kuna antud juhul on kõige uuem punkt täielik varukoopia, millele järgneb nn rullbackide ahel (failid, millel on laienemine VRB), piisab hoidmise rakendamiseks lihtsalt kõige vanema rullbacki kustutamisest. Olukord jääb samaks: pärast seanssi ületab punktide arv seadistatud arvu ühe võrra, pärast mida taastub see vajalikule väärtusele.
Pange tähele, et tagurpidi inkrementaalse režiimi puhul on võimalik ka lubada perioodiline täielik varukoopia (valik 4), kuid see ei muuda asja olemust. Jah, ahelas ilmuvad täielikud taastepunktid, kuid me jätkame kõige vanade punktide eemaldamist üksikutena.
Lõpuks jõuame huvitava osa juurde. Kui aktiveerida inkrementaalne varundamine ja lisada valikud 3 või 4 (või mõlemad korraga), hakkab ülesanne looma perioodilisi täielikke varukoopiaid "aktiivse" või sünteetilise meetodi abil. Täieliku varukoopia loomiseks kasutatav meetod ei oma tähtsust – see sisaldab samu andmeid, samas kui inkrementaalne ahel jaguneb "alam-ahelateks". Seda meetodit nimetatakse edasi suunatud inkrementaalseks, ja see tekitab meie klientide seas hulgaliselt küsimusi.
Retensioon kehtib siin kõige vanema osa (täieliku varukoopia ja inkrementaali) eemaldamisena. Sellega ei eemalda me vaid tühja varukoopiat ega ka ainult osa inkrementaalidest. Kogu „alam-ahel” eemaldatakse täielikult korraga. Muutub ka punkti arvu seadistuse tähendus – kui teistes meetodites on see maksimaalselt lubatud arv, mille järel tuleb rakendada retensiooni, siis siin määratleb see seade minimaalset arvu. Teisisõnu, pärast kõige vanema „alam-ahela” eemaldamist ei tohi jäämas oleval osal punktide arv langeda alla selle miinimumi.
Püüan seda kontseptsiooni visuaalselt kujutada. Oletame, et säilitamisperiood on seadistatud 3 punktile, ülesanne töötab iga päev täie varukoopiaga esmaspäeviti. Sellisel juhul rakendatakse säilitamist, kui punktide koguarv ulatub 10-ni:
Miks just 10, kui seadistasime 3? Esmaspäeval loodi täisvarukoopia. Teisipäevast pühapäevani genereeris ülesanne inkremente. Lõpuks luuakse järgmisel esmaspäeval jälle täisvarukoopia ja ainult siis, kui on loodud 2 inkremente, võib kogu vana osa ahelast lõpuks eemaldada, kuna allesjäänud punktide arv ei lange alla seatud 3.
Kui idee on selge, siis pakun välja, et proovite säilitamist ise arvutada. Võtame sellised tingimused: ülesanne käivitub esmakordselt neljapäeval (loomulikult tehakse täisvarukoopia). Ülesanne on seadistatud looma täisvarukoopiaid kolmapäeviti ja pühapäeviti ning hoidma 8 taastamispunkti. Millal rakendatakse säilitamist esmakordselt?
Sellele küsimusele vastamiseks soovitan teil võtta paberileht, jagada see nädalapäevadeks ja kirjutada, milline punkt luuakse iga päev. Vastus muutub ilmseks.
Vastus
Selgitus: piisab, kui küsida endalt 'millal rakendatakse kinnipidamist'? Vastus on, et siis, kui suudame eemaldada 3 esimest punkti (VBK, VIB, VIB) ja ülejäänud ahel ei lange alla ettenähtud 8 punkti. Selgub, et saame seda teha, kui meil on kokku 11 punkti, st pühapäeval teisel nädalal.
Mõned lugejad võivad vastu vaielda: 'miks kõik see, kui on olemas ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Lõpuks ei arutanud me valikut "Muuda varasemaid varukoopiaid tagasipöördumisteks" (margitud numbriga 5). See valik segadusse ajab mõnikord kliente, kes aktiveerivad selle „automaatrežiimis”, soovides lihtsalt lisada sünteetilise varukoopia. Samas aktiveerib see valik hoopis erilise varundusrežiimi. Üksikasjadesse laskumata ütlen kohe, et toote praeguses arenguetapis on "Muuda varasemaid varukoopiaid tagasipöördumisteks" vananenud valik ja ma ei suuda välja mõelda ühtki stsenaariumi, kus seda võiks kasutada. Selle väärtus on nii küsitav, et Antonn Gostev ise kutsus teatud aega foorumi kaudu üles saatma talle näiteid selle kasulikest kasutusvõimalustest (kui teil neid on, kirjutage kommentaarides, olen väga huvitatud). Kui neid ei leita (ma arvan, et nii läheb), siis eemaldatakse see valik järgmistes versioonides.
Ülesanne loob inkremente (VIB) kuni päevani, mil on määratud sünteetiline täielik varukoopia. Sellel päeval luuakse tõeliselt VBK, aga kõik punktid kuni selle VBK-ni muudetakse rollback'iks (VRB). Pärast seda jätkab ülesanne inkrementide loomist täieliku varukoopia jaoks kuni järgmise sünteetilise varukoopiani. Tulemuseks on ahelas segu VBK, VBR ja VIB failidest. Retentsioon kehtestatakse väga lihtsalt – eemaldades viimase VBR:
Probleemid
Lisaks sellele, et oleks arusaam, kuidas see töötab, on enamik inkrementaalse režiimi kasutamisel tekkivaid probleeme tavaliselt seotud täieliku varukoopiaga. Regulaarne täielik varukoopia on selle režiimi jaoks vajalik, vastasel juhul hakkab repository koguma punkte, kuni see on täis.
Näiteks võib täisvarundus toimuda liiga harva. Oletame, et ülesanne on määratud hoidma 10 punkti, kuid täisvarundus luuakse kord kuus. On selge, et tegelik punktide arv siin on oluliselt suurem kui määratud. Või on ülesanne üldse määratud töötama lõpmatus-inkrementaalses režiimis ja hoidma 50 punkti. Siis keegi kogemata loob täisvarunduse. Kõik, nüüd ootab ülesanne, kuni täispunkt kogub 49 inkrementi, pärast mida rakendab see säilitamispoliitikat ja naaseb lõpmatus-täis režiimi.
Teistes olukordades on täisvarukoopia seadistatud looma regulaarselt, kuid mingil põhjusel seda ei tehta. Kirjutan siin kõige populaarsema põhjuse. Mõned kliendid eelistavad kasutada “run after” ajastamisvalikut ja seadistada ülesanded tööle ahelana. Vaatame näiteks: on 3 ülesannet, mis töötavad igapäevaselt ja loovad täisvarukoopia pühapäeval. Esimene ülesanne käivitub kell 22.30, teised käivituvad ahelana. Inkrementaalne varukoopia võtab aega 10 minutit, seega kell 23.00 lõpetavad kõik ülesanded töö. Täisvarukoopia aga võtab aega tund, seetõttu toimub pühapäeval järgnev: esimene ülesanne töötab kell 22.30 kuni 23.30. Järgmine kell 23.30 kuni 00.30. Kolmas ülesanne käivitub juba esmaspäeval. Täisvarukoopia on seadistatud pühapäevaks, mistõttu seda lihtsalt ei toimu. Ülesanne ootab täisvarukoopiat, et rakendada säilitamispoliitikat. Seega olge ettevaatlikud, kui kasutate “run after” valikut, või ärge kasutage seda üldse — seadistage ülesanded käivituma samal ajal ja laske ressursside ajastajal oma tööd teha.
Kõrvaldas dificultad “Eemalda kustutatud üksused”
Minu kaudu Storage – Advanced – Maintenance seadeid liikudes võib leida valiku "remove deleted items data after", mis arvutatakse päevades.
Mõned kliendid eeldavad, et see ongi retentsioon. Tegelikult on see täiesti eraldi valik, mille vale mõistmine võib viia ootamatute tagajärgedeni. Ennekõike tuleks selgitada, kuidas B&R reageerib olukordadele, kus seansi ajal varundatakse edukalt ainult mõned masinad.
Kujutame ette järgmist stsenaariumi: lõputu inkrementaalne ülesanne, mis on seadistatud hoidma 6 punkti. Ülesandes on 2 masinat, üks varesemas olis alati edukalt varundatud, teine aga andis aeg-ajalt vigu. Lõpuks, seitsmenda punkti puhul, tekkis selline olukord:
On aeg rakendada retentsioon, kuid ühel masinal on 7 punkti ja teisel ainult 4. Kas retentsioon rakendatakse? Vastus on jah, rakendatakse. Kui vähemalt üks objekt on varundatud, arvab B&R, et punkt on loodud.
Sarnane olukord võib tekkida, kui mõni masin ei olnud lihtsalt ülesandes määratud teatud seansi ajal. See võib juhtuda näiteks siis, kui masinad on ülesandele lisatud mitte eraldi, vaid konteinerite (kaustade, ladustamise) koosseisus ning mõni masin rändab ajutiselt teise konteinerisse. Sellisel juhul loetakse ülesanne õnnestunud, kuid statistikast leiate teate, mis kutsub tähelepanu sellele, et teatud masinat ei töödelda enam ülesande raames.
Mis juhtub, kui sellele tähelepanu ei pöörata? Infiniitsetes inkrementaalsetes või tagasiinkrementaalsetes režiimides 'probleemse' masina taastamispunktide arv väheneb iga seansiga, kuni see jõuab 1, mis on salvestatud VBK-sse. Teisisõnu, isegi kui masinat pikka aega varundatakse, jääb üks taastamispunkt ikkagi alles. Asi on teisiti, kui on sisse lülitatud perioodilised täielikud varukoopiad. Kui ignoreerida B&R signaale, võib viimase punkti eemaldada koos vanema osa ahelaga.
Kuna need üksikasjad on selged, saab lõpuks arvesse võtta valikut "Remove deleted items data after". See kustutab kõik andmed konkreetse masina kohta, kui masinat ei varundata X päeva jooksul. Pange tähele, et see seade ei reageeri vigadele (proovisime - ei õnnestunud). Masina varundamise katset ei tohi olla. Tundub, et valik on kasulik ja seda tuleks alati sisse lülitada. Kui administraator on masina ülesandest eemaldanud, on mõistlik mõne aja pärast eemaldada tarbetud andmed ja ahel. Kuid seadistus nõuab distsipliini ja tähelepanelikkust.
Tõin praktika näite: ülesandele lisati mitu konteinerit, mille koostis oli üsna dünaamiline. Puuduliku RAM-i tõttu koges B&R server probleeme, mis jäid märkamatuks. Ülesanne käivitus ja proovib varundada masinad, välja arvatud üks, mis sellel hetkel konteineris ei olnud. Kuna paljud masinad andsid vigu, peab B&R vaikimisi tegema 3 täiendavat katset probleemsete masinate varundamiseks. Pidevate RAM-i probleemide tõttu venisid need katsed mitme päeva peale. Puuduva VM-i varundamiseks ei olnud korduskatset (puuduv VM ei ole viga). Lõpuks, ühe korduskatse ajal, rakendati tingimus “Eemalda kustutatud esemed” ja kõik masina punktid eemaldati.
Selle kohta võin öelda järgmist: kui olete seadistanud ülesannete tulemuste teavitused, ja veel parem — kui kasutate integraatori Veeam ONE, siis tõenäoliselt ei juhtu sellist asja teiega. Kui aga vaatate B&R serverisse kord nädalas, et kontrollida, et kõik töötab, siis tasub loobuda valikutest, mis võivad potentsiaalselt viia varunduste eemaldamiseni.
Mida uut on v.10-sse lisatud
See, millest me eelnevalt rääkisime, on olnud B&R-s paljusid versioone. Nüüd, kui oleme need tööpõhimõtted selgeks saanud, vaatame, mida on juubeli "kümnes" versioon kaasa toonud.
Päeva säilitamine
Ülalpool käsitlesime "klassikalist" säilitamise poliitikat, mis põhineb punktide arvul. Alternatiivne lähenemine on menüüsse "days" määramine, selle asemel et kasutada "restore points".
Idee tuleneb juba nimest – säilitamine hoiab teatud arvu päevi, samas ei ole oluline, kui palju punkte igas päevas on.
- Praegust päeva ei arvestata säilitamise arvutamisel
- Päevad, mil ülesanne ei töötanud, arvatakse samuti arvesse. Seda tuleks silmas pidada, et mitte juhuslikult kaotada punktid ülesannetest, mis töötavad ebaühtlaselt.
- Taastamispunkt loetakse päevast, mil selle loomine algas (st kui ülesanne hakkas töötama esmaspäeval ja lõppes teisipäeval, on see punkt esmaspäevast)
Muudel juhtudel määravad ülesannete rakendamise printsiibid valitud varundusmeetodi. Proovime veel ühte arvutamise ülesannet, kasutades sama inkrementaalset meetodit. Oletame, et säilitustähtaeg on 8 päeva, ülesanne töötab iga 6 tunni järel koos täieliku varundusega kolmapäeval. Selle juures ülesanne pühapäeval ei toimi. Ülesanne käivitub esmakordselt esmaspäeval. Millal säilitustähtaeg rakendub?
Vastus
Nagu tavaliselt, on kõige parem joonistada tabel. Lubage mul lihtsustada ülesannet ja ma ei joonista kõiki punkte, mis on loodud iga päev, kuna punktide arv päevas ei ole siin oluline. Meile on tähtis, et esmaspäeval ja kolmapäeval on esimene punkt täielik varundus, kuid teistel päevadel loob ülesanne lihtsalt 4 inkrementaalset punkti.
Selgitame endale, et säilitustähtaeg rakendub esmaspäeva täieliku varunduse ja selle inkrementaalse variandi eemaldamisega. Millal see juhtub? Kui jäänud osa ahelast sisaldab 8 päeva. Seejuures me ei arvestada praegust päeva, aga hoolikalt arvestame pühapäeva. Seega on vastus – teise nädala neljapäeval.
GFS-meetodi arhiveerimine tavapäraste ülesannete jaoks
Kuni v.10 oli Grandfather-Father-Son (GFS) säilitamise meetod saadaval ainult varukoopia (Backup copy) ja magnetlintidele kopeerimise ülesannete jaoks. Nüüd on see saadaval ka tavalise varustamise jaoks.
Küll see ei seondu praeguse teema, ei saa ma mitte öelda, et uus funktsioon ei tähenda taganemist 3-2-1 strateegiast. Arhiveerimispunktide olemasolu peamises hoidlas ei mõjuta selle usaldusväärsust. Eeldatakse, et GFS'i kasutatakse koos laiendatava (Scale-out) hoidla, et need punktid saata S3 ja teiste sarnaste salvestuslahenduste juurde. Kui te neid ei kasuta, on parem hoida esmased ja arhiveeritud punktid erinevates hoidlates.
Nüüd vaatame GFS punktide loomise põhimõtteid. Ülesande seadetes, sammus Storage, on ilmnenud spetsiaalne nupp, mis kutsub esile järgmise menüü:
GFS olemus võib kokku võtta mitme punktiga (pange tähele, et GFS-i teistes ülesannetes töötab teisiti, kuid sellest räägime hiljem):
- Ülesanne ei loo eraldi täielikku varukoopia GFS punkti jaoks. Selle asemel kasutatakse olemasolevatest kõige sobivamat täielikku varukoopiat. Seetõttu peab ülesanne töötama inkrementaalses režiimis perioodiliste täiendava varukoopiate tegemisega või peab täieliku varukoopia looma kasutaja käsitsi.
- Kui on lubatud vaid üks periood (näiteks nädalane), siis GFS perioodi alguses hakkab ülesanne lihtsalt ootama täiendavat varukoopiat ja märgistab esimese sobiva kui GFS.
Näide: ülesanne on seadistatud hoidma nädala GFS-i, kasutades varukoopiat kolmapäeval. Ülesanne töötab iga päev, kuid täielik varukoopia on määratud reedel. Sellisel juhul algab kolmapäeval GFS periood ja ülesanne hakkab ootama sobivat punkti. See ilmub reedel ja saadab GFS lipu.
- Kui on lubatud mitu perioodi (nt nädalane ja kuine), siis B&R rakendab meetodi, mis võimaldab kasutada ühte ja sama punkti mitme intervalli GFS-ina (ruumi säästmiseks). Lipud määratakse vaheldumisi, alustades nooremast.
Näide: nädalane GFS on määratud kolmapäevaks, samas kui kuukäik on viimase nädala jaoks. Ülesanne töötab iga päev ja loob täielikke varukoopiaid esmaspäeviti ja reedeti.
Lihtsuse huvides alustame arvestust eelviimasest nädalast. Sel nädalal luuakse esmaspäeval täisvarukoopia, kuid see jäetakse tähelepanuta, sest nädalane GFS intervall algab kolmapäeval. Küll aga reedene täisvarukoopia sobib täielikult GFS punktiks. See süsteem on meile juba tuttav.
Nüüd vaatame, mis juhtub kuu viimasel nädalal. Kuukäigu intervall käivitub esmaspäeval, kuid esmaspäevane VBK ei märgita GFS-iks, sest ülesanne püüab tähistada ühte VBK-d nii kuukäiguna kui ka nädalase GFS punktina. Otsing algab just nädalasest, sest see võib definition järgi olla ka kuukäik.
Kui aga lubada ainult nädalaseid ja aastaseid intervalle, toimivad need üksteisest sõltumatult ja võivad tähistada 2 eraldi VBK-d kui vastavaid GFS intervalle.
Varukoopia loomise ülesanded (Backup copy)
Teine tüüpi ülesanded, mis vajavad sageli töö käigus selgitusi. Alustame "klassikalise" töömeetodiga, ilma uute uuendusteta v.10.
Lihtne retenšene meetod
Vaikimisi töötavad sellised ülesanded pidevalt ja järjestikku. Punktide loomine määrab kaks parameetrit – varundusintervall ja soovitud punktide arv (päevade järgi retenšeni siin pole). Varundusintervall seadistatakse ülesande loomise esimesel vahekaartil Job:
Punktide arv määratakse veidi hiljem vahekaardil Target.
Ülesanne loob iga intervalli järel 1 uue punkti (kui palju punkte on algsetest ülesannetest VM-i jaoks loodud, pole tähtis). Intervalli lõpus viime lõpule uue punkti ja vajadusel rakendame retenšeni VBK ja kõige vanema inkrementi liitmise kaudu. See mehhanism on meile juba tuttav.
Retenšeni meetod GFS-i kasutamisega
BCJ oskab samuti säilitada arhiivipunkte. Sätted tehakse samal vahekaardil Target, veidi allpool säilituspunktide arvu määramise seadistus:
GFS punkte võivad olla loodud kahel viisil – sünteetiliselt, kasutades andmeid teises hoidlas, või imiteerides täielikku varukoopiat ja lugedes kõik andmed esimesest hoidlast (aktiveeritakse valiku, millel on number 3, kaudu). Säilitamine mõlemas juhul erineb oluliselt, seega vaatame need eraldi üle.
Sünteetiline GFS
Sellest tulenevalt ei loodud GFS punkti täpselt määratud kuupäeval. Selle asemel luuakse GFS punkt, kui selle päeva VIB, millele oli GFS punkti loomine määratud, on ühendatud täieliku varukoopiaga. See võib aeg-ajalt tekitada arusaamatusi, sest aeg läheb, kuid GFS punkti ei ole ikka veel. Ainult tugeva tugiteenuse šamaan suudab ennustada, millisel päeval punkt tegelikult ilmub. Tegelikult ei ole mingit maagiat vaja – piisab, kui vaadata väljakujundatud punktide arvu ja sünkroonimisintervalli (kui palju punkte luuakse iga päev). Proovige ise arvutada järgmisel näitel: määratakse 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 sellele päevale on määratud GFS punkti loomine. Millisel päeval see luuakse?
Vastus
Siin on parem täpsustada, kuidas ahel muutub dünaamikas, päevade kaupa:
Nii et esmaspäeval märgitakse ahelas viimane inkrement GFS-iks, kuid muid nähtavaid muudatusi ei toimu. Igal päeval loob ülesanne 2 uut punkti ning hoidmine surub ahelat pidevalt edasi. Lõpuks, neljapäeval, on aeg rakendada hoidmist sellele inkrementile. See seanss võtab tavalisest rohkem aega – kuna ülesanne "kaevab" vajalikud plokid ahelast välja ja loob uue täispunkti. Sellest hetkest alates on ahelas juba 8 punkti – 7 põhiasendil + GFS.
GFS punktide loomine valikuga "Loe kogu punkti"
Eelnevalt mainisin, et BCJ töötab lõpmatus-inkrementaalses režiimis. Nüüd vaatame seda reeglit, millel on üks erand. Kui valik "Loe kogu punkt" on lubatud, luuakse GFS punkt täpselt plaanitud päeval. Ülesanne ise töötab inkrementaalses režiimis perioodiliste täistehikute tegemisega, millest me eelnevalt rääkisime. Retentsioon kehtib, kustutades kõige vanema osa ahelast. Kuid antud juhul kustutatakse ainult inkremente, samas kui täistehik jääb GFS punktina. Vastavalt, retentsiooni arvutamisel ei arvestata punkte, mis on märgitud GFSi lippudega.
Oletame, et ülesanne on seadistatud hoidma 7 punkti ja looma iganädalast GFS punkti esmaspäeval. Sel juhul loob ülesanne igal esmaspäeval tõepoolest täistehik ja märgib selle GFS-ks. Retentsioon kehtib, kui pärast inkrementide kustutamist kõige vanemast osast ei jää üle vähem kui 7 inkrementi. Nii see skeem välja näeb:
Nii, teise nädalaga on kettas kokku 14 punkti. Teise nädala jooksul luuakse 7 punkti. Kui see oleks lihtne ülesanne, oleks tagasikutsumine juba rakendatud. Aga see on BCJ GFS tagasikutsumisega, seega GFS punkte me ei arvesta, seega on neid ainult 6. Seega ei saa me tagasikutsumist veel rakendada. Kolmandal nädalal loome veel ühe täieliku varukoopia GFS lipuga. 15 punkti, aga seda me jälle ei arvesta. Ja lõpuks, kolmanda nädala teisipäeval loome inkremente. Nüüd, kui me eemaldame esimese nädala kettas olevad inkreendid, rahuldab inkreentide koguhulk kehtestatud tagasikutsumist.
Nagu juba eespool öeldud, on seda meetodit kasutades väga oluline, et täielikke varukoopiaid luuakse regulaarselt. Oletame, et kui seadistame põhilise tagasikutsumise 7 päevaks, kuid ainult 1 aastase punkti korral, ei ole keeruline ette kujutada, et inkreente koguneb palju, palju rohkem kui 7. Sellistes olukordades on parem kasutada sünteetilist GFS loomise meetodit.
Ja jälle „Eemalda kustutatud üksused”
See valik on olemas ka BCJ jaoks:
Selle valiku loogika on siin sama, nagu tavapärastes varundusülesannetes – kui masin ei ole töötlemises määratud arvu päeva, siis tema andmed eemaldatakse ahelast. Siiski on BCJ puhul selle valiku kasulikkus objektiivselt suurem, ja siin on põhjus.
Tavarežiimil töötab BCJ lõputult inkrementaalses režiimis, seega kui mõnel hetkel masin ülesandest eemaldatakse, eemaldab säilitamine järk-järgult kõik taastepunktid, kuni jääb alles üks – VBK. Kujutage nüüd ette, et ülesanne on endiselt seadistatud looma sünteetilisi GFS punkte. Kui tulemus on käes, peab ülesanne looma GFS kõigi ahelas olevate masinate jaoks. Kui mõnel masinal pole üldse uusi punkte – noh, tuleb kasutada olemasolevat. Ja nii iga kord. Lõpuks võib tekkida selline olukord:
Pange tähele sektsiooni Failid: meil on peamine VBK ja 2 nädalast GFS punkti. Ja nüüd sektsioonis Taastepunktid – tegelikult on nende failide sees sama masina pilt. Loomulikult pole sellistes GFS punktides mingit mõtet, nad võtavad lihtsalt ruumi.
Seda olukord on võimalik ainult kunstliku GFS-i kasutamisel. Selle vältimiseks kasutage valikut “Remove deleted items”. Ainult ärge unustage selle seadistamist adekvaatse päevade arvu peale. Tehniline tugi on näinud juhtumeid, kus valikut seati vähemaks päevade arvuks, kui sünkroniseerimise intervall – BCJ hakkas rahutuks minema ja kustutama punkte, enne kui need olid loodud.
Pange tähele, et see valik ei puutu juba loodud GFS punkte. Kui soovite arhiive puhastada, tuleb seda teha käsitsi – paremklõpsake masinal ja valige “Delete from disk” (avatavas aknas ärge unustage märkida kasti “Remove GFS full backup”):
Uuendus v.10 – kohene koopia (immediate copy)
Kuna oleme selgeks saanud «klassikalise» funktsionaalsuse, liigutame edasi uude. Uuendus on üks, kuid väga oluline. See on uus töörežiim.
Siin ei ole mõistet „sünkroonimisvahemik“, ülesanne jälgib pidevalt, kas on tekkinud uusi punkte, ja kopeerib need kõik, sõltumata nende arvust. Samuti jääb ülesanne inkrementaalseks, see tähendab, et isegi kui põhitegevus loob VBK või VRB, kopeeritakse need punktid VIB-na. Muus osas ei ole selles režiimis üllatusi – nii standardne kui ka GFS-i säilitamine toimivad ülaltoodud reeglite järgi (tõsi, siin on saadaval ainult sünteetiline GFS).
Kettad pöörlevad. Diskide rullimise (rotated drives) hoidlate omadused
Pidev krüpteerijate viiruste oht on muutnud andmete hoidmise koopia olemasolu meedias, kuhu viirus ei pääse, de facto turvastandardiks. Üks võimalus on kasutada diskide rullimise hoidlaid, kus kettad vahelduvad: samal ajal kui üks ketas on ühendatud ja kirjutamiseks saadaval, hoitakse teisi turvalises kohas.
Kuidas õpetada B&R töötama selliste hoidlate puhul, tuleb hoidla seadetes, sammul Repository, klikkida nupule Advanced ja valida vastav valik:
Pärast seda ootab VBR, et aeg-ajalt kuvav ahel kaob hoidlast, mis tähendab ketta rotatsiooni. Olenevalt hoidla tüübist ja ülesande tüübist käitub B&R erinevalt. Seda saab esitada järgmise tabelina:
Vaatame iga varianti.
Tavaline ülesanne ja Windowsi hoidla
Nii et meil on ülesanne, mis salvestab ahelad esimesel kettal. Ketta rotatsiooni korral kaob loodud ahel tegelikult ning ülesanne peab kuidagi selle kaotuse üle elama. Loht leiate täisvarunduse loomises. Seega iga rotatsioon tähendab täisvarundust. Kuid mis juhtub punktidega, mis on väljalülitatud kettal? Need salvestatakse ja arvestatakse tagasivõtmise arvutamisel. Seega ülesandes määratud punktide arv on see, mitu punkti tuleb kõikidel kettadel hoida. Toome välja näite:
Ülesanne töötab lõputult kasvavas režiimis ja on seadistatud hoidma 3 taastamispunkti. Kuid meil on veel teine ketas ja me viime kord nädalas läbi rotatsiooni (kettad võivad olla ka rohkem, see ei muuda asja olemust).
Esimese nädala jooksul loob ülesanne punkte esimesel ketasal 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 kasutajaliidest, kuid teave selle kohta jääb ära andmebaasi. Nüüd hoiab ülesanne 3 punkti teisel kettal. Üldine olukord on järgmine:
Lõpuks ühendame uuesti esimese ketta. Enne uue punkti loomist kontrollib ülesanne, mis on retentsiooniga. Ja retentsioon, meenutan, on seatud 3 punkti hoidmiseks. Meil on 3 punkti ketas 2-l (aga see on välja lülitatud ja hoitakse turvalises kohas, kuhu B&R ei pääse) ja 3 punkti ketas 1-l (see on aga ühendatud). Seega on võimalik julgelt kustutada 3 punkti kettalt 1, kuna need ületavad retentsiooni. Pärast seda loob ülesanne uuesti täieliku varunduse ja meie ahel näeb välja nii:
Kui retentsioon on seatud päevade hoidmiseks, siis loogika ei muutu. Lisaks ei toetata GFS-retentsiooni üldse ketaste rotatsiooni kasutamisel.
Tavaline ülesanne ja Linuxi repositooriumi võrgu salvestus
See variant is also possible, but generally less recommended due to imposed restrictions. The task will respond to disk rotation and the disappearance of the chain in the same way – by creating a full backup. The limitation is related to the truncated retention mechanism.
Here, during rotation, the entire chain on the inactive disk is simply deleted from the B&R database. Note – it is removed from the database, while the files themselves remain on the disk. They can be imported and used for recovery, but it is easy to guess that sooner or later such forgotten chains will fill up the entire repository.
The solution lies in adding DWORD ForceDeleteBackupFiles as specified on this page: . After that, the task will start simply deleting all contents of the task folder or repository folder (depending on the value) upon each rotation.
However, this is not an elegant retention solution, but rather a cleanup of all contents. Unfortunately, support has encountered cases where the root directory of the disk was specified as the repository, where besides backups, other data also existed. All of it was destroyed during rotation.
Lisaks, kui ForceDeleteBackupFiles on lubatud, töötab see kõigi tüüpi repositooriumide jaoks, seega ka Windowsi repositooriumid lõpetavad säilitamise rakendamise ja hakkavad sisu eemaldama. Teisisõnu, kohalikel kõvaketastel Windowsis on parim valik selliseks varundussüsteemiks.
Varukoopia ja Windowsi repositoorium
BCJ puhul muutub kõik veelgi huvitavamaks. Lisaks sellele, et olemas on täisfunktsionaalne säilitamine, ei ole vaja iga kettavahetuse korral teha täisvarukoopiat! See töötab nii:
Esmalt B&R hakkab looma punkte esimesel kettal. Oletame, et oleme seadnud säilitamise 3 punktile. Ülesanne töötab lõputu inkrementaalse režiimiga ja ühendab kõik üleliigse (meenutan, et GFS säilitamine ei ole sellel juhul toetatud).
Seejärel ühendame teise ketta. Kuna sellel ei ole veel ahelat, loome täisvarukoopia, pärast mida ilmub meile teine ahel kolmest punktist:
Lõpuks on aeg uuesti ühendada esimene kettas. Ja nüüd algab maagia, kuna ülesanne ei loo täisvarukoopiat, vaid jätkab lihtsalt inkrementaalse ahelaga:
Pärast seda on igal kettal tegelikult oma sõltumatu ahel. Seetõttu tähendab säilitamine siin mitte punktide arvu kõigil ketastel, vaid punktide arvu igal kettal eraldi.
Backup copy ja Linuxi repository võrgu salvestus
Ja taas, kogu elegants kaob, kui repository ei asu Windowsi kohaliku kettal. See stsenaarium töötab sarnaselt ülaltoodud lihtsa ülesandega. Iga rotatsiooni käigus loob BCJ täieliku varukoopia, ja olemasolevad punktid unustatakse. Et mitte jääda ilma vaba ruumita, tuleb kasutada DWORD ForceDeleteBackupFiles.
Kokkuvõte
Nii et pika teksti tulemusena oleme käsitlenud kahte ülesande tüüpi. Loomulikult on ülesandeid palju rohkem, kuid neid kõiki ei saa ühes artiklis käsitleda. Kui teil on pärast lugemist küsimusi, kirjutage need kommentaaridesse, olen rõõmus, kui saan isiklikult vastata.
Allikas: habr.com
