12 běžný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 Firebird DBMS, ale kontakty s administrátory jiných databází ukázaly, že většina chyb je společná i jim a doslova každý klopýtá přes 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 zkrátit prostoje informačního systému (jehož důležitou součástí je databáze) na co nejkratší dobu.

V důsledku toho zůstává systém 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. Protože vytvoření záložní kopie může trvat poměrně dlouho, je to ideální čas pro to, aby se projevil Murphyho zákon. Tento přístup funguje obzvláště dobře, když je kombinován s problémem č. 7 (viz níže).

Doporučení: nemazat předchozí záložní kopii, dokud není vytvořena nová! (a nevytvářet novou záložní kopii do existujícího souboru).

Doporučení pro Firebird: Nástroj FBDataGuard zahrnutý v HQbird (pokročilý distribuční balíček Firebirdu) 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, že je poškozená (viz problém č. 6), nebudete mít ani předchozí kopii databáze, ani platnou záložní kopii.

Takový chaos se obvykle stane v pátek večer, když je vše hektické a když jsou pokyny od vedení poněkud rozporuplné. Trocha smůly a lenošný víkend v serverovně je tu pro vás.

Firebird má určitou ochranu proti této chybě - nebude možné obnovit databázi ze záložní kopie pomocí utility gbak, pokud je zapnutý 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 vašeho vedení.

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

3. Použití jednokrokové zálohy/obnovy bez použití mezilehlého záložního souboru

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

Například pokud během tohoto procesu zálohy/obnovy dojde k vážné poruše disku, počáteční databáze může být poškozena, 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, budou ztracena pouze data vytvořená nebo aktualizovaná v databázi po vytvoření této kopie.

Doporučení: nepoužívejte jednokrokovou zálohu/obnovu v automatickém režimu a vždy v manuálním režimu kontrolujte dostupnost dostatečně aktuální kopie.

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

Mnohým z vás může připadat legrační, že naše rada je tak trochu dětinská - abeceda zálohování. Ano, to je pravda, ale databáze a disk mohou skončit uložené v jednom úložném systému kvůli popularitě virtuálních prostředí. A určitě selže v tu nejnevhodnější chvíli. Navíc stále existují lidé, kteří věří, že se jejich daty 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 jedno zařízení, bez ohledu na to, jak spolehlivé se může zdát.

5. Žádná kontrola úspěšného dokončení 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 to rovnou nedělat. 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 v našem článku (i když je zatím příliš brzy na cenu), se může zeptat: “Ale co to má společného s vedením?” Tady je co - administrátor obvykle nakonfiguruje proces zálohování, ale připadá mu příliš nudné kontrolovat oznámení, zvláště když jsou uložena v samostatné složce, takže není nikdy na škodu vyžadovat další zprávy o stavu procesu. To se týká otázky, kdo za to může, když se zdá, že záložní kopie existují, ale ve skutečnosti tam nejsou ve chvíli, kdy je potřebujete :)

! v kombinaci 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é mohou monitorovat úspěšné i neúspěšné procesy zálohování, upozorňovat uživatele na problémy a nabízet nástroje souhrnné kontroly (je to zvláš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 mnoha databázemi existuje souhrnné monitorování druhé úrovně 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áložních kopií

Skutečnost, že jsou záložní kopie někde uloženy, neznamená, že je odtud lze 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: můžete automatizovat validaci záložních kopií pomocí FBDataGuard.

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

Obvykle databáze používají několik typů záloh - dumpy, běžné záložní kopie atd. Bez zacházení do detailů můžeme rozlišit dvě kategorie: ověřené a neověřené. V případě Firebirdu jsou 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 dostat do obnovené kopie, ale to je další způsob, jak administrátor databáze může něco pokazit související se špatně organizovanou migrací) a samotnou databázi (pokud ji lze přečíst od začátku do konce, pravděpodobně není poškozená).

Nbackup (neboli inkrementální záloha) dočasně uzamkne hlavní soubor databáze pro aktualizace (v konzistentním stavu) a umožňuje rychle zkopírovat soubor 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, aby se nezpomalovaly uživatelské operace, ale zároveň je nutné validovat databázi, 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 selhání RAM) nebo na logické úrovni, neověřená záložní kopie ji bude obsahovat stejně jako původní databáze.

Abyste tomu předešli, měli byste používat online validaci původní databáze (online validace pomocí gfix je dostupná od verze Firebird 2.5.4, zatímco náš nástroj FBDataGuard podporuje online validaci databáze pro verze 1.5-2.5).

