12 častých chyb při zálohování databází

od Alexey Kovyazin, 11. listopadu 2015

Stáhnout PDF (anglicky) Tento článek byl původně určen vývojářům a administrátorům DBMS Firebird, ale kontakty s administrátory jiných databází ukázaly, že většina chyb je mezi nimi společná a doslova každý zakopne o téměř stejné kameny. Pokud můžete tento seznam doplnit (i o něco specifického pro konkrétní DBMS), kontaktujte nás prostřednictvím našeho e-mailu [email protected].

1. Smazání předchozí záložní kopie před vytvořením nové záložní kopie

Tato chyba je nejčastější mezi začátečníky, kteří si neuvědomují, že hlavním účelem záložní kopie databáze není jen vytvořit kopii databáze, ale co nejvíce zkrátit dobu odstávky informačního systému (jehož důležitou součástí je databáze).

Výsledkem je, že systém zůstává nechráněný od okamžiku smazání poslední záložní kopie až do okamžiku vytvoření nové, protože databáze během tohoto období nemá jedinou záložní kopii. Vzhledem k tomu, že vytvoření záložní kopie může trvat poměrně dlouho, je to ideální čas, aby se projevil Murphyho zákon. Tento přístup funguje obzvláště dobře ve spojení s problémem 7 (viz níže).

Doporučení: nemažte předchozí záložní kopii před vytvořením nové! (a nevytvářejte novou záložní kopii do existujícího souboru).

Doporučení pro Firebird: Existuje nástroj FBDataGuard zahrnutý v HQbird (pokročilá distribuce Firebird), který maže nejstarší záložní kopii v historii až po vytvoření nové.

2. Přepsání existující databáze při obnově ze záložní kopie

Tato chyba je méně častá, i když výsledky mohou být mnohem horší. Pokud záložní kopie nebyla ověřena a ukáže se jako poškozená (viz problém 6), nebudete mít ani předchozí kopii databáze, ani platnou záložní kopii.

Takový nepořádek obvykle nastane v pátek večer, kdy je vše hektické a kdy jsou pokyny vedení tak nějak protichůdné. Trochu smůly a čeká vás langurózní víkend v serverovně.

Firebird má určitou ochranu proti této chybě – nebude možné obnovit databázi ze záložní kopie pomocí nástroje gbak, pokud je zapnutý jeho výchozí přepínač -create a pokud zadaný název souboru ukazuje na existující databázi. Bohužel existuje způsob, jak tuto ochranu obejít: přepínač -rep stále umožňuje přepsat existující soubor.

Doporučení: nikdy nepřepisujte soubor pracovní databáze bez písemného pokynu od vedení.

Doporučení pro Firebird: Používejte FBDataGuard, protože nikdy nepřepisuje soubor databáze.

3. Používání jednostupňové zálohy/obnovy bez použití mezilehlého záložního souboru

Standardní vstupní/výstupní proudy umožňují u mnoha DBMS (včetně Firebird) provést zábavný trik: implementovat streamovací zálohu s okamžitou obnovou databáze z ní. Výsledkem není vytvořen žádný mezilehlý záložní soubor. To je vhodné pro rutinní údržbu a pro spuštění testovací operace obnovy (za předpokladu, že je k dispozici jiná záložní kopie), ale nesmíte to používat pro automatické zálohování!

Například pokud během tohoto procesu zálohy/obnovy dojde k vážné poruše disku, počáteční databáze se může poškodit, zatímco nová databáze ještě nebyla vytvořena. Samozřejmě, pokud vezmete v úvahu problém 1 a existuje kopie databáze z předchozího pokusu, ztratí se pouze data vytvořená nebo aktualizovaná v databázi po vytvoření této kopie.

Doporučení: nepoužívejte jednostupňovou zálohu/obnovu v automatickém režimu a v manuálním režimu vždy zkontrolujte dostupnost kopie, která je dostatečně aktuální.

4. Ukládání záložních kopií a databáze na stejné fyzické zařízení

Mnohým z vás může připadat legrační, že naše rada je tak nějak dětinská – abeceda zálohování. Pravda, je to tak, ale databáze a disk mohou kvůli popularitě virtuálních prostředí skončit na stejném úložném systému. A určitě selže v tu nejnevhodnější chvíli. Navíc stále existují lidé, kteří věří, že s jejich daty se nemůže nic stát, pokud používají RAID pole (verze 1 nebo vyšší :)). Kromě toho existují lidé, kteří věří, že některé „značkové“ servery jsou nezničitelné, ale to je zvláštní případ.

