Ochrana dat Oracle databázového stroje

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Ochrana dat Oracle databázového stroje Bakalářská práce Autor: Luděk Holý Informační technologie Vedoucí práce: Ing. Vladimír Beneš Praha Duben, 2010

2 Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury. V Praze, dne Luděk Holý

3 Anotace Bakalářská práce je zpracovaná na téma ochrany dat Oracle databázového serveru a má poskytnout ucelený přehled o možnostech ochrany databázových dat, mapuje různé zálohovací režimy Oracle databází a používané technologie sloužící k zajištění vyšší bezpečnosti uložení dat. V první části popisuji typy databázových záloh, v druhé hardwarové zálohovací zařízení na trhu, ve třetí možné režimy záloh. Ve čtvrté představím další vhodné možnosti ochrany dat a v závěrečné části zhodnotím popsané možnosti zálohování. Tato práce si neklade za cíl popsat ochranu dat na databázové úrovni ve smyslu bezpečnostních politik. Cílem práce je nalezení vhodných variant zálohování, ať již v oblasti zálohovacích strategií, tak i v použití jednotlivých zálohovacích systémů. Annotation The theme of the Bachelor Thesis is data protection of the Oracle database server and it provides a comprehensive outline of the possibilities of protecting database data, it maps various backup regimes of Oracle databases and the technologies in use ensuring higher security of data storing. The first part describes the types of database backups, the second deals with hardware backup devices available in the market, and the third shows the possible backup regimes. The fourth part presents other suitable options of data protection and the final part evaluates the described possibilities of backup. This Thesis does not aim to describe data protection at the database level within the meaning of security policies. The paper aims to find suitable variants of backup, both in terms of backup strategies and of using the particular backup systems.

4 Obsah Úvod Možnosti zálohování Dělení podle způsobu přístupu k datům databáze Logické zálohování Fyzické zálohování Dělení podle režimu databáze Offline zálohování Online zálohování Dělení podle způsobu uložení dat Souborový systém Optické datové nosiče Magnetická pásková média Dělení podle použitého software Export a Import Datová pumpa Fyzická záloha datových souborů databáze Recovery Manager Hardwarová zálohovací řešení HP Data Protector HP Archive Backup System for OpenVMS EMC NetWorker IBM Tivoli Storage Manager Symantec Veritas NetBackup Oracle Secure Backup Výběr vhodného režimu zálohování Úplná záloha databáze Přírůstková záloha databáze Přírůstkově aktualizované zálohy Záloha databáze za využití parametru skip readonly Záloha databáze za využití klonovacích technologií Další možnosti ochrany dat Cluster Cold/hot failover Real Application Cluster Oracle Data Guard RAID Archivace dat Vyhodnocení popisovaných možnosti Závěr Seznam použité literatury Definice, akronymy a zkratky... 55

5 Úvod Ve své bakalářské práci se zaměřím na možnosti, jak lze chránit databázová data. V dnešním světě se téměř žádná organizace neobejde bez použití informačních technologií. Pokud daná organizace zpracovává a uchovává jakákoliv data v elektronické podobě, nejčastěji si jako vlastní úložiště dat volí databázový systém. Podle svých potřeb si především vybírá z komerčních databázových produktů firem Oracle, Microsoft, IBM a dalších, případně si může pro uchování svých dat zvolit open source databázové produkty, například databázový produkt MySQL. Pracovníci odpovědní za rozvoj, správu a provoz IT musí nejpozději v době implementace nového informačního systému zvolit způsob ochrany a zálohování dat databázového systému, neboť jejich případná ztráta může fatálně poškodit provoz organizace citelnými finančními ztrátami a právními následky plynoucími z nesplněných závazků a povinností vůči obchodním partnerům a státním institucím a nezvratně tak poškodit důvěryhodnost firmy v očích jejích partnerů. V závislosti na povaze, provozním režimu a důležitosti informačního systému je nutné rozhodnout, jaký typ zálohování bude použit a na jaké záznamové medium bude vlastní záloha ukládána. Je nutné zvolit kompromis mezi důležitosti uchovávaných dat, rychlostí zálohy a případné obnovy a cenou zálohovacího systému. Výsledná volba je dále omezena dostupností zálohovacího systému na konkrétní hardwarové a softwarové platformě a možnostmi dalšího možného využití v organizaci, neboť nabízená hardwarová řešení zpravidla poskytují komplexní služby v oblasti zálohování i archivace celého podniku a neomezují se pouze na problematiku zálohování databází. Ve své práci se zaměřím na databázový systém firmy Oracle ve verzi 10g a postupně představím jednotlivé možnosti zálohování dat, dále popíši existující hardwarová zálohovací řešení, možné režimy zálohování a zmíním i další možné prostředky k zajištění vyšší bezpečnosti. Součástí práce je i kapitola vyhodnocení popisovaných možností, ve které se soustředím na výběr optimálního řešení zálohování databázového stroje v závislosti na požadavcích na finanční náročnost, rychlost a ochranu dat. 5

6 1 Možnosti zálohování Pro zálohování databázového systému můžeme zvolit různé programy, zálohovat můžeme v různých provozních režimech a zazálohovaná data lze uložit na různá zařízení. Zálohování lze dělit i na fyzické, které zahrnuje vlastní zálohu fyzických souborů databáze, a na logické, při kterém se čtou logické struktury databáze a ukládají se do fyzického souboru. 1.1 Dělení podle způsobu přístupu k datům databáze Logické zálohování Logickou zálohou nazýváme způsob vytvoření zálohy, během které program čte logické struktury databáze a následně je ukládá do souboru na zálohovací zařízení. Podmínkou pro online zálohování je databáze ve stavu open a přístup do datového slovníku. Pro logickou zálohu databáze lze využít utility Oracle Export/Import a Oracle Data Pump Export/Import. Za logickou zálohu lze považovat i vyselektování dat do souboru ve strukturované formě, kdy je možné pro případný návrat dat do databáze použít utilitu Oracle SQL Loader Fyzické zálohování Fyzickou zálohou nazýváme způsob vytvoření zálohy, při kterém jsou fyzické soubory přesunuty na zálohovací zařízení v nezměněné podobě nebo uloženy do souboru (saveset, backupset). Mezi prostředky využívající fyzické zálohování patří kopírovací, komprimovací a zálohovací prostředky konkrétního operačního systému, softwarové produkty třetích stran, ať již komerční nebo open source. Pro fyzickou zálohu lze samozřejmě využít i utilitu RMAN. 1.2 Dělení podle režimu databáze Metody a použití konkrétních nástrojů pro zálohu databáze závisí na stavu databáze během zálohování. Tyto stavy lze rozdělit na dvě základní skupiny. 6

