- Oh, žiadny úkryt nevydrží náraz meteoritu. Ale ako všetci ostatní máte rezervu, takže sa nemusíte obávať.
Stanislav Lem, „Hviezdne denníky Tichého Ijonu“
Zálohovanie znamená uloženie kópie údajov niekde mimo ich primárneho úložného priestoru.
Hlavným účelom zálohovania je obnovenie údajov po ich strate. V tejto súvislosti často počujete, že ak máte repliku databázy, môžete z nej vždy obnoviť údaje a nie je potrebné zálohovanie. V skutočnosti vám záloha umožňuje vyriešiť najmenej tri problémy, ktoré nemožno vyriešiť pomocou repliky, a repliku nie je možné inicializovať bez záložnej kópie.
Po prvé, záloha vám umožňuje obnoviť údaje po logickej chybe. Napríklad účtovník vymazal skupinu transakcií alebo administrátor databázy zničil tabuľkový priestor. Obe operácie sú z hľadiska databázy úplne legálne a proces replikácie ich reprodukuje v replikačnej databáze.
Po druhé, moderné DBMS sú veľmi spoľahlivé softvérové systémy, ale občas dôjde k poškodeniu interných databázových štruktúr, po ktorých sa stratí prístup k údajom. Urážlivé je najmä to, že takéto porušenie sa zvyčajne vyskytuje pri vysokej záťaži alebo pri inštalácii nejakého druhu aktualizácie. Vysoká záťaž aj pravidelné aktualizácie však naznačujú, že databáza nie je v žiadnom prípade testovacou databázou a údaje v nej uložené sú cenné.
Napokon treťou úlohou, ktorej riešenie si vyžaduje záložnú kópiu, je klonovanie databázy napríklad na testovacie účely.
Zálohovanie databázy je tak či onak založené na jednom z dvoch princípov:
- Vzorkovanie údajov a následné uloženie vo vlastnom formáte;
- Snímka databázových súborov a uloženie protokolov.
Pozrime sa bližšie na tieto princípy a nástroje, ktoré ich implementujú.
Nahrávajú sa údaje
Sada nástrojov, ktoré sú súčasťou každého DBMS, musí obsahovať nástroje na nahrávanie a načítanie údajov. Údaje sú uložené buď v textovom formáte alebo v binárnom formáte špecifickom pre konkrétny DBMS. V tabuľke nižšie nájdete zoznam takýchto nástrojov:
Binárny formát
Textový formát
veštec
Export DataPump/Import DataPump
Export Import
SQL*Plus/SQL*Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQL Server
BCP
BCP
DB2
vyložiť/naložiť
vyložiť/naložiť
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoexport/mongoimport
Cassandra
nodetool snapshot/stableloader
cqlsh
Dobrá vec na textovom formáte je, že ho možno upravovať alebo dokonca vytvárať externými programami a binárny formát je zase dobrý, pretože vám umožňuje rýchlejšie nahrávať a sťahovať údaje tým, že šetrí zdroje pri konverzii formátu.
Napriek jednoduchosti a očividnosti myšlienky sťahovania údajov sa táto metóda zriedka používa na zálohovanie načítaných priemyselných databáz. Tu sú dôvody, prečo vyloženie nie je vhodné pre úplnú zálohu:
- proces vykládky vytvára značné zaťaženie zdrojového systému;
- vykládka zaberie veľa času - po dokončení vykládky už nebude relevantná;
- Je takmer nemožné vykonať koordinované uvoľnenie celej databázy pri vysokej záťaži, pretože DBMS je nútený uložiť snímku svojho stavu v čase, keď sa začne uvoľňovanie. Čím viac transakcií bolo dokončených od začiatku nahrávania, tým väčšia je veľkosť snímky (irelevantné kópie údajov v PostgreSQL, miesto vrátenia späť v Oracle, tempdb v Microsoft SQL Server atď.);
- unloading zachováva logickú štruktúru dát, ale nezachováva ich fyzickú štruktúru – parametre fyzického uloženia tabuliek, indexov a pod.
Nahrávanie má však aj svoje výhody:
- vysoká selektivita: môžete si stiahnuť jednotlivé tabuľky, jednotlivé polia a dokonca aj jednotlivé riadky;
- stiahnuté dáta je možné načítať do databázy inej verzie, a ak sa sťahovanie uskutoční v textovom formáte, tak do inej databázy.
Nahrávanie sa teda používa hlavne na úlohy, ako je zálohovanie malých tabuliek (napríklad adresárov) alebo distribúcia súborov údajov s ďalším vydaním aplikácie.
Najbežnejšou metódou zálohovania databázy je kopírovanie súborov databázy.
Chladné ukladanie databázových súborov
Zjavnou myšlienkou je zastaviť databázu a skopírovať všetky jej súbory. Táto záloha sa nazýva „studená“ záloha. Metóda je mimoriadne spoľahlivá a jednoduchá, má však dve zjavné nevýhody:
- Zo „studenej“ zálohy môžete obnoviť len stav databázy, ktorý bol v čase vypnutia; transakcie uskutočnené po reštarte databázy nebudú zahrnuté do „studenej“ záložnej kópie;
- Nie každá databáza má technologické okno, kedy je možné databázu zastaviť.
Ak vám vyhovuje „studené“ zálohovanie, musíte na to pamätať
- Studená kópia musí niekedy obsahovať denníky. Metódy na určenie protokolov, ktoré by mali ísť do „studenej“ kópie, sú individuálne pre každý DBMS. Napríklad v Oracle je potrebné skopírovať takzvané online redo, teda pevný počet log súborov v špeciálnom adresári, aj keď je databáza korektne zastavená. V PostgreSQL musíte uložiť všetky protokoly začínajúce protokolom obsahujúcim posledný kontrolný bod, ktorého informácie sú obsiahnuté v kontrolnom súbore.
- Adresár databázy môže obsahovať dočasné súbory tabuľkového priestoru, ktoré sú dostatočne veľké na to, aby ich nebolo potrebné zahrnúť do zálohy. Mimochodom, táto poznámka platí aj pre horúce zálohy.
Ukladanie horúcich súborov
Väčšina moderných záloh databázy sa vykonáva kopírovaním databázových súborov bez zastavenia databázy. Problémov je tu niekoľko:
- Keď sa začne kopírovanie, obsah databázy sa nemusí zhodovať s obsahom súborov, pretože niektoré informácie sú vo vyrovnávacej pamäti a ešte neboli zapísané na disk.
- Počas kopírovania sa môže obsah databázy zmeniť. Ak sa použijú meniteľné dátové štruktúry, zmení sa obsah súborov a ak sa použijú nemenné štruktúry, zmení sa množina súborov: objavia sa nové súbory a staré sa odstránia.
- Keďže zápis údajov do databázy a čítanie databázových súborov nie sú nijako synchronizované, zálohovací program môže prečítať nesprávnu stránku, z ktorej polovica bude zo starej verzie stránky a druhá polovica z novej.
Aby bola záloha konzistentná, každý DBMS má príkaz, ktorý oznamuje, že proces zálohovania sa začal. Syntakticky môže tento príkaz vyzerať inak:
- v Oracle je to samostatný príkaz ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- v PostgreSQL – funkcia pg_start_backup();
- V Microsoft SQL Server a DB2 sa príprava na zálohovanie vykonáva implicitne počas vykonávania príkazu BACKUP DATABASE;
- v MySQL Enterprise, Cassandra a MongoDB sa príprava implicitne vykonáva pomocou externého nástroja - mysqlbackup, OpsCenter a Ops Manager.
Napriek rozdielom v syntaxi vyzerá proces prípravy zálohy rovnako.
Takto vyzerá príprava na zálohovanie v DBMS s meniteľnými diskovými štruktúrami, t. j. vo všetkých tradičných diskových relačných systémoch:
- Zapamätá sa okamih spustenia zálohovania; záloha bude musieť od tohto bodu obsahovať denníky databázy.
- Vykoná sa kontrolný bod, to znamená, že všetky zmeny, ktoré nastali na dátových stránkach pred zapamätaným momentom, sa vyprázdnia na disk. To zaisťuje, že pred spustením zálohovania počas obnovy nie sú potrebné žiadne protokoly.
- Je povolený špeciálny režim protokolovania: ak sa dátová stránka zmenila prvýkrát po načítaní z disku, tak namiesto zapisovania zmien stránky do protokolu tam databáza zapíše celú stránku. Pri vykonávaní prípravnej procedúry sa všetky stránky vyprázdnia na disk, takže pri prvej zmene sa do protokolu vždy zapíše celý blok. Ak sa však stránka počas procesu zálohovania znova vysunie na disk, ďalšia zmena na nej bude mať za následok aj zobrazenie úplnej kópie stránky v protokole. To zaisťuje, že ak sa pri kopírovaní dátového súboru ukáže, že stránka je nesprávna, použitím protokolu bude opäť správna.
- Zmeny v hlavičkách dátových súborov sú zablokované, teda tá časť, ktorej zmeny sa neprejavia v protokoloch. To zaisťuje, že hlavička sa správne skopíruje a potom sa protokoly správne aplikujú na dátový súbor.
Po dokončení všetkých vyššie uvedených postupov môžete skopírovať dátové súbory pomocou nástrojov operačného systému - cp, rsync a ďalších. Povolenie režimu zálohovania znižuje výkon databázy: po prvé, objem protokolov sa zvyšuje a po druhé, ak náhle dôjde k zlyhaniu v režime zálohovania, obnova bude trvať dlhšie, pretože hlavičky dátových súborov sa neaktualizujú. Čím rýchlejšie je záloha dokončená, tým lepšie pre databázu, preto je vhodné použiť také nástroje ako snapshot súborového systému alebo rozbitie zrkadla (BCV) v diskovom poli. Niektoré DBMS (Oracle, PostgreSQL) ponechávajú správcovi možnosť nezávisle zvoliť metódu kopírovania, iné (Microsoft SQL Server) poskytujú rozhranie na integráciu vlastných zálohovacích utilít so súborovým systémom alebo mechanizmami ukladania.
Po dokončení zálohovania musíte databázu vrátiť späť do normálneho stavu. V Oracle sa to robí pomocou príkazu ALTER DATABASE/TABLESPACE END BACKUP, v PostgreSQL volaním funkcie pg_stop_backup() a v iných databázach internými rutinami zodpovedajúcich príkazov alebo externých služieb.
Časová os procesu zálohovania vyzerá takto:
- Príprava na zálohovanie si vyžaduje čas, niekedy aj značný čas. Aj keď sa použijú zrkadlené zväzky alebo súborové systémy s možnosťou snímania, proces zálohovania nebude okamžitý.
- Spolu s dátovými súbormi je potrebné ukladať aj protokoly od okamihu, keď začnete s prípravou na zálohovanie, až po návrat databázy do normálneho stavu.
- Z tejto zálohy môžete obnoviť v čase, keď sa základňa vráti do normálneho stavu. Obnovenie do skoršieho bodu nie je možné.
Pri databázach, ktoré využívajú nemenné dátové štruktúry (pamäťové snímky, LSM stromy), je situácia jednoduchšia. Príprava na zálohovanie pozostáva z nasledujúcich krokov:
- Údaje z pamäte sa vyprázdnia na disk.
- Zaznamená sa zoznam súborov zahrnutých v záložnej kópii. Kým sa proces zálohovania nedokončí, databáza nesmie tieto súbory vymazávať, aj keď už nie sú potrebné.
Po signáli, že zálohovanie je dokončené, môže databáza s nemennými štruktúrami opäť vymazať nepotrebné súbory.
Zotavenie do bodu
Záložná kópia vám umožňuje obnoviť stav databázy do okamihu, keď bol dokončený príkaz návratu z režimu zálohovania. Nehoda, ktorá si vyžaduje zotavenie, sa však môže stať kedykoľvek. Úloha obnovenia stavu databázy v ľubovoľnom okamihu sa nazýva „obnovenie v určitom čase“.
Aby ste to zabezpečili, mali by ste uložiť protokoly databázy počnúc koncom zálohy a počas procesu obnovy pokračovať v aplikovaní protokolov na obnovenú kópiu. Po obnovení databázy zo záložnej kópie v čase dokončenia kopírovania je stav databázy (súborov a stránok uložených vo vyrovnávacej pamäti) zaručene správny, takže nie je potrebný špeciálny režim protokolovania. Použitím protokolov v správnom okamihu môžete získať stav databázy kedykoľvek.
Zatiaľ čo rýchlosť obnovy zálohy je obmedzená iba šírkou pásma disku, rýchlosť aplikácie protokolov je zvyčajne obmedzená výkonom procesora. Ak sa zmeny vyskytnú paralelne v hlavnej databáze, potom sa počas obnovy všetky zmeny vykonajú postupne - v poradí, v akom sa načítajú z protokolu. Čas obnovy teda lineárne závisí od toho, ako ďaleko je bod obnovy od koncového bodu zálohy. Z tohto dôvodu je potrebné pomerne často robiť úplné zálohy – minimálne raz týždenne pre databázy s malým transakčným zaťažením a až denné kópie vysoko zaťažených databáz.
Prírastkové zálohovanie
Pre urýchlenie obnovy do určitej miery by som chcel, aby som mohol zálohovať čo najčastejšie, no zároveň nezaberať miesto na disku navyše a nezaťažovať databázu úlohami zálohovania.
Riešením problému je prírastkové zálohovanie, teda kopírovanie len tých dátových stránok, ktoré sa od predchádzajúcej zálohy zmenili.
Prírastkové zálohy majú zmysel len pre DBMS, ktoré používajú meniteľné dátové štruktúry.
Prírastok možno počítať buď z úplnej zálohy (kumulatívna kópia) alebo z akejkoľvek predchádzajúcej kópie (diferenciálna kópia).
Bohužiaľ neexistuje jednotná terminológia a rôzni výrobcovia používajú rôzne výrazy:
diferenciál
Kumulatívne
veštec
Diferenciálny
súhrnný
PostgreSQL
inkrementálny
-
Microsoft SQL Server
-
Diferenciálny
IBM DB2
delta
inkrementálny
Ak existujú prírastkové kópie, proces obnovenia do bodu je nasledujúci:
- posledná úplná záloha vytvorená pred obnovením;
- prírastkové kópie sa obnovia nad úplnou kópiou;
- protokoly sa zrolujú od počiatočného bodu zálohy do bodu obnovy.
Kumulatívna kópia urýchľuje proces obnovy. Napríklad na obnovenie stavu databázy do bodu medzi T3 a T4 je potrebné obnoviť dve prírastkové kópie a do bodu po T4 iba jednu.
Je zrejmé, že veľkosť jednej kumulatívnej kópie je menšia ako veľkosť niekoľkých rozdielových kópií, pretože niektoré strany sa niekoľkokrát zmenili a každá prírastková kópia obsahuje inú verziu stránky.
Existujú tri spôsoby, ako vytvoriť prírastkovú kópiu:
- vytvorenie úplnej kópie a výpočet rozdielu s predchádzajúcou úplnou kópiou;
- analýza protokolov, vytváranie zoznamu zmenených stránok a zálohovanie stránok zahrnutých v zozname;
- vyhľadávanie zmenených stránok v databáze.
Prvá metóda šetrí miesto na disku, ale neznižuje zaťaženie databázy. Navyše, ak máme úplnú zálohu, jej prevod na inkrementálnu je zbytočný, pretože obnovenie úplnej zálohy je rýchlejšie ako obnovenie predchádzajúcej úplnej zálohy a inkrementálnej. Úlohu šetrenia miesta na disku pri tomto prístupe je lepšie delegovať na špecializované komponenty so zabudovanými mechanizmami deduplikácie. Môžu to byť buď špecializované úložné systémy (EMC DataDomain, HPE StorageWorks VLS, celá rada NetApp), alebo softvérové produkty (ZFS, Veritas NetBackup PureFile, Windows Server Deduplikácia dát).
Druhá a tretia metóda sa líšia v mechanizme určovania zoznamu zmenených stránok. Analýza protokolov je náročnejšia na zdroje a na jej implementáciu potrebujete poznať štruktúru protokolových súborov. Najjednoduchším spôsobom je opýtať sa samotnej databázy, ktoré stránky sa zmenili, ale na to musí mať jadro DBMS funkciu sledovania zmien blokov.
Funkcia prírastkového zálohovania bola prvýkrát predstavená v softvéri Oracle Recovery Manager (RMAN), ktorý bol predstavený vo vydaní Oracle 8i. Oracle okamžite implementoval sledovanie zmenených blokov, takže nie je potrebné analyzovať protokoly.
PostgreSQL nesleduje upravené bloky, takže nástroj pg_probackup, vyvinutý ruskou spoločnosťou Postgres Professional, určuje upravené stránky analýzou protokolu. Spoločnosť však dodáva aj PostgresPro DBMS, ktorý obsahuje rozšírenie ptrack, ktoré sleduje zmeny stránok. Pri použití pg_probackup s PostgresPro DBMS si obslužný program vyžiada zmenené stránky zo samotnej databázy – presne to isté ako RMAN.
Microsoft SQL Server, podobne ako Oracle, sleduje zmenené stránky, ale príkaz BACKUP vám umožňuje robiť iba úplné a kumulatívne zálohy.
DB2 má schopnosť sledovať zmenené stránky, ale štandardne je zakázaná. Po povolení DB2 umožní úplné, rozdielové a kumulatívne zálohy.
Dôležitým rozdielom medzi nástrojmi opísanými v tejto časti (okrem pg_probackup) a nástrojmi na zálohovanie súborov je to, že požadujú obrazy stránok z databázy, a nie samotné čítanie údajov z disku. Nevýhodou tohto prístupu je malé dodatočné zaťaženie základne. Táto nevýhoda je však viac než kompenzovaná skutočnosťou, že čítanie stránky je vždy správne, takže počas zálohovania nie je potrebné povoliť špeciálny režim protokolovania.
Upozorňujeme, že prítomnosť prírastkových kópií nevylučuje požiadavku mať k dispozícii protokoly na obnovenie do ľubovoľného časového bodu. Preto sa v priemyselných databázach protokoly neustále prepisujú na externé médiá a podľa plánu sa vytvárajú úplné a/alebo prírastkové zálohy.
Najlepšou implementáciou myšlienky inkrementálneho zálohovania je dnes Zero Data Loss Recovery Appliance, hardvérový a softvérový systém (v terminológii Oracle, systém navrhnutý pre inštalácie) – špecializované riešenie Oracle na zálohovanie vlastnej databázy. Systém je klaster. serverov ZDLRA má veľké diskové kapacity a používa upravenú verziu softvéru Recovery Manager. Dokáže spolupracovať s inými hardvérovými a softvérovými systémami Oracle (Database Appliance, Exadata, SPARC Supercluster), ako aj s databázami Oracle bežiacimi na tradičnej infraštruktúre. Na rozdiel od „bežného“ RMAN implementuje ZDLRA koncept „inkrementálneho navždy“. Systém vytvorí úplnú kópiu databázy raz a potom vytvára iba inkrementálne kópie. Ďalšie moduly RMAN umožňujú zlúčenie kópií a vytvorenie nových úplných kópií z inkrementálnych.
Ku cti ruských vývojárov treba poznamenať, že pg_probackup dokáže zlúčiť aj prírastkové kópie.
Na rozdiel od mnohých podobných otázok má otázka „ktorá metóda zálohovania je lepšia“ jasnú odpoveď – najlepšou možnosťou je pomôcka natívna pre používaný DBMS, ktorá poskytuje možnosť prírastkového zálohovania.
Pre správcu databázy sú oveľa dôležitejšie otázky výberu stratégie zálohovania a integrácie nástrojov na zálohovanie databázy do podnikovej infraštruktúry. Tieto otázky však presahujú rámec tohto článku.
Zdroj: hab.com
