Zálohování a obnova dat

Zde jsou uvedeny souhrnné informace týkající se zálohování a obnovy dat.

Zálohy dat je možné provádět více způsoby. Výhody a nevýhody:

  • Uživatelská jednoduchost
  • Bez odstávky, během zálohování je ABRA Gen plně přístupná uživatelům
  • Jedním krokem se zálohují jak data z databáze, tak i vybraná data z centrální repozitoře. Viz též Co obsahuje záloha *.ABF.
  • Záloha nemusí vždy obsahovat všechny databázové objekty. Tj. záloha pomocí systému ABRA Gen nemusí v okrajových případech obsahovat vše, co uživatel v databázi vytvořil jinak než přímo přes systém ABRA Gen. Viz též dále Co obsahuje záloha *.ABF.

  • Náročnější obsluha v případě existence více spojení. Platí:

    • Záloha v systému ABRA Gen se týká vždy pouze jednoho spojení.

    Čili pokud máte systém instalován tak, že máte nadefinováno připojení k více databázím než jen k jedné (více connections), pak budete zálohovat každou databázi samozřejmě zvlášť. Způsob této instalace je typický v případě zakoupené licence na multiverzi a byl popsán, včetně výhod a nevýhod tohoto řešení, v kapitole Typy instalací.

  • Úplnost zálohovaných informací
  • Rychlost
  • variabilita = možnosti různých nastavení zálohování (ORACLE)

  • Je třeba zvlášť zálohovat repozitoř

    K zálohování repozitoře je možné použít nástroj StorExpl.

    StorExpl.exe /eStorageBackup.stf

    Pokud zvolíte tuto možnost, není nutnost odděleného zálohování repozitoře nevýhodou (zálohu je možné provádět i s běžícím aplikačním serverem), pouze nezapomeňte zálohování repozitoře do svého zálohovacího scénáře zařadit.

Problematice zálohování a obnovy dat pomocí nástrojů třetích stran se podrobně věnují PDF příručky.

Mezi oběma způsoby zálohování není praktický rozdíl v tom, v jaké "kondici" se bude databáze nacházet bezprostředně po obnově. Proces obnovy zálohy vytvořené pomocí prostředků ABRA Gen stejně jako zálohy vytvořené prostřednictvím systémových nástrojů (GBAK) zahrnuje vytvoření prázdných tabulek, do kterých jsou následně vložena optimálně uspořádaná (setříděná) data. Stejně tak jsou při obnově znovu vytvořeny (optimálně vyvážené) indexy.

Z tohoto důvodu není při zálohování pomocí prostředků ABRA Gen nutné provádět zálohu/obnovu nástrojem GBAK. Míra "údržby databáze" je při obnovování souborů ABF dostatečná.

Jak bylo řečeno výše, tímto způsobem zálohování se jedním krokem zazálohují jak data z databáze, tak i vybraná data z centrální repozitoře. Výsledkem zálohy je soubor *.ABF (Abra Backup File).

Soubor zálohy je uložen v místě, které uživatel před spuštěním zálohování specifikuje. Dále viz Co obsahuje záloha *.ABF. Zálohovaná data se průběžně komprimují pomocí stejného komprimačního algoritmu, jaký je využit při komprimování CAB souborů. Název *.ABF souboru je vytvořen automaticky, obsahuje datum a čas vytvoření souboru a také název databázového spojení. Více viz parametr Adresář v popisu naplánované úlohy Zálohování dat.

190422-145000-ProductionData.ABF je soubor zálohy databázového spojení s názvem ProductionData vytvořený 22.4.2019 ve 14:50:00. O hodinu později vytvořený soubor zálohy stejného databázového spojení by měl název 190422-155000-ProductionData.ABF, atd.

Formát zálohy se od v.10.02.vč. změnil, proto i jiná přípona souboru oproti starším verzím. Původní soubory zálohy *.NXB není možné do verze 10.02 a vyšších obnovit.

Pokud se při zálohování vyskytne stream > 2GB, pak dojde k jeho rozdělení na menší kusy, tj. automaticky se vytvoří nový stream. Pozor, v dřívějších verzích se v těchto případech vyskytoval při zálohování problém a zálohu nebylo možno vytvořit nebo se vytvořila chybně. K dispozici však byly opravné patche. V každém případě pokud máte takový problém, konzultujte s konzultanty servisní sítě výrobce! Neznalým zásahem do tabulek si můžete nenávratně poškodit data!!!!