7 1.2.1 Offline zálohování Databáze je zálohována v neaktivním stavu. Je důležité, aby byla databáze uzavřena korektním způsobem, jen za splnění této podmínky je záloha konzistentní. Offline zálohu lze provést na databázi, která je provozována v režimu ARCHIVELOG i NOARCHIVELOG. Vlastní záloha spočívá ve zkopírování datových a řídících souborů, online transakčních žurnálů a konfiguračních souborů databáze na zálohovací zařízení. Je vhodné, ale není to nezbytná podmínka, provést zároveň zálohu databázového software Online zálohování Databáze je během zálohovacího procesu ve stavu open a musí být provozována v režimu ARCHIVELOG. Jedině za splnění těchto podmínek je možné databázi obnovit a aplikací archivních žurnálů(redologů) dostat do konzistentního stavu. Online zálohování vyžaduje po dobu zálohy přepnutí tabulkových prostorů (tablespace) do režimu begin backup a po skončení zálohy přepnutí zpět do režimu end backup. Při použití utility RMAN není nutné během zálohy tabulkové prostory přepínat. Záloha spočívá ve zkopírování datových, řídících souborů databáze a také archivních žurnálů. Většina databází je v dnešní době zálohována pomocí online zálohy buď za pomoci prostředků operačního systému, nebo produktů třetích stran. Stále častěji se využívá utilita RMAN. Velkou výhodou online proti offline zálohování je možnost provádět konzistentní zálohu během provozu databáze, neboť velká část produkčních databází neumožňuje odstavovat databázi kvůli provedení zálohy. 1.3 Dělení podle způsobu uložení dat Souborový systém V dnešní době je uložení zálohy databáze do souborového systému (filesystem), ať již do lokálního, nebo sdíleného, nejlevnější variantou. Dnešní diskové systémy dosahují vynikajícího poměru rychlosti, spolehlivosti a také ceny. Zálohy můžeme ukládat jako savesety do souborového systému, ale můžeme využít i různé klonovací techniky na úrovni diskového pole, které vynikají rychlostí zálohování i obnovy databází. 7

8 1.3.2 Optické datové nosiče Pro uložení databázové zálohy je možné použít i optické nosiče CD R/RW, DVD +/- R/RW/RAM, HD DVD a Blue-ray. Lze je využít pro jednorázové i opakované zálohy. Často se jedná o jediný způsob, jak za přijatelnou cenu nosiče s databázovými zálohami uskladnit na bezpečném místě. Pro zálohování velkých produkčních databází se ale většinou nepoužívají z důvodu malé kapacity, problematické životnosti záznamu a obtížích při manipulaci s médii Magnetická pásková média Po uložení záloh do souborového systému se jedná o druhou nejčastější variantu. Nejpoužívanější magnetické pásky jsou typu DAT, DLT, SDLT, LTO a existuji v mnoha verzích. Pásková magnetická média lze použít buď v samostatné mechanice připojené k databázovému serveru s manuální obsluhou pásek, nebo častěji v páskovém robotu, což je systém skládající se ze sady páskových mechanik a příslušného poolu pásek, které jsou obsluhovány robotickým ramenem a jehož provoz je plně automatický, což v dnešní době již bývá jeden ze základních požadavků. Tento systém ale může paradoxně komplikovat plnění auditních předpisů, které s tímto režimem (uzavřený pool pásek obsluhovaný roboticky) nepočítají a vyžadují umísťování nahraných záloh do trezorů. Tento požadavek je často obtížně splnitelný. Zálohovací systém (často se používá termín zálohovací knihovna či robot) je dodáván jako balík hardware a software produktů, který zabezpečuje komplexní zálohovací služby včetně držení databáze záloh, automatické expirační politiky, řešení bezpečnosti přístupu k zálohám, clusterová řešení, robustní plánovač a GUI. Tyto systémy bývají ve společnostech využívány jako sdílené zálohovací a archivační řešení, jejich jednotlivé moduly umožňují standardní souborové zálohy a obsahují také zálohovací rozhraní pro různé typy aplikací i databází na několika platformách zároveň, v případě více vláknového napojení na firemní infrastrukturu umožňují souběžné zálohování. Zvláštní požadavek je kladen na kvalitu médií. Tyto zálohovací systémy poskytují pro databázové produkty komunikační softwarovou vrstvu MML (Media Management Layer), kterou využívá databázová utilita RMAN, například produkt IBM Tivoli Storage Manager (TSM), EMC NetWorker (Legato), HP 8

9 ABS/MDMS. Tyto produkty běžně poskytují MML na více operačních systémech zároveň, je tedy možné souběžně zálohovat Oracle databáze běžící na různých platformách. V oblasti velkých produkčních databází je využití těchto komplexních zálohovacích systémů považováno za preferovaný standard, který splňuje bezpečnostní i kapacitní požadavky a umožňuje plnou automatizaci zálohování. Nevýhodou bývá cena vlastního zálohovacího systému a medií. 1.4 Dělení podle použitého software Export a Import Export (exp) je nástroj pro exportování dat z Oracle databáze. Kromě jiných funkcí lze program exp využít pro logické zálohování databáze v režimu FULL, kdy je exportován obsah celé databáze včetně dat a definic databázových objektů. Dále pak v režimu OWNER, kdy jsou exportována data pouze zvoleného uživatele, v režimu TABLESPACE, který umožňuje export dat zvoleného tabulkového prostoru a nakonec v režimu TABLE, kdy se exportuji pouze specifikované tabulky. Párový nástroj programu export se jmenuje import (imp) a slouží k importu dat do databáze. Využívá se v analogických režimech programu export. Oba párové programy umožňují ovlivnit průběh zálohy mnoha parametry. Použití programů exp/imp jako zálohovacího řešení pro celý databázový stroj je problematické, neboť neumožňují plnou obnovu stavu databáze k okamžiku zálohy. Z tohoto důvodu se programy využívají spíše jako prostředek k záloze neprodukčních databází a i toto použití je na ústupu. Často se však z důvodu jednoduchosti a kompatibility využívá k záloze pouze části dat jako součást archivační strategie. V dnešní době je použití programů export a import na ústupu, neboť je ve verzi 10g nahradila nová utilita Datová pumpa. Export a Import není již nadále vyvíjen, ale z důvodu zpětné kompatibility je stále zachována možnost použití i v posledních verzích databáze Oracle 11g Datová pumpa Oracle ve verzi databáze 10g uvedl nový nástroj, který nahrazuje zastaralé programy export/import. Utility Data Pump Export/Import (expdp/impdb) rozšiřují možnosti původních programu export/import, implementují nové funkce v ovládání procesů, v jejich 9