Doporučení: neukládejte záložní kopie a databázi na stejné zařízení, ať se zdá být jakkoli spolehlivé.

5. Žádná kontrola nad úspěšným dokončením procesu zálohování

Je to poměrně častá chyba jak mezi administrátory, tak mezi vedoucími IT oddělení. Pokud nekontrolujete výsledky procesu zálohování, můžete ho stejně dobře neprovádět vůbec. Musíte dostávat oznámení o úspěšně dokončeném procesu zálohování e-mailem nebo, ještě lépe, také prostřednictvím SMS. A absence takových oznámení je známkou problému!

Pozorný čtenář, který se dostal až sem (i když na cenu je zatím brzy), se může zeptat: „Ale co to má společného s vedením?“ Tady je co – administrátor obvykle konfiguruje proces zálohování, ale přijde mu nudné kontrolovat oznámení, zvláště když jsou uložena ve zvláštní složce, takže nikdy není na škodu vyžádat si další zprávy o stavu procesu. To se týká otázky, kdo je vinen, když to vypadá, že záložní kopie byly, ale ve skutečnosti v okamžiku, kdy je potřebujete, nejsou :)

! ve spojení s problémem 2 nemáme ani databázi, ani její záložní kopii.

Doporučení: používejte nástroje pro automatizaci zálohování, které dokážou sledovat úspěšné i neúspěšné procesy zálohování, upozorňovat uživatele na problémy a nabízet nástroje pro souhrnnou kontrolu (to je obzvláště důležité, když potřebujete kontrolovat desítky a stovky procesů zálohování na různých serverech).

Doporučení pro Firebird: FBDataGuard kontroluje, zda byl proces zálohování dokončen, a odesílá odpovídající oznámení. Pro systémy s velkým množstvím databází existuje druhotné souhrnné monitorování pomocí nástroje Control Center, který vám umožňuje vidět stavy všech monitorovaných serverů a databází na jedné stránce.

6. Žádná validace zálohy

Skutečnost, že jsou záložní kopie někde uloženy, neznamená, že je lze odtud přečíst.

Proto musíte pravidelně ověřovat záložní kopie, které vytváříte, abyste se ujistili, že nejsou poškozené nebo zkopírované do /dev/null.

Doporučení pro Firebird: validaci záloh můžete automatizovat pomocí FBDataGuard.

7. Žádné kontroly stavu databáze při používání neověřených záložních kopií

Databáze obvykle používají několik typů zálohování – dumpy, pravidelné záložní kopie atd. Bez zacházení do podrobností můžeme vyčlenit dvě kategorie: ověřené a neověřené. V případě Firebird je to gbak a nbackup.

Gbak čte celou databázi na úrovni záznamů, aby vytvořil záložní soubor, a vytváří databázi vkládáním záznamů do nové databáze, čímž ověřuje záložní kopii (existují způsoby, jak se chyby mohou vplížit do obnovené kopie, ale to je jiný způsob, jak může administrátor databáze zpackat věci související se špatně organizovanou migrací) i databázi samotnou (pokud ji lze přečíst od začátku do konce, s největší pravděpodobností není poškozená).

Nbackup (také známý jako inkrementální zálohování) dočasně uzamkne hlavní soubor databáze pro aktualizace (v konzistentním stavu) a umožňuje rychlé kopírování souboru databáze (úplně nebo částečně/inkrementálně).

V případě velkých databází Firebird (větších než 500 GB) je vhodné použít nbackup, abyste nezpomalili uživatelské operace, ale zároveň je nutné databázi validovat, protože neověřené záložní kopie, které vytváří, jsou kopiemi stránek databáze, a pokud chyba spočívá na úrovni záznamů (kvůli poruše RAM) nebo na logické úrovni, bude ji obsahovat i neověřená záložní kopie stejně jako původní databáze.

Abyste tomu zabránili, měli byste použít online validaci původní databáze (online validace pomocí gfix je k dispozici od verze Firebird 2.5.4, zatímco náš nástroj FBDataGuard podporuje online validaci databáze pro verze 1.5–2.5).

