Vítám čtenáře našeho blogu! Částečně se už známe – moje anglické příspěvky se zde objevovaly v překladu mé drahé kolegyně . Tentokrát jsem se rozhodl obrátit přímo na rusky mluvící publikum.
Pro svůj debut jsem chtěl najít téma, které by zajímalo co nejširší publikum a vyžadovalo podrobné prozkoumání. Daniel Defoe tvrdil, že každého člověka čekají smrt a daně. Za sebe mohu říct, že každého podpůrného inženýra čekají otázky o politikách uchovávání bodů obnovení (nebo jednoduše – retenci). Jak funguje retence, jsem začal vysvětlovat před 4 lety, když jsem byl juniorským inženýrem prvního stupně, a stále to vysvětluji nyní, už jako týmový lídr španělsky a italsky mluvícího týmu. Jsem si jistý, že moji kolegové druhé a dokonce i třetí úrovně podpory také pravidelně odpovídají na stejné otázky.
V tomto světle jsem chtěl napsat konečný, co nejpodrobnější příspěvek, ke kterému by se rusky mluvící uživatelé mohli vracet znovu a znovu jako k příručce. Okamžik je vhodný – nedávno vydaná jubilejní desátá verze přidala nové možnosti k základnímu funkčnímu celku, který se roky neměnil. Můj příspěvek je orientován především na tuto verzi — i když většina napsaného platí i pro předchozí verze, něco z popisovaného funkčního celku tam prostě nenajdete. Nakonec, malinko nahlédnu do budoucnosti a řeknu, že v další verzi se očekávají některé změny, ale o tom budeme mluvit, až přijde čas. Takže, pojďme na to.
Úkoly zálohování (Backup job)
Nejprve se podívejme na tu část, která se ve verzi 10 nezměnila. Politika retence je definována několika parametry. Otevřeme okno pro vytvoření nového úkolu a přejdeme na kartu Storage. Zde uvidíme parametr, který určuje požadovaný počet bodů obnovení:
To však je jen část rovnice. Skutečný počet bodů je také určen režimem zálohy nastaveným pro úkol. Pro výběr tohoto parametru je třeba kliknout na tlačítko Advanced na stejné kartě. To otevře nové okno s mnoha možnostmi. Číslujeme je a prozkoumáme po jednom:
Pokud aktivujete pouze možnost 1, úloha bude pracovat v režimu "nekonečné inkrementace" (forever forward incremental). Nebudou s tím žádné potíže – úloha si uchovává stanovený počet bodů obnovení od kompletního zálohování (soubor s příponou VBK) po poslední inkrement (soubor s příponou VIB). Jakmile počet bodů překročí stanovenou hodnotu, nejstarší inkrement bude sloučen s kompletním zálohováním. Jinými slovy, pokud je úloha nastavena na uchovávání 3 bodů, ihned po další relaci budou na úložišti 4 body, po čemž bude kompletní zálohování sloučeno s nejstarším inkrementem a celkový počet bodů se vrátí na 3.
Také je velmi jednoduché spravovat retenci pro režim "zpětné inkrementace" (reverse incremental) (možnost 2). V tomto případě bude nejnovější bod kompletním zálohováním, za kterým bude následovat řetězec takzvaných rollbacků (souborů s příponou VRB), takže pro aplikaci retence stačí jednoduše odstranit nejstarší rollback. Situace bude stejná: ihned po relaci počet bodů překročí stanovenou hodnotu o 1, po čemž se vrátí na požadovanou hodnotu.
Mějte na paměti, že s režimem zpětné inkrementace lze také aktivovat periodické kompletní zálohování (možnost 4), ale to na podstatě nic nemění. Ano, v řetězci se objeví kompletní body obnovení, ale vždy jednoduše odstraníme ty nejstarší body jeden po druhém.
Nakonec se dostáváme k zajímavé části. Pokud aktivujete inkrementální zálohování, ale navíc zapnete možnosti 3 nebo 4 (nebo obě najednou), úloha začne vytvářet periodická kompletní zálohování "aktivní" nebo syntetickou metodou. Způsob vytvoření kompletního zálohování není důležitý – bude obsahovat ta samá data, a inkrementální řetězec bude rozdělen na "podřetězce". Tento způsob se nazývá forward incremental a právě on vyvolává značnou část otázek našich zákazníků.
Retention here is applied by removing the oldest part of the chain (from a full backup to increments). In this case, we will not remove just the empty backup or just part of the increments. The entire "subchain" is deleted completely at once. The meaning of the setting for the number of points changes – if in other methods it is the maximum allowed number after which retention needs to be applied, here this setting determines the minimum number. In other words, after the oldest "subchain" is deleted, the number of points in the remaining part should not fall below this minimum.
I will try to illustrate this concept graphically. Suppose retention is set to 3 points, and the task runs every day with a full backup on Monday. Retention will be applied in this case when the total number of points reaches 10:
Why 10 when we've set 3? A full backup was created on Monday. From Tuesday to Sunday, the task created increments. Finally, the next Monday, a full backup is created again, and only when 2 increments have been created can the entire old part of the chain be deleted because the remaining number of points will not drop below the established 3.
If the idea is clear, I suggest you try to calculate retention yourself. Let’s take the following conditions: the task runs for the first time on Thursday (naturally, a full backup will be made). The task is set to create full backups on Wednesdays and Sundays, retaining 8 recovery points. When will retention be applied for the first time?
To answer this question, I recommend you take a piece of paper, draw it by the days of the week, and write down which point is created each day. The answer will become obvious.
Odpověď
Explanation: to answer, it is enough to ask yourself "when will retention be applied"? The answer is when we can delete 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, that is, on the Sunday of the second week.
Some readers may object: "why all this, if there is ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Nakonec jsme se nezabývali možností „Transformovat předchozí zálohovací řetězce na návraty“ (označenou číslem 5). Tato možnost někdy mate zákazníky, kteří ji aktivují „automaticky“, chtějí jen zahrnout syntetickou zálohu. Mezitím tato možnost aktivuje zcela zvláštní režim zálohování. Aniž bychom zacházeli do podrobností, ihned řeknu, že v tomto stádiu vývoje produktu je „Transformovat předchozí zálohovací řetězce na návraty“ zastaralá volba a nedokážu si představit ani jeden scénář, kdy by se měla používat. Její hodnota je tak pochybně malá, že nějakou dobu sám Anton Gostevi vyzýval prostřednictvím fóra, aby mu poslali příklady jejího užitečného použití (pokud nějaké máte, napište do komentářů, velmi mě to zajímá). Pokud se žádné nenajdou (myslím, že to tak bude), tak bude možnost odstraněna v dalších verzích.
Úkol bude vytvářet inkrementy (VIB) až do dne, kdy je plánována syntetická kompletní záloha. V tento den se skutečně vytváří VBK, ale všechny body před tímto VBK se transformují na návraty (VRB). Poté úkol bude pokračovat v vytváření inkrementů k plné záloze až do další syntetické zálohy. Nakonec se v řetězci vytvoří směsice z VBK, VBR a VIB souborů. Retenční pravidlo se pak aplikuje velmi jednoduše – odstraněním posledního VBR:
Problémy
Kromě samotného pochopení, jak to funguje, většina problémů, které nastanou při používání inkrementálního režimu, obvykle souvisí s úplnou zálohou. Pravidelná úplná záloha je pro tento režim nezbytná, jinak bude úložiště shromažďovat body, dokud nepřeplní.
Například, úplná záloha může být vytvářena příliš zřídka. Řekněme, že je úkol nastaven na uložení 10 bodů, zatímco úplná záloha je vytvářena jednou za měsíc. Je jasné, že skutečný počet bodů zde bude výrazně vyšší, než je nastavena hodnota. Nebo je úkol nastaven na práci v nekonečně inkrementálním režimu a uchování 50 bodů. Pak někdo náhodou vytvořil úplnou zálohu. Všechno, od nynějška úkol čeká, až plný bod shromáždí 49 inkrementů, poté aplikuje retenční pravidlo a vrátí se do nekonečně plného režimu.
Jindy se plný zálohování nastavuje na pravidelnou údržbu, ale z nějakého důvodu se to neděje. Zde popíšu nejvíce rozšířenou příčinu. Někteří klienti dávají přednost používání možnosti plánování „běžet po“ a nastavují úkoly tak, aby pracovaly ve vedlejších sekvencích. Vezměme takový příklad: existují 3 úkoly, které probíhají každý den a vytvářejí plnou zálohu v neděli. První úkol se spouští v 22:30, ostatní se spouštějí po řetězu. Inkrementální záloha trvá 10 minut, a proto do 23:00 všechny úkoly končí. Ale plná záloha trvá hodinu, a proto v neděli nastává následující: první úkol pracuje od 22:30 do 23:30. Následující od 23:30 do 00:30. A třetí úkol se už spouští v pondělí. Plná záloha je nastavena na neděli, takže v tom případě jednoduše nebude. Úkol bude čekat na plnou zálohu, aby mohl aplikovat retenci. Proto buďte opatrní při používání možnosti „běžet po“ nebo ji vůbec nepoužívejte – nastavte úkoly, aby se spouštěly ve stejnou dobu, a nechte plánovač zdrojů dělat svou práci.
Složitá možnost „Odebrat smazané položky“
Při procházení nastavení úkolu Úložiště – Pokročilé – Údržba, můžete narazit na možnost „odebrat data smazaných položek po“, měřenou v dnech.
Někteří klienti očekávají, že to je retence. Ve skutečnosti je to zcela samostatná možnost, jejíž nepochopení může vést k neočekávaným důsledkům. Nicméně nejprve je třeba vysvětlit, jak B&R reaguje na situace, kdy během sezení úspěšně zálohují pouze některé stroje.
Představme si takový scénář: nekonečně inkrementální úkol, nastavený na uchování 6 bodů. V úkolu jsou 2 stroje, jeden se vždy úspěšně zálohoval, zatímco druhý občas selhal. V důsledku toho se k sedmému bodu vytvořila taková situace:
Je čas aplikovat retenci, ale na jednom stroji je 7 bodů, zatímco na druhém pouze 4. Bude zde aplikována retence? Odpověď zní – ano, bude. Pokud byl alespoň jeden objekt zálohován, B&R považuje, že bod byl vytvořen.
Podobná situace může nastat, pokud byla nějaká mašina jednoduše vyloučena z úkolu během určité relace. K tomu dochází například, když jsou mašiny do úkolu přidávány nikoli individuálně, ale v rámci kontejnerů (složek, úložišť) a nějaká mašina dočasně migruje do jiného kontejneru. Úkol bude v takovém případě považován za úspěšný, ale ve statistikách najdete zprávu, která vás vyzývá, abyste si uvědomili, že tato mašina již není úkolem zpracovávána.
Co se stane, pokud na to nebudete brát zřetel? V případě nekonečně inkrementálního nebo obráceně inkrementálního režimu se počet bodů obnovení "problémové" mašiny bude s každou relací snižovat, dokud nedosáhne 1, uložené ve VBK. Jinými slovy, i když mašina dlouho nebude zálohována, jeden bod obnovení přesto zůstane. Situace je jiná, pokud jsou povoleny pravidelné celkové zálohy. Pokud ignorujete signály od B&R, nakonec může být poslední bod odstraněn spolu se starou částí řetězce.
Pochopením těchto detailů lze konečně zvážit možnost „Odstranit data smazaných položek po“. Tato volba odstraní všechny body pro konkrétní mašinu, pokud tato mašina není zálohována po dobu X dnů. Všimněte si, že tato nastavení nereagují na chyby (vyzkoušeli jsme – nefungovalo to). Neměla by proběhnout ani pokus o zálohu mašiny. Zdá se, že je tato volba užitečná a měla by být vždy zapnutá. Pokud správce odstranil mašinu z úkolu, je logické po nějaké době vyčistit nepotřebná data a řetězec. Nicméně tato nastavení vyžadují disciplínu a pozornost.
Uvedu příklad z praxe: do úkolu bylo přidáno několik kontejnerů, jejichž složení bylo poměrně dynamické. V důsledku nedostatku RAM měl B&R server problémy, které zůstaly bez povšimnutí. Úkol byl spuštěn a pokusil se provést zálohu strojů, s výjimkou jednoho, který v té době v kontejneru nebyl. Protože mnohé stroje vykázaly chyby, měl B&R podle defaultního nastavení provést 3 další pokusy o zálohu
V této souvislosti mohu říci následující: pokud máte nastavené notifikace ohledně výsledků úkolů, a ještě lépe — pokud používáte integraci s Veeam ONE, je velmi pravděpodobné, že se vám to nestane. Pokud se ale na B&R server podíváte jednou týdně, abyste zkontrolovali, že vše funguje, doporučuji se vzdát možností, které potenciálně mohou vést k odstranění záloh.
Co se přidalo ve verzi 10
To, o čem jsme hovořili dříve, existovalo v B&R po mnoho verzí. Ujasněním těchto pracovních principů se nyní podívejme, co bylo přidáno v jubilejní "desítce".
Denní uchovávání
Shora jsme zkoumali "klasickou" politiku uchovávání, založenou na počtu bodů. Alternativní přístup - nastavit v tomtéž menu "dny" místo "bodů pro obnovení".
Myšlenka je jasná z názvu – uchovávání bude mít nastavený počet dnů, přičemž počet bodů v každém dni není důležitý. Při tom je potřeba mít na paměti následující:
- Aktuální den se nezapočítává do výpočtu uchovávání
- Dny, kdy úkol nefungoval vůbec, se také počítají. Je dobré to mít na paměti, abyste náhodou neztratili body těch úkolů, které fungují nepravidelně.
- Bod obnovení se počítá od dne, kdy začalo jeho vytváření (tj. pokud úkol začal pracovat v pondělí a skončil v úterý, pak je to bod od pondělí)
Principy použití retence úloh jsou i nadále určovány zvolenou metodou zálohování. Zkusme další úlohu na výpočet podle stejné inkrementální metody. Řekněme, že retence je nastavena na 8 dní, úloha běží každé 4 hodiny s plnou zálohou ve středu. Úloha nefunguje v neděli. Úloha se poprvé spouští v pondělí. Kdy bude aplikována retence?
Odpověď
Jak je obvyklé, nejlepší je nakreslit tabulku. Umožním si zjednodušit úkol a nebudu vykreslovat všechny body vytvořené každý den, neboť zde nezáleží na počtu bodů za den. Důležité je, že v prvním pondělí a ve středu bude první bod plnou zálohou, v ostatních dnech úloha jednoduše vytvoří 4 inkrementální body.
Uvědomujeme si, že retence bude aplikována odstraněním pondělní plné zálohy a jejího inkrementu. Kdy se to stane? Když zbytek řetězce bude obsahovat 8 dní. Při tom nepočítáme aktuální den, nicméně neděli počítáme. Proto odpověď je – ve čtvrtek druhého týdne.
Archivace metodou GFS pro běžné úlohy
Do verze 10 byla metoda uchovávání Grandfather-Father-Son (GFS) dostupná pouze pro úlohy vytváření archivačních kopií (Backup copy) a úlohy kopírování na magnetickou pásku. Nyní je však dostupná i pro běžné zálohování.
I když to nesouvisí s aktuálním tématem, nemohu si pomoci a musím zmínit, že nová funkce neznamená odklon od strategie 3-2-1. Přítomnost archivačních bodů v hlavním repozitáři nijak neovlivňuje jeho spolehlivost. Předpokládá se, že GFS bude používán společně s rozšiřitelným (Scale-out) repozitářem, pro export těchto bodů do S3 a podobných úložišť. Pokud je nepoužíváte, je lepší nadále uchovávat primární a archivační body na různých repozitářích.
Nyní se podívejme na principy vytváření GFS bodů. V nastavení úlohy, ve fázi Storage, se objevilo speciální tlačítko, které vyvolává následující menu:
Podstatu GFS lze shrnout do několika bodů (všimněte si, že GFS v jiných typech úloh funguje jinak, ale o tom později):
- Úkol nevytváří samostatnou plnou zálohu pro GFS bod. Místo toho bude použit nejvhodnější plný záložní soubor z dostupných. Proto musí úkol fungovat v inkrementálním režimu s pravidelnou plnou zálohou, nebo by plnou zálohu měl vytvořit uživatel ručně.
- Pokud je povolen pouze jeden interval (např. týdenní), úkol na začátku GFS období jednoduše začne čekat na plnou zálohu a označí první vhodnou jako GFS.
Příklad: úkol je nastaven na uchovávání týdenního GFS, používající zálohu ve středu. Úkol běží každý den, ale plná záloha je naplánována na pátek. V tomto případě ve středu začne GFS období a úkol začne čekat na vhodný bod. Ten se objeví v pátek a bude označen jako GFS.
- Pokud jsou povoleny více než jeden interval (např. týdenní a měsíční), pak B&R použije metodu, která umožňuje použít jeden a tentýž bod jako GFS pro několik intervalů (pro úsporu místa). Vlajky budou přiřazeny postupně, počínaje nižšími.
Příklad: týdenní GFS je nastaven na středu a měsíční – na poslední týden v měsíci. Úkol běží každý den a vytváří plné zálohy v pondělí a pátek.
Pro jednoduchost začneme počítat od předposledního týdne v měsíci. V tomto týdnu bude vytvořena plná záloha v pondělí, ale ta bude ignorována, protože týdenní GFS interval začíná ve středu. Zato páteční plná záloha zcela odpovídá GFS bodu. Tento systém už známe.
Nyní se podívejme, co se stane v posledním týdnu v měsíci. Měsíční GFS interval začne v pondělí, ale pondělní VBK nebude označen jako GFS, protože úkol se snaží označit jeden VBK jak jako měsíční, tak jako týdenní GFS bod. Při tom začne hledání právě s týdenním, protože ten může podle definice být také měsíční.
Pokud však povolíte pouze týdenní a roční intervaly, budou fungovat nezávisle na sobě a mohou označit 2 samostatné VBK jako příslušné GFS intervaly.
Úkoly pro vytváření záložních kopií (Backup copy)
Další typ úkolů, který často vyžaduje vysvětlení ohledně fungování. Nejprve si objasníme 'klasickou' metodu práce, bez novinek v.10.
Jednoduchá metoda retence
Standardně takové úkoly fungují v nekonečně inkrementálním režimu. Vytváření bodů je určeno dvěma parametry – intervalem kopírování a požadovaným počtem bodů obnovení (žádný retence po dnech zde není). Interval kopírování se nastavuje na první záložce Job při vytváření úkolu:
Počet bodů se určuje o něco dále na záložce Target
Úkol vytváří 1 nový bod za každý interval (na počtu bodů vytvořených pro VM původními úkoly nezáleží). Na konci intervalu se nový bod finalizuje a, pokud je to nutné, aplikuje se retence sloučením VBK a nejstaršího inkrementu. Tento mechanismus už známe.
Metoda retence pomocí GFS
BCJ také umí uchovávat archivní body. To se nastavuje na stejné záložce Target, kousek níže od nastavení počtu bodů obnovení:
GFS body mohou být vytvářeny dvěma způsoby – synteticky, využívajícími data na sekundárním repozitáři, nebo simulováním plné zálohy a čtením všech dat z primárního repozitáře (aktivováno volbou označenou číslem 3). Retence se v obou případech bude výrazně lišit, proto je prozkoumejme zvlášť.
Syntetický GFS
V tomto případě GFS bod není vytvořen přesně v určený den. Místo toho bude GFS bod vytvořen, když bude VIB toho dne, na který byl plánován vznik GFS bodu, sloučen s plnou zálohou. To občas způsobuje nedorozumění, protože čas běží, a GFS bod stále není. A jedině mocný šaman z technické podpory dokáže předpovědět, který den bod nakonec vznikne. Ve skutečnosti magie není potřeba – stačí se podívat na stanovené množství bodů a interval synchronizace (kolik bodů se vytváří každý den). Zkuste to spočítat sami na takovém příkladu: úkol je nastaven na uchování 7 bodů, interval synchronizace – 12 hodin (tj. 2 body denně). V tuto chvíli již v řetězci je 7 bodů, dnes je pondělí a na tento den je naplánováno vytvoření GFS bodu. Kdy bude vytvořen?
Odpověď
Zde je lepší popsat, jak se řetězec bude měnit v dynamice, po dnech:
V pondělí je poslední inkrement v řetězci označen jako GFS, ale žádné další viditelné změny se nedějí. Každý den úloha vytváří 2 nové body a retenční mechanismus neúprosně posouvá řetězec vpřed. Nakonec ve čtvrtek nastává čas aplikovat retenční mechanismus na tento inkrement. Tato relace zabere více času než obvykle – protože úloha „vytáhne“ potřebné bloky z řetězce a vytvoří nový plný bod. Od tohoto okamžiku bude v řetězci již 8 bodů – 7 v hlavním řetězci + GFS.
Vytváření GFS bodů s možností „Přečíst celý bod“
Jak jsem již zmínil, BCJ pracuje v neomezeně inkrementálním režimu. Nyní se podíváme na jediné vyloučení z tohoto pravidla. Pokud je aktivována možnost „Přečíst celý bod“, GFS bod bude vytvořen přesně v plánovaný den. Samotná úloha bude fungovat v inkrementálním režimu s periodickými plnými zálohami, které jsme probrali výše. Retenční mechanismus bude také aplikován odstraněním nejstarší části řetězce. Nicméně v tomto případě budou odstraněny pouze inkrementy, zatímco plná záloha zůstane jako GFS bod. Odpovídající body označené GFS flagy nebudou při výpočtu retenčního mechanismu zohledněny.
Předpokládejme, že úloha je nastavena na uchovávání 7 bodů a vytváření týdenního GFS bodu v pondělí. V tomto případě každé pondělí úloha skutečně vytvoří plnou zálohu a označí ji jako GFS. Retenční mechanismus bude aplikován, když po odstranění inkrementů z nejstarší části nebude počet zbývajících inkrementů nižší než 7. Takto to vypadá na schématu:
Konec druhého týdne, v řetězci je celkem 14 bodů. Během druhého týdne úloha vytvořila 7 bodů. Kdyby šlo o jednoduchou úlohu, retenční mechanismus by již byl aplikován. Ale jde o BCJ s GFS retencí, takže GFS body nepočítáme, tedy jich je pouze 6. To znamená, že retenční mechanismus zatím nemůžeme aplikovat. Ve třetím týdnu vytváříme další plnou zálohu s GFS flagem. 15 bodů, ale tuto znovu nepočítáme. A konečně, v úterý třetího týdne vytváříme inkrement. Nyní, pokud odstraníme inkrementy řetězce prvního týdne, celkový počet inkrementů splní stanovený retenční mechanismus.
Jak již bylo zmíněno výše, v této metodě je velmi důležité, aby se plné zálohy vytvářely pravidelně. Řekněme, že pokud nastavíte hlavní retenci na 7 dní, ale máte pouze 1 roční bod, není těžké si představit, že se inkrementy nahromadí mnohem, mnohem více než 7. V takových případech je lepší použít syntetickou metodu vytváření GFS.
A znovu „Odstranit vymazané položky“
Tato možnost je také přítomná pro BCJ:
Logika této možnosti je zde stejná jako u běžných zálohovacích úkolů – pokud není stroj zpracováván po zadaný počet dní, jeho data jsou odstraněna z řetězce. Nicméně pro BCJ je užitečnost této možnosti objektivně vyšší, a to z následujících důvodů.
V běžném režimu BCJ pracuje v nekonečně inkrementálním režimu, takže pokud je stroj v určitém okamžiku odstraněn ze záložního úkolu, retence postupně odstraní všechny body obnovení, dokud nezůstane jen jeden – ve VBK. Nyní si představme, že úkol je stále nastaven na vytváření syntetických GFS bodů. Když nastane čas, úkol by měl vytvořit GFS pro všechny stroje v řetězci. Pokud nějaký stroj nemá vůbec žádné nové body – co na to říct, budeme muset použít ten, který máme. A tak pokaždé. Výsledkem může být taková situace:
Všimněte si sekce Soubory: máme zde hlavní VBK a 2 týdenní GFS body. A teď se podívejme na sekci Body obnovení – ve skutečnosti jsou v těchto souborech jeden a tentýž obraz stroje. Samozřejmě, že nemá smysl mít takové GFS body, jen zbytečně zabírají místo.
Taková situace je možná pouze při používání syntetického GFS. Aby se tomu zabránilo, použijte možnost „Odstranit vymazané položky“. Nezapomeňte ji však nastavit na adekvátní počet dní. Technická podpora již viděla případy, kdy byla možnost nastavena na menší počet dní, než je interval synchronizace – BCJ začala zcela neovladatelně odstraňovat body, aniž by je stihla vytvořit.
Mějte také na paměti, že tato možnost neovlivňuje již vytvořené GFS body. Pokud chcete vyčistit archivy, musíte to udělat ručně – kliknutím pravým tlačítkem na stroj a výběrem „Odstranit z disku“ (v zobrazeném okně nezapomeňte zaškrtnout možnost „Odstranit GFS plnou zálohu“):
Novinka v.10 – okamžitá kopie (immediate copy)
Po zvládnutí „klasické“ funkčnosti přejdeme k novému. Novinka je jedna, ale velmi důležitá. To je nový pracovní režim.
V tomto kontextu neexistuje pojem „interval synchronizace“, úkol bude neustále sledovat, zda se neobjevily nové body, a kopírovat je všechny, kolik jich jen je. Přesto úkol zůstává inkrementální, což znamená, že i když hlavní úkol vytváří VBK nebo VRB, tyto body budou zkopírovány jako VIB. Jinak v tomto režimu nejsou žádná překvapení – jak standardní, tak GFS retenční pravidla fungují podle zásad uvedených výše (přičemž zde je dostupný pouze syntetický GFS).
Otáčí se disky. Vlastnosti repozitářů s rotací disků (rotated drives)
Nepřetržité nebezpečí ransomware virů učinilo de-facto standardem bezpečnosti mít kopii dat na médiu, kam se virus nedostane. Jednou z možností je využití repozitářů s rotací disků, kde se disky používají střídavě: zatímco jeden disk je připojen a dostupný pro zápis, ostatní se uchovávají na bezpečném místě.
Aby se B&R naučilo pracovat s takovými repozitáři, je nezbytné v nastavení repozitáře, na kroku Repository, kliknout na tlačítko Advanced a vybrat odpovídající možnost:
Poté VBR očekává, že čas od času existující řetězec zmizí z repozitáře, což znamená rotaci disku. V závislosti na typu repozitáře a povaze úkolu se B&R bude chovat různě. Tuto situaci si můžeme představit následující tabulkou:
Podívejme se na každou možnost.
Obvyklý úkol a Windows repozitář
Takže máme úkol, který ukládá řetězce na první disk. Při rotaci vytvořený řetězec v podstatě zmizí a úkol musí nějak přežít tuto ztrátu. Utěšení nachází ve vytvoření úplné zálohy. Takže každá rotace znamená úplné zálohování. Ale co se stane s body na vypnutém disku? Ty jsou pamětovány a zohledňovány při výpočtu retenční doby. Takto stanovený počet bodů v úkolu je to, kolik bodů je třeba držet na všech discích. Uveďme příklad:
Úkol pracuje v nekonečně inkrementálním režimu a je nastaven na uchovávání 3 bodů obnovení. Ale máme zde ještě druhý disk a jednou týdně provádíme rotaci (disků může být i více, to podstatu nemění).
V prvním týdnu úkol vytvoří body na prvním disku a sloučí nadbytečné. Takže celkový počet bodů bude tři:
Pak připojíme druhý disk. Při spuštění B&R si všimne, že se disk změnil. Řetězec na prvním disku zmizí z rozhraní, ale informace o něm zůstane v databázi. Nyní úkol bude mít 3 body na druhém disku. Celková situace bude následující:
Nakonec znovu připojíme první disk. Před vytvořením nového bodu úkol zkontroluje, jak to vypadá s retencí. A připomínám, že retence je nastavena na uchování 3 bodů. Mezitím máme 3 body na disku 2 (ale ten je odpojen a uchovává se na bezpečném místě, kam se B&R nedostane) a 3 body na disku 1 (a ten je připojen). To znamená, že můžeme směle smazat 3 body z disku 1, protože překračují retenci. Poté úkol znovu vytvoří úplnou zálohu a naše řetězce začnou vypadat takto:
Pokud je retence nastavena na uchování dní místo počtu bodů, logika se nemění. Kromě toho, GFS retence není při použití repozitářů s rotací disků vůbec podporována.
Obvyklý úkol a Linux repozitář pro síťové úložiště
Taková varianta je také možná, ale celkově je méně doporučována kvůli uvaleným omezením. Na rotaci disku a zmizení řetězce úkol reaguje stejně – vytvořením úplné zálohy. Omezení souvisí s omezeným mechanismem retence.
Při rotaci se celý řetězec na odpojeném disku jednoduše odstraňuje z databáze B&R. Všimněte si – z databáze, soubory zůstávají na disku. Lze je importovat a použít k obnově, ale není těžké si domyslet, že dříve či později takové zapomenuté řetězce zaplní celý repozitář.
Řešení spočívá v přidání DWORD ForceDeleteBackupFiles, jak je uvedeno na této stránce: . Po tom úkol začne jednoduše odstraňovat veškerý obsah složky úkolu nebo složky repozitáře (v závislosti na hodnotě) při každé rotaci.
Nicméně to není elegantní retence, ale skutečně vyčištění celého obsahu. Bohužel technická podpora se setkala s případy, kdy jako repozitář byl uveden pouze kořenový adresář disku, kde kromě záloh byly uloženy i další údaje. Vše bylo zničeno při rotaci.
Kromě toho, při zapnutí ForceDeleteBackupFiles funguje pro všechny typy úložišť, což znamená, že i úložiště na Windows přestane uplatňovat retenci a začne odstraňovat obsah. Jinými slovy, lokální disk na Windows je nejlepší volbou pro tento systém ukládání záloh.
Záložní kopie a Windows úložiště
S BCJ se to stává ještě zajímavější. Nejen, že zde existuje plná retence, ale také je zde potřeba neprovádět plnou zálohu při každé výměně disku! Funguje to takto:
Nejprve B&R začne vytvářet body na prvním disku. Řekněme, že jsme nastavili retenci na 3 body. Úkol bude fungovat v neustále inkrementálním režimu a slučovat všechno nadbytečné (připomínám, GFS retence v tomto případě není podporována).
Poté připojujeme druhý disk. Protože na něm ještě není řetězec, vytvoříme plnou zálohu, po které máme druhý řetězec se třemi body:
Nakonec přichází čas znovu připojit první disk. A zde začíná magie, protože úkol nevytvoří plnou zálohu, ale místo toho prostě pokračuje v inkrementálním řetězci:
Po této operaci bude na každém disku existovat svůj nezávislý řetězec. Proto retence zde znamená ne počet bodů na všech discích, ale počet bodů na každém disku zvlášť.
Záložní kopie a Linux úložiště síťové úložiště
A opět, veškerá elegance mizí, pokud úložiště není na lokálním disku Windows. Tento scénář funguje analogicky k tomu, který byl uveden výše jednoduchým úkolem. Při každé rotaci BCJ bude vytvářet plnou zálohu a existující body budou zapomenuty. Abychom se nedostali do situace bez volného místa, je třeba použít DWORD ForceDeleteBackupFiles.
Závěr
Takže na závěr tohoto dlouhého textu jsme probrali dva typy úkolů. Samozřejmě existuje mnohem více úloh, ale nelze je všechny probrat v rámci jednoho článku. Pokud máte po přečtení jakékoli dotazy, napište je do komentářů, rád na ně osobně odpovím.
Zdroj: habr.com