10 paralelizaci a tím pádem i v podstatném zrychlení exportu a importu dat. Filozofie nových utilit vychází z původních programů exp/imp, má tedy i stejné limity jako původní utility. Neumožňují kompletní obnovu k okamžiku zálohy a jsou tedy nevhodné jako zálohovací řešení produkčních systémů. Často se jich využívá k záloze části dat v rámci archivační strategie. Datové exporty z utilit export/import a Data Pump Export/Import nejsou vzájemně kompatibilní Fyzická záloha datových souborů databáze Zálohování fyzických souboru databáze v online i offline režimu lze provádět prostředky operačního systému nebo komerčními programy ostatních výrobců. Lze použít open source produkty. Dostupnost jednotlivých produktů závisí na použitém operačním systému. Jednotlivé programy se můžou lišit možnostmi nastavení, robustností, implementací GUI, možnostmi plánování úloh, implementací bezpečnostních politik, možnostmi komprese či paralelizací úloh. Nejběžnější je na platformě wintel použití programu copy, pro zálohování lze ale užít celou řadu produktů, například Norton Ghost či Acronis True Image Home. Na unix platformě je možné využít program cp či příkaz tar. Lze také použít klienty produktů TSM, EMC Networker a další dostupné systémy k záloze dat na páskové knihovny. Na platformě OpenVMS je možné k záloze na disk či magnetické pásky kromě příkazu copy využít i příkaz backup. Lze využít i klientskou část zálohovacího systému ABS/MDMS. Ještě v nedávné době byla většina produkčních databází zálohována tímto způsobem. Na jedné straně tento přístup umožňuje administrátorovi maximální kontrolu nad zálohovacím procesem, je v principu jednoduchý a transparentní. Na druhou stranu je poměrně pracný pro administrátora databáze i obsluhu zálohovacího systému, umožňuje pouze menší stupeň automatizace. Není flexibilní, i běžné provozní změny (přidání datových souborů) často vyžadují zásah do provozních skriptů, čímž roste i riziko lidské chyby. Pokud není 10

11 aplikačně definovaná politika uchovávání záloh (retention politika), je nutné ji komplikovaně vytvořit. A jako fatální problém se postupem doby může jevit délka zálohy. Všechny tyto aspekty generují mnoho činností a nejsou v souladu se současnými trendy snižování provozních nákladů, jak v oblasti administrace systémů, tak i v obsluze datových center Recovery Manager Recovery Manager (RMAN) jakožto nový softwarový nástroj pro zálohu a obnovu Oracle databází byl poprvé představen jako součást databáze Oracle verze Postupným vývojem se z něj stal komplexní softwarový nástroj, který výrazně přesahuje problematiku zálohy a obnovy databáze. V začátcích často vzbuzoval v administrátorech nejistotu, protože jeho použitím se vzdávali maximální kontroly nad procesem zálohování i obnovy a přenechávali je ve značné míře na aplikační logice programu. RMAN si nicméně své postavení postupně vydobyl a dnes je nejpoužívanějším řešením. Hlavním impulsem opuštění strategie fyzického zálohování v naší organizaci se stala narůstající délka záloh, kdy záloha celé databáze ve dvou vláknech trvala více než 16 hodin. Zavedením utility RMAN klesl čas potřebný k záloze téže databáze ve dvou vláknech na 3 hodiny. Proč tedy použít RMAN: RMAN nezálohuje datové soubory blok po bloku jako v případě tradičního postupu. Naopak zálohy optimalizuje vynecháním nevyužitých bloků, čímž zkracuje dobu zálohy. a zároveň zmenšuje velikost vlastní zálohy. RMAN umožňuje online kompresi záloh. RMAN umožňuje provádět offline i online zálohy (v režimu ARCHIVELOG), nevyžaduje přepínání tabulkových prostorů do begin backup/end backup režimu, čímž snižuje zatížení databáze během zálohování. RMAN umožňuje během zálohy kontrolovat konzistenci databáze. RMAN umožňuje přírůstkové zálohy v různých režimech a podstatně tak snižuje čas potřebný k provedení záloh a zmenšuje velikost vlastní zálohy. RMAN umožňuje block-level recovery, v případě narušení jednotlivých databázových bloků umí obnovit pouze tyto konkrétní bloky a není nutné obnovovat celý datový soubor. RMAN umožňuje zálohovat a obnovovat databázi ve více vláknech. Tato vlastnost je možná pouze ve verzi Enterprise. RMAN je nezávislý na konkrétní hardwarové nebo softwarové platformě. 11

