Ahoj čtenáři našeho blogu! Částečně už se známe - moje anglicky psané příspěvky se zde objevily v překladu mého drahého kolegy . Tentokrát jsem se rozhodl oslovit přímo rusky mluvící publikum.
Pro svůj debut jsem chtěl najít téma, které by bylo zajímavé pro co nejširší publikum a vyžadovalo by podrobné zvážení. Daniel Defoe tvrdil, že smrt a daně čekají na každého člověka. Za sebe mohu říci, že každý technik podpory čeká na otázky týkající se zásad pro ukládání bodů obnovení (nebo, jednodušeji řečeno, uchovávání). Začal jsem vysvětlovat, jak retence funguje před 4 lety jako junior inženýr úrovně XNUMX, a pokračuji ve vysvětlování nyní jako vedoucí španělsky a italsky mluvícího týmu. Jsem si jist, že na stejné otázky pravidelně odpovídají i moji kolegové z druhého a dokonce i třetího stupně podpory.
V tomto světle jsem chtěl napsat závěrečný, co nejpodrobnější příspěvek, ke kterému by se rusky mluvící uživatelé mohli znovu a znovu vracet jako referenci. Nastal správný okamžik – nedávno vydaná desetiletá verze přidala k základní funkcionalitě nové funkce, které se léta nezměnily. Můj příspěvek je zaměřen primárně na tuto verzi - ačkoli většina toho, co je napsáno, platí pro předchozí verze, některé popisované funkcionality tam prostě nenajdete. Nakonec, když se podívám trochu do budoucnosti, řeknu, že v příští verzi se očekávají nějaké změny, ale o tom vám povíme, až přijde čas. Pojďme tedy začít.
Zálohovací úlohy
Nejprve se podívejme na část, která se ve verzi 10 nezměnila. Zásadu uchovávání určuje několik parametrů. Otevřeme okno pro vytvoření nového úkolu a přejdeme na záložku Úložiště. Zde uvidíme parametr, který určuje požadovaný počet bodů obnovení:
To je však pouze část rovnice. Skutečný počet bodů je také určen režimem zálohování nastaveným pro úlohu. Chcete-li tuto možnost vybrat, klikněte na stejné kartě na tlačítko Upřesnit. Otevře se nové okno s mnoha možnostmi. Pojďme je očíslovat a zvážit je jeden po druhém:
Pokud je povolena pouze volba 1, bude úloha probíhat v režimu „nekonečně přírůstkové“ (vždy přírůstkové dopředu). Zde nejsou žádné potíže - úloha uloží nastavený počet bodů obnovení od plné zálohy (soubor s příponou VBK) až po poslední přírůstek (soubor s příponou VIB). Když počet bodů překročí nastavenou hodnotu, nejstarší přírůstek bude sloučen s plnou zálohou. Jinými slovy, pokud je úloha nastavena na ukládání 3 bodů, pak ihned po další relaci budou v úložišti 4 body, po kterých bude plná záloha sloučena s nejstarším přírůstkem a celkový počet bodů se vrátí na 3.
Mimořádně jednoduché je také uchování pro „reverzní inkrementální“ (reverzní inkrementální) režim (volba 2). Protože v tomto případě bude nejnovějším bodem úplná záloha, po níž bude následovat řetězec tzv. rollbacků (souborů s příponou VRB), pro uplatnění retence stačí nejstarší rollback jednoduše smazat. Situace bude stejná: ihned po sezení překročí počet bodů nastavenou hodnotu o 1, poté se vrátí na požadovanou hodnotu.
Všimněte si, že s reverzním přírůstkovým režimem můžete také povolit pravidelné úplné zálohování (možnost 4), ale to nemění podstatu. Ano, v řetězci se objeví úplné body obnovení, ale stále budeme pouze mazat nejstarší body jeden po druhém.
Konečně se dostáváme k zajímavé části. Pokud povolíte přírůstkové zálohování, ale také povolíte možnosti 3 nebo 4 (nebo obě současně), úloha začne vytvářet pravidelné plné zálohy pomocí „aktivní“ nebo syntetické metody. Způsob vytvoření plné zálohy není důležitý – bude obsahovat stejná data a přírůstkový řetězec bude rozdělen na „podřetězce“. Tato metoda se nazývá dopředná přírůstková a je to právě on, kdo způsobuje významnou část dotazů našich zákazníků.
Zachování se zde aplikuje odstraněním nejstarší části řetězce (z plné zálohy na přírůstek). Zároveň nesmažeme pouze dutou zálohu nebo jen část přírůstků. Celý "podřetězec" se odstraní úplně najednou. Mění se i význam nastavení počtu bodů - pokud se v jiných metodách jedná o maximální přípustný počet, po jehož překročení je nutné uplatnit retenci, tak zde toto nastavení určuje minimální počet. Jinými slovy, po smazání nejstaršího „podřetězce“ by počet bodů ve zbývající části neměl klesnout pod toto minimum.
Pokusím se tento koncept znázornit graficky. Řekněme, že retence je nastavena na 3 body, úloha běží každý den s plnou zálohou v pondělí. V tomto případě bude uchování uplatněno, když celkový počet bodů dosáhne 10:
Proč už 10, když dali 3? V pondělí byla vytvořena plná záloha. Od úterý do neděle přibývalo pracovních míst. Příští pondělí se konečně opět vytvoří plná záloha a teprve při vytvoření 2 přírůstků může být konečně smazána celá stará část řetězce, protože zbývající počet bodů neklesne pod nastavené 3.
Pokud je myšlenka jasná, pak vám doporučuji zkusit si vypočítat retenci sami. Vezměme si následující podmínky: úloha se poprvé spustí ve čtvrtek (samozřejmě se vytvoří plná záloha). Úloha je nastavena na vytvoření úplné zálohy ve středu a neděli a uložení 8 bodů obnovení. Kdy bude retence použita poprvé?
K zodpovězení této otázky doporučuji vzít si list papíru, nakreslit si ho podle dnů v týdnu a zapsat si, který bod je každý den vytvořen. Odpověď bude zřejmá
odpověď
Upřesnění: Abychom odpověděli, stačí si položit otázku „kdy bude retence uplatněna“? Odpověď je, když můžeme odstranit první 3 body (VBK, VIB, VIB) a zbytek řetězce neklesne pod požadovaných 8 bodů. Je jasné, že se nám to podaří, až budeme mít celkem 11 bodů, tedy v neděli druhého týdne.
Někteří čtenáři mohou namítnout: „proč to všechno, pokud existuje ? Bezesporu je to velmi užitečný nástroj a v některých případech bych ho použil, ale má také omezení. Za prvé vám neumožňuje specifikovat počáteční podmínky a v mnoha případech je otázka přesně „máme takový řetězec, co se stane, když změníme takové a takové nastavení?“. Za druhé, nástroj stále poněkud postrádá viditelnost. Ukazováním stránky RPS klientům jsem nenašel pochopení, ale po vymalování jako v příkladu (i pomocí stejného Malování) se den za dnem vše vyjasnilo.
Nakonec jsme neuvažovali o možnosti „Transformovat předchozí řetězce záloh na vrácení zpět“ (označené číslem 5). Tato možnost někdy mate zákazníky, kteří si ji aktivují „za chodu“ a chtějí povolit jednoduché syntetické zálohování. Mezitím tato možnost aktivuje velmi speciální režim zálohování. Aniž bych zacházel do podrobností, hned řeknu, že v této fázi vývoje produktu je „Transformace předchozích řetězců zálohování na vrácení zpět“ zastaralou možností a nenapadá mě jediný scénář, kdy by se měla použít. Jeho hodnota je tak pochybná, že už nějakou dobu sám Anton Gostev volal přes fórum a žádal ho, aby mu poslal příklady jeho užitečného použití (pokud nějaké máte, napište do komentářů, velmi mě to zajímá). Pokud žádné nejsou (myslím, že budou), pak bude tato možnost v budoucích verzích odstraněna.
Úloha bude vytvářet přírůstky (VIB) až do dne, kdy je naplánována syntetická plná záloha. V tento den je skutečně vytvořen VBK, ale všechny body před tímto VBK jsou transformovány do rollbacků (VRB). Poté bude úloha pokračovat ve vytváření přírůstků do plné zálohy až do další syntetické zálohy. V důsledku toho se v řetězci vytvoří výbušná směs souborů VBK, VBR a VIB. Retension se aplikuje velmi jednoduše – odstraněním posledního VBR:
Problémy
Kromě skutečného pochopení toho, jak to funguje, většina problémů, které vznikají při použití přírůstkového režimu, je obvykle spojena s úplnou zálohou. Pro tento režim je nutná pravidelná plná záloha, jinak bude úložiště sbírat body, dokud se nepřeteče.
Například úplná záloha může být vytvořena příliš zřídka. Řekněme, že úloha je nastavena na uložení 10 bodů a jednou za měsíc se vytvoří plná záloha. Je jasné, že skutečný počet bodů zde bude mnohem větší než stanovený. Nebo je úloha obecně nastavena tak, aby pracovala v nekonečném přírůstkovém režimu a uložila 50 bodů. Pak někdo omylem vytvořil plnou zálohu. To je vše, od nynějška bude úkol čekat, až plný bod nashromáždí 49 přírůstků, poté použije retenci a vrátí se do režimu nekonečného plného.
V ostatních případech je plná záloha nastavena na pravidelné vytváření, ale z nějakého důvodu se tak nestane. Zde uvedu nejoblíbenější důvod. Někteří zákazníci dávají přednost použití možnosti plánování „spustit po“ a nastavují úlohy tak, aby se spouštěly v řetězci. Vezměme si tento příklad: existují 3 úlohy, které běží každý den a vytvářejí plnou zálohu v neděli. První úkol začíná ve 22.30, ostatní jsou spuštěny v řetězci. Přírůstková záloha trvá 10 minut, a proto do 23.00:22.30 všechny úlohy dokončí svou práci. Ale úplná záloha trvá hodinu, takže v neděli se stane následující: první úloha běží od 23.30:23.30 do 00.30:XNUMX. Další je od XNUMX:XNUMX do XNUMX:XNUMX. Ale třetí úkol je spuštěn v pondělí. Plná záloha je nakonfigurována na neděli, takže v tomto případě to prostě nebude. Úloha počká na úplnou zálohu, aby se uchování uplatnilo. Při používání možnosti „spustit po“ buďte opatrní nebo ji nepoužívejte vůbec – nastavte úlohy tak, aby se spouštěly ve stejnou dobu, a nechte plánovač zdrojů, aby svou práci provedl.
Obtížná možnost „Odstranit smazané položky“
Procházením nastavení úlohy Úložiště - Pokročilé - Údržba můžete narazit na možnost „odebrat data smazaných položek po“, počítáno ve dnech.
Někteří klienti očekávají, že to bude retence. Ve skutečnosti se jedná o zcela samostatnou možnost, jejíž nepochopení může vést k neočekávaným následkům. Nejprve však musím vysvětlit, jak B&R reaguje na situace, kdy se během seance úspěšně zálohuje jen několik strojů.
Představte si tento scénář: nekonečně přírůstková úloha nakonfigurovaná pro uložení 6 bodů. V úloze jsou 2 stroje, jeden vždy úspěšně zálohoval, druhý občas dával chyby. V důsledku toho se v sedmém bodě vyvinula tato situace:
Je čas uplatnit retenci, ale jeden stroj má 7 bodů a druhý jen 4. Bude zde retence uplatněna? Odpověď je ano, bude. Pokud byl zálohován alespoň jeden objekt, B&R považuje bod za vytvořený.
Podobná situace může nastat, pokud některý stroj během určité relace prostě nebyl zahrnut do úlohy. K tomu dochází například tehdy, když jsou stroje přidány do úlohy nikoli jednotlivě, ale jako součást kontejnerů (složek, úložišť) a některý stroj dočasně migruje do jiného kontejneru. Úloha bude poté považována za úspěšnou, ale ve statistikách najdete zprávu, která vám říká, abyste věnovali pozornost tomu, že takový a ten stroj již není zpracováván.
Co se stane, když tomu nebudete věnovat pozornost? V případě režimů s nekonečným přírůstkem nebo zpětným přírůstkem se počet bodů obnovení „problémového“ počítače s každou relací sníží, dokud nedosáhne 1 uloženého ve VBK. Jinými slovy, i když stroj nebude po dlouhou dobu zálohován, jeden bod obnovení stále zůstane. To neplatí, pokud jsou povoleny pravidelné plné zálohy. Pokud jsou signály z B&R ignorovány, může být nakonec odstraněn i poslední bod spolu se starou částí řetězce.
Po pochopení těchto podrobností můžeme konečně zvážit možnost „Odstranit data odstraněných položek po“. Pokud tento stroj nebude zálohován po dobu X dní, odstraní všechny body pro konkrétní počítač. Upozorňujeme, že toto nastavení nereaguje na chyby (vyzkoušeno - nefungovalo). Nemělo by dojít ani k pokusu o zálohování stroje. Zdá se, že tato možnost je užitečná a měla by být vždy povolena. Pokud správce odstranil stroj z úlohy, je logické po chvíli vyčistit řetězec zbytečných dat. Ladění však vyžaduje disciplínu a péči.
Uvedu příklad z praxe: k úkolu bylo přidáno několik kontejnerů, jejichž složení bylo značně dynamické. Kvůli nedostatku paměti RAM zaznamenal server B&R problémy, které zůstaly bez povšimnutí. Úloha se spustila a pokusila se provést zálohu strojů, kromě jednoho, který v té době v kontejneru nebyl. Protože mnoho počítačů generovalo chyby, musí B&R ve výchozím nastavení provést 3 další pokusy o zálohování „problémových“ strojů. Kvůli neustálým problémům s RAM se tyto pokusy vlekly několik dní. Nedošlo k žádnému druhému pokusu o zálohování chybějícího virtuálního počítače (absence virtuálního počítače není chyba). Výsledkem bylo, že během jednoho z opakovaných pokusů byla splněna podmínka „Odebrat smazané položky“ a všechny body stroje byly smazány.
Při této příležitosti mohu říci následující: pokud máte nastavená upozornění na výsledky úkolů a ještě lépe se využívá integrace s Veeam ONE, tak se vám to s největší pravděpodobností nestane. Pokud se jednou týdně podíváte na server B&R a zkontrolujete, zda vše funguje, je lepší odmítnout možnosti, které by mohly potenciálně vést ke smazání záloh.
Co je nového ve verzi 10
To, o čem jsme mluvili dříve, existuje v B&R pro mnoho verzí. Po pochopení těchto principů práce se nyní podívejme, co bylo přidáno do jubilejní „top ten“.
Denní retence
Výše jsme zvažovali „klasickou“ politiku úložiště na základě počtu bodů. Alternativním přístupem je nastavení „dnů“ místo „bodů obnovení“ ve stejné nabídce.
Myšlenka je jasná už z názvu – retence uloží nastavený počet dní, na počtu bodů v jednotlivých dnech nezáleží. Přitom pamatujte na následující:
- Aktuální den se při výpočtu zádržného nebere v úvahu
- Počítají se i dny, kdy úkol vůbec nefungoval. To je třeba mít na paměti, abyste náhodou nepřišli o body těch úkolů, které fungují nepravidelně.
- Bod obnovení se počítá ode dne, kdy byl vytvořen (tj. pokud úloha začala v pondělí a skončila v úterý, pak se jedná o bod od pondělí)
Jinak zásady pro aplikaci uchovávání podle úloh určuje i zvolená metoda zálohování. Zkusme další výpočetní úlohu pomocí stejné inkrementální metody. Řekněme, že uchovávání je nastaveno na 8 dní, úloha se spouští každých 6 hodin s plnou zálohou ve středu. V tomto případě úkol v neděli nefunguje. Práce běží poprvé v pondělí. Kdy bude retence uplatněna?
odpověď
Jako obvykle je nejlepší nakreslit znak. Dovolím si úkol zjednodušit a nebudu losovat všechny vytvořené body za každý den, protože zde na počtu bodů za den nezáleží. Pro nás je důležité pouze to, že první pondělí a středu bude první bod plná záloha, ostatní dny úkol jednoduše vytvoří 4 přírůstkové body.
Sami rozumíme, že uchování bude aplikováno odstraněním pondělní plné zálohy a jejího přírůstku. kdy se to stane? Když zbytek řetězce bude obsahovat 8 dní. Nepočítáme přitom aktuální den, ale neděli naopak počítáme. Takže odpověď je čtvrtek druhého týdne.
Archivace GFS pro běžné úlohy
Před verzí 10 byla metoda ukládání Grandfather-Father-Son (GFS) dostupná pouze pro úlohy zálohování a kopírování na pásku. Nyní je k dispozici i pro běžné zálohování.
I když to nesouvisí s aktuálním tématem, nemohu říci, že nová funkcionalita neznamená odklon od strategie 3-2-1. Přítomnost archivních bodů v hlavním úložišti nijak neovlivňuje jeho spolehlivost. Rozumí se, že GFS bude použito ve spojení s škálovatelným úložištěm k odeslání těchto bodů do S3 a podobných úložišť. Pokud jej nepoužíváte, je lepší nadále ukládat primární a archivní body do různých úložišť.
Nyní se podíváme na principy tvorby GFS bodů. V nastavení úlohy se v kroku Úložiště objevilo speciální tlačítko, které vyvolá následující nabídku:
Podstatu GFS lze zredukovat na několik bodů (všimněte si, že GFS funguje jinak v jiných typech úloh, ale o tom později):
- Úloha nevytváří samostatnou plnou zálohu pod bodem GFS. Místo toho bude použita nejvhodnější dostupná plná záloha. Úloha proto musí běžet v přírůstkovém režimu s periodickou plnou zálohou, nebo musí být plná záloha vytvořena ručně uživatelem.
- Pokud je povoleno pouze jedno období (například týdenní), pak na začátku období GFS úloha jednoduše začne čekat na plnou zálohu a jako GFS označí první vhodné.
Příklad: Úloha je nakonfigurována k ukládání týdenního GFS pomocí středeční zálohy. Úloha se spouští každý den, ale plná záloha je naplánována na pátek. V tomto případě začne období GFS ve středu a úloha začne čekat na vhodný bod. Objeví se v pátek a bude označena vlajkou GFS.
- Pokud je povoleno více období najednou (například týdenní a měsíční), pak B&R použije metodu, která umožňuje použít stejný bod jako GFS pro více intervalů (pro úsporu místa). Vlajky budou přidělovány postupně, počínaje nejmladším.
Příklad: týdenní GFS je nastaveno na středu a měsíční GFS je nastaveno na poslední týden v měsíci. Úloha běží každý den a vytváří plné zálohy v pondělí a pátek.
Pro zjednodušení začněme počítat od předposledního týdne v měsíci. Tento týden bude plná záloha vytvořena v pondělí, ale bude ignorována, protože týdenní interval GFS začíná ve středu. Ale páteční plná záloha je pro bod GFS zcela vhodná. Tento systém je nám již známý.
Nyní zvažte, co se stane v posledním týdnu měsíce. Měsíční interval GFS začne v pondělí, ale pondělní VBK nebude označen jako GFS, protože úloha se snaží označit jeden VBK jako měsíční i týdenní bod GFS. Vyhledávání přitom začíná týdenním, tedy z definice se může stát i měsíčním.
Pokud jsou však povoleny pouze týdenní a roční intervaly, budou fungovat nezávisle na sobě a mohou označit 2 samostatné VBK jako odpovídající intervaly GFS.
Úlohy zálohování
Další typ úkolu, který často vyžaduje objasnění v práci. Pro začátek si rozeberme „klasický“ způsob práce, bez inovací v.10
Jednoduchá metoda retence
Ve výchozím nastavení se takové úlohy spouštějí v režimu nekonečného přírůstku. Vytváření bodů je určeno dvěma parametry - intervalem kopírování a požadovaným počtem bodů obnovení (zde nedochází k uchování ve dnech). Interval kopírování se nastavuje na první kartě Úloha při vytváření úlohy:
Počet bodů se určuje o něco dále na záložce Cíl
Úloha vytvoří 1 nový bod na interval (nezáleží na tom, kolik bodů bylo vytvořeno pro virtuální počítač původními úlohami). Na konci intervalu je nový bod finalizován a v případě potřeby je aplikována retence zřetězením VBK a nejstaršího přírůstku. Tento mechanismus je nám již známý.
Retenční metoda pomocí GFS
BCJ může také ukládat archivované body. Toto se konfiguruje na stejné kartě Cíl, těsně pod nastavením počtu bodů obnovení:
GFS body lze vytvářet dvěma způsoby - synteticky, pomocí dat na sekundárním úložišti, nebo simulací plné zálohy a načtením všech dat z primárního úložiště (aktivuje se volbou označenou číslem 3). Retence v obou případech bude velmi odlišná, proto je zvážíme samostatně.
Syntetický GFS
V tomto případě není bod GFS vytvořen přesně ve stanovený den. Místo toho bude bod GFS vytvořen, když se VIB dne, kdy bylo naplánováno vytvoření bodu GFS, sloučeno s plnou zálohou. To někdy způsobuje nedorozumění, protože čas plyne, ale stále neexistuje žádný bod GFS. A jen mocný šaman z technické podpory dokáže předpovědět, jaký den se tečka ještě objeví. Ve skutečnosti magie není potřeba – stačí se podívat na nastavený počet bodů a interval synchronizace (kolik bodů se každý den vytvoří). Zkuste si to spočítat sami na tomto příkladu: úloha je nastavena na uložení 7 bodů, interval synchronizace je 12 hodin (tedy 2 body za den). V tuto chvíli je v řetězci již 7 bodů, dnes je pondělí a na tento den je naplánováno vytvoření bodu GFS. Který den bude vytvořen?
odpověď
Zde je lepší popsat, jak se bude řetěz měnit v dynamice, ve dne:
V pondělí je tedy poslední přírůstek v řetězci označen jako GFS, ale k žádným dalším viditelným změnám nedochází. Každý den úkol vytvoří 2 nové body a udržení posouvá řetězec neúprosně dopředu. Konečně ve čtvrtek je čas použít retenci na stejný přírůstek. Tato relace bude trvat déle než obvykle – úloha totiž „vytáhne“ potřebné bloky z řetězce a vytvoří nový plný bod. Od této chvíle bude v řetězci 8 bodů - 7 v hlavním řetězci + GFS.
Vytváření bodů GFS pomocí možnosti „Přečíst celý bod“.
Výše jsem řekl, že BCJ pracuje v nekonečně inkrementálním režimu. Nyní rozebereme jedinou výjimku z tohoto pravidla. Pokud povolíte možnost „Přečíst celý bod“, bude bod GFS vytvořen přesně v naplánovaný den. Samotná úloha bude fungovat v přírůstkovém režimu s pravidelnými plnými zálohami, o kterých jsme hovořili výše. Retence se uplatní i odstraněním nejstarší části řetězu. V tomto případě však budou odstraněny pouze přírůstky a plná záloha bude ponechána jako bod GFS. Body označené příznaky GFS se tedy při výpočtu retence neberou v úvahu.
Předpokládejme, že úloha je nastavena na uložení 7 bodů a vytvoření týdenního bodu GFS v pondělí. V tomto případě každé pondělí úloha skutečně vytvoří plnou zálohu a označí ji jako GFS. Zachování bude použito, když po smazání přírůstků z nejstarší části počet zbývajících přírůstků neklesne pod 7. Takto to vypadá na diagramu:
Do konce druhého týdne je tedy v řetězci celkem 14 bodů. Během druhého týdne úkol vytvořil 7 bodů. Pokud by se jednalo o jednoduchý úkol, retence by již byla použita. Jedná se ale o BCJ s retencí GFS, takže nepočítáme body GFS, což znamená, že jich je pouze 6. To znamená, že retenci stále nemůžeme uplatnit. Ve třetím týdnu vytvoříme další plnou zálohu s příznakem GFS. 15 bodů, ale tento opět nepočítáme. A nakonec v úterý třetího týdne vytvoříme přírůstek. Nyní, pokud odstraníme přírůstky řetězce prvního týdne, celkový počet přírůstků vyhoví nastavenému zachování.
Jak je uvedeno výše, u této metody je velmi důležité, aby byly pravidelně vytvářeny plné zálohy. Pokud například nastavíte hlavní retenci na 7 dní, ale pouze 1 roční bod, lze si snadno představit, že přírůstky nashromáždí mnohem, mnohem více než 7. V takových případech je lepší použít syntetickou metodu vytváření GFS.
A znovu „Odstranit smazané položky“
Tato možnost je k dispozici také pro BCJ:
Logika této možnosti je zde stejná jako u běžných úloh zálohování – pokud není stroj zpracován po zadaný počet dní, jsou jeho data z řetězce vymazána. Pro BCJ je však tato možnost objektivně užitečnější a zde je důvod.
V normálním režimu BCJ pracuje v infinite-inkrementálním režimu, takže pokud je v určitém okamžiku stroj odstraněn z úlohy, pak retence postupně smaže všechny body obnovy, dokud nezbude pouze jeden - ve VBK. Nyní si představme, že úloha je nakonfigurována také pro vytváření syntetických bodů GFS. Až přijde čas, bude potřeba vytvořit GFS pro všechny stroje v řetězci. Pokud některý stroj nemá vůbec žádné nové body - no, musíte použít ten, který je. A tak pokaždé. V důsledku toho může nastat následující situace:
Věnujte pozornost sekci Soubory: máme hlavní body VBK a 2 týdenní body GFS. A nyní k části Body obnovení – ve skutečnosti tyto soubory obsahují stejný obraz stroje. Takové body GFS přirozeně nemají smysl, pouze zabírají místo.
Tato situace je možná pouze při použití syntetického GFS. Chcete-li tomu zabránit, použijte možnost „Odstranit smazané položky“. Nezapomeňte jej nastavit na dostatečný počet dní. Technická podpora zaznamenala případy, kdy byla volba nastavena na méně než počet dní, než je interval synchronizace – BCJ začalo řádit a mazat body dříve, než je stačilo vytvořit.
Všimněte si také, že tato možnost neovlivňuje existující body GFS. Pokud chcete vyčistit archivy, musíte to udělat ručně - kliknutím pravým tlačítkem myši na stroj a výběrem "Odstranit z disku" (v okně, které se zobrazí, nezapomeňte zaškrtnout políčko "Odstranit plnou zálohu GFS"). :
Inovace v.10 – okamžitá kopie (okamžitá kopie)
Když už jsme se vypořádali s „klasickou“ funkcionalitou, přejděme k té nové. Inovace je jedna, ale velmi důležitá. Toto je nový provozní režim.
Neexistuje nic jako „synchronizační interval“, úloha bude neustále sledovat, zda se objevily nové body a kopírovat je všechny, bez ohledu na to, kolik jich je. Úloha však zůstává přírůstková, což znamená, že i když hlavní zakázka vytvoří VBK nebo VRB, tyto body budou zkopírovány jako VIB. Jinak se v tomto režimu nekoná žádné překvapení – standardní i GFS retence fungují podle výše popsaných pravidel (i když zde je k dispozici pouze syntetické GFS).
Disky se točí. Vlastnosti úložišť rotovaných disků
Neustálá hrozba ransomwarových virů učinila de facto bezpečnostním standardem mít kopii dat na médiu, kam se virus nedostane. Jednou z možností je použití úložišť s rotací disků, kde se disky používají postupně: zatímco jeden disk je připojen a lze do něj zapisovat, zbytek je uložen na bezpečném místě.
Chcete-li naučit B&R pracovat s takovými repozitáři, v nastavení úložiště v kroku Repozitář klikněte na tlačítko Upřesnit a vyberte příslušnou možnost:
Poté VBR počká, až periodicky existující řetězec zmizí z úložiště, což znamená rotaci disku. V závislosti na typu úložiště a typu úlohy se bude B&R chovat odlišně. Můžete to reprezentovat tabulkou takto:
Zvažme každou možnost.
Normální úloha a úložiště Windows
Máme tedy úlohu, která ukládá řetězce na první disk. Během rotace vytvořený řetězec skutečně zmizí a úkol musí tuto ztrátu nějak přežít. Útěchu nachází ve vytvoření úplné zálohy. Každé otočení tedy znamená plnou zálohu. Co se ale stane s tečkami na odpojeném disku? Jsou zapamatovány a zohledněny při výpočtu retence. Stanovený počet bodů v úloze je tedy to, kolik bodů musí zůstat na všech discích. Zde je příklad:
Úloha běží v nekonečném přírůstkovém režimu a je nakonfigurována tak, aby ukládala 3 body obnovení. Ale máme i druhý kotouč a ten střídáme jednou týdně (kotoučků může být více, to na podstatě nic nemění).
V prvním týdnu úkol vytvoří body na prvním disku a sloučí přebytečné. Celkový počet bodů tedy bude tři:
Poté připojíme druhý disk. Při spuštění si B&R všimne, že se disk změnil. Řetěz na prvním disku zmizí z rozhraní, ale informace o něm zůstanou v databázi. Úloha bude nyní obsahovat 3 tečky na druhém disku. Obecná situace bude vypadat takto:
Nakonec znovu připojíme první disk. Před vytvořením nového bodu úkol zkontroluje, co tam je s retencí. A uchovávání, připomínám, je nastaveno na uložení 3 bodů. Mezitím máme 3 body na disku 2 (ale je offline a uložený na bezpečném místě, kam se B&R nedostane) a 3 body na disku 1 (ten je ale připojený). Takže můžete bezpečně odebrat 3 body z disku 1, protože překračují retenci. Poté úloha znovu vytvoří plnou zálohu a náš řetězec začne vypadat takto:
Pokud je uchovávání nakonfigurováno tak, aby místo počtu bodů ukládalo dny, pak se logika nezmění. Uchovávání GFS také není vůbec podporováno při použití úložišť s rotací disku.
Normální úloha a síťové úložiště úložiště Linux
Tato možnost je také možná, ale obecně je méně doporučována kvůli uloženým omezením. Na rotaci disku a zmizení řetězce bude úloha reagovat stejně – vytvořením plné zálohy. Omezení je spojeno s zkráceným retenčním mechanismem.
Zde se při rotaci celý řetězec na odpojeném disku jednoduše smaže z databáze B&R. Pozor - z databáze samotné soubory zůstávají na disku. Lze je importovat a použít pro obnovu, ale není těžké uhodnout, že dříve nebo později takové zapomenuté řetězce zaplní celé úložiště.
Řešením je přidat DWORD ForceDeleteBackupFiles, jak je uvedeno na této stránce: . Poté úloha jednoduše začne mazat veškerý obsah složky úlohy nebo složky úložiště (v závislosti na hodnotě) při každém otočení.
Nejedná se však o elegantní retenci, ale spíše o očistu veškerého obsahu. Technická podpora se bohužel setkala s případy, kdy byl repozitář prostě kořenový adresář disku, kde byla kromě záloh i další data. To vše bylo zničeno při rotaci.
Navíc, když je povolena ForceDeleteBackupFiles, funguje pro všechny typy úložišť, to znamená, že i úložiště ve Windows přestanou ukládat a začnou mazat obsah. Jinými slovy, místní disk v systému Windows je nejlepší volbou pro takový systém úložiště záloh.
Záložní kopie a úložiště Windows
S BCJ jsou věci ještě zajímavější. Nejen, že dochází k plnohodnotnému uchování, ale není potřeba dělat plnou zálohu při každé výměně disku! Funguje to takto:
Nejprve B&R začne dělat tečky na prvním disku. Řekněme, že nastavíme udržení na 3 body. Úloha bude fungovat v nekonečném inkrementálním režimu a sloučí vše nadbytečné (připomínám, že retence GFS v tomto případě není podporována).
Poté připojíme druhý disk. Protože na něm ještě není žádný řetězec, vytvoříme plnou zálohu, po které máme druhý řetězec tří bodů:
Konečně je čas znovu připojit první disk. A to je místo, kde přichází kouzlo, protože úloha nevytvoří úplnou zálohu, ale místo toho bude pokračovat v přírůstkovém řetězci:
Poté bude mít ve skutečnosti každý disk svůj vlastní nezávislý řetězec. Retence zde tedy neznamená počet bodů na všech discích, ale počet bodů na každém disku zvlášť.
Záložní kopie a síťové úložiště úložiště Linux
Opět se veškerá elegance ztrácí, pokud úložiště není na místní jednotce Windows. Tento skript funguje podobně jako výše uvedený jednoduchý úkol. Při každé rotaci BCJ vytvoří plnou zálohu a stávající body budou zapomenuty. Abyste nezůstali bez volného místa, musíte použít DWORD ForceDeleteBackupFiles.
Závěr
V důsledku tak dlouhého textu jsme tedy uvažovali o dvou typech úloh. Úkolů je samozřejmě mnohem více, ale nebude možné je všechny zvážit ve formátu jednoho článku. Pokud budete mít po přečtení ještě nějaké dotazy, tak je napište do komentářů, rád odpovím osobně.
Zdroj: www.habr.com