Vitajte čitatelia nášho blogu! Do istej miery sa už poznáme – moje príspevky v angličtine sa tu objavovali v preklade mojej drahej kolegyne . Tentoraz som sa rozhodol osloviť rusky hovoriace publikum priamo.
Pre svoj debut som chcel nájsť tému, ktorá by zaujímala čo najširšie publikum a vyžadovala podrobné zváženie. Daniel Defo tvrdil, že smrť a dane čakajú každého. Z mojej strany môžem povedať, že každého technika podpory čakajú otázky týkajúce sa politík uchovávania bodov obnovy (alebo ak to zjednodušíme – retencie). Ako funguje retencia, som začal vysvetľovať pred 4 rokmi, keď som bol junior technik prvého stupňa, a pokračujem v tom aj dnes ako tímový líder španielskej a talianskej podpornej skupiny. Som si istý, že moji kolegovia zo druhého a dokonca tretieho stupňa podpory tiež pravidelne odpovedajú na rovnaké otázky.
V tomto svetle som sa rozhodol napísať konečný, čo najpodrobnejší príspevok, ku ktorému by sa rusky hovoriaci používatelia mohli vracať znova a znova ako k príručke. Okamih je vhodný – nedávno vydaná jubilejná desiata verzia pridala nové funkčnosti k základnému funkčnému súboru, ktorý sa roky nezmenil. Môj príspevok je zameraný predovšetkým na túto verziu — hoci väčšina napísaného platí aj pre predchádzajúce verzie, niečo z opísaných funkcií tam prosto nenájdete. Napokon, ak sa pozrieme trochu do budúcnosti, poviem, že v ďalšej verzii sa očakávajú niektoré zmeny, ale o tom sa podelíme, keď príde čas. Tak sa do toho pustime.
Zadania zálohovania (Backup job)
Najprv sa pozrime na tú časť, ktorá sa v verzii 10 nezmenila. Politika retencie sa určuje niekoľkými parametrami. Otvoríme okno na vytvorenie nového zadania a prejdeme na kartu Úložisko. Tu uvidíme parameter, ktorý určuje požadovaný počet bodov obnovy:
Avšak, to je len časť rovnice. Skutočný počet bodov sa určuje aj režimom zálohy, ktorý je nastavený pre zadanie. Pre výber tohto parametra je potrebné kliknúť na tlačidlo Rozšírené na tej istej karte. To otvorí nové okno s množstvom možností. Očíslujme ich a preskúmajme po jednom:
Ak sa aktivuje iba možnosť 1, úloha bude fungovať v režime „nepretržitých inkrementov“ (forever forward incremental). Tu nevznikajú žiadne ťažkosti – úloha bude uchovávať nastavený počet bodov obnovenia od úplného zálohovania (súbor s príponou VBK) po posledný inkrement (súbor s príponou VIB). Keď počet bodov prekročí nastavenú hodnotu, najstarší inkrement sa spojí s úplným zálohovaním. Inými slovami, ak je úloha nastavená na uchovávanie 3 bodov, hneď po ďalšej relácii na úložisku budú 4 body, po čom sa úplné zálohovanie spojí s najstarším inkrementom a celkový počet bodov sa vráti na 3.
Rovnako je veľmi jednoduché spravovať retenciu pre režim „obrátených inkrementov“ (reverse incremental) (možnosť 2). Keďže v tomto prípade je najnovší bod úplným zálohovaním, za ktorým sa ťahá reťazec tzv. rollbackov (súbory s príponou VRB), na aplikáciu retencie stačí jednoducho odstrániť najstarší rollback. Situácia bude rovnaká: hneď po relácii počet bodov prekročí nastavené o 1, po čom sa vráti na požadovanú hodnotu.
Majte na pamäti, že s režimom obrátených inkrementov je možné tiež zahrnúť periodické úplné zálohovanie (možnosť 4), ale podstatu to nezmení. Áno, v reťazci sa objavia úplné body obnovenia, ale aj tak budeme jednoducho odstraňovať najstaršie body jeden po druhom.
Nakoniec sa dostávame k zaujímavej časti. Ak aktivujete inkrementálne zálohovanie, ale navyše aktivujete možnosti 3 alebo 4 (alebo obidve naraz), úloha začne vytvárať periodické úplné zálohovania „aktívnym“ alebo syntetickým spôsobom. Metóda vytvorenia úplného zálohovania nie je podstatná – bude obsahovať rovnaké údaje, a inkrementálny reťazec bude rozdelený na „podreťazce“. Táto metóda sa nazýva forward incremental a práve ona spôsobuje významnú časť otázok našich klientov.
Retencia sa tu aplikuje odstránením najstaršej časti reťazca (od úplného zálohovania po inkrement). Pri tom nebudeme odstraňovať len prázdne zálohovanie alebo len časť inkrementov. Celá „podreťazec“ sa odstraňuje naraz. Zmení sa aj význam nastavenia počtu bodov – ak v iných metódach ide o maximálne povolený počet, po ktorom je potrebné aplikovať retenciu, tak tu toto nastavenie určuje minimálny počet. Inými slovami, po odstránení najstaršej „podreťazca“ nesmie počet bodov v zostávajúcej časti klesnúť pod túto minimálnu hodnotu.
Pokúsim sa túto koncepciu znázorniť graficky. Predpokladajme, že je nastavená retencia na 3 body, úloha beží každý deň s úplným zálohovaním v pondelok. Retencia sa v takom prípade použije, keď celkový počet bodov dosiahne 10:
Prečo 10, keď je nastavených 3? V pondelok bol vytvorený úplný záloh. Od utorka po nedeľu úloha vytvárala inkrementy. Nakoniec, v nasledujúci pondelok sa opäť vytvorí úplný záloh a až keď budú vytvorené 2 inkrementy, nakoniec sa môže odstrániť celá stará časť reťazca, pretože zostávajúci počet bodov neklesne pod nastavené 3.
Ak je myšlienka jasná, navrhujem vám skúsiť vypočítať retenciu samostatne. Vezmime si také podmienky: úloha sa spúšťa prvýkrát vo štvrtok (samozrejme, vykoná sa úplný záloh). Úloha je nastavená na vytváranie úplného zálohu v stredu a v nedeľu a uchovávanie 8 bodov obnovenia. Kedy sa retencia aplikuje prvýkrát?
Na odpoveď na túto otázku vám odporúčam vziať si papier, rozdelený podľa dní v týždni a napísať, aký bod sa každý deň vytvára. Odpoveď bude jasná.
Odpoveď
Vysvetlenie: na odpoveď stačí opýtať sa sami seba „kedy sa aplikuje retencia“? Odpoveď – keď budeme schopní odstrániť 3 prvé body (VBK, VIB, VIB) a ostatná reťazec neklesne pod požadovaných 8 bodov. Je jasné, že to môžeme urobiť, keď budeme mať celkom 11 bodov, t. j. v nedeľu druhého týždňa.
Niektorí čitatelia môžu namietať: „načo to všetko, ak je tu ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Nakoniec sme nepreskúmali možnosť "Transform previous backup chains into rollbacks" (označenú číslom 5). Táto možnosť niekedy mätie klientov, ktorí ju aktivujú „automaticky“, s cieľom zahrnúť iba syntetickú zálohu. Medzitým táto možnosť aktivuje úplne osobitný režim zálohy. Bez podrobností hneď poviem, že v súčasnej fáze vývoja produktu je "Transform previous backup chains into rollbacks" - zastaraná možnosť, a neviem si predstaviť žiadny scenár, kedy by sa mala použiť. Jej hodnota je tak pochybne, že istý čas sám Anton Gostev vyzýval prostredníctvom fóra, aby mu poslali príklady jej užitočného použitia (ak ich máte, napíšte do komentárov, veľmi ma to zaujíma). Ak sa takéto príklady nenájdu (myslím, že to tak bude), tak túto možnosť odstránia v ďalších verziách.
Úloha bude vytvárať inkrementy (VIB) do dňa, keď je naplánovaná syntetická úplná záloha. V tento deň sa naozaj vytvorí VBK, ale všetky body pred týmto VBK sa transformujú na rolbaky (VRB). Po tomto úloha bude pokračovať vo vytváraní inkrementov k úplnej zálohe do ďalšej syntetickej zálohy. V dôsledku toho sa v reťazci vytvára nebezpečná kombinácia súborov VBK, VBR a VIB. Retenčný proces sa aplikuje veľmi jednoducho – odstránením posledného VBR:
Problémy
Okrem porozumenia, ako to funguje, väčšina problémov, ktoré sa vyskytujú pri používaní inkrementálneho režimu, je zvyčajne spojená s úplnou zálohou. Pravidelná úplná záloha je pre tento režim nevyhnutná, inak sa v úložisku nahromadia body, až kým sa nepreplní.
Napríklad, úplná záloha sa môže vytvárať príliš zriedkavo. Povedzme, úloha je nastavená na uchovávanie 10 bodov, ale úplná záloha sa vytvára raz za mesiac. Je jasné, že skutočný počet bodov tu bude výrazne väčší než nastavený. Alebo je úloha nastavená na prácu v nekonečne-inkrementálnom režime a uchovávanie 50 bodov. Potom niekto náhodou vytvoril úplnú zálohu. Všetko, odteraz bude úloha čakať, kým sa plná bodka nahromadí 49 inkrementov, po čom uplatní retenčný proces a vráti sa do nekonečne-úplného režimu.
V iných prípadoch je plný záloh nastavený na pravidelné vytváranie, ale z nejakého dôvodu to nerobí. Tu popíšem najčastejší dôvod. Niektorí klienti uprednostňujú používanie opcie plánovania „run after“ a nastavujú úlohy, aby pracovali v reťazci. Predstavme si takýto príklad: sú 3 úlohy, ktoré pracujú každý deň a vytvárajú plný záloh v nedeľu. Prvá úloha sa spúšťa o 22:30, ďalšie sa spúšťajú v reťazci. Inkrementálny záloh trvá 10 minút, a preto do 23:00 všetky úlohy končia svoju prácu. Plný záloh však trvá hodinu, a preto sa v nedeľu deje nasledovné: prvá úloha pracuje od 22:30 do 23:30. Ďalšie od 23:30 do 00:30. A tretia úloha sa spúšťa už v pondelok. Plný záloh je naplánovaný na nedeľu, preto v takomto prípade jednoducho nebude. Úloha bude čakať na plný záloh, aby mohla uplatniť retenciu. Preto buďte opatrní pri používaní opcie „run after“ alebo ju vôbec nepoužívajte – jednoducho nastavte úlohy, aby sa spúšťali v rovnakom čase a nechajte plánovač zdrojov vykonať svoju prácu.
Náročná opcia „Remove deleted items“
Prechádzajúc nastaveniami úlohy Storage – Advanced – Maintenance, môžete naraziť na opciu „remove deleted items data after“, počítanú v dňoch.
Niektorí klienti očakávajú, že toto je retencia. V skutočnosti je to úplne samostatná opcia, nepochopenie ktorej môže viesť k neočakávaným následkom. Najprv je však potrebné vysvetliť, ako B&R reaguje na situácie, keď sa počas relácie úspešne zálohujú iba niektoré stroje.
Predstavme si taký scénar: nekonečne-inkrementálna úloha, nastavená na uchovávanie 6 bodov. V úlohe sú 2 stroje, jeden sa vždy úspešne zálohovať, druhý občas dával chyby. Nakoniec pri siedmom bode nastala takáto situácia:
Nastáva čas uplatniť retenciu, ale na jednom stroji je 7 bodov, zatiaľ čo na druhom iba 4. Bude tu aplikovaná retencia? Odpoveď – áno, bude. Ak aspoň jeden objekt bol zálohovaný, B&R považuje bod za vytvorený.
Podobná situácia môže nastať, ak nejaký stroj jednoducho nebol zahrnutý do úlohy počas určitej relácie. To sa stáva napríklad, keď sú stroje pridané do úlohy nie individuálne, ale v rámci kontajnerov (priečinkov, úložísk) a nejaký stroj dočasne migruje do iného kontajnera. Úloha bude v takom prípade považovaná za úspešnú, ale v štatistike nájdete oznam, ktorý upozorňuje, že určitý stroj už nie je spracovávaný úlohou.
Čo sa však stane, ak na to nebudeme brať ohľad? V prípade nekonečne inkrementálneho alebo spätného inkrementálneho režimu sa počet bodov obnovenia "problémového" stroja bude znižovať s každou reláciou, až kým nedosiahne 1, uloženú v VBK. Inými slovami, aj keď sa stroj nebude zálohovať dlhý čas, jeden bod obnovenia predsa len zostane. Situácia je iná, ak sú povolené periodické kompletné zálohy. Ak ignorujete signály od B&R, nakoniec môže byť posledný bod odstránený spolu so starou časťou reťazca.
Po pochopení týchto detailov sa konečne môžeme pozrieť na možnosť "Odstrániť údaje o odstránených položkách po". Táto možnosť odstráni všetky body pre konkrétny stroj, ak sa tento stroj nezálohuje počas X dní. Upozorňujeme, že táto nastavenie nereaguje na chyby (skúsili sme - nepodarilo sa). Nemala by byť ani snaha zálohovať stroj. Zdalo by sa, že táto možnosť je užitočná a mala by byť vždy zapnutá. Ak správca odstránil stroj z úlohy, je logické po nejakom čase vyčistiť zbytočné údaje a reťazec. Avšak, táto nastavenie vyžaduje disciplínu a pozornosť.
Uvediem príklad z praxe: do úlohy bolo pridaných niekoľko kontajnerov, ktorých obsah bol dosť dynamický. Z dôvodu nedostatku RAM mal server B&R problémy, ktoré zostali nepozorované. Úloha sa spustila a pokúsila sa vytvoriť zálohu strojov, okrem jedného, ktorý v tom čase nebol prítomný v kontajneri. Keďže mnohé stroje narazili na chyby, server B&R sa pokúsil vykonať 3 ďalšie pokusy o vytvorenie zálohy „problémových“ strojov. Kvôli neustálym problémom s RAM sa tieto pokusy natiahli na niekoľko dní. Opätovný pokus o vytvorenie zálohy chýbajúcej VM sa nekonal (absencia VM nie je chyba). Nakoniec, počas jedného z opakovaných pokusov bol splnený predpoklad „Odstrániť odstránené položky“ a všetky body stroja boli odstránené.
K tomu môžem povedať toto: ak máte nastavené upozornenia na výsledky úloh, a ešte lepšie - používate integráciu s Veeam ONE, pravdepodobne sa vám to nestane. Ak sa však na server B&R pozriete raz za týždeň, aby ste skontrolovali, či všetko funguje, je lepšie sa vzdať možností, ktoré môžu potenciálne viesť k odstráneniu záloh.
Čo sa pridalo vo verzii 10
To, o čom sme hovorili predtým, existovalo v B&R počas mnohých verzií. Ujasnili sme si tieto principy fungovania, teraz sa pozrime na to, čo sa pridalo v jubilejnej 'desiatke'.
Denná retencia
Vyššie sme sa zaoberali „klasickou“ politikou uchovávania založenou na počte bodov. Alternatívny prístup - nastaviť v rovnakom menu 'dni' namiesto 'bodov na obnovenie'.
Nápad je jasný z názvu - retencia bude uchovávať stanovený počet dní, pričom počet bodov v každom dni nie je dôležitý. Pri tom treba mať na pamäti nasledujúce:
- Súčasný deň sa nezohľadňuje pri výpočte retencie
- Dni, keď úloha úplne nefungovala, sa tiež počítajú. Toto by ste mali mať na pamäti, aby ste náhodou nestratili body tých úloh, ktoré pracujú nepravidelne.
- Bod obnovenia sa počíta od toho dňa, keď začalo jeho vytváranie (t. j. ak úloha začala fungovať v pondelok a skončila v utorok, tak to je bod od pondelka)
V ostatnom prípade sú zásady aplikácie retencie úloh stále stanovené zvolenou metódou zálohovania. Skúsme ďalšiu úlohu na výpočet, znovu použijeme inkrementálnu metódu. Predpokladajme, že retencia je nastavená na 8 dní, úloha beží každých 6 hodín s úplnou zálohou v stredu. Úloha však nebeží v nedeľu. Úloha sa spustí vo štvrtok prvýkrát. Kedy sa aplikuje retencia?
Odpoveď
Ako obvykle, najlepšie je nakresliť tabuľku. Umožním si zjednodušiť úlohu a nebudem kresliť všetky body, ktoré vznikli každý deň, pretože počet bodov za deň tu nie je podstatný. Dôležité pre nás je, že v prvý štvrtok a v stredu bude prvý bod úplnou zálohou, v ostatných dňoch úloha jednoducho vytvorí 4 inkrementálne body.
Ujasňujeme si, že retencia bude aplikovaná odstránením štvrtkového úplného zálohovania a jeho inkrementu. Kedy k tomu dôjde? Keď bude zostávajúca časť reťazca obsahovať 8 dní. Pri tom neberieme do úvahy aktuálny deň, naopak, nedeľu berieme do úvahy. Preto je odpoveď – vo štvrtok druhého týždňa.
Archívanie metódou GFS pre bežné úlohy
Pred v.10 bola metóda uchovávania Grandfather-Father-Son (GFS) dostupná iba pre úlohy vytvárania archívnych kópií (Backup copy) a úlohy kopírovania na magnetickú pásku. Teraz je však dostupná aj pre bežné zálohy.
Hoci sa to netýka aktuálnej témy, nemôžem nespomenúť, že nová funkcia neznamená odklon od stratégie 3-2-1. Prítomnosť archívnych bodov v hlavnom repozitári nijako neovplyvňuje jeho spoľahlivosť. Predpokladá sa, že GFS bude použitý spolu s rozšíriteľným (Scale-out) repozitárom, na prenášanie týchto bodov do S3 a podobných úložísk. Ak ich nepoužívate, je lepšie naďalej uchovávať primárne a archívne body na rôznych repozitároch.
Teraz si priblížime zásady vytvárania GFS bodov. V nastaveniach úlohy, v kroku Storage, sa objavila špeciálna tlačidlo, ktoré vyvoláva nasledujúce menu:
Podstatu GFS môžeme zhrnúť do niekoľkých bodov (berte na vedomie, že GFS v iných druhoch úloh funguje inak, ale o tom neskôr):
- Úloha nevytvára samostatnú úplnú zálohu pre GFS bod. Namiesto toho sa použije najvhodnejšia úplná záloha zo dostupných. Preto by úloha mala pracovať v inkrementálnom režime s periodically vytváranou úplnou zálohou, alebo by mala byť úplná záloha vytvorená používateľom manuálne.
- Ak je zapnuté iba jedno obdobie (napríklad týždenné), tak na začiatku GFS obdobia úloha jednoducho začne čakať na úplnú zálohu a označí prvú vhodnú ako GFS.
Príklad: úloha je nastavená tak, aby uchovávala týždenný GFS, pričom používa zálohu v stredu. Úloha beží každý deň, ale úplná záloha je naplánovaná na piatok. V tomto prípade v stredu začína GFS obdobie a úloha začne čakať na vhodný bod. Ten sa objaví v piatok a bude označený ako GFS.
- Ak sú zapnuté súčasne viaceré obdobia (napríklad týždenné a mesačné), potom B&R aplikuje metódu, ktorá umožňuje použiť ten istý bod ako GFS pre viacero intervalov (na úsporu miesta). Zástavy budú prideľované po jednom, počnúc nižším.
Príklad: týždenný GFS je nastavený na stredu a mesačný na posledný týždeň mesiaca. Úloha beží každý deň a vytvára úplné zálohy v pondelok a piatok.
Aby sme to zjednodušili, začneme počítať od predposledného týždňa mesiaca. V tomto týždni bude vytvorená úplná záloha v pondelok, ale tá bude ignorovaná, pretože týždenný GFS interval začína v stredu. Naopak, piatková úplná záloha je úplne vhodná pre GFS bod. Tento systém už poznáme.
Teraz sa pozrime, čo sa stane v poslednom týždni mesiaca. Mesačný GFS interval začne v pondelok, ale pondelňový VBK nebude označený ako GFS, pretože úloha sa snaží označiť jeden VBK ako mesačnú aj týždennú GFS bod. Pri tom sa začne hľadanie práve s týždennou, pretože tá podľa definície môže byť aj mesačnou.
Ak zapneme iba týždenné a ročné intervaly, budú sa správať nezávisle od seba a môžu označiť 2 samostatné VBK ako zodpovedajúce GFS intervaly.
Úlohy pre vytvorenie rezerve zálohy (Backup copy)
Ešte jeden typ úloh, ktorý často vyžaduje vysvetlenie pre jeho fungovanie. Najprv sa pozrime na "klasickú" metódu práce, bez noviniek v.10
Jednoduchá metóda uchovávania
Predvolene úlohy bežia v nekonečne inkrementálnom režime. Tvorba bodov sa určuje dvoma parametrami – intervalom zálohovania a požadovaným počtom bodov obnovenia (žiadny retain po dňoch tu nie je). Interval zálohovania sa nastavuje na prvej záložke Job pri vytváraní úlohy:
Počet bodov sa určuje o niečo neskôr na záložke Target
Úloha vytvára 1 nový bod za každý interval (to, koľko bodov bolo vytvorených pre VM pôvodnými úlohami, nemá význam). Na konci intervalu sa nový bod finalizuje a, ak je to potrebné, aplikuje sa retenčná stratégia zlúčením VBK a najstaršieho inkrementu. Tento mechanizmus už poznáme.
Metóda retenčnej stratégie s využitím GFS
BCJ tiež dokáže uchovávať archívne body. Nastavuje sa to na tej istej záložke Target, trochu nižšie nastavení počtu bodov obnovenia:
GFS body môžu byť vytvárané dvoma spôsobmi – synteticky, využívajúc dáta na sekundárnom úložisku, alebo simulovaním plnej zálohy a načítavaním všetkých dát z primárneho úložiska (aktivuje sa možnosťou označenou číslom 3). Retenčná stratégia sa v oboch prípadoch bude výrazne líšiť, preto ich preskúmame osobitne.
Syntetický GFS
V tomto prípade GFS bod nie je vytvorený presne v určený deň. Namiesto toho sa GFS bod vytvorí, keď sa VIB toho dňa, na ktorý bolo naplánované vytvorenie GFS bodu, zlúči s plnou zálohou. To niekedy spôsobuje nedorozumenie, pretože čas plynie, a GFS bod stále nie je. A len mocný šaman z technickej podpory dokáže predpovedať, v ktorý deň sa bod nakoniec objaví. V skutočnosti nie je potrebná mágia – stačí sa pozrieť na stanovený počet bodov a interval synchronizácie (koľko bodov sa vytvára každý deň). Skúste si to sami vypočítať na takomto príklade: úloha je nastavená na uchovávanie 7 bodov, interval synchronizácie – 12 hodín (t. j. 2 body denne). V tomto momente je už v reťazci 7 bodov, dnes je pondelok a na tento deň je naplánované vytvorenie GFS bodu. Kedy bude vytvorený?
Odpoveď
Tu je lepšie podrobne opísať, ako sa bude reťazec meniť v dynamike, po dňoch:
Takže v pondelok bude posledný increment v reťazci označený ako GFS, ale žiadne iné viditeľné zmeny sa neudržia. Každý deň úloha vytvára 2 nové body a retenčné obdobie nekompromisne posúva reťazec dopredu. Nakoniec, vo štvrtok nastáva čas aplikovať retenčné obdobie na tento konkrétny increment. Táto relácia zabere viac času, než je obvyklé – pretože úloha "extrahuje" požadované bloky z reťazca a vytvorí nový plný bod. Od tohto okamihu bude v reťazci už 8 bodov – 7 v hlavnom reťazci + GFS.
Vytváranie GFS bodov s možnosťou „Prečítať celý bod“
Vyššie som povedal, že BCJ funguje v nekonečne incrementálnom režime. Teraz si podrobne vysvetlíme jediné vynímanie z tohto pravidla. Pri zapnutí možnosti "Prečítať celý bod" bude GFS bod vytvorený presne v plánovaný deň. Samotná úloha bude fungovať v incrementálnom režime s periódickými plnými zálohami, s ktorými sme sa vyššie zaoberali. Retenčné obdobie sa tiež použije na odstránenie najstaršej časti reťazca. Avšak v tomto prípade budú odstránené len incrementy, zatiaľ čo plná záloha zostane ako GFS bod. Tým pádom sa pri výpočte retenčného obdobia nezohľadňujú body označené GFS vlajkami.
Predpokladajme, že úloha je nastavená na uchovávanie 7 bodov a vytváranie týždenného GFS bodu v pondelok. V takom prípade každý pondelok úloha naozaj vytvorí plnú zálohu a označí ju ako GFS. Retenčné obdobie sa aplikuje, keď po odstránení incrementov z najstaršej časti klesne počet zostávajúcich incrementov pod 7. Takto to vyzerá na schéme:
Takže do konca druhého týždňa je v reťazci dokopy 14 bodov. Počas druhého týždňa úloha vytvorila 7 bodov. Keby to bola jednoduchá úloha, retenčné obdobie by už bolo aplikované. Ale toto je BCJ s GFS retenčným obdobím, preto GFS body nepočíta, a teda ich je len 6. To znamená, že retenčné obdobie ešte nemôžeme aplikovať. V treťom týždni vytvárame ďalšiu plnú zálohu s GFS vlajkou. 15 bodov, ale tú opäť nepočíta. A nakoniec, v utorok tretieho týždňa vytvárame increment. Teraz, ak odstránime incrementy reťazca prvého týždňa, celkový počet incrementov splní stanovené retenčné obdobie.
Ako už bolo spomenuté vyššie, pri tejto metóde je veľmi dôležité, aby sa plné zálohy vytvárali pravidelne. Povedzme, že ak nastavíte základné uchovávanie na 7 dní, ale iba 1 ročný bod, nie je ťažké si predstaviť, že sa hromadia inkrementy oveľa, oveľa viac ako 7. V takýchto prípadoch je lepšie použiť syntetickú metódu vytvárania GFS.
Opäť “Odstrániť odstránené položky”
Táto možnosť je tiež prítomná aj pre BCJ:
Logika tejto možnosti je tu rovnaká ako pri bežných úlohách zálohovania – ak sa stroj nezpracováva uvedený počet dní, jeho údaje sú vymazané z reťazca. Avšak užitočnosť tejto možnosti je pre BCJ objektívne vyššia, a tu je dôvod.
V bežnom režime BCJ funguje v nekonečne inkrementálnom režime, takže ak je stroj niekedy odstránený zo zadania, uchovávanie postupne odstráni všetky body obnovenia, až kým nezostane iba jeden – v VBK. Teraz si predstavme, že úloha je ešte nastavená na vytváranie syntetických GFS bodov. Keď príde čas, úloha by mala vytvoriť GFS pre všetky stroje v reťazci. Ak pre nejaký stroj nie sú žiadne nové body – nuž, budeme musieť použiť ten, ktorý je. A takto každý raz. Nakoniec môže vzniknúť taká situácia:
Venujte pozornosť sekcii Súbory: máme základný VBK a 2 týždenné GFS body. A teraz pozrite na sekciu Body obnovenia – v skutočnosti tieto súbory obsahujú jeden a ten istý obraz stroja. Samozrejme, nemá zmysel mať také GFS body, len zaberajú miesto.
Takáto situácia je možná len pri používaní syntetického GFS. Aby sa tomu predišlo, použite možnosť “Odstrániť odstránené položky”. Len nezabudnite nastaviť ju na adekvátne množstvo dní. Podpora technológie videla prípady, keď bola možnosť nastavená na menší počet dní ako interval synchronizácie – BCJ sa začala rozčulovať a odstraňovať body, aniž by ich stihla vytvoriť.
Vezmite tiež na vedomie, že táto možnosť neovplyvňuje už vytvorené GFS body. Ak chcete vyčistiť archívy, musíte to urobiť ručne – kliknutím pravým tlačidlom myši na stroj a výberom “Odstrániť z disku” (v objavenej ponuke nezabudnite zaškrtnúť políčko “Odstrániť GFS plnú zálohu”):
Novinka v.10 – okamžitá kópia (immediate copy)
Po pochopení „klasickej“ funkcionality prejdeme k novému. Novinka je jedna, ale veľmi dôležitá. Je to nový režim práce.
Tu nie je pojem „interval synchronizácie“, úloha bude neustále sledovať, či sa objavili nové body a kopírovať ich všetky, nech je ich akokoľvek. Ale úloha zostáva inkrementálna, teda aj keď hlavná úloha vytvára VBK alebo VRB, tieto body budú skopírované ako VIB. Inak v tomto režime nie sú žiadne prekvapenia – ako štandardná, tak aj GFS retenčná zóna fungujú podľa pravidiel opísaných vyššie (avšak tu je dostupná iba syntetická GFS).
Disky sa točia. Charakteristiky repozitárov s rotáciou diskov (rotated drives)
Stála hrozba vírusov zašifrovateľov urobila z bezpečnostného štandardu mať kópiu údajov na nosiči, kam vírus nemôže preniknúť. Jednou z možností je použitie repozitárov s rotáciou diskov, kde sa disky používajú striedavo: zatiaľ čo jeden disk je pripojený a dostupný na zápis, ostatné sú uložené na bezpečnom mieste.
Aby sa B&R naučilo pracovať s takými repozitármi, je potrebné v nastaveniach repozitára, na kroku Repozitár, kliknúť na tlačidlo Rozšírené a vybrať príslušnú možnosť:
Po tomto VBR čaká, že existujúci reťazec sa občas stratí z repozitára, čo znamená rotáciu disku. V závislosti od typu repozitára a druhu úlohy sa B&R bude správať rôzne. Môže to ilustrovať nasledujúca tabuľka:
Preskúmajme každú možnosť.
Štandardná úloha a Windows repozitár
Takže máme úlohu, ktorá uchováva reťazce na prvom disku. Pri rotácii sa vytvorený reťazec fakticky stratí a úloha nejako musí toto stratu prežiť. Útechu nachádza vo vytvorení úplného zálohovania. Týmto spôsobom každá rotácia znamená úplné zálohovanie. Ale čo sa deje s bodmi na odpojenom disku? Tieto sa pamätajú a zohľadňujú pri prepočte retenčných zón. Takže stanovený počet bodov v úlohe je to, koľko bodov je potrebné uchovávať na všetkých diskoch. Uveďme príklad:
Úloha pracuje v nekonečne inkrementálnom režime a je nastavená tak, aby uchovávala 3 body obnovenia. Ale máme tu aj druhý disk a raz za týždeň vykonávame rotáciu (diskov môže byť viac, to nemení podstatu).
V prvom týždni bude úlohou vytvoriť body na prvom disku a zlúčiť zbytočné. Celkový počet bodov teda bude tri:
Potom pripojíme druhý disk. Pri spustení B&R si všimne, že disk sa zmenil. Reťazec na prvom disku zmizne z rozhrania, ale informácie o ňom zostanú v databáze. Teraz úloha bude uchovávať 3 body na druhom disku. Celková situácia bude teda nasledovná:
Nakoniec opäť pripojíme prvý disk. Pred vytvorením nového bodu úloha skontroluje, čo je s retenčným mechanizmom. A retenčný mechanizmus, pripomínam, je nastavený na uchovávanie 3 bodov. Medzitým máme 3 body na disku 2 (ale ten je odpojený a uchovávaný na bezpečnom mieste, ku ktorému B&R nemôže mať prístup) a 3 body na disku 1 (a tento je pripojený). Znamená to, že môžeme bez obáv odstrániť 3 body z disku 1, pretože prekračujú retenčný limit. Po tom úloha opäť vytvorí kompletný zálohovací bod a naša reťaz začína vyzerať takto:
Ak je retenčný mechanizmus nastavený na uchovávanie dní namiesto počtu bodov, logika sa nemení. Okrem toho GFS retenčný mechanizmus sa pri používaní repozitárov s rotáciou diskov vôbec nepodporuje.
Obvyklá úloha a Linux repozitár sieťové úložisko
Takáto možnosť je tiež možná, ale vo všeobecnosti sa neodporúča kvôli uvaleným obmedzeniam. Pri rotácii disku a zmiznutí reťazca bude úloha reagovať rovnako – vytvorením kompletného zálohovania. Obmedzenie sa však týka orezaného mechanizmu retenčného limitu.
Tu pri rotácii sa celá reťaz na odpojenom disku jednoducho odstráni z databázy B&R. Všimnite si – z databázy, samotné súbory zostanú na disku. Môžu sa importovať a použiť na obnovenie, ale nie je ťažké uhádnuť, že skôr či neskôr také zabudnuté reťazce zaplnia celý repozitár.
Riešenie spočíva v pridaní DWORD ForceDeleteBackupFiles, ako je uvedené na tejto stránke: . Po tomto začne úloha jednoducho odstraňovať všetok obsah priečinka úlohy alebo priečinka repozitára (v závislosti od hodnoty) pri každej rotácii.
Avšak toto nie je elegantná retenčná metóda, ale presne čistenie celého obsahu. Bohužiaľ, technickej podpore sa stretli s prípadmi, keď bol ako repozitár uvedený jednoducho koreňový adresár disku, kde okrem záloh ležali aj ďalšie údaje. Všetko to bolo zničené pri rotácii.
Okrem toho, keď je aktivovaný ForceDeleteBackupFiles, funguje to pre všetky typy úložísk, teda aj úložiská na Windows prestanú aplikovať retention a začnú mazať obsah. Inými slovami, lokálny disk na Windows je najlepšou voľbou pre takýto systém uchovávania záloh.
Backup copy a Windows úložište
S BCJ je to ešte zaujímavejšie. Nielen že tu je plnohodnotný retention, ale tu sa nevyžaduje robiť plnú zálohu pri každej zmene disku! Funguje to takto:
Najprv B&R začne vytvárať body na prvom disku. Povedzme, že sme nastavili retention na 3 body. Úloha bude pracovať v nekonečne inkrementálnom režime a zlúči všetko zbytočné (pripomínam, GFS retention v tomto prípade nie je podporované).
Potom pripojíme druhý disk. Keďže na ňom ešte nie je reťazec, vytvoríme plnú zálohu, po ktorej sa nám objaví druhý reťazec z troch bodov:
Nakoniec príde čas znovu pripojiť prvý disk. A tu začína kúzlo, pretože úloha nevytvorí plnú zálohu, ale namiesto toho jednoducho pokračuje v inkrementálnom reťazci:
Po tomto bude na každom disku existovať svoj nezávislý reťazec. Preto retention tu znamená nie počet bodov na všetkých diskoch, ale počet bodov na každom disku osobitne.
Backup copy a Linux úložište sieťového úložiska
A opäť, celá elegancia sa stratí, ak úložisko nie je na lokálnom disku Windows. Tento scenár funguje podobne ako ten, ktorý sme zvažovali vyššie s jednoduchou úlohou. Pri každej rotácii BCJ bude vytvárať plnú zálohu a existujúce body budú zabudnuté. Aby ste nezostali bez voľného miesta, musíte použiť DWORD ForceDeleteBackupFiles.
Záver
Takže, v dôsledku tohto dlhého textu sme preskúmali dva typy úloh. Samozrejme, úloh je omnoho viac, ale nie je možné ich všetky preskúmať v rámci jedného článku. Ak po prečítaní máte nejaké otázky, napíšte ich do komentárov, rád odpoviem osobne.
Zdroj: habr.com