12 RMAN umožňuje přímý zápis na páskové mechaniky, pokud je při alokování kanálu specifikován parametrický soubor v proměnné ENV. RMAN implementuje skriptování a umožňuje ukládání skriptů v RMAN katalogu a jejich volání. RMAN katalogizuje záznamy o provedených zálohách. RMAN na základě nastavení retention politiky automaticky maže expirované zálohy všech databázových objektů. RMAN umí katalogizovat fyzické zálohy provedené prostředky operačního systému. RMAN umožňuje provedení image copy záloh příkazem backup as copy, což jsou zálohy identické s fyzickými databázovými soubory. RMAN umožňuje provádění duplex záloh. RMAN umožňuje ze svého prostředí zadávat příkazy operačního systému, sql příkazy databázi, startovat a zastavovat databázi. RMAN není možné využít pro zálohu souboru v operačním systému, jako například různé statické konfigurační soubory, databázový software, logy v souborovém systému. Jeho zálohovací schopnosti jsou spjaty s databází. RMAN je možné provozovat ve dvou základních režimech, které se liší místem uložení metadat o provedených zálohách. Nocatalog - kdy jsou informace o provedených zálohách a nastavení RMANa uloženy v řídícím souboru databáze(controlfile).tento režim umožňuje základní operace a množství uchovávaných dat je limitováno velikostí řídícího souboru a inicializačním parametrem CONTROL_FILE_RECORD_KEEP_TIME. Catalog kdy jsou informace o provedených zálohách a nastavení RMANa uloženy ve speciálním databázovém schématu(recovery Catalog) v jiné databázi na jiném fyzickém serveru. Tento režim je doporučovaný, umožňuje větší variabilitu nastavení a usnadňuje obnovu databáze, avšak vyžaduje existenci další databáze. Použití catalogu je nutné v případech, kdy jsou v RMANu uložené skripty, catalog je možné použít pro více databází(ale nejedná se o doporučovanou variantu, je vždy lepší pro každou databázi použít vlastní catalog(nové Oracle schéma), nabízí větší možnosti reportů a umožňuje uložení některých konfiguračních parametrů. RMAN směruje uložení záloh podle parametru při alokovaní kanálů. Existují dva základní typy, type DISK a type SBT_TAPE. V případě varianty SBT_TAPE je nutné v proměnné ENV specifikovat konfigurační soubor páskové knihovny. 12

13 RMAN umožňuje provádět zálohu na úrovni datového souboru (datafilu), na úrovni tabulkového prostoru, zálohu celé databáze, řídících souborů, spfilu, archivních redologů. Jeho velkou předností je plná automatizace politik uchovávání záloh, kdy automaticky hlídá kombinace záloh databáze a zazálohovaných archivních redologů potřebných pro zotavení databáze, pravidelné čištění prostoru pro archivní redology, kdy RMAN hlídá, zda je daný redolog již zazálohován (případně zda je splněno množství požadovaných záloh) a jedině v tom případě je smazán. Toto byl v dobách před masovým rozšířením RMANa častý zdroj problémů. RMANa je možné ovládat z příkazového promptu nebo grafického prostředí Grid Console, samozřejmostí je dávkové spuštění v závislosti na možnostech konkrétního operačního systému. Na platformě wintel je možné použít dávkový příkaz AT či Naplánované spuštění, na platformě unix a linux crontab a v prostředí OpenVMS Queue Manager. Pro plánování spuštění záloh a údržbu catalogu je samozřejmě možné použít vestavěné plánovací funkce komerčních zálohovacích systému. V současné době představuje RMAN mocný nástroj na komplexní využití při záloze a obnově Oracle databází. Při jeho použití a splnění základních podmínek je bezpečnost databázových dat zaručena. 13

14 2 Hardwarová zálohovací řešení Dnešním standardem zálohování Oracle databází je využití utility RMAN a zároveň jeho propojení na existující zálohovací knihovnu (Media Management Server, MMS). Přestože stále klesá cena pevných disků a SAN diskové pole nabízejí stále se zvyšující bezpečnost a výkon, existuje řada důvodů pro zálohování na magnetické pásky. U rozsáhlých databází by pro zálohy byl potřeba několikanásobek velikosti databáze. Z tohoto důvodu vychází poměr cena za MB příznivěji pro pásku. Dalším důvodem je trvanlivost a bezpečnost uložení, kde také stále dominuje páska. Ukládáním záloh na disk se také můžeme dostat do konfliktu s požadavky na archivaci dat. Společnosti v současné době snižování nákladů využívají enterprise zálohovacích systému, kdy na jedno fyzické zařízení zálohují různá data z různých systému a nemusejí tak řešit každou aplikaci a systém zvlášť, což v konečném důsledku snižuje náklady na provoz. Utilita RMAN neumožňuje kromě zálohy na disk přímý přístup na zařízení, proto je nutné pro ukládání záloh využít vrstvu Media Management Layer (MML), která zpřístupní RMANu zálohovací systém pro zápis i čtení. Děje se tak při alokování kanálu v režimu SBT_TAPE, v proměnné ENV se specifikuje konfigurační soubor použité zálohovací knihovny. Zálohování Oracle databází se při použití režimu SBT_TAPE neliší od klasického zálohování na disk. Jediný rozdíl je ve způsobu alokování kanálu. Po úspěšné alokaci pak RMAN pouze posílá standardní příkazy MML vrstvě, která je zodpovědná za komunikaci s MMS. MML rozhraní pro RMANa není součástí databázového softwaru, ale dodává ho dodavatel MMS (zálohovací knihovny). Media Management Server se skládá ze tří základních komponent: Media management library - je softwarový plug-in pro utilitu RMAN, ve formě konfiguračního souboru nebo logického jména se specifikuje během alokace kanálu. Media management client software je klientská část programu, který je zodpovědný za spojení a přenos dat do media management server. Media management server - je vlastní zálohovací systém. 14

15 Media management server lze dále dělit na několik softwarových a hardwarových komponent, jednotlivé komponenty se liší podle konkrétního dodavatele, nicméně vlastní architektura je podobná. Softwarová část se dělí na Media Manager Catalog (což je interní databáze, která obsahuje konfigurační údaje a dále informace o uložení záloh na konkrétních páskách), programy na zápis a čtení dat na pásky a také ovládací programy na podavač pásek. Hardwarová část se skládá z magnetických pásek, slotů, podavače a dalších komponent. Obrázek č. 1: Obecné schéma zálohování databázového serveru na MMS Databázový server Databázové soubry Oracle intance Alokovaný kanál Media Management Server Media management server software RMAN Media Management Library Pásková mechanika Media Management klient software Zdroj: Oracle databáze 10g RMAN Backup&Recovery, vlastní úprava Výběr použitého MML závisí na mnoha faktorech, především na ceně zálohovacího systému (MMS), ceně licence MML, robustnosti a vysoké dostupnosti MMS, požadované životnosti magnetických pásek a bývá podřízeno již existující firemní infrastruktuře a případně existujícímu zálohovacímu systému. U některých méně rozšířených platforem také existencí MML na dané platformě. 15

16 MML rozhraní pro zálohování Oracle databází dodávají následující společnosti: Arkeia Software - Arkeia Network Backup Tempo - Time Navigator BakBone Software - NetVault BridgeHead Software - HyperTape CommVault Systéme - QiNetix Galaxy CA BrighStor - ARCServ backup EMC - EMC Disk Library, EMC Networker, EMC Avamar HP - Data Protektor, Archive Backup System for OpenVMS Novastor - NovaNet Backup Innovation Data Processing - FDR/UPSTREAM STORServer Inc. - SDP for Oracle on OpenVMS Syncsort - Backup Express IBM - Tivoli Storage Manager UTS Global LLC - Backup and Recovery Sterling Software - SAMS:Alexandria Symantec/Veritas NetBackup, Backup Exec Sun - SUN's Soltice Backup Viton - NetBunker WumpusWare - OpenVMS Client to EMC Networker V další části podrobně popíši nejpoužívanější MML. 2.1 HP Data Protector Data Protector je zálohovací systém společnosti Hewlett Packard. Jedná se rozšířený komplexní zálohovací systém, známý také pod označením OMNIBack Data Protector. Vlastní systém se skládá ze softwarové části a hardwarové knihovny. 16

17 Softwarová část obsahuje interní databázi, umožňuje plnou automatizaci záloh, řízení přístupových práv, optimalizované zálohovací algoritmy (synthetic backups) a mnoho dalších funkčností. Systém je možné administrovat z příkazového terminálu nebo z grafického prostředí. HP Data Protector klienta je možné využívat na platformách MS Windows, Novell NetWare, HP-UX,Sun Solaris, Linux, IBM AIX, SGI IRIX, SNI SINIX, SCO OpenServer, SCO Unixware, HP True64 Unix, OpenVMS. HP Data Protector umožňuje přímé připojení páskových mechanik typu DDS, DLT,DLT1, SuperDLT,QIC/Travan, Magneto-Optical,Mammoth M2, Eliant, IBM 3590 (Magstar), STK 9840,STK 9940, AIT, LTO Ultrium. HP Data Protector také spolupracuje se zálohovacími knihovnami mnoha výrobců, například s HP, StorageTek, Sony, Dell, Seagate, ADIC, ATL, Spectralogical, Exabyte, Quantum,Breece Hill, Overland Data a další. HP Data Protector nabízí širokou škálu agentů pro zálohování různých typů aplikací a databází: Microsoft Exchange Microsoft SQL Server VMware Informix Sybase Oracle SAP R/3 IBM DB2 a další Pro zálohování Oracle databází je nutné nainstalovat na databázový server Data Protector Oracle integration software a například na unix platformě je dále nutné vytvořit symbolický link mezi rozhraním utility RMAN a MML knihovnou. 17

18 Tento krok se samozřejmě liší v závislosti na platformě operačního systému. Na OpenVMS systémech je nutné změnit další Oracle zdrojové soubory a následně zrelinkovat EXE spustitelné soubory. Pro použití Data Protector je nutné alokovat kanál jedním z následujících způsobů: allocate channel t1 type 'SBT_TAPE' PARMS='SBT_LIBRARY= /opt/omni/lib/libob2oracle8_64bit.sl'; allocate channel 'dev_1' type 'sbt_tape' parms 'ENV=OB2BARTYPE=Oracle,OB2APPNAME=orcl,OB2BARLIST=machlogs)'; Obrázek č. 2: Topologie HP Data Protector Zdroj: HP OpenView Storage Data Protector Integration Guide for Oracle and SAP HP Data Protector je v současné době nabízen ve verzi

19 2.2 HP Archive Backup System for OpenVMS ABS/MDMS je komplexní zálohovací systém, který firma Hewlett Packard dodává jako standardní zálohovací řešení pro Aplha a Integrity serverové systémy na platformě OpenVMS. Jedná se robustní systém mající z důvodu vysoké dostupnosti clusterové řešení. ABS obsahuje interní databází záloh, plánovač úloh, umožňuje hardwarové i softwarové kryptování. ABS nabízí i plně automatické zálohy souborových systémů. Klientská část ABS je dostupná na platformách OpenVMS, MS Windows a True 64 Unix. Pro použití ABS MML utilitou RMAN je nutné nainstalovat klientskou část ABS programu, nadefinovat logické systémové jméno abs_sbt a korektně nakonfigurovat následující MDMS parametry: Media definice typu použitého záznamového media. Location umístění zálohovacího serveru. Domain - popis domény. Node název serveru. Jukebox specifikace použitého jukeboxu. Tape drives specifikace použitých mechanik. Pool specifikace použité skupiny pásek. Tape volumes názvy použitých medií. Při alokaci kanálu je nutné definovat proměnou MDMS$SBT_CATALOG, což je lokální, na serveru uložená interní databáze záloh a dále MDMS$SBT_ARCHIVE, kde jsou specifikovány parametry nutné k připojení MDMS serveru. allocate channel ch1 type "sbt_tape" parms="env=(mdms$sbt_archive=ora_arch_m24, MDMS$SBT_CATALOG=ORACLE_DB_M24)"; 19

20 Obrázek č. 3: Topologie ABS/MDMS Cluster Databázový server A Databázové soubory MDMS$Server A Pásková knihovna A RMAN ABS klient Lokalita A Databázový server B Lokalita B Databázové soubory MDMS$Server B Pásková knihovna B RMAN ABS klient Zdroj: vlastní úprava ABS/MDMS je v současné době nabízen ve verzi EMC NetWorker NetWorker je produkt společnosti EMC. Jedná se o robustní a rozšířený komplexní zálohovací systém. EMC v minulosti zakoupilo tento produkt od společnosti Legato. Z tohoto historického důvodu je možné se často setkat s označením Legato NetWorker. 20

21 EMC NetWorker Server obsahuje kromě hardwarové části interní databázi záloh, robustní plánovač úloh, umožňuje plně automatické souborové zálohy a mnoho dalších modulů pro zálohování databází a aplikací: Networker Module for Oracle pro zálohování Oracle databází. Networker Module for IBM DB2 pro zálohování DB2 databází. Networker Module for IDM Informix. Networker Module for Lotus Notes/Domino. Networker Module for Microsoft Exchange Server. Networker Module for Microsoft SQL Server. Networker Module for SAP with Oracle. Networker Module for Sybase. Klientská část EMC NEetWorker Module for Oracle (NMO) je dostupná na platformách AIX, HP-UX, Linux, Solaris, True64 Unix a MS Windows. Pro využití NMO MML utilitou RMAN je nutné na databázový server nainstalovat klientskou část programu Networker, následně vlastní modul Networker Module for Oracle posléze nastavit konfigurační soubor nwora.res v případě platformy MS Windows, na unix platformě je nutné vytvořit symbolický link na knihovnu libobk.a. Další nastavení je nutné provést i na straně EMC Networker serveru Jedná se o parametry: NSR_SERVER NSR_GROUP NSR_CLIENT NSR_DATA_VOLUME_POOL NSR_SAVESET_BROWSE NSR_SAVESET_RETENTION NMO umožňuje provádění záloh dvěma způsoby: Lokálně řízené zálohování zálohovací skript je spuštěn manuálně nebo z lokálního plánovače úloh. Centrálně řízené spuštění záloh zálohovací skripty jsou spouštěny centrálně z NetWorker Serveru. 21

22 Obě varianty mají klady i zápory často ovlivněné střetem mezi databázovým administrátorem a správcem NetWorker serveru. Databázový administrátor je odpovědný za stav databáze i provedených záloh, ale většinou nemá možnosti monitorovat stav a zatížení NetWorker serveru, což v prostředí velké společnosti může při souběhu záloh z různých systémů způsobovat zahlcení NetWorker serveru. Správce NetWorker má zase detailní přehled o stavu svého serveru, nicméně není odpovědný za stav zálohovaných databází a serverů, často se ani neangažuje v případné obnově. Pro použítí v utilitě RMAN je nutné kanál alokovat následujícím způsobem: allocate channel t1 type 'SBT_TAPE'; send device type 'SBT_TAPE' 'ENV=(NSR_SERVER=<NetWorker_Server_name>, NSR_GROUP=<Group_name>)'; Obrázek č. 4: Topologie EMC NetWorker Zdroj: HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The EMC Networker Server je v současné době nabízen ve verzi

23 2.4 IBM Tivoli Storage Manager Tivoli Storage Manager (TSM) je produkt společnosti IBM. I v tomto případě se jedná o velmi rozšířený komplexní zálohovací systém. TSM obsahuje kromě hardwarové části interní SQL databázi, plánovač úloh umožňující plně automatické souborové zálohy, šifrování dat, pro zvýšení dostupnosti je možné ho využívat TSM v clusterové konfiguraci. TSM má také mnoho dalších modulů pro zálohování různých typů databází a aplikací. TSM server je možné provozovat na platformách IBM AIX, HP-UX, Windows, Sun Solária, OS/390, Linux. TSM klient je možné používat na platformách AIX, HP-UX, Linux, Macintosh, Novell NetWare, OS/390, OS/400, Sun Solaris, Windows, Citrix Presentation Server,True64 Unix a MS Windows. Pro využití TSM MML utilitou RMAN je nutné na databázový server nainstalovat klientskou část programu TSM Tivoli Data Protector for Oracle (TDPO) a na unix platformě nastavit konfigurační soubory tdpo.opt, dsm.sys, dsm.opt a include.def, dále je nutné vytvořit symbolický link na knihovnu libobk.a. Nastavení je nutné provést i na straně TSM serveru: Node a heslo verdeleted retonly backdelete frequency verexists retextra mode serialization Pro použití TDPO je nutné alokovat kanál následujícím způsobem: allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/home/oracle/rman/tdpo_sid.opt)'; 23