Kromě toho je vhodné občas provést ověřenou zálohu (například jednou týdně) navíc k neověřené záloze.

Doporučení pro Firebird: kromě online kontroly stavu umožňuje FBDataGuard testovat proces obnovy ze zálohy v automatickém režimu.

8. Žádná kontrola volného místa pro záložní kopie

Vlastně je to klasická chyba: pokud není dostatek místa, záložní kopie zaberou veškeré volné místo a proces skončí chybou. Ukládání záložních kopií na stejný disk jako databáze může vést k přerušení provozu databáze a jejich ukládání na systémový disk může mít za následek selhání systému.

Ve spojení s problémem 4 bude nejlepším možným výsledkem ten, kdy systém přestane fungovat, protože databáze také potřebuje volné místo, ale to je obsazeno záložními kopiemi. Pokud jde o kombinaci s problémy 5 a 2, opět nám nezůstane ani databáze, ani její záložní kopie.

Doporučení: používejte nástroje pro zálohování, které předpovídají velikost zálohy a varují vás před možným nedostatkem volného místa.

Doporučení pro Firebird: FBDataGuard kontroluje velikost volného místa pro účely zálohování a také velikost volného místa na disku s databázemi i na systémovém disku.

9. Žádná kontrola nad dobou potřebnou k vytvoření záložní kopie

Proces zálohování trval doslova před půl rokem 40 minut a najednou už trvá tři hodiny – proč? Velikost databáze se mohla zvětšit nebo mohl z vašeho RAID pole vypadnout disk, což má za následek výrazně pomalejší zápis, a všechny vaše záložní kopie se mohou chystat opustit tento svět. Nebo váš dobrý kolega mohl spustit další záložní systém ve stejnou dobu (mimochodem, Firebird umožňuje spustit několik procesů zálohování najednou, i když není zcela jasné, proč by to někdo vůbec potřeboval). Pokud nekontrolujete dobu potřebnou k vytvoření záložní kopie, můžete přehlédnout nově vzniklý problém a propásnout šanci ho opravit, než se rozroste.

Kromě toho, pokud záložní systém nesleduje stavy úloh zálohování a spouští je jen podle plánu, můžete snadno „přestřelit“, což znamená situaci, kdy systém spustí nový proces zálohování, zatímco předchozí ještě neskončil.

Doporučení: používejte nástroje, které kontrolují dobu trvání procesu zálohování!

Doporučení pro Firebird: FBDataGuard kontroluje dobu trvání procesu zálohování.

10. Zálohování databáze během aplikace aktualizací operačního systému

Je to velmi častý problém, zejména ve spojení s problémem 9 a povolenými automatickými aktualizacemi Windows (ve výchozím nastavení se aktualizace aplikují ve 3 hodiny ráno). V nejlepším případě to vede ke zpomalení, ale pokud se operační systém restartuje za účelem aplikace aktualizací, záložní kopie se poškodí. Dobrou zprávou alespoň je, že operační systém se neaktualizuje každý den.

Doporučení: naplánujte aktualizace operačního systému tak, aby nezasahovaly do procesu zálohování.

11. Zálohování databáze pomocí nástrojů pro zálohování souborů nebo nástrojů pro zálohování virtuálních strojů za běhu databázového serveru

Mnoho administrátorů zapomíná, že každý DBMS má aktivní a složitou cache, která obsahuje data čtená a zapisovaná, zatímco samotné soubory databáze jsou otevřeny v režimu náhodného přístupu. Proto je nutné používat speciální typy zálohování namísto pouhého zálohování souborů (včetně pouhého kopírování souborů databáze) nebo zálohování virtuálních strojů. Nástroje pro zálohování souborů čtou databázi sekvenčně a to může trvat poměrně dlouho, zejména v případě velkých databází, takže není možné zaručit integritu vytvořené záložní kopie.

Virtuální stroje mohou využívat mechanismy snímků (snapshotů) a sledování změněných bloků (Changed Block Tracking), ale je nutné synchronizovat vytvořené záložní kopie, abyste získali konzistentní záložní kopii databáze, protože záložní kopie bude nekonzistentní v případě jakýchkoli aktivních zápisových operací s databází v okamžiku třídění sbírky změněných bloků.

