Administrace komentářů

Běžný uživatel nemusí mít pro řadu souborů OS a aplikací ani právo čtení. Záloha v takovém případě může být neúplná.

Pokud si představíme rozsáhlý soubor(y) živé databáze, mohou v nich probíhat neustálé změny a to v různých jejich částech. Při zálohování tímto způsobem pak nemusí být z pohledu dat obsah souboru(skupin souborů) konzistentní.

Velmi zjednodušeně. Například záznam o stavu účtu pana Nováka ležícího na začátku datafilu (je 10000Kč). Představme si, poté co zálohovací proces zazálohuje část souboru s účtem pana Nováka je z jeho účtu převedena částka 5000Kč na účet pana Kováře(účet leží na konci souboru). Ve chvíli kdy se začně zálohovat část s účtem pana Kováře je na něm již o 5000Kč více. Výsledný soubor zálohy pak může obsahovat původní částku (před převodem) na účtě pana Nováka a novou částku na účtě pana Kováře(po převodu). To není konzistetní stav (za ty se dá považovat stav kdy na obou účtech jsou buď původní či nové zůstatky). Konzistence se samozřejmě nemusí omezovat na jediný soubor, požadavkem mohou být záznamy kozistentní z pohledu business trasakcí napříč všemi soubory.

Pro tyto účely se pak nejen pro zálohování (on-line tj. běžících DB) např. u Oracle DB používá archivelog režim, kdy veškeré změny v DB jsou zaznamenávány sekvenčně do tzv. log souborů (tyto jsou pak vždy po zaplnění archivovány). Takže součástí zálohy jsou nejen vlastní soubory DB (měnící se behěm dlouho trvající zálohy), ale i archiv všech transakcí (logfilů) zaarchivovaných během doby zálohování. Při recovery se pak obnoví (nekonzistentní zazálohované) datafily a do těch promítnou ze zazálohovaného archivu logfilu všechny transkace proběhlé během doby zálohování. Tak je možné docílit konzistetního stavu databáze v čase ukončení zálohy.