24 Obrázek č. 5: Topologie TSM Zdroj:HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The IBM Tivoli Storage Manager je v současné době nabízen ve verzi Symantec Veritas NetBackup Veritas NetBackup nabízí v současné době společnost Symantec, která toto enterprise zálohovací řešení odkoupila v roce 2005 od společnosti Openvision. Jedná se rozšířený, robustní zálohovací systém. Kompletní zálohovací řešení NetBackup se skládá z hardwarové a softwarové části, softwarová část obsahuje interní databázi, plánovač úloh umožňující plně automatické souborové zálohy, šifrování dat a optimalizované zálohovací algoritmy (synthetic backups). Symantec Veritas NetBackup dokáže spolupracovat s většinou dodavatelů páskových robotů, například s Dell, Exabyte, HP, IBM, Overland Data, Quasar, Quantum, Sony,Spectra Logic a SUNStorageTek. V současné době nabízí Symantec tři základní edice Veritas NetBackup: NetBackup Enterprise Server. NetBackup Server. NetBackup Starter Pack. 24

25 Veritas NetBackup nabízí širokou škálu agentů pro zálohování různých typů aplikací a databází: Lotus Notes and Lotus Domino Server. IBM DB2. Informix. Microsoft Active Directory. Microsoft Exchange Server. Microsoft SharePoint Portal Server. Microsoft SQL Server. Oracle. SAP. Sybase. Symantec Enterprise Vault. Veritas NetBackup for Oracle agent je dostupný na platformách HP-UX, HP True64 Unix, IBM AIX, Linux, Microsoft Windows, Novell NetWare, SGI IRIX a Sun Solaris. Pro používání Veritas NetBackupu je nutné na databázový server nainstalovat NetBackup Server software, NetBackup for Oracle a dále je nutné vytvořit symbolický link na knihovnu libobk.a. Pro zálohování Oracle databází je možné využít i samostatně licencovaný Netbackup for Oracle Advanced BLI (Block Level Incremental), který je součástí NetBackup Snapshot Client. Oproti standardnímu balíku redukuje množství zálohovaných dat. Při využití NetBackup MML je nutné alokovat kanál následujícím způsobem: allocate channel t1 type 'SBT_TAPE' parms 'ENV=(NB_ORA_SERV=server_name, NB_ORA_POLICY=RMAN_DEFAULT, NB_ORA_CLIENT=my_host_name), SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so64.1'; 25