Při zálohování se používá speciální nastavení spojení s databázovým serverem (snapshot). Je to proto, aby se v případě, že uživatel zálohuje při současné práci jiných uživatelů, zazálohoval konzistentní stav. Tedy stav, který byl v okamžiku zahájení zálohování.

Pro zálohování od v.10.02 dále platí:

  • Oproti původnímu systému zálohování (do v.10.02) se provedení zálohy urychlilo a to v řádech desítek procent (i když rychlost zálohy samozřejmě záleží na mnoha okolnostech).

  • Díky změně systému update a zálohování se od v.10.02.vč. změnil i způsob přechodu mezi systémy ABRA Gen. Viz Přechod mezi systémy ABRA Gen (migrace).

    Do verze 10.01. vč. bylo možné zálohu dat z jednoho systému bez dalších úprav obnovit do jiného (typicky z ABRA Gen s podvojným účetnictvím na ABRA Gen příp. opačně). Od v. 10.02 zavedením inkrementálního update, kdy se součástí zálohy dat staly nejenom data, ale i systémové objekty (metadata), viz výše, již toto není možné a přechod je třeba řešit jiným způsobem.

ABRA Gen podporuje zálohování pouze datových typů, které jsou použity na strukturách, které jsou dodávány ve výchozím stavu. Na databázové platformě Firebird je zálohování rozšířeno o Stored funkce a NULL hodnoty (týká se především tabulek, které byly přidány zakázkovou úpravou a obsahují NULL hodnoty obsažené v databázi). Ostatní datové typy můžou být zálohovány, ale jejich podpora není nijak testována.

Pokud vaše databáze obsahuje datové typy, které nejsou standardně používány ve strukturách ABRA Gen nedoporučujeme zálohování prostředky ABRA Gen provádět. Je třeba používat nativní zálohování.

Zálohují se všechny entity podporovaného typu (tj. např. všechny tabulky). Ale pokud byla databáze uživatelsky rozšířena o tabulku s nepodporovaným datovým typem, může dojít ke kolizi: záloha sice proběhne, ale obnova dat s velkou pravděpodobností již nikoliv.

Z toho plyne:

Seznam zálohovaných databázových objektů a datových typů může být na základě požadavků uživatelů postupně rozšiřován. Databázové programy se ale vyvíjejí a není možné se domnívat, že pokud přijde daná db platforma s novým typem objektu, může ji uživatel ihned použít v databázi systému ABRA Gen a že bude automaticky také platit, že se mu řádně zazálohuje a obnoví, jak bylo řečeno výše.

Pokud uživatel tvoří v databázi ABRA Gen nějaké "své" objekty, měl by pro ně přednostně používat takové typy, s kterými pracuje sám systém ABRA Gen (neboli je vhodné se inspirovat metadady systému ABRA). Pokud by z nějakého důvodu chtěl použít jiné datové typy, je na něm, aby si ověřil, zda se stanou součástí ABRA Gen zálohy a zda data těchto typů půjdou také následně obnovit. Z důvodu bezpečnosti však doporučujeme zálohu a obnovu dat vyzkoušet VŽDY po jakémkoliv přidání uživatelského rozšíření databáze.

  • Dále záloha obsahuje některá data z centrální repozitoře. Z repozitoře to jsou např. uživatelské DynSQL, definice zobrazení definovatelných sloupců, definice extra položek aj.

    Srovnejte se zálohováním prováděným např. pomocí nějakého nástroje pro zálohování databáze (např. gbak), kdy se zazálohuje pouze databáze.

  • Záloha obsahuje dále tzv. kontrolní součet (CRC). Díky tomu je možné poškozenou zálohu identifikovat ještě před zahájením vlastní obnovy. Viz nastavení Ověřit kontrolní součet v nástroji DBAdmin.

    Ve starších verzích obnova probíhala až do té doby, než narazila na místo poškození, a poté teprve skončila chybou, přičemž z chybového hlášení nemuselo být vždy patrné, že jde o porušení souboru zálohy. Díky kontrolním součtům je tato závada identifikována jasně a včas.

  • Dále jsou v záloze uložené další základní informace o záloze, které slouží především pro identifikaci dané zálohy (např. uživatel, který ji vytvořil, datum vytvoření,...) či pro posouzení, jestli lze danou zálohu obnovit do aktuální verze (verze systému, informace o lokalizaci, verze databázového serveru) aj.

    Tyto informace o dané záloze se zobrazují např. v nástroji DBAdmin v kroku Soubor zálohy.

