Zálohovanie a obnova dát

Tu sú uvedené súhrnné informácie týkajúce sa zálohovania a obnovy dát.

Zálohy dát je možné vykonávať viacerými spôsobmi. Výhody a nevýhody:

  • Používateľská jednoduchosť
  • Bez odstávky, počas zálohovania je ABRA Gen plne prístupná používateľom
  • Jedným krokom sa zálohujú ako dáta z databázy, tak aj vybrané dáta z centrálneho repozitára. Viď tiež Čo obsahuje záloha *.ABF.
  • Záloha nemusí vždy obsahovať všetky databázové objekty. Tj. záloha pomocou systému ABRA Gen nemusí v okrajových prípadoch obsahovať všetko, čo používateľ v databáze vytvoril inak než priamo cez systém ABRA Gen. Viď tiež ďalej Čo obsahuje záloha *.ABF.

  • Náročnejšia obsluha v prípade existencie viacerých spojení. Platí:

    • Záloha v systéme ABRA Gen sa týka vždy iba jedného spojenia.

      Čiže ak máte systém nainštalovaný tak, že máte nadefinované pripojenie k viacerým databázam než len k jednej (viac connections), potom budete zálohovať každú databázu samozrejme zvlášť. Spôsob tejto inštalácie je typický v prípade zakúpenej licencie na multiverziu a bol opísaný, vrátane výhod a nevýhod tohto riešenia, v kapitole Typy inštalácií.

    • Pokiaľ ide o závislé spojenie (databáza Oracle/MSSQL), tj. spojenie so synonymami, platí:

      Záloha obsahuje iba definície synoným používateľskej schémy (ktoré následná obnova obnoví), ale už nič, čo sa týka objektov za synonymami (teda nie definície a dáta z odkazovaných (aliasovaných) tabuliek). Z toho vyplýva, že takáto záloha dát nemôže byť sama osebe konzistentná. (Za konzistentnú zálohu považujme v tomto prípade zálohu, ktorú je možné samu osebe obnoviť do samostatného spojenia tak, že výsledok bude plne funkčný.) Ak má byť výsledok funkčný, musia byť obnovené aj odkazované spojenia (pričom pri zálohovaní a obnove musí byť dodržaný presný postup a nesmú sa dáta zálohovaných databáz jednotlivých spojení medzitým nijako meniť).

      Pokiaľ by to tak nebolo a odkazovaný tablespace/schéma pri obnove neexistuje, synonymá sa vytvoria a obnova samotná neskončí chybou, ale chybou by skončil akýkoľvek pokus o SQL nad touto tabuľkou (napr. počas update).

      "Správnym" nástrojom na zálohovanie "klbka" hlavného a všetkých závislých spojení je použitie Zálohovanie pomocou databázových a systémových nástrojov (RMAN). Pokiaľ naopak chcete vybrané závislé spojenie tzv. "desynonymizovať" (tj. vytvoriť z neho nezávislé spojenie), je vhodným nástrojom na vyhratie dát z neho a odkazovaných tabuliek nástroj DBExport.

Pri vytváraní zálohy na Oracle môže na niektorých inštaláciách dôjsť ku chybám na strane Oracle, napr. ORA-00604, ORA-08177 a pod. Chyby nastávajú pri viacužívateľskom prístupe na Oracle. Tento problém je na strane Oracle a nemusí k nemu dochádzať na všetkých inštaláciách. Riešením je používať natívne zálohovanie na Oracle, prípadne zaručiť výhradný prístup pri zálohovaní v systéme ABRA Gen. Viď sekcia Zálohy pomocou natívnych databázových a systémových nástrojov.

  • Úplnosť zálohovaných informácií
  • Rýchlosť
  • variabilita = možnosti rôznych nastavení zálohovania (ORACLE)

  • Je potrebné zvlášť zálohovať repozitár

    Na zálohovanie repozitára je možné použiť nástroj StorExpl.

    StorExpl.exe /eStorageBackup.stf

    Pokiaľ zvolíte túto možnosť, nie je nutnosť oddeleného zálohovania repozitára nevýhodou (zálohu je možné vykonávať aj s bežiacim aplikačným serverom), len nezabudnite zálohovanie repozitára zaradiť do svojho zálohovacieho scenára.

Problematike zálohovania a obnovy dát pomocou nástrojov tretích strán sa podrobne venujú PDF príručky.

Pre databázový server firebird platí:

Medzi oboma spôsobmi zálohovania nie je praktický rozdiel v tom, v akej "kondícii" sa bude databáza nachádzať bezprostredne po obnove. Proces obnovy zálohy vytvorenej pomocou prostriedkov ABRA Gen rovnako ako zálohy vytvorenej prostredníctvom systémových nástrojov (GBAK) zahŕňa vytvorenie prázdnych tabuliek, do ktorých sú následne vložené optimálne usporiadané (utriedené) dáta. Rovnako tak sú pri obnove znovu vytvorené (optimálne vyvážené) indexy.

Z tohto dôvodu nie je pri zálohovaní pomocou prostriedkov ABRA Gen nutné vykonávať zálohu/obnovu nástrojom GBAK. Miera "údržby databázy" je pri obnovovaní súborov ABF dostatočná.

Ako bolo povedané vyššie, týmto spôsobom zálohovania sa jedným krokom zazálohujú tak dáta z databázy, ako aj vybrané dáta z centrálneho repozitára. Výsledkom zálohy je súbor *.ABF (Abra Backup File).

Súbor zálohy je uložený na mieste, ktoré používateľ pred spustením zálohovania špecifikuje. Ďalej viď Čo obsahuje záloha *.ABF. Zálohované dáta sa priebežne komprimujú pomocou rovnakého komprimačného algoritmu, aký je využitý pri komprimovaní CAB súborov. Názov *.ABF súboru je vytvorený automaticky, obsahuje dátum a čas vytvorenia súboru a tiež názov databázového spojenia. Viac viď parameter Adresár v popise naplánovanej úlohy Zálohovanie dát.

190422-145000-ProductionData.ABF je súbor zálohy databázového spojenia s názvom ProductionData vytvorený 22. 4. 2019 o 14:50:00. O hodinu neskôr vytvorený súbor zálohy rovnakého databázového spojenia by mal názov 190422-155000-ProductionData.ABF, atď.

Formát zálohy sa od v.10.02.vr. zmenil, preto aj iná prípona súboru oproti starším verziám. Pôvodné súbory zálohy *.NXB nie je možné do verzie 10.02 a vyšších obnoviť.

Ak sa pri zálohovaní vyskytne stream > 2GB, potom dôjde k jeho rozdeleniu na menšie časti, tj. automaticky sa vytvorí nový stream. Pozor, v starších verziách sa v týchto prípadoch vyskytoval pri zálohovaní problém a zálohu nebolo možné vytvoriť alebo sa vytvorila chybne. K dispozícii však boli opravné patche. V každom prípade, ak máte taký problém, konzultujte s konzultantmi servisnej siete výrobcu. Neznalým zásahom do tabuliek si môžete nenávratne poškodiť dáta.

Pri zálohovaní sa používa špeciálne nastavenie spojenia s databázovým serverom (snapshot). Je to preto, aby sa v prípade, že používateľ zálohuje pri súčasnej práci iných používateľov, zazálohoval konzistentný stav. Teda stav, ktorý bol v okamihu začatia zálohovania.

Pre zálohovanie od v.10.02 ďalej platí:

  • Oproti pôvodnému systému zálohovania (do v.10.02) sa vykonanie zálohy zrýchlilo, a to v rádoch desiatok percent (aj keď rýchlosť zálohy samozrejme závisí od mnohých okolností).

  • Vďaka zmene systému update a zálohovania sa od v.10.02.vč. zmenil aj spôsob prechodu medzi systémami ABRA Gen. Viď Prechod medzi systémami ABRA Gen (migrácia).

    Do verzie 10.01. vrátane bolo možné zálohu dát z jedného systému bez ďalších úprav obnoviť do iného (typicky z ABRA Gen s podvojným účtovníctvom na ABRA Gen príp. opačne). Od v. 10.02 zavedením inkrementálneho update, keď sa súčasťou zálohy dát stali nielen dáta, ale aj systémové objekty (metadáta), viď vyššie, už toto nie je možné a prechod je potrebné riešiť iným spôsobom.

ABRA Gen podporuje zálohovanie iba dátových typov, ktoré sú použité v štruktúrach, ktoré sú dodávané vo východiskovom stave.

Na databázovej platforme firebird je zálohovanie rozšírené o Stored funkcie a NULL hodnoty (týka sa predovšetkým tabuliek, ktoré boli pridané zákazkovou úpravou a obsahujú NULL hodnoty obsiahnuté v databáze), avšak okrem databázovej platformy firebird nie je podpora NULL hodnôt pri obnove databázy. Ostatné dátové typy môžu byť zálohované, ale ich podpora nie je nijako testovaná.