26 Obrázek č. 6: Topologie NetBackup Zdroj: KUHL Darl; ALAPATI Sam; NANDA Arup. RMAN Recipes for Oracle Database 11g: Problem- Solution Approach Symantec Veritas NetBackup je v současné době dostupný ve verzi Oracle Secure Backup Zálohovací systém Oracle Secure Backup (OSB) dodává přímo dodavatel Oracle databáze firma Oracle. Z důvodu licenčních podmínek se v současnosti jedná o populární a výhodnou možnost využití entreprise zálohovacího řešení za přijatelnou cenu. Softwarová část umožňuje všechny obvyklé vlastnosti, které jsou od robustního zálohovacího řešení požadovány, tj. plná automatizace zálohování souborových systému i databáze, využívání Network Attached Storage (NAS), přenos záloh z Virtual Tape Library (VTL) na fyzické pásky. Zvláště se zaměřuje integraci s ostatními produkty dodávané s Oracle databázemi (Grid Control, Real Application Cluster, Automatic Storage Management a Data Guard), na šifrování ukládaných dat, optimalizuje rotační politiku záloh mezi lokalitami (tape vaulting) a optimalizační algoritmy při zálohování (Oracle udává % zrychlení oproti srovnatelným řešením ostatních dodavatelů při poklesu zatížení CPU o 10 %). 26

27 Oracle dodává OSB jako hotové řešení s hardwarovou knihovnou od firmy Sun StorageTek (v roce 2009 došlo k fůzi společností Sun Microsystem a Oracle), ale umožňuje také spolupráci s většinou dodavatelů páskových robotů. OSB umožňuje zálohovat souborové systémy a databáze v prostředí Microsoft Windows, Unix, Linux a NAS. Softwarová část je dodávána ve dvou verzích. Oracle Secure Backup Express je dodávána zdarma jako součást dodávky databázové softwaru a umožňuje zálohovat jeden databázový server na jednu páskovou mechaniku. Plná verze rozšiřuje nabízené možnosti o podporu VTL, Fibre Channel a šifrování. Při užívání OSB je nutné mít nainstalovaný administrativní server, media server a klientskou část OSB. Pro využití v utilitě RMAN je možné alokovat kanál následujícím způsobem: allocate channel ch1 device type sbt parms `env=(ob_device=drive3,ob_media_family=medfami1)`; Obrázek č. 7: Topologie OSB, varianta samostatný server Zdroj: HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The Oracle Secure Backup v současné době dostupný ve verzi

28 3 Výběr vhodného režimu zálohování Výběr vhodné zálohovací strategie závisí na mnoha faktorech a ve výsledku je ve většině případů založen na kompromisu mezi chtěným a možným. Databáze Oracle standardně umožňuje obnovu k poslední vytvořené záloze, na kterou lze následně aplikovat archivní redology. Podle situace a požadavků je databázi možné obnovit do dvou různých stavů. Kompletní obnova nepředstavuje žádnou ztrátu dat, naproti nekompletní obnova se využívá v situacích, kdy není možné databázi plně zotavit, ať už z chtěných důvodů (návrat databáze před okamžik chyby) či nechtěných (ztráta online redologů, nečitelnost zálohy atd.). Jak již bylo zmíněno výše, Oracle databáze umožňuje zálohování ve dvou různých stavech. Offline záloha představuje konzistentní zálohu, která vznikla při uzavřené databázi. Při využití prostředků OS jde o kompletně uzavřenou databázi, při využití utility RMAN pak je databáze ve stavu mount. Online záloha je oproti tomu vytvořena při otevřené databázi a je tedy z podstaty nekonzistentní a pro obnovu databáze je nutné aplikovat redology. Při záloze prostředky OS je nutné přepínat tabulkové prostory do stavu begin backup a end backup, při záloze utilitou RMAN to nutné není. Online zálohování předpokládá, že databáze je provozována v archivním režimu. Produkční Oracle databáze často není možné zálohovat v režimu offline, neboť tento typ zálohy vždy znamená její nedostupnost po dobu zálohování. Pokud rovnou pomineme databáze, které operují v režimu 24x7, i ostatní databáze, které mají požadovanou dostupnost jen v pracovních hodinách, není možné odstavovat v nočních hodinách, protože v té době probíhají systémové a aplikační údržbové úlohy, které není možné a ani žádoucí spouštět během denního provozu. Z výše uvedených důvodů proto bývají databáze zálohovány především v režimu online. Pro ochranu databáze a s ní související obnovu je ideální mít k dispozici co nejčerstvější plnou zálohu databáze. Obchodní útvary často požadují vytvořit zálohu před spuštěním EOD a v ranních hodinách před otevřením systému pro běžné uživatele. Lze se také setkat s požadavkem na velmi časté, i hodinové zálohování archivních redologů databáze, aby se co nejvíce minimalizovala ztráta dat během případné obnovy a zotavení databáze. V reálných podmínkách ale většinou není možné dělat zálohu 28