Jedná se o jednu z možností zálohování prostředky ABRA Gen (co pro něj obecně platí, bylo uvedeno výše), jehož výsledkem je soubor zálohy *.ABF. Co obsahuje záloha *.ABF, viz rovněž výše. Popis postupu zálohování tímto způsobem viz agenda Zálohování dat.

V rámci systému ABRA Gen je implementována možnost spouštění služeb z příkazové řádky AbraGen.exe. (Zatím pouze spouštění služby Backup - zálohování). Jedná se o jednu z možností zálohování prostředky ABRA Gen (co pro něj obecně platí, bylo uvedeno výše), jehož výsledkem je soubor zálohy *.ABF. Co obsahuje záloha *.ABF, viz rovněž výše.

K dispozici jsou následující parametry potřebné pro realizaci zálohování z příkaz. řádky (viz též obecně spuštění systému ABRA Gen s parametry):

  • -run="BACKUP:FILENAME=...;DIRECTORY=....;NOTE=...." - pomocí něj lze specifikovat:
    • jméno služby - v tomto případě BACKUP s následujícími specifikacemi:

      • FILENAME - jméno souboru zálohy. Uvádí se bez přípony. Jedná se o specifikování začátku jména souboru zálohy ABF.

        FILENAME nemusí být uveden. Pak se vytvoří automaticky dle názvu databázového spojení, data a času. Viz dále.

      • DIRECTORY - cesta pro uložení souboru zálohy
      • NOTE - poznámka k záloze

      Uvozovky jsou nutné, pokud jsou v hodnotách parametru mezery (např. v textu poznámky NOTE).

  • -terminate - je-li uveden, pak způsobí ukončení ABRA Gen, ihned po provedení úlohy
  • -connection - název spojení, pro které se má záloha provést
  • -loginname - přihlašovací jméno uživatele
  • -password - heslo pro přihlášení uživatele

    • Z příkazové řádky se spustí:

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

Uživatel musí zajistit, aby byl název zálohy vždy jedinečný. Pokud soubor zálohy téhož jména bude již v cílovém místě existovat, vytvoření nové zálohy neproběhne!!!

Z toho plyne, že generování jména souboru zálohy pomocí pevně daného jména souboru ve specifikaci FILENAME má nevýhodu v případě opakovaného volání generovaných záloh s úplně stejnými parametry (tj. nastane případ, kdy v cílovém adresáři již existuje soubor téhož jména a záloha neproběhne). Možná řešení:

Zálohování lze dále provádět pomocí Automatizačního serveru systému ABRA Gen. Viz agenda Naplánované úlohy→úloha typu Záloha.

Jedná se přímo o zazálohování pomocí databázových a systémových nástrojů.

Problematice zálohování a obnovy dat pomocí nástrojů třetích stran se podrobně věnují PDF příručky.

Příklady nástrojů:

  • GBAK Scheduler - řeší automatické zálohování dat na databázovém stroji s SQL serverem Firebird s využitím nástroje GBAK.EXE, který je dodáván spolu s SQL serverem Firebird.

    Tento způsob zálohování je výhodný pro automatické spouštění zálohování (tj. v čase, nastaveném konfiguračním programem se podle zadané konfigurace spustí zálohovací nástroj a provede zazálohování).
    Jiná možnost by byla, si na nějaké "bezpečné" místo pouze uložit kopii databáze, tj. souboru fdb (respektive do verze 9.02 gdb). Výhodou použití nástroje gbak je ale to, že databázi "vyčistí" (odstraní záznamy určené ke smazání atd.).

Jak bylo řečeno výše v Porovnání obou principů zálohování, tímto způsobem nebudou zazálohována data uložená jen v repozitoři a je třeba ji zazálohovat zvlášť.

Z vytvořených záložních souborů *.ABF, můžete kdykoli později provést obnovu dat.