Pokiaľ vaša databáza obsahuje dátové typy, ktoré sa štandardne nepoužívajú v štruktúrach ABRA Gen neodporúčame zálohovanie prostriedkami ABRA Gen vykonávať. Je potrebné používať natívne zálohovanie.

Zálohujú sa všetky entity podporovaného typu (tj. napr. všetky tabuľky). Ale ak bola databáza používateľsky rozšírená o tabuľku s nepodporovaným dátovým typom, môže dôjsť ku kolízii: záloha síce prebehne, ale obnova dát s veľkou pravdepodobnosťou už nie.

Z toho vyplýva:

Zoznam zálohovaných databázových objektov a dátových typov môže byť na základe požiadaviek používateľov postupne rozširovaný. Databázové programy sa ale vyvíjajú a nie je možné sa domnievať, že ak príde daná db platforma s novým typom objektu, môže ju používateľ ihneď použiť v databáze systému ABRA Gen a že bude automaticky tiež platiť, že sa mu riadne zazálohuje a obnoví, ako bolo povedané vyššie.

Ak používateľ tvorí v databáze ABRA Gen nejaké "svoje" objekty, mal by pre ne prednostne používať také typy, s ktorými pracuje sám systém ABRA Gen (alebo je vhodné sa inšpirovať metadátami systému ABRA Gen). Ak by z nejakého dôvodu chcel použiť iné dátové typy, je na ňom, aby si overil, či sa stanú súčasťou ABRA Gen zálohy a či dáta týchto typov pôjdu tiež následne obnoviť. Z dôvodu bezpečnosti však odporúčame zálohu a obnovu dát vyskúšať VŽDY po akomkoľvek pridaní používateľského rozšírenia databázy.

  • Ďalej záloha obsahuje niektoré dáta z centrálneho repozitára. Z repozitára to sú napr. používateľské DynSQL, definície zobrazenia definovateľných stĺpcov, definície extra položiek a i.

    Porovnajte so zálohovaním vykonávaným napr. pomocou nejakého nástroja na zálohovanie databázy (napr. gbak), keď sa zazálohuje iba databáza.

  • Záloha ďalej obsahuje tzv. kontrolný súčet (CRC). Vďaka tomu je možné poškodenú zálohu identifikovať ešte pred začatím vlastnej obnovy. Viď nastavenie Overiť kontrolný súčet v nástroji DBAdmin.

    V starších verziách obnova prebiehala až dovtedy, kým nenarazila na miesto poškodenia, a potom až skončila chybou, pričom z chybového hlásenia nemuselo byť vždy zrejmé, že ide o porušenie súboru zálohy. Vďaka kontrolným súčtom je táto chyba identifikovaná jasne a včas.

  • Ďalej sú v zálohe uložené ďalšie základné informácie o zálohe, ktoré slúžia predovšetkým na identifikáciu danej zálohy (napr. používateľ, ktorý ju vytvoril, dátum vytvorenia,...) či na posúdenie, či možno danú zálohu obnoviť do aktuálnej verzie (verzia systému, informácie o lokalizácii, verzia databázového servera) a i.

    Tieto informácie o danej zálohe sa zobrazujú napr. v nástroji DBAdmin v kroku Súbor zálohy.

Ide o jednu z možností zálohovania prostriedkami ABRA Gen (čo preň všeobecne platí, bolo uvedené vyššie), ktorej výsledkom je súbor zálohy *.ABF. Čo obsahuje záloha *.ABF, viď tiež vyššie. Popis postupu zálohovania týmto spôsobom viď agenda Zálohovanie dát.

V rámci systému ABRA Gen je implementovaná možnosť spúšťania služieb z príkazového riadka AbraGen.exe. (Zatiaľ iba spustenie služby Backup - zálohovanie). Ide o jednu z možností zálohovania prostriedkami ABRA Gen (čo preň všeobecne platí, bolo uvedené vyššie), ktorej výsledkom je súbor zálohy *.ABF. Čo obsahuje záloha *.ABF, viď tiež vyššie.

K dispozícii sú nasledujúce parametre potrebné na realizáciu zálohovania z príkazového riadka (viď tiež všeobecne spustenie systému ABRA Gen s parametrami):

  • -run="BACKUP:FILENAME=...;DIRECTORY=....;NOTE=...." - pomocou neho možno špecifikovať:
    • názov služby - v tomto prípade BACKUP s nasledujúcimi špecifikáciami:

      Úvodzovky sú nutné, ak sú v hodnotách parametra medzery (napr. v texte poznámky NOTE).

  • -terminate - ak je uvedený, potom spôsobí ukončenie ABRA Gen, ihneď po vykonaní úlohy
  • -connection - názov spojenia, pre ktoré sa má záloha vykonať
  • -loginname - prihlasovacie meno používateľa
  • -password - heslo pre prihlásenie používateľa

    • Z príkazového riadka sa spustí:

    AbraGen.exe -loginname=Supervisor -password=12345 -terminate -run="backup:filename=Zaloha;directory=C:\Backup;note=Pravidelná nočná záloha" -connection=DATA

Používateľ musí zabezpečiť, aby bol názov zálohy vždy jedinečný. Ak súbor zálohy toho istého mena bude už v cieľovom mieste existovať, vytvorenie novej zálohy neprebehne!!!

Z toho vyplýva, že generovanie mena súboru zálohy pomocou pevne daného mena súboru v špecifikácii FILENAME má nevýhodu v prípade opakovaného volania generovaných záloh s úplne rovnakými parametrami (tj. nastane prípad, keď v cieľovom adresári už existuje súbor toho istého mena a záloha neprebehne). Možné riešenia:

Zálohovanie možno ďalej vykonávať pomocou Automatizačného servera systému ABRA Gen. Viď agenda Naplánované úlohy → úloha typu Záloha.

Ide priamo o zazálohovanie pomocou databázových a systémových nástrojov.

Problematike zálohovania a obnovy dát pomocou nástrojov tretích strán sa podrobne venujú PDF príručky.

Príklady nástrojov:

  • GBAK Scheduler - rieši automatické zálohovanie dát na databázovom stroji so SQL serverom Firebird s využitím nástroja GBAK.EXE, ktorý sa dodáva spolu so SQL serverom Firebird.

    Tento spôsob zálohovania je výhodný na automatické spúšťanie zálohovania (tj. v čase, nastavenom konfiguračným programom sa podľa zadanej konfigurácie spustí zálohovací nástroj a vykoná zazálohovanie).
    Iná možnosť by bola, na nejaké "bezpečné" miesto iba uložiť kópiu databázy, tj. súboru fdb (respektíve do verzie 9.02 gdb). Výhodou použitia nástroja gbak je však to, že databázu "vyčistí" (odstráni záznamy určené na zmazanie atď.).

  • SQL Management Studio - pri databáze MSSQL
  • RMAN - pri databáze Oracle

Ako bolo povedané vyššie v Porovnanie oboch princípov zálohovania, týmto spôsobom nebudú zazálohované dáta uložené len v repozitári a je potrebné ich zazálohovať zvlášť.

Ak vo vašej produkčnej databáze prevádzkujete závislé spojenia (týka sa databázových serverov Oracle/MSSQL) s režimom synoným tabuliek, potom je zálohovanie pomocou databázových nástrojov jediný "správny" spôsob na zazálohovanie "klbka" hlavného a všetkých závislých spojení. Zálohovanie prostriedkami ABRA Gen nie je v tomto prípade možné použiť.

Z vytvorených záložných súborov *.ABF môžete kedykoľvek neskôr vykonať obnovu dát.

Platí:

  • Ak sa má do daného spojenia (connection) vykonať obnova dát zo zálohy, spojenie musí byť v stave Obnova. Po spustení systému ABRA Gen a výbere takého spojenia sa začne vykonávať obnova dát.

  • Súčasťou obnovy nie sú žiadne konverzie, modifikácie dát a pod. Dáta sa obnovia do stavu presne tak, ako boli zálohované. Po obnove dát sa ale stav spojenia zmení automaticky na stav Update a prebehne ďalší proces - dátový update, ktorý upraví databázu do stavu zodpovedajúceho aktuálnej verzii príslušnej inštalácie ABRA Gen, do ktorej sa obnovuje. Z používateľského pohľadu sa teda proces obnovy databázy a následný proces updatu javí ako jeden proces, aj keď sú v skutočnosti tieto procesy jasne oddelené.

    Tzn., že dáta zazálohované v staršej verzii možno všeobecne načítať do novšej verzie, keďže sa po obnove vykonávajú aj kroky potrebné na povýšenie verzie dát (update).

  • Pre databázové servery Oracle/MSSQL ďalej platí:

    Pokiaľ záloha dát obsahuje definície synoným, je používateľ varovaný. Spojenie po obnove z takej zálohy samo osebe by nemuselo byť konzistentné, pokiaľ nebudú správne obnovené aj odkazované spojenia. Odporúčaným nástrojom je preto nástroj tretej strany, podobne ako bolo uvedené pri zálohovaní, nie zálohy/obnovy vykonávané cez systém ABRA Gen.

    Problematike zálohovania a obnovy dát pomocou nástrojov tretích strán sa podrobne venujú PDF príručky.

Súbor zálohy *.ABF odporúčame obnovovať do rovnakej verzie databázového servera. V opačnom prípade môžu byť niektoré obnovy dát komplikované. Môže sa napr. stať, že obnova dát nebude možná do nejakej novšej verzie databázového servera, ktorý v danej dobe ešte nebude systémom ABRA Gen podporovaný. Preto vždy konzultujte kompatibilitu databázových serverov uvedenú v kap. Databázový server.

V prípade obnovy dát, ktorá bola vytvorená na verzii databázového servera Firebird nižšej ako verzia 3, do verzie Firebird 3 postupujte podľa odporúčaní Obnova databázy do verzie databázového servera Firebird 3.

Tu je ešte dôležité, z akej verzie presne na akú verziu presne sa prechádza (najmä pri prechode medzi hlavnými verziami, tj. napr. z 9.xx na 11.xx). Niektoré kombinácie totiž nemusia byť povolené (viď tiež Kontrola identických verzií pri obnove zo zálohy).

Opačne to neplatí, teda dáta z novšej verzie nemožno obnovovať do staršej verzie.

Konkrétne kroky, ktoré systém pri obnove dát vykoná:

  • Vytvorí novú databázu (súbor *.fdb) zadaného mena a na zadanom mieste (pri Win PC hovoríme o ceste); pokiaľ ide o obnovu dát do už existujúcej databázy, potom databázu najskôr vymaže.

    Tzn., že pokiaľ by sa v priebehu obnovy ukázalo, že vaša záloha dát je z nejakého dôvodu nefunkčná a neobnoviteľná či databáza je po obnove nepoužiteľná, nebudete sa mať k čomu vrátiť. Preto odporúčame si v pravidelných intervaloch kontrolovať, či je vaša záloha obnoviteľná (vykonávať kontrolnú obnovu dát), prípadne si pred obnovou dát na nejaké "bezpečné" miesto uložiť kópiu databázy, tj. súboru fdb (respektíve do verzie 9.02 gdb), čo si však vyžaduje zastavenie databázového servera).

  • Ďalej vytvorí tabuľky a iné databázové objekty v tejto databáze podľa metadát zo zálohy - Ako bolo povedané vyššie, databáza sa obnoví presne tak, ako bola (teda vytvára sa podľa informácií obsiahnutých v zálohe (nie podľa súboru Create.DBO dodávaného pre danú inštaláciu). To platí aj pre prípad, že v zálohe sú obsiahnuté tabuľky modulu, ktoré v inštalácii, do ktorej sa obnovuje, nie sú nainštalované (registrované). Tabuľky preň sa vytvoria, keďže sú obsiahnuté v zálohe. Pokiaľ ide o opačný prípad, tj. doinštalovanie modulu (v aktuálnej inštalácii je nainštalovaný (registrovaný) modul, ktorý nebol obsiahnutý v zálohe), založia sa tabuľky preň podľa príslušnej časti Create.DBO a informácií v súbore Install.DBO.
  • Ďalej vytvorí tabuľky a iné databázové objekty v databáze podľa definícií používateľa, a to ak ide o tvorbu nového spojenia prostredníctvom nástroja DBAdmin a ak boli v kroku Zákaznícke úpravy zadané aj *.DBO súbory so zákazníckymi úpravami.

  • Zo zvolenej zálohy dát do týchto tabuliek nahrá dáta.

    Ak záloha dát obsahuje aj dáta z tabuliek, ktoré nie sú v aktuálnej inštalácii k dispozícii (keďže modul nie je registrovaný), nie sú k dispozícii jeho tabuľky, potom sa nič zásadné nestane, príslušné dáta sa iba pri obnove vynechajú.

  • Vytvorí indexy k tabuľkám databázy.

  • Potom sa prepne do stavu Update a vykoná sa update týchto dát (ak je to potrebné, tj. ak vykonávate obnovu dát do vyššej verzie programu, než v ktorej bola vykonaná záloha, a nová verzia programu vyžaduje update dátových štruktúr).

    Ako je to pri tabuľkách, ktoré sú výrobcom dodávané naplnené inicializačnými dátami: Dáta zo zálohy sa obnovia presne tak, ako v zálohe boli. Ak výrobca medzitým vykonal nejaký zásah v záznamoch, ktoré sú súčasťou dodávaných inicializačných dát (napr. pridanie nových záznamov, zmenu existujúcich), potom sa tieto v rámci update dát môžu zaktualizovať. Závisí od toho, či výrobca daný zásah zaradil medzi tzv. "update operácie". Typicky je to tak, že výrobcom novo pridané inicializačné dáta sa pridajú do updatovanej používateľovej databázy (napr. pridané systémové tlačové zostavy). Inicializačné dáta výrobcom zmenené sa podľa charakteru tabuľky buď tiež zmenia v používateľovej databáze (napr. zmenené systémové tlačové zostavy), alebo zostanú tak, ako ich mal používateľ (napr. preto, že ide o záznamy, pri ktorých je pravdepodobné, že ich mohol používateľ tiež zmeniť, a teda by nebolo žiaduce, aby update tieto používateľove zmeny "prepísal".

    Tzn., že dáta zazálohované v staršej verzii možno vo všeobecnosti načítať do novšej verzie, keďže sa po obnove vykonávajú aj kroky potrebné na povýšenie verzie dát.

Po obnove dát je spojenie automaticky nastavené ako testovacie. Ak obnova dát nie je zamýšľaná na testovacie účely, odporúčame tento parameter prepnúť na hodnotu Nie.

Aby sa bezprostredne po obnove zo zálohy predišlo nežiaducej aktivácii niektorých funkcionalít, je možné nastaviť, aby niektoré funkcionality neboli v testovacom spojení aktívne. Konkrétne:

Kombináciou nastavenia "Aktívny = Áno" a "Aktívny pre testovacie spojenie = Nie" docielite to, že príslušné funkcionality budú k dispozícii iba v produkčnom prostredí (až potom, čo v spojení s obnovenými dátami ručne zrušíte začiarknutie príznaku Spojenie je testovacie.)

Ak nie je služba, ktorej dáta sú súčasťou zálohy, nainštalovaná, tieto dáta sa neobnovia.

Obnova dát vykonávaná v agende Obnova dát sa vykonáva zo záložného súboru dát *. ABF vytvoreného v rámci zálohovania pomocou prostriedkov systému ABRA Gen. Obnova dát vykonávaná v tejto agende znamená obnovu dát do aktuálnej databázy (v ktorej aktuálne pracujete, teda do aktuálneho spojenia - connection).

Obnova dát prebehne do databázy, v ktorej aktuálne pracujete (aktuálne spojenie na databázu) a to tak, že vaša existujúca databáza sa najskôr VYMAŽE a bude vytvorená nová databáza (súbor *.fdb) rovnakého názvu a na rovnakom mieste ako je aktuálna databáza, do ktorej budú obnovené dáta z vybranej zálohy dát. Teda o vaše existujúce dáta prídete (vaše existujúce dáta budú nahradené dátami zo zálohy).

Ak to tak nechcete a chcete si dáta zo zálohy obnoviť na iné účely, potom si ich obnovte do iného spojenia (do inej databázy). Na obnovu do iného spojenia môžete využiť obnovu z agendy Vytvorenie novej firmy - nové spojenie (platí pre firebird) alebo obnovu z nástroja DBAdmin.

Samotná fyzická obnova dát zo zálohy sa vykonáva až po opätovnom spustení programu. Teda po príprave na obnovu dát vykonanej v ďalších krokoch sprievodcu obnovou v agende Obnova dát a pri novom spustení systému program vykoná OBNOVU dát a UPDATE dát, ako bolo povedané vyššie Konkrétne kroky, ktoré systém pri obnove dát vykoná. Aby táto obnova mohla prebehnúť bez nutnosti ďalšieho zásahu používateľa, je po nastavení obnovy dát z agendy Obnova dát pri danom spojení automaticky nastavený príznak "Vymazať databázu pred spustením".

Agenda Vytvorenie novej firmy - nové spojenie slúži na vytvorenie nového spojenia na databázu. Súčasťou vytvorenia tohto nového spojenia môže byť aj obnova dát zo zálohy, ak je ako Spôsob vytvorenia nového spojenia zvolené Nová firma s obnovou dát zo zálohy. Ide o obdobu obnovy dát z agendy Obnova dát s tým rozdielom, že sa obnova dát nevykoná do aktuálnej databázy, ale do databázy novo vytváraného databázového spojenia.

V nástroji DBAdmin si môžete nadefinovať nové spojenie s obnovou dát alebo vykonať obnovu dát do niektorého z existujúcich spojení. Viď popis nástroja DBAdmin - voľba Obnova databázy. Ak neviete, ako na to, objednajte si daný úkon u servisných konzultantov servisnej siete výrobcu.

Problematike zálohovania a obnovy dát pomocou nástrojov tretích strán sa podrobne venujú PDF príručky.
  • Obnova používateľských definícií dynsql, progpointov a reportingov

Obnova zo zálohy je riešená tak, aby sa používateľské definície dynsql, progpointov a reportingov (ďalej viď Vecný obsah (tlač.výstupy) - rozšírené informácie) neobnovili zo zálohy v prípade, že už existujú systémové s rovnakým interným identifikátorom (GUID).

  • Obnova správnej štruktúry tabuliek podľa definícií extra položiek

    Viď Extra položky - vnútorná reprezentácia.

  • Obnova predkontácií

    Obnova predkontácií je riešená špeciálnym spôsobom, aby bolo možné zaistiť, že používateľské zmeny nebudú nijako prepísané dodávanými dátami, ale súčasne, aby bolo možné prihrať nové predvolene dodávané predkontácie pre nový typ dokladu (napr. pre prípad dokúpenia nového modulu a pod.). Ako je automatická aktualizácia predkontácií v rámci obnovy dát riešená, viď Aktualizácia predkontácií.

  • Obnova zo staršej zálohy s multiverznými firmami

Popis obnovy dát zo skorších verzií, ktoré umožňovali mať viac multiverzných firiem v jednej databáze, viď Update z verzie s mutiverznými firmami v jednej databáze.

Dáta zazálohované v určitej lokalizácii (napr. sk verzii), nemožno načítať do verzie v inej lokalizácii (napr. cz verzie).

Obnova zálohy z jednej lokalizácie do inej by spôsobovala problémy, pretože proces obnovy, resp. update dopĺňa niektoré záznamy, ktoré majú väzbu na inicializačné dáta dodávané v rámci konkrétnej lokalizácie. Preto je súčasťou zálohy aj informácia o lokalizácii verzie, v ktorej záloha vznikla, a táto sa pri obnove kontroluje.

Pri zásadných zmenách v systéme vzniká nový rad update označovaný zmenou v hlavnom čísle verzie, tj. napr. 5.xx.xx, 6.xx.xx atď. Pritom platí, že pri prechode medzi týmito verziami môžu byť vždy počas nejakej prechodnej doby udržiavané oba rady a vyvinuté drobné update v oboch hlavných verziách naraz. Tj. dochádza k súbehu hlavných verzií. Z toho však vyplýva, že update v nižšom hlavnom rade môže byť novšieho dátumu než nejaký update z vyššieho vývojového radu. Objasníme na príklade:

Majme hlavnú verziu 4.xx.xx s posledným update napr. 4.02.10 ku dňu 1. 11. 2004 a ďalej novú hlavnú verziu 5.xx.xx s posledným update napr. 5.01.02. ku dňu 15. 11. 2004. Ak napr. ku dňu 30. 11. 2004 vznikne update 4.02.11, bude dátumovo "novší" než vyšší update v rade 5.01.02.

V rámci nových update môže dochádzať aj k rôznym zmenám štruktúry dát. Pritom všeobecne platí, že do "novšej" verzie možno obnoviť dáta z verzie "staršej" a ak je to potrebné, dôjde automaticky k príslušnému update dátových štruktúr. Pritom z dôvodu možného súbehu verzií nestačí posudzovať iba číslo verzie, ale aj dátum jej generovania a číslo štruktúry dát. Pri obnove dát sa kontroluje, z ktorej verzie programu a ktorej verzie dát bola záloha vyhotovená vrát. dátumu jej generovania (súčasť zálohy dát) a ďalej záznamy identických verzií dát vrát. dátumu vzniku staršej verzie. Ak bude dátum vzniku staršej verzie vyšší, musí sa update vykonať aj keď je číslo verzie dát nižšie. V opačnom prípade sa taký update nevykoná.

Keďže sa pri obnove vykonávajú súčasne aj kroky potrebné na povýšenie verzie dát, potom všeobecne platí, že dáta zazálohované v staršej verzii možno bez problémov načítať do novšej verzie.

Majme inštaláciu verzie 4.01 a v nej vytvorenú poslednú zálohu. Nech medzitým došlo k vývoju verzie 5.01 a 5.02, v oboch došlo k zmene dátových štruktúr. Zaobstaráme si update na verziu 5.02 a spustíme jeho inštaláciu s voľbou Aktualizácia existujúcej verzie. V rámci inštalácie prebehne obnova dát z našej zálohy a ich postupný update tak, aby zodpovedal najskôr verzii 5.01 a potom aj verzii 5.02. Z uvedeného však tiež vyplýva, že ak si update obstarávame s väčším časovým odstupom, môže potom jeho inštalácia vďaka zložitejšiemu updatovaciemu procesu trvať dlhší čas.

Pojmom "novšia" verzia sa tu však myslí verzia, ktorá vznikla dátumovo neskôr než verzia, v ktorej bola vytvorená "stará" záloha, pričom vďaka súbehu hlavných verzií nemusí nevyhnutne platiť, že verzia s vyšším číslom vznikla neskôr než verzia s nižším číslom. Čo myslíme súbehom verzií a ktoré verzie presne možno obnoviť do ktorých, viď Kontrola identických verzií pri obnove zo zálohy.

Súbor zálohy *.ABF odporúčame obnovovať do rovnakej verzie databázového servera. V opačnom prípade môžu byť niektoré obnovy dát komplikované. Môže sa napr. stať, že obnova dát nebude možná do nejakej novšej verzie databázového servera, ktorý v danej dobe ešte nebude systémom ABRA Gen podporovaný. Preto vždy konzultujte kompatibilitu databázových serverov uvedenú v kap. Databázový server.

V prípade obnovy dát, ktorá bola vytvorená na verzii databázového servera Firebird nižšej ako verzia 3, do verzie Firebird 3 postupujte podľa odporúčaní Obnova databázy do verzie databázového servera Firebird 3.

V databáze systému ABRA Gen nesmie byť v položkách namiesto hodnoty <null> hodnota 0000000000. Ak by tam taká hodnota bola, bola by to chyba (napr. v dôsledku nesprávne napísanej zákazkovej aplikácie). Pri najbližšej zálohe a obnove dát by sa z danej hodnoty 0000000000 stala <null> hodnota a príslušná zákazk. aplikácia by nefungovala riadnym spôsobom. Viac viď popis pojmu NULL hodnoty.

Zálohovanie by ste mali vykonávať jednak pravidelne a tiež pred každým väčším či zložitejším zásahom do vášho systému, pri ktorom možno aspoň v minimálnej miere predpokladať, že by daný zásah mohol mať deštruktívne následky (napr. nejaký servisný zásah do databázy, inštalácia nejakého doplnku, inštalačnej sady, mazanie nejakých dát a pod.). Rovnako je potrebné vykonať skúšobnú zálohu a obnovu dát v okamihu, keď ste napr. pridávali vlastné databázové entity (je vhodné overiť, že zálohovanie aj obnova prebehnú správne, a to vrátane týchto entít). Viac viď upozornenie v sekcii Čo obsahuje záloha *.ABF.

V súvislosti s bezpečnostným zálohovaním majte vždy na pamäti nasledujúce: Nestačí len zálohu vytvoriť. Je potrebné, aby táto záloha dát bola aj funkčná a obnoviteľná. Preto odporúčame si v pravidelných intervaloch vykonávať kontrolnú obnovu dát. Rovnako odporúčame si obnovu dát zo zálohy vykonávať najskôr do iného (testovacieho) spojenia, než v ktorom je vaša existujúca databáza s ostrými dátami.

Pre databázový server firebird platí:

Prípadne si pred obnovou dát zaarchivovať pôvodnú databázu, napr. zastaviť databázový server a súbor s databázou skopírovať na nejaké "bezpečné" miesto. Zastavenie databázového servera nie je bezpodmienečne nutné, ale je to odporúčané na bezpečné vykonanie tejto operácie, aby kopírovaný súbor nebol v nevalidnom stave napr. z dôvodu nejakých "nakešovaných" informácií na databázovom serveri.

Pre databázové servery Oracle/MSSQL platí:

Prípadne si pred obnovou dát zaarchivovať pôvodnú databázu. Na vytvorenie archívu databázy môžete použiť nástroje databázových serverov. Pre Oracle napríklad Rman, v prípade MSSQL napríklad Management studio. Viac sú jednotlivé nástroje tretích strán opísané v inštalačnej príručke v sekcii Inštalačné PDF príručky pre Oracle a pre MSSQL.

Záloha, ktorá by bola neobnoviteľná či z iného dôvodu po obnove nepoužiteľná (napr. preto, že ste ju vytvorili za zlých podmienok (napr. na počítači s nesprávne nastaveným českým prostredím, teda po obnove dát bude chybná diakritika)), bude na nič. Potom pre vás situácia, keď by ste nevyhnutne potrebovali obnoviť dáta zo zálohy (čo sa môže stať z rôznych dôvodov), bude bezvýchodisková a môže viesť aj k dlhodobej odstávke vášho systému ABRA Gen so všetkými dôsledkami, ktoré z toho pre vás vyplynú. Preto obstaranie použiteľnej zálohy dát nepodceňujte.