Také je vhodné provádět ověřenou zálohu čas od času (například jednou týdně) kromě neověřené zálohy.

Doporučení pro Firebird: kromě online kontroly zdraví 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.

V kombinaci s problémem č. 4 bude nejlepším možným výsledkem situace, 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. Co se týče kombinace s problémy č. 5 a 2, zůstáváme opět bez databáze i bez její záložní kopie.

Doporučení: používejte záložní nástroje, 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 doby potřebné k vytvoření záložní kopie

Proces zálohování trval doslova před půl rokem 40 minut a najednou už tři hodiny - proč? Velikost databáze se mohla zvětšit nebo disk mohl vypadnout z vašeho RAID pole, což má za následek výrazně pomalejší zápis a všechny vaše záložní kopie se mohou chystat k odchodu z tohoto světa. Nebo váš dobrý kolega mohl spustit další záložní systém ve stejnou dobu (mimochodem, Firebird vám umožňuje spustit několik procesů zálohování najednou, i když není úplně jasné, proč by to někdo potřeboval). Pokud nekontrolujete dobu vytváření záložní kopie, můžete přehlédnout nově vzniklý problém a zmeškat příležitost jej opravit, než se stane masivním.

Kromě toho, pokud záložní systém nesleduje stavy záložních úloh a spouští je pouze podle plánu, můžete snadno “předběhnout”, 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 instalace aktualizací operačního systému

Je to velmi častý problém, zvláště v kombinaci s problémem č. 9 a povolenými automatickými aktualizacemi Windows (ve výchozím nastavení se aktualizace instalují ve 3 hodiny ráno). V nejlepším případě to vedlo ke zpomalení, ale pokud je operační systém restartován kvůli instalaci aktualizací, záložní kopie bude poškozena. Dobrou zprávou alespoň je, že operační systém není aktualizován každý den.

Doporučení: naplánujte aktualizace operačního systému na dobu, kdy nezasahují 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 komplexní mezipaměť, která obsahuje čtená a zapisovaná data, 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áloh mí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 může to trvat poměrně dlouho, zejména u 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 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 shromažďování sady změněných bloků.

Těm, 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. úplně vypnout služby a procesy DBMS, aby v mezipaměti nic nezůstalo,
2. použít agenty a/nebo skripty, které přepnou databázi do speciálního režimu, díky němuž je bezpečné kopírovat databázový soubor sekvenčně. Například existuje mechanismus nazvaný VSS writer pro databáze MSSQL. Na vyžádání přepne databázi do režimu příznivého pro snapshoty v okamžiku, kdy je snapshot vytvořen. Pokud používáte mechanismy založené na sledování změněných bloků, musíte sami zajistit, aby byla databáze v okamžiku synchronizace konzistentní.

Pokud databázi nepřepnete do režimu příznivé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 výpadku napájení). Tato úroveň spolehlivosti je pro většinu podniků naprosto nedostatečná. Více se o tom můžete dozvědět 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í nástroje nbackup a po skončení procesu jej odemknout. Pro jiné DBMS existují podobné nástroje pro zapnutí/vypnutí odpovídajících režimů.

Někteří správci databází jsou přesvědčeni, ž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á představa, kterou vývojáři DBMS nepodporují.

Kořeny této mylné představy jsou jasné: agresivní reklama vývojářů virtuálních strojů a zálohovacích nástrojů obvykle nezmiňuje, že databáze stejně jako jiné intenzivně aktualizované soubory vyžadují pokročilou konfiguraci. Nevěřte humbuku - ne všechny jogurty mají stejné benefity.

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), který 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 prevenci ztráty dat, ale přesto se značně liší.

Každý má rád 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 klidně odešle změny do repliky, zatímco zálohování (zejména s kopiemi na médiích pouze pro čtení) je vůči takovým operacím imunní. Vyžaduje určité úsilí správně nakonfigurovat replikaci i zálohování a přesto možnost chyb 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, který obsahuje nástroje pro zálohování i replikaci.

Shrnutí

Není tak snadné nakonfigurovat zálohování pro váš oblíbený DBMS, takže správci databází z organizací, které si svá data cení, obvykle používají profesionální zálohovací nástroje, které jim umožňují zohlednit výše uvedené problémy a předejít potížím.

Pro Firebird (promiňte za reklamu) existuje balíček nazvaný HQbird, který obsahuje FBDataGuard.

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

A samozřejmě nadále pěstujte svou administrátorskou paranoiu - například vstaňte a hned teď zkontrolujte své záložní kopie :)

Kontakty

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

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