Pro ty, kteří si přejí zálohovat své databáze pomocí nástrojů pro zálohování souborů nebo virtuálních strojů, můžeme nabídnout dvě metody:

1. zcela vypnout služby a procesy DBMS, aby v cache nic nezůstalo,
2. použít agenty a/nebo skripty, které přepnou databázi do speciálního režimu, který umožňuje bezpečné sekvenční kopírování databázového souboru. Například pro databáze MSSQL existuje mechanismus zvaný VSS writer. Na vyžádání přepne databázi do režimu vhodného pro snímky v okamžiku, kdy je snímek pořízen. Pokud používáte mechanismy založené na Changed Block Tracking, musíte se sami ujistit, že databáze je v okamžiku synchronizace konzistentní.

Pokud databázi nepřepnete do režimu vhodného pro zálohování, výsledná kopie databáze bude vypadat, jako by na hostitelském počítači došlo k tvrdému resetu (například k výpadku napájení). Tato úroveň spolehlivosti je pro většinu podniků naprosto nedostatečná. Více se o tom dozvíte v článku „Zvláštnosti práce s databázemi na virtuálních strojích".

Pro Firebird je nutné před zahájením procesu zálohování uzamknout hlavní soubor databáze pomocí nbackup a po ukončení procesu jej odemknout. Pro jiné DBMS existují podobné nástroje pro zapínání/vypínání odpovídajících režimů.

Někteří správci databází jsou si jisti, že mohou bezpečně zálohovat své databáze pomocí standardních nástrojů pro zálohování souborů, pokud má DBMS transakční log, protože v nejhorším případě bude poškozen pouze tento log. Je to nebezpečný mylný názor, který vývojáři DBMS nepodporují.

Kořeny tohoto mylného názoru jsou jasné: agresivní reklama vývojářů virtuálních strojů a zálohovacích nástrojů obvykle nezmíní, že databáze, stejně jako jiné intenzivně aktualizované soubory, vyžadují pokročilou konfiguraci. Nevěřte humbuku – ne všechny jogurty mají stejné přínosy.

Doporučení: nepoužívejte nástroje pro zálohování souborů a virtuálních strojů bez odpovídajících automatizačních nástrojů pro databáze.

Doporučení pro Firebird: použijte FBDataGuard (z distribučního balíčku HQbird), poskytuje integraci s nástroji pro zálohování podporujícími VSS.

12. Nahrazení zálohování replikací

Zálohování dat a replikace dat se používají ke zvýšení spolehlivosti a k prevenci ztráty dat, ale přesto jsou to zcela odlišné věci.

Všichni milují replikaci pro schopnost synchronizovat data na jiném serveru s minimálním zpožděním, ale zálohování má také některé nesporné výhody. Například v případě náhodného (nebo úmyslného) smazání dat replikace rychle a neochvějně odešle změny na repliku, zatímco záloha (zejména s kopiemi na médiích určených pouze pro čtení) je vůči takovým operacím imunní. Správné nastavení replikace i zálohování vyžaduje určité úsilí a možnost chyb zde přesto vždy existuje.

Doporučení: Pokud máte nakonfigurovanou replikaci, nezanedbávejte záložní kopie, používejte obojí.

Doporučení pro Firebird: použijte distribuční balíček HQbird Enterprise, obsahuje nástroje pro zálohování i replikaci.

Shrnutí

Nakonfigurovat zálohování pro vámi oblíbený DBMS není tak snadné, proto správci databází z organizací, kde si cení svých dat, obvykle používají profesionální zálohovací nástroje, které jim umožňují zohlednit výše uvedené problémy a předcházet jim.

Pro Firebird (omlouváme se za reklamu) existuje balíček s názvem HQbird, který zahrnuje FBDataGuard.

Naše společnost také poskytuje kompletní podporu zálohování a údržby pro Firebird a další databáze, což je dobrá volba pro ty, kteří neznají všechny technické podrobnosti zálohování.

A samozřejmě si dál hýčkejte svou adminovskou paranoiu, například vstaňte a zkontrolujte své záložní kopie právě teď :)

Kontakty

Neváhejte se zeptat na jakékoli otázky: [email protected]

Chcete dostávat novinky a články o Firebird? Přidejte se k nám na Telegramu https://t.me/firebirdsql