29 databáze častěji než jednou denně. Záloha archivních redologů pak probíhá dvakrát denně. Protože záloha vždy představuje znatelné zatížení zálohované databáze (CPU, IO), je snaha databáze zálohovat v době nejmenšího zatížení systému, což bývá zpravidla během nočních hodin. S růstem velikosti databáze se navíc na stávajícím zálohovacím zařízení čas potřebný k záloze protahuje, dochází ke kolizním špičkám mezi souběžně zálohovanými systémy. Pro efektivní plánování doby zálohování hraje velký význam, zda má databáze na zálohovacím zařízení dedikované mechaniky nebo zda zálohuje na sdílené. V druhém případě je pak nutná koordinace s dalšími administrátory a správcem zálohovacího systému. V další části budu popisovat režimy zálohování pouze utilitou RMAN, neboť zálohování prostředky OS je již v dnešní době považované za zastaralé a neplnící důležité požadavky (optimalizování průběhu zálohování, přírůstové zálohy, retention politika). Dodavatel databáze společnost Oracle doporučuje využívat utilitu RMAN. Dobu trvání zálohy i případné obnovy je možné zkrátit rozvlákněním. Podmínkou pro tento režim je existence více dostupných mechanik v zálohovacím systému. V utilitě RMAN je tento režim zajištěn použitím dalších kanálů, kdy si každý kanál alokuje jednu mechaniku (i LVT). V praxi se využívají dva až čtyři kanály. Běžně použití dvou kanálů znamená zkrácení doby potřebné na provedení zálohy na polovinu. Efektivita alokování více kanálů závisí na použitém zálohovacím systému i na hardwarové konfiguraci. Rozvláknění má ale i negativní stránku, neboť rozvlákněním roste riziko nečitelnosti medií a znamená i násobně větší zatížení jak vlastní databáze, tak i přenosové infrastruktury a zálohovacího systému. Ochranu zálohovaných dat na mediích je možné zvýšit režimem duplex během alokování kanálu. Stejně jako v předchozím případě i zde je nutné alokovat více mechanik. V podstatě to znamená, že při režimu duplex=2 každý kanál zapisuje na dvě mechaniky stejná data, databáze je tedy v jeden čas zazálohovaná dvakrát a data uložená na páskách jsou identická. V případě nečitelnosti jedné sady pásek je možné databázi obnovit ze záložní sady. Duplex režim, stejně jako předchozí režim rozvláknění, znamená v závislosti na počtu použitých kanálů násobné zatížení infrastruktury, ale čas potřebný k záloze i obnově databáze zůstává stejný jako použití jednoho vlákna. Cenou za vyšší bezpečnost je tedy větší zatížení infrastruktury při zachování délky zálohy i obnovy. 29

30 3.1 Úplná záloha databáze Úplná záloha databáze je nejčastějším typem zálohy. Z hlediska správy a případné obnovy přestavuje nejsnadnější a nejrychlejší možnost obnovy databáze. Během zálohy se kromě řídících a konfiguračních souborů zálohují všechny databázové soubory. Následně je nutné zálohovat vzniklé archivní redology. Doba trvání zálohy je ale ze všech popisovaných možnosti nejdelší. Pokud to neznamená problém, je možné tento typ trvale používat. 3.2 Přírůstková záloha databáze Pokud není možné databázi zazálohovat v požadovaném čase, je nutné přikročit k úpravě dosavadní zálohovací strategie. Jednou z možností je použití přírůstkové (inkrementální) zálohy. V určený den, typicky v době slabšího provozu během víkendu, je provedena speciální plná záloha databáze a v dalších dnech se v různých režimech zálohují pouze změněné databázové bloky. V případě obnovy je nejdříve aplikovaná nejčerstvější plná záloha, na ní jsou aplikovány nejnovější přírůstky a poté proběhne zotavení databáze za použití archivních redologů. Možné režimy jsou následující: Incremental level 0(L0) - speciální plná záloha databáze. Incremental level 1(L1) - rozdílová záloha databáze vztažená k jakékoli přírůstkové záloze databáze. Incremental level 1 cumulative(l1c) - kumulativní záloha databáze vztažená k počáteční záloze L0. Zvolení způsobu provádění záloh záleží na režimu databáze (OLTP versus Datawarehouse). Zvolený typ inkrementální zálohy také ovlivňuje případnou délku obnovy, neboť při využívání pouze L1 se nám zkrátí každodenní záloha, nicméně pro obnovu budeme potřebovat kromě L0 i několik L1 záloh, což obnovu prodlouží. Použití L1 cumulative naopak znamená, že denní zálohy budou delší, nicméně případná obnova využije pouze L0 a jednu L1C zálohu. Další možností zkrácení doby zálohování představují přírůstkově aktualizované zálohy, když se pouze aktualizuje L1 zálohou poslední L0 záloha. 30

31 Obrázek č. 8: Obecné schéma zálohování databázového serveru na MMS L0 L1 L1 L1 L1C L1C L1 Den 0 Den 1 Den 2 Den 3 Zdroj: vlastní úprava Výrazného zrychlení přírůstkového zálohování je možné docílit i sledováním změn bloků v souboru sledování změn (block tracking file). Během zálohy pak RMAN nekontroluje každý blok databáze, zda se změnil, ale pouze zálohuje již zaznamenané změněné bloky ze souboru změn. Využití této metody sice přináší nepatrně zvýšenou zátěž, neboť databáze musí změny bloků zapisovat i do souboru, nicméně u rozsáhlých databází přináší použití souboru sledování změn významné úspory času během přírůstkové zálohy. Jak je patrné i na následujícím testu, zavedení přírůstkového zálohování sice výrazně zkracuje dobu záloh a množství ukládaných dat a v případě sdíleného zálohovacího systému i výrazně snižuje celkové zatížení (CPU, IO, síťové spojení), nicméně může mít negativní důsledky, protože znamená prodloužení doby potřebné na obnovu databáze. U méně důležitých systémů je možné přírůstkové zálohování bez většího váhání nasadit (typicky testovací a vývojová prostředí), ale u produkčních systémů je vždy nutné posoudit negativní vliv na délku případné obnovy, zvláště u systému, které se rychle mění. Z toho vyplývá, že přírůstkové zálohování je méně vhodné pro databázové systémy typu OLTP. V následující tabulce je možné vidět časy z jednotlivých testů, které předcházely zavádění přírůstkových záloh v naší společnosti. Cílem testů bylo porovnat doby zálohy a případné obnovy i se započítáním případné obnovy po pěti dnech přírůstkových záloh. Protože se jedná o sdílené prostředí, a to jak na úrovni serveru, tak i na úrovni zálohovacího systému TSM a koneckonců i na síťové vrstvě, není možné zabránit určitému 31