Platí:

  • Má-li se do daného spojení (connection) provést obnova dat ze zálohy, spojení musí být ve stavu Obnova. Po spuštění systému ABRA Gen a výběru takového spojení se začne obnova dat provádět.

  • Součástí obnovy nejsou žádné konverze, modifikace dat apod. Data se obnoví do stavu přesně tak, jak byla zálohována. Po obnově dat se ale stav spojení změní automaticky na stav Update a proběhne další proces - datový update, který upraví databázi do stavu odpovídajícímu aktuální verzi příslušné instalace ABRA Gen, do níž se obnovuje. Z uživatelského pohledu se tedy proces obnovy databáze a následný proces updatu jeví jako jeden proces, i když jsou ve skutečnosti tyto procesy jasně odděleny.

    Tzn., že data zazálohovaná ve starší verzi, lze obecně načíst do verze novější, jelikož se po obnově provádějí i kroky nutné k povýšení verze dat (update).

Soubor zálohy *.ABF doporučujeme obnovovat do stejné verze databázového serveru. V opačném případě mohou být některé obnovy dat komplikované. Může se např. stát, že obnova dat nebude možná do nějaké novější verze databázového serveru, který v dané době ještě nebude systémem ABRA Gen podporován. Proto vždy konzultujte kompatibilitu databázových serverů uvedenou v kap. Databázový server.

V případě obnovy dat, která byla vytvořená na verzi databázového serveru Firebird nižší, než je verze 3, do verze Firebird 3 postupujte dle doporučení Obnova databáze do verze databázového serveru Firebird 3.

Zde je ještě důležité, z jaké verze přesně na jakou verzi přesně se přechází (zejména při přechodu mezi hlavními verzemi, tj. např. z 9.xx na 11.xx). Některé kombinace totiž nemusí být povoleny (viz také Kontrola identických verzí při obnově ze zálohy).

Opačně to neplatí, tedy data z novější verze nelze obnovovat do verze starší.

Konkrétní kroky, které systém při obnově dat provede:

  • Vytvoří novou databázi (soubor *.fdb) zadaného jména a na zadaném místě (u Win PC mluvíme o cestě); pokud se jedná o obnovu dat do již existující databáze, pak databázi nejdříve smaže!!!

    Tzn., že pokud by se v průběhu obnovy ukázalo, že vaše záloha dat je z nějakého důvodu nefunkční a neobnovitelná či databáze je po obnově nepoužitelná, nebudete se mít k čemu vrátit. Proto doporučujeme si v pravidelných intervalech kontrolovat, zda je vaše záloha obnovitelná (provádět kontrolní obnovu dat) případně si před obnovou dat na nějaké "bezpečné" místo uložit kopii databáze, tj. souboru fdb (respektive do verze 9.02 gdb), což ovšem vyžaduje zastavení databázového serveru).

  • Dále vytvoří tabulky a jiné databázové objekty v této databázi podle metadat ze zálohy - Jak bylo řečeno výše, databáze se obnoví přesně tak, jak byla (tedy vytváří se podle informací obsažených v záloze (nikoli podle souboru Create.DBO dodávaného pro danou instalaci). To platí i pro případ, že v záloze jsou obsaženy tabulky modulu, které v instalaci, do níž je obnovováno, nejsou nainstalovány (registrovány). Tabulky pro něj se vytvoří, jelikož jsou obsaženy v záloze. Pokud se jedná o případ opačný, tj. doinstalace modulu (v aktuální instalaci je nainstalován (registrován) modul, který nebyl obsažen v záloze), založí se tabulky pro něj podle příslušné části Create.DBO a informací v souboru Install.DBO.
  • Dále vytvoří tabulky a jiné databázové objekty v databázi podle definic uživatele a to, jedná-li se o tvorbu nového spojení prostřednictvím nástroje DBAdmin a byly-li v kroku Zákaznické úpravy zadány i *.DBO soubory se zákaznickými úpravami.

  • Ze zvolené zálohy dat do těchto tabulek nahraje data.

    Pokud záloha dat obsahuje i data z tabulek, které nejsou v aktuální instalaci k dispozici (jelikož není modul registrován), nejsou k dispozici jeho tabulky, pak se nic zásadního nestane, příslušná data jsou pouze při obnově vynechána.

  • Vytvoří indexy k tabulkám databáze.

  • Poté se přepne do stavu Update a provede se update těchto dat (je-li to třeba, tj. provádíte-li obnovu dat do vyšší verze programu, než ve které byla provedena záloha, a nová verze programu vyžaduje update datových struktur).

    Jak je tomu u tabulek, které jsou výrobcem dodávané naplněné inicializačními daty: Data ze zálohy se obnoví přesně tak, jak v záloze byla. Pokud výrobce mezitím provedl nějaký zásah v záznamech, které jsou součástí dodávaných inicializačních dat (např. přidání nových záznamů, změnu existujících), pak se tyto v rámci update dat mohou zaktualizovat. Závisí na tom, zda výrobce daný zásah zařadil mezi tzv. "update operace". Typicky je to tak, že výrobcem nově přidaná inicializační data se přidají do updatované uživatelovy databáze (např. přidané systémové tiskové sestavy). Inicializační data výrobcem změněná se podle charakteru tabulky buď rovněž změní v uživatelově databázi (např. změněné systémové tiskové sestavy) nebo zůstanou tak, jak je měl uživatel (např. proto, že se jedná o záznamy, u nichž je pravděpodobné, že je mohl uživatel rovněž změnit, a tudíž by nebylo žádoucí, aby update tyto uživatelovy změny "přepsal".

    Tzn., že data zazálohovaná ve starší verzi, lze obecně načíst do verze novější, jelikož se po obnově provádějí i kroky nutné k povýšení verze dat.

Po obnově dat je spojení automaticky nastaveno jako testovací. Pokud není obnova dat zamýšlena pro testovací účely, doporučujeme tento parametr přepnout na hodnotu Ne.

Aby se bezprostředně po obnově ze zálohy předešlo nežádoucí aktivaci některých funkcionalit, je možné nastavit, aby některé funkcionality nebyly v testovacím spojení aktivní. Konkrétně:

Kombinací nastavení "Aktivní = Ano" a "Aktivní pro testovací spojení = Ne" docílíte toho, že příslušné funkcionality budou k dispozici pouze v produkčním prostředí (až poté, co ve spojení s obnovenými daty ručně zrušíte zatržení příznaku Spojení je testovací.)

Pokud není služba, jejíž data jsou součástí zálohy, nainstalována, tato data se neobnoví.

Obnova dat prováděná v agendě Obnova dat se provádí ze záložního souboru dat *. ABF vytvořeného v rámci zálohování pomocí prostředků systému ABRA Gen. Obnova dat prováděná v této agendě znamená obnovu dat do aktuální databáze (ve které aktuálně pracujete, tedy do aktuálního spojení - connection).

Obnova dat proběhne do databáze, ve které aktuálně pracujete (aktuální spojení na databázi) a to tak, že vaše stávají databáze se nejdříve SMAŽE a bude vytvořena nová databáze (soubor *.fdb) stejného jména a na stejném místě jako je aktuální databáze, do níž budou obnovena data z vybrané zálohy dat. Tudíž o vaše stávající data přijdete (vaše stávající data budou nahrazena daty ze zálohy).

Pokud to tak nechcete a chcete si data ze zálohy obnovit k jiným účelům, pak si je obnovte do jiného spojení (do jiné databáze). K obnově do jiného spojení můžete využít obnovu z agendy Vytvořenínové firmy - nové spojení nebo obnovu z nástroje DBAdmin.

Vlastní fyzická obnova dat ze zálohy se provádí až po znovuspuštění programu. Tedy po přípravě na obnovu dat provedené v dalších krocích průvodce obnovou v agendě Obnova dat a při novém spuštění systému program provede OBNOVU dat a UPDATE dat, jak bylo řečeno výše Konkrétní kroky, které systém při obnově dat provede. Aby tato obnova mohla proběhnout bez nutnosti dalšího zásahu uživatele, je po nastavení obnovy dat z agendy Obnova dat u daného spojení automaticky nastaven příznak "Smazat databázi před spuštěním".

Agenda Vytvoření nové firmy - nové spojení slouží k vytvoření nového spojení na databázi. Součástí vytvoření tohoto nového spojení může být také obnova dat ze zálohy, pokud je jako Způsob vytvoření nového spojení zvoleno Nová firma s obnovou dat ze zálohy. Jedná se o obdobu obnovy dat z agendy Obnova dat s tím rozdílem, že se obnova dat neprovede do aktuální databáze, ale do databáze nově vytvářeného databázového spojení.

V nástroji DBAdmin si můžete nadefinovat nové spojení s obnovou dat nebo provést obnovu dat do některého z existujících spojení. Viz popis nástroje DBAdmin - volba Obnova databáze. Pokud nevíte, jak na to, objednejte si daný úkon u servisních konzultantů servisní sítě výrobce.

Problematice zálohování a obnovy dat pomocí nástrojů třetích stran se podrobně věnují PDF příručky.
  • Obnova uživatelských definic DynSQL, ProgPointů a Reportingů

Obnova ze zálohy je řešena tak, aby se uživatelské definice DynSQL, ProgPointů a Reportingů (dále viz Věcný obsah (tisk.výstupy) - rozšířené informace) neobnovily ze zálohy v případě, že už existují systémové se stejným interním identifikátorem (GUID).

  • Obnova správné struktury tabulek dle definic extra položek

    Viz Extra položky - vnitřní reprezentace.

  • Obnova předkontací

    Obnova předkontací je řešena speciálním způsobem, aby bylo možno zajistit, že uživatelské změny nebudou nijak přepsány dodávanými daty, ale současně, aby bylo možno přihrát nové defaultně dodávané předkontace pro nový typ dokladu (např. pro případ dokoupení nového modulu apod.). Jak je automatická aktualizace předkontací v rámci obnovy dat řešena, viz Aktualizace předkontací.

  • Obnova ze starší zálohy s multiverzními firmami

Popis obnovy dat z dřívějších verzí, které umožňovaly mít více multiverzních firem v jedné databázi, viz Update z verze s mutiverzními firmami v jedné databázi.

Data zazálohovaná v určité lokalizaci (např. SK verzi), nelze načíst do verze v jiné lokalizaci (např. CZ verze).

Obnova zálohy z jedné lokalizace do jiné by způsobovala problémy, protože proces obnovy resp. update doplňuje některé záznamy, které mají vazbu na inicializační data dodávaná v rámci konkrétní lokalizace. Proto je součástí zálohy i informace o lokalizaci verze, v níž záloha vznikla, a tato se při obnově kontroluje.

Při zásadních změnách v systému vzniká nová řada update označovaná změnou v hlavním čísle verze, tj. např. 5.xx.xx, 6.xx.xx atd. Při tom platí, že při přechodu mezi těmito verzemi, mohou být vždy po nějakou přechodnou dobu udržovány obě řady a vyvinuty drobné update v obou hlavních verzích najednou. Tj. dochází k souběhu hlavních verzí. Z toho ovšem plyne, že update v nižší hlavní řadě může být novějšího data než nějaký update z vyšší vývojové řady. Objasníme na příkladu:

Mějme hlavní verzi 4.xx.xx s posledním update např. 4.02.10 ke dni 1.11.04 a dále novou hlavní verzi 5.xx.xx s posledním update např. 5.01.02. ke dni 15.11.04. Pokud např. ke dni 30.11.04 vznikne update 4.02.11, bude datumově "novější", než vyšší update v řadě 5.01.02.

V rámci nových update může docházet i k různým změnám struktury dat. Přitom obecně platí, že do "novější" verze lze obnovit data z verze "starší" a je-li to potřeba, dojde automaticky k příslušnému update datových struktur. Při tom z důvodu možného souběhu verzí nestačí posuzovat pouze číslo verze, ale i datum jejího generování a číslo struktury dat. Při obnově dat se kontroluje, z které verze programu a které verze dat byla záloha pořízena vč. datumu jejího generování (součástí zálohy dat) a dále záznamy identických verzí dat vč. datumu vzniku starší verze. Pokud bude datum vzniku starší verze vyšší, musí se update provést i když je číslo verze dat nižší. V opačném případě se takový update neprovede.

Jelikož se při obnově provádějí současně i kroky nutné k povýšení verze dat, pak obecně platí, že data zazálohovaná ve starší verzi, lze bez problémů načíst do verze novější.

Mějme instalaci verze 4.01 a v ní pořízenou poslední zálohu. Nechť mezitím došlo k vývoji verze 5.01 a 5.02, v obou došlo ke změně datových struktur. Pořídíme si update na verzi 5.02 a spustíme jeho instalaci s volbou Aktualizace stávající verze. V rámci instalace proběhne obnova dat z naší zálohy a jejich postupný update tak, aby odpovídal nejdříve verzi 5.01 a poté i verzi 5.02. Z uvedeného ale také plyne, že pokud si update pořizujeme s větší časovou prodlevou, může pak jeho instalace díky složitějšímu updatovacímu procesu trvat delší dobu.

Pojmem "novější" verze se zde ovšem míní verze, která vznikla datumově později, než verze, v níž byla pořízena "stará" záloha, přičemž díky souběhu hlavních verzí nemusí nutně platit, že verze s vyšším číslem vznikla později než verze s číslem nižším. Co myslíme souběhem verzí a které verze přesně lze obnovit do kterých, viz Kontrola identických verzí při obnově ze zálohy.

Soubor zálohy *.ABF doporučujeme obnovovat do stejné verze databázového serveru. V opačném případě mohou být některé obnovy dat komplikované. Může se např. stát, že obnova dat nebude možná do nějaké novější verze databázového serveru, který v dané době ještě nebude systémem ABRA Gen podporován. Proto vždy konzultujte kompatibilitu databázových serverů uvedenou v kap. Databázový server.

V případě obnovy dat, která byla vytvořená na verzi databázového serveru Firebird nižší, než je verze 3, do verze Firebird 3 postupujte dle doporučení Obnova databáze do verze databázového serveru Firebird 3.

V databázi systému ABRA Gen nesmí být v položkách místo hodnoty <null> hodnota 0000000000. Pokud by tam taková hodnota byla, bylo by to chybou (např. díky nesprávně napsané zakázkové aplikaci). Při nejbližší záloze a obnově dat by se z dané hodnoty 0000000000 stala <null> hodnota a příslušná zak. aplikace by nefungovala řádným způsobem. Více viz popis pojmu NULL hodnoty.

Zálohování byste měli provádět jednak pravidelně a také před každým větším či složitějším zásahem do vašeho systému, kdy lze alespoň v minimální míře předpokládat, že by daný zásah mohl mít destruktivní následky (např. nějaký servisní zásah do databáze, instalace nějakého doplňku, instalační sady, mazání nějakých dat apod.). Rovněž je třeba provést zkušební zálohu a obnovu dat v okamžiku, kdy jste např. přidávali vlastní databázové entity (je vhodné ověřit, že zálohování i obnova proběhne správně a to vč. těchto entit). Více viz upozornění v sekci Co obsahuje záloha *.ABF.

V souvislosti s bezpečnostním zálohováním mějte vždy na paměti následující: Nestačí jen zálohu vytvořit. Je třeba, aby tato záloha dat byla také funkční a obnovitelná!!! Proto doporučujeme si v pravidelných intervalech provádět kontrolní obnovu dat. Rovněž doporučujeme si obnovu dat ze zálohy provádět nejdříve do jiného (testovacího) spojení, než v kterém je vaše stávající databáze s ostrými daty. Případně si před obnovou dat zaarchivovat původní databázi, např. zastavit databázový server a soubor s databází zkopírovat na nějaké "bezpečné" místo. Zastavení databázového serveru není bezpodmínečně nutné, ale je to doporučeno k bezpečnému provedení této operace, aby kopírovaný soubor nebyl v nevalidním stavu např. z důvodu nějakých "nakešovaných" informací na databázovém serveru.

Záloha, která by byla neobnovitelná či z jiného důvodu po obnově nepoužitelná (např. proto, že jste ji pořídili za špatných podmínek (např. na počítači s nesprávně nastaveným českým prostředím, tudíž po obnově dat bude chybně diakritika)) bude k ničemu! Pak by situace, kdy byste nezbytně potřebovali obnovit data ze zálohy (což se může stát z různých důvodů), bude pro vás bezvýchodná a může vést i k dlouhodobé odstávce vašeho systému ABRA Gen, se všemi důsledky, které z toho pro vás vyplynou. Proto pořízení použitelné zálohy dat NEPODCEŇUJTE !!!