32 zkreslení testů, neboť nebylo možné utlumit provoz ostatních systémů. Z tohoto důvodu byly testy prováděny opakovaně. Testy byly prováděny na Oracle Database 10g Enterprise Edition Release za použití TSM(TDPO). Konfigurace serveru: System Model: IBM, A; Processor Type: PowerPC_POWER5 Number Of Processors: 4 Processor Clock Speed: 1648 MHz CPU Type: 64-bit Memory Size: MB Tabulka č. 1: Testování délky záloh a obnovy databáze CLDDEV2 backup Akce start stop trvání size/mb 1 full backup 9:02:50 9:07:10 0:04: incremental 0 9:09:51 9:14:20 0:04: create 2 tables & update 1GB data 4 incremental 1 10:05:26 10:09:07 0:03: create 2 tables & update 1GB data 6 incremental 1 10:14:29 10:17:49 0:03: create 2 tables & update 1GB data 8 incremental 1 10:22:18 10:25:28 0:03: create 2 tables & update 1GB data 10 incremental 1 10:30:03 10:33:14 0:03: create 2 tables & update 1GB data 12 incremental 1 11:06:35 11:09:55 0:03: incremental 1 cumulative 11:37:46 11:41:26 0:03: použité savesety z akcí ve sloupci restore backup 1 restore (1) 9:37:45 9:45:53 0:08:08 restore (1) 9:50:00 9:58:07 0:08:07 2 restore (2) 10:17:30 10:25:48 0:08:18 restore (2) 10:30:11 10:38:08 0:07:57 3 restore ( ) 10:44:53 10:55:14 0:10:21 restore ( ) 10:59:16 11:10:22 0:11:06 restore ( ) 11:18:22 11:29:24 0:11:02 4 restore (2+13) 11:32:26 11:42:33 0:10:07 restore (2+13) 11:47:53 11:57:40 0:09:47 restore (2+13) 12:02:26 12:12:50 0:10:24 Zdroj: vlastní úprava 32

33 Tabulka č. 2 Testování délky záloh a obnovy databáze s použitím souboru sledování změn. CLDDEV2 block change tracking file backup akce start stop trvání size/mb 1 full backup 8:28:33 8:32:42 0:04: incremental 0 8:33:28 8:37:18 0:03: create 2 tables & update 1GB data 4 incremental 1 8:42:17 8:42:46 0:00: create 2 tables & update 1GB data 6 incremental 1 8:51:34 8:52:02 0:00: create 2 tables & update 1GB data 8 incremental 1 8:56:09 8:56:39 0:00: create 2 tables & update 1GB data 10 incremental 1 9:00:16 9:00:46 0:00: create 2 tables & update 1GB data 12 incremental 1 9:03:16 9:03:46 0:00: incremental 1 cumulative 9:06:44 9:08:12 0:01: použité savesety z akcí ve sloupci restore backup 1 restore (1) 9:20:11 9:28:55 0:08:44 restore (1) 9:36:15 9:44:53 0:08:38 2 restore (2) 9:49:57 9:58:26 0:08:29 restore (2) 9:59:47 10:08:02 0:08:15 3 restore ( ) 10:10:03 10:20:10 0:10:07 restore ( ) 10:22:04 10:32:01 0:09:57 restore ( ) 10:32:05 10:42:55 0:10:50 4 restore (2+13) 10:43:51 10:54:06 0:10:15 restore (2+13) 10:53:58 11:04:25 0:10:27 restore (2+13) 11:04:16 11:14:54 0:10:38 Zdroj: vlastní úprava V první tabulce je možné vysledovat, že přírůstková záloha neznamenala podstatnou úsporu času, jen kolem 27 %. Množství ukládaných dat se snížilo o 90 %. Doba obnovy se průměrně protáhla o 37 %. V druhé tabulce, která popisuje přírůstkové zálohování při použití souboru sledování změn, je již zkrácení zálohy razantní o více než 87 %. Doba obnovy se oproti prvnímu testu nezměnila, množství ukládaných dat se dokonce nepatrně snížilo. Z testů vyplývá vysoká důležitost použití souboru pro sledování změn, zátěž generovaná plněním tohoto souboru nebyla měřitelná. 33

34 3.3 Přírůstkově aktualizované zálohy Další možností, jak zefektivnit přírůstkovou zálohu a obnovu databáze, je možnost pravidelně aktualizovat L0 level zálohu. Zálohovací plány jsou často postaveny na režimu, kdy o víkendu proběhne přírůstková L0 záloha databáze (plná záloha databáze) a další dny až do dalšího víkendu probíhá již pouze L1 či L1C záloha. Z tohoto faktu plyne, že pokud nastane potřeba obnovy databáze těsně před vznikem další L0 zálohy, je při obnově nutné na starou L0 zálohu aplikovat několik dalších L0 či L1C přírůstkových záloh. Doba obnovy se na naší testovací databázi v takovém případě prodloužila o 37% (tabulka č.1 a č.2.),nicméně záleží na velikosti a provozu takové databáze. V reálném provozu tak může dojít k výraznému prodloužení doby obnovy. Tuto situaci lze vyřešit pravidelným aktualizováním přírůstkové L0 zálohy. Máme tak k dispozici vždy čerstvou L0 zálohu, což vede k výraznému zkrácení doby obnovy. Dalším pozitivem je fakt, že v tom případě není nutné ani periodicky zatěžovat infrastrukturu i databázi víkendovým vytvářením L0 zálohy, neboť máme tuto zálohu stále aktuální. Aktualizace L0 zálohy se používá ve dvou základních režimech: L0 záloha je stará 1 den a je na ní v případě potřeby aplikována jedna L1C záloha. run { recover copy of database with tag 'LEVEL_0'; backup incremental level 1 cumulative copies=1 for recover of copy with tag 'LEVEL_0' database; } Přírůstková záloha je ihned aplikována na L0 zálohu a plná záloha je vždy plně aktuální. run { backup incremental level 1 cumulative copies=1 for recover of copy with tag 'LEVEL_0' database; recover copy of database with tag 'LEVEL_0'; } 34