4.

SIGURNOSNE KOPIJE I OPORAVAK BAZE PODATAKA

Podaci predstavljaju jedan od najznaajnijih resursa u organizaciji. Tokom godina poslovanja
organizacije prikupe mnogo podataka o svojim kupcima, imovini, ulaganjima, prozvodima i sl.
Ti podaci se koriste u cilju unapreenja poslovanja organizacije. Zbog svog znaaja za preduzee
nemogunost pristupa takvim podacima je neprihvatljiva i moe biti pogubna za poslovanje.
Svaki sat nedostupnosti moe znaiti gubitak u milionskim iznosima. Da bi se obezbedilo
nesmetano poslovanje u preduzeima se implementiraju razliita reenja kojima se nastoji
obezbediti dostupnost podataka ak i u sluaju pojave nekih problema poput problema sa
elektrinom energijom, kvar na disku ili pad servera. Problemi poput grekom obrisanih
podataka od strane korisnika, nemogunost pristupa podacima usled problema sa softverom nisu
pokriveni ovakvimm reenjima. Sve nabrojano ukazuje na potrebu za stalnim kreiranjem
rezervnih kopija podataka da bi se spreio njihov gubitak. Poseban problem predstavljaju
vanredne situacije poput: zemljotresa, poplava, poara i uragana koje mogu biti pogubne po
preduzee. U takvim okolnostima nije dovoljno samo posedovanje rezervnih kopija ve je
imperativ da one budu na drugoj lokaciji van opasnosti od unitenja.

4.1. POTREBA ZA REZERVNIM KOPIJ AMA PODATAKA

Rezervna kopija predstavlja glavnu komponentu plana kreiranja sigurnosnih kopija i
oporavka podataka. Ukoliko iz bilo kog razloga baza podataka postane nedostupna putem
rezervne kopije se moe izvriti oporavak baze i tako je dovesti u stanje pre pada. Samim tim
jedan od najvanijih zadataka administratora treba da bude redovno kreiranje kopija. To
podrazumeva pravljenje konzistentnih kopija podataka obino u formi image fajlova.
Razliiti su uzroci koji mogu dovesti do potrebe za oporavkom baze podataka. Moemo ih
podeliti na:
Hardver nekada je hardver bio glavni uzrok oporavka. Mada je danas hardver
uglavnom pouzadan opet moe doi do kvara pojedinih komponenti kao to su diskovi,
kontroleri i sl.
Greke u samim aplikacijama u aplikacijama mogu postojati greke (tzv. bug) koje
mogu dovesti do neeljenih izmena nad podacima. Da bi se to spreilo potrebno je da
aplikacije pre upotrebe budu podvrgnute testiranju. Meutim, ponekad se moe desiti da
uprkos testiranjima aplikacija i dalje sadri greke koje jo nisu otkrivene.
Padovi operativnog sistema poput baze podataka operativni sistem takoe moe da
padne. Pogreni drajveri, ne auriranje sigurnosnim zakrpama su samo neki od uzroka
koji mogu dovesti do problema u radu operativnog sistema.
Korisnike greke pored greaka u samim aplikacijama korisnici su najei uzrok
potrebe za oporavkom. Nepaljivo auriranje podataka esto dovodi do potrebe za
oporavkom.
Sigurnosni propusti danas sve vie dobijaju na znaenju. Loe podeavanje firewall-a,
odsustvo bilo kakvog antivirusnog programa, neadekvatno dodeljene privilegije
korisnicima sve to moe dovesti do neovlatenog pristupa i izmene nad podacima.
Vanredne situacije elementarne nepogode kao to su: poplave, uragani, poari i sl.

Sigurnosne kopije i oporavak baze podataka

2

Prilikom kreiranja rezervne kopije potrebno je odluiti da li e se kreiratu puna kopija ili
inkrementalna. Puna rezervna kopija predstavlja kompletnu kopiju svih podataka. U ovom
sluaju glavni problem moe nastati ukoliko je re o velikim bazama podataka jer da bi se
kreirala kopija potrebno je mnogo vremena a i prostora na medijumu (disku ili traci).
Inkrementalne kopije (ponekad nazvane i diferencijalne) obuhvataju podatke koji su pretrpeli
izmene od poslednje izrade sigurnosne kopije. To znai da je za njih potrebno manje vremena da
se kreiraju kao i da zauzimaju manje prostora. Nedostatak jeste da se samo putem njih nemoe
izvriti oporavak ve je potrebno da postoji i puna kopija koja e posluiti kao osnova.
Osim podataka mogue je i kreiranje kopije indeksa. I dok je kod nekih SUBP to opcija kod
drugih se to podrazumeva. Potrebno je da administrator analizira isplativost kreiranja kopija
indeksa. Pitanje treba da bude da li kreirati rezervnu kopiju i kasnije je iskoristiti pri oporavku ili
je moda bolje reenje ponovo ih kreirati kada se jednom izvri oporavak. Ukoliko je re o veim
bazama podataka gde je prisutno mnogo indeksa svakako da je bolje reenje kreiranje
sigurnosnih kopija indeksa.
Administrator treba da odredi koliko e se esto kreirati sigurnosne kopije. Pri tome treba
imati na umu sledee:
Koliko su podaci vani za poslovanje? Koliki je gubitak u sluaju da podaci postanu
nepristupani?
O kakvim podacima je re? Da li su u pitanju podaci kojima se pristupa samo radi itanja
ili su podloni i izmenama?
Da li postoji vremenski period u toku dana kada je smanjen broj pristupa bazi podataka
tako da se moe pristupiti kreiranju sigurnosne kopije bez da se ometa poslovanje
preduzea?
Kolika je veliina baze podataka i koliko je vremena potrebno za razliite tipove
rezervnih kopija? Da li je to vreme prihvatljivo? Ukoliko je re o izuzetno velikoj bazi
podataka, kreiranje rezervnih kopije e zahtevati znatan prostor i vreme.
Na kom medijumu se smetaju rezervne kopije? Preporuljivo je da se rezervne kopije
prvo kreiraju na disku pa potom prebace na drugi medij: drugi disk, traku a ukoliko je
re i o manjim kopijama moe i na DVD-u.
Da li se rezervna kopija prebacuje na nekoliko razliitih medija koji se potom alju na
druge lokacije?
Preporuljivo je da se izvri i analiza kritinosti i dinaminosti (podlonosti promenama)
podataka. U tu svrhu moe se iskoristiti dijagram sa slike 1. na sledeoj strani. Apscisa prikazuje
vanost podataka i to od nekritinih podataka koji su lako zamenljivi pa do kritinih koji su
vitalni za preduzee. Na ordinanti je prikazana njihova promenljivost i to od podataka koji su
statini (nepromenljivi) pa do dinaminih podataka. Da bi se dijagram mogao koristiti potrebno
je prvo analizirati podatke i postaviti ih na dijagram. Nakon to se ustanovi poloaj na dijagramu
moe se odrediti koliko je esto potrebno kreirati rezervnu kopiju svakog objekta. Potrebno je
esto kreirati sigurnosne kopije podataka koji su kritini i promenljivi.
U prvom kvadrantu e biti podaci koji su kritini za poslovanje i podloni su estim
izmenama. Budui da je re o vrlo bitnim podacima potrebno je ee praviti rezervne kopije.
Preporuljivo je kreiranje svakodnevno.
U drugom kvadrantu se nalaze podaci koji su kritini za poslovanje preduzea ali ih
karakterie statinost. Kada je u pitanju ova grupa podataka preporuuje se kreiranje kopija
jednom nedeljno.
Sigurnosne kopije i oporavak baze podataka

3

U treem kvadrantu su podaci koji su podloni estim izmenama ali nisu toliko vitalni za
poslovanje preduzea. Re je o podacima kod kojih svi ne moraju biti obuhvaeni sigurnosnom
kopijom.
U etvrtom kvadrantu su podaci koji su najmanje vani za poslovanje preduzea. Re je o
podacima koji se lako mogu ponovo obnoviti iz drugih izvora.
Ukoliko se u preduzeu nalazi vie baza podataka potrebno je analizirati svaku od njih. Neke
od njih su kritine za poslovanje firme i ukoliko doe do njihovog pada potrebno ih je to je
mogue pre obnoviti.
















Slika 1. Kritinost i dinaminost podataka

Osim rasporeda administrator treba da odlui i koliko verzija kopija eli da uva. uvanjem
dodatnih verzija obezbeuje se oporavak baze podataka u sluaju pojave bilo kakvog problema
prilikom upotrebe poslednje verzije rezervne kopije tako to e se upotrebiti prethodna verzija.
Perod uvanja rezervnih kopija trebalo bi da bude dva ciklusa. Dakle osim poslednje kreirane
kopije treba da postoji jo najmanje jedna kreirana ranije. U skladu sa brojem kopija koje se
uvaju potrebno je uvati i odgovarajui broj dnevnika.
Sledei saveti su vezani za kreiranje kopija tako da se obezbedi efikasan oporavak:
Istu rezervnu kopiju potrebno je kopirati na nekoliko medija da bi se izbegla neupotre-
bljivost usled oteenja medija na kom se nalazi (trake ili diskovi),
Potrebno je da strategija kreiranja rezervnih kopija bude usklaena sa strategijom
oporavka u sluaju vanrednih situacija. Mnogi alati za rezervne kopije obezbeuju
mogunost simultanog kreiranja lokalnih i offsite sigurnosnih kopija,
Za svaki objekat u bazi podataka potrebno je uvati dve verzije rezervne kopije tako da
ukoliko poslednje kreirana verzija postane neupotrebljiva se moe izvriti oporavak
koristei stariju verziju,
Rezervna kopija se moe prvo kreirati na disku na kom se nalazi i baza podataka pa
potom se prebaciti na traku ili drugi disk,
Da bi se smanjio broj traka ili diskova potrebnih za smetanje rezervnih kopija
preporuljivo je izriti kompresovanje fajlova,
1 2
4 3
Statini Dinamini
N
e
k
r
i
t
i

n
i

K
r
i
t
i

n
i

V
a

n
o
s
t

p
o
d
a
t
a
k
a

Promenljivost podataka
Sigurnosne kopije i oporavak baze podataka

4

Neophodno je da u plan kreiranja rezervnih kopija i oporavka bude ukljuen i sistem
katalog objekata baze objekata.
Potrebno je obezbediti da se zapoeti proces kreiranja rezervnih kopija moe nastaviti
ukoliko doe do prekida. Primera radi, ukoliko je za kreiranje rezervne kopije potrebno
3h, a do prekida doe nakon 2h i 30 minuta ukoliko se proces ne moe nastaviti potrebno
je poeti sve od poetka.
Preporuljivo je da kada se jednom kreira rezervna kopija proveri njenu ispravnost.
Podaci koji se ne nalaze u bazi podataka ali se upotrebljvaju od strane aplikacija baze
podataka treba takoe da su ukljueni u rezervnu kopiju.
Razliiti SUBP se meusobno razlikuju po opcijama koje poseduju kada je su u pitanju
rezervne kopije i oporavak podataka. Zbog toga je vano da administrator bude upoznat sa
mogunostima konkretnog SUBP -a.
Na kraju potrebno je reiti i uvanje rezervnih kopija. uvanje na istoj lokaciji na kojoj je i
firma predstavlja loe reenje. Glavni razlog za to lei u injenici da u sluaju bilo kakve
vanredne situacije objekti firme mogu biti uniteni a time i sigurnosne kopije.




Slika 2. New Orleans (USA) nakon uragana Katrina 2005. godine
Preduzea koja su uvala sigurnosne kopije na istoj lokaciji gde je i sedite su nepovratno
izgubila svoje podatke

Da bi se to spreilo organizacije pohranjuju podatke na udaljenim lokacijama (remote
locations). U sluaju da su finansijska sredstva ograniena alternativu predstavljaju kompanije
koje obezbeuju infrastrukturu za uvanje u svojim objektima. Tipian primer ovakve kompanije
jeste Iron Mountain (slika 3.) sa seditem u Bostonu. Podaci se uvaju daleko od bilo kog grada
u zabaenom planinskom mestu, duboko ispod povrine zemlje. Iron Mountain je osnovana
1951. godine kada je otkupljen veliki naputen rudnik. Objekat je ureen i sadri veliki broj
nivoa sa prostranim hodnicima toje bilo idealno za stvaranje podzemne baze. Rudnik je i u
vreme hladnog rata sluio za sline stvari za koje slui i danas, brojne firme i ustanove su
odlagale svoje arhive, proizvode ili predmete od vrednosti. Sa sve veim prisustvom raunara u
savremenom poslovanju i budui da su firme ukinule papirno poslovanje to je i ova kompanija
svoj podzemni objekat dobrim delom preorijentisala, te on danas slui za arhiviranje elektronskih
dokumenata. U podzemnim hodnicima se nalaze raunari, monitori, bekap serveri ime je
Sigurnosne kopije i oporavak baze podataka

5

dobijen data centar. Precizna lokacija ovog centra nije poznata iroj javnosti, jedino to se zna
jeste da se nalazi u oblasti Gvozdenih planina u amerikoj dravi Pensilvanija. Nepostoje nikakvi
putokazi niti natpisi, ve oni koji dolaze, dolaze iskljuivo po pozivu i dobijaju pisana uputstva.



Slika 3. Iron Mountain, ulaz u objekat (levo), raunaski centar (u sredini), serveri
za smetanje podataka (desno)

U Evropi postoji slino reenje koje postoji u okolini Kampfberga u Austriji. Objekat je po
svojoj nameni i nainu funkcionisanja veoma slian prethodnom. earthDATAsafe (slika 4.) je
otvoren novembra 2003. godine. Pokreta projekta je kompanija Daimler Chrysler Consult Graz
Gmbh. Raunarski centar je ukopan 250 metara ispod planine i od poetka je zamiljen kao
bezbedan raunarski centar za razliko od amerikog objekta koji je nastao adaptacijom
naputenog rudnika.



Slika 4. earthDATAsafe: levo unutranjost objekta. Jedan od ulaza u objekat (desno)

4.2. ALTERNATIVNI PRISTUPI IZRADI REZERVNIH KOPIJ A
4.2.1. Upotreba opcije export za kreiranje logikih kopija
Alternativa tradicionalnoj izradi rezervnih kopija baze podataka jeste da se umesto kreiranja
kopija vri se export ili unload podataka. Kopije podataka koje su dobijene na ovaj nain
nazivaju jo i logike budui da se obuhvataju samo podaci. Njihova prednost je u sledeim
sluajevima:
Nadogradnja SUBP-a ponekad se desi da proizvoa SUBP-a izvri izmene u samoj
strukturi baze podataka,
Oporavak objekta ili reda u sluaju da doe do brisanja tabele ili redova u tabeli mnogo
e se bre izvriti oporavk primenom logikih kopija,
Sigurnosne kopije i oporavak baze podataka

6

Migracije izmeu razliitih baza podataka i razliitih operatvinih sistema primera radi,
ukoliko se u organizaciji koristi Oracle, razliita e biti struktura fajla na OS/390 od one
na WindowsNT.
Migracije podataka esto se moe ukazati potreba da se podaci sele unutar
organizacije: na druge SUBP, u programima za tabelarna izraunavanja i sl. Logike
kopije obezbeuju laku migraciju podataka kad i gde je to potrebno.
4.2.2. Upotreba Storage Management softvera za izradu kopija
Storage management softver prua mogunost kreiranja kopija fajlova. Pojedini SUBP mogu
i da sarauju sa Storage Management softverom kao na to je sluaj primer IBM-ovim DFSMS i
DB2. Kod upotrebe ovakvog softvera potrebno je da objekti baze podataka za koje se kreira
kopija budu ili u offline ili u reimu itanja. Ukoliko se kasnije ukae potreba za oporavkom
objekta njegov oporavak e se izvriti upotrebom storage managment.
4.3. REZERVNE KOPIJ E U SQL Server-u 2005

U SQL Serveru 2005 korisnicima je omogueno da biraju izmeu nekoliko opcija kada je u
pitanju kreiranje sigurnosnih kopija podataka:
1. Pune rezervne kopije,
2. Parcijalne rezervne kopije,
3. Rezervne kopije fajla/grupe fajlova i
4. Diferencijalne rezervne kopije

Pune rezervne kopije - podrazumevaju celokupnu kopiju podataka kao i log zapisa potrebnih za
oporavak. Budui da ukljuuje sve potrebne elemente ovaj tip rezervnih kopija se moe
posmatrati kao osnova za oporavak. Prilikom samog procesa kreiranja kopije SQL Server vri
zapisivanje u dnevnik da bi se po zavretku nastali zapis zajedno sa kopijom smetao na medij
(disk ili traku). Prednost ovog tipa je svakako jednostavnost njegove upotrebe dok je glavni
nedostatak pre svega vreme i potreban prostor za smetanje kopije ukoliko su u pitanju velike
bazama podataka. SQL Server prua mogunost da se puna kopija kreira upotrebom Transact-
SQL-a (T-SQL u daljem tekstu) ili putem SQL Server Management Studia.
Kada je u pitanju T-SQL opti izgled sintakse je:

backup database ImeBaze
to disk=Lokacija
with description=ImeBaze_Puna rezervna kopija

SQL Server putem Management Studia prua mogunost kreiranja sigurnosne kopije putem
grafikog interfejsa. Da bi se kreirala rezervna kopija potrebno je prvo odabrati bazu podataka,
pritisnuti desni taster mia i odabrati Tasks pa zatim Backup. Pojavie se prozor koji prikazuje
slika 5. Da bi se kreirala kopija potrebno je odabrati za Backup type Full, u polje Name upisati
ime i u polje Description napisati blii opis. U okviru Back up to potrebno je dodati lokaciju na
kojoj elimo da se kreira kopija.

Sigurnosne kopije i oporavak baze podataka

7



Slika 5. Prozor za kreiranje sigurnosne kopije

Parcijalne sigurnosne kopijepredstavljaju novu opciju u SQL Serveru 2005 i treba ih razlikovati
od diferencijalnih. Primenjuju se uglavnom kada su u pitanju baze podataka kojima se pristupa
samo radi itanja. Obuhvata primarne fajlove, fajlove za itanje i pisanje i druge specifikovane
fajlovi kojima se pristupa samo radi itanja.
Opti oblik T-SQL sintakse:

backup database ImeBaze read_write_filegroups
to disk=lokacija
with description=Parcijajlna rezervna kopija svih read/write fajlova

Rezervne kopije fajla/grupe fajlova - SQL Server 2005 prua mogunost da se umesto kreiranja
rezervne kopije celokupne baze podataka odabere fajl ili odreena grupa fajlova. Ovaj tip je
primenljiv usluaju da baza podataka sadri veliki broj fajlova to moe biti pogodno ukoliko je
re o velikim bazama podataka.
Opti oblik T-SQL sintakse:

backup database ImeBaze
filegroup=ImeGrupeFajlova
to disk=lokacija
with description=ImeBaze ImeGrupeFajlova reyervna kopija fajlova

Osim T-SQL sigurnosne kopije fajla/fajlova se mogu kreirati i putem Management Studia.
Koraci su slini kao i kad su u pitanju pune rezervne kopije celokupne baze podataka samo to
je u okviru Backup component potrebno odabrati File and filegroup nakon ega e se pojaviti
prozor za odabir fajlova, slika 6 gde je potrebno odabrati fajlove koje elimo da ukljuimo u
kopiju.

Sigurnosne kopije i oporavak baze podataka

8



Slika 6 Kreiranje sigurnosne kopije fajlova

Diferencijalne rezervne kopije obuhvataju samo podatke koji su pretrpeli izmene od poslednje
rezervne kopije.
Opti oblik T-SQL sintakse:

backup database ImeBaze
to disk=lokacija
with diferential, description=ImeBaze diferencijalna rezervna kopija

Kreiranje diferencijalnih kopija putem Management Studia podrazumeva korake kao i u sluaju
punih kopija s tim to je pod Backup type potrebno odabrati Diferential.
4.3.1. COPY-ONLY KOPIJE U SQL Serveru 2005
Predstavljaju novinu u verziji 2005. Glavni razlog za njihovu implementaciju jeste da
prilikom kreiranja copy-only kopija SQL Server ne vri zapisivanje informacija o njihovom
kreiranju. Ukoliko to ne bi bio sluaj mogao bi se javiti problem koji najbolje ilustruje sledei
primer. U organizaciji je implemetirana strategija da se pune rezervne kopije kreiraju vikendom
dok se preko nedelje svakodnevno kreiraju diferencijalne. Primera radi, ukae se potreba da se
kreira kopija baze koja e se iskoristiti za testiranja. U sluaju da se kreira puna rezervna kopija,
SQL Server e vriti zapis o procesu tako da e kada se pristupi redovnom kreiranju
diferencijalne kopije bie obuhvaeni samo podaci koji su se izmenili od poslednje pune
rezervne kopije a to e biti ona koja je kreirana preko nedelje za potrebe testiranja a koja vie
nije raspoloiva. Ovaj tip kopija se moe krerati samo putem T-SQL -a:

backup database ImeBaze
to disk = 'lokacija'
with copy-only

Sigurnosne kopije i oporavak baze podataka

9

4.3.2. REZERVNE KOPIJE DNEVNIKA
Izmene nad podacima u bazi podataka se zapisuju od strane SUBP-a u poseban fajl koji se
obino zove transakcioni dnevnik. Transakcioni dnevnik sadri zapise o transakcijama (drugim
reima modifikacijama) uinjenim nad podacima u bazi podataka. U fajlu e se vriti zapisi za
svako uspeno izvravanje SQL iskaza insert, update i delete. Kako vreme prolazi broj izmena
nad bazom podataka e rasti ime e se poveavati i dnevnik baze. Budui da se putem rezervne
kopije dnevnika moe izvriti oporavak baze podataka na tekue stanje razumljiva je potreba da
se pored podataka prave rezervne kopije dnevnika baze. Kada je u pitanju SQL Server 2005
kopije dnevnika su potrebne u sluaju da su odabrani Full ili Bulk-Logged reimi oporavka. U
sluaju da je Simple reima nije mogue kreirati sigurnosnu kopiju dnevnika.
Dnevnik baze podataka se moe kreirati putem T-SQL-a pri emu e sintaksa imati sledei
oblik:

backup log ImeBaze
to disk=lokacija
with description=ImeBaze sigurnosna kopija log fajla

Kada je u pitanju Management Studio koraci su slini kao i kod kopija podataka samo to je
pod opcijom Backup type potrebno odabrati Transaction Log.
Na kraju treba pomenuti jo jednu osobenost SQL Servera 2005 kad su u pitanju dnevnici. U
pojedinim situacijama uprkos tome to je dolo do pada baze podataka mogue je pristupiti
kreiranju rezervne kopije dnevnika ime se tako obezbeuje da se izvri oporavak baze podataka
u neposredno stanje pre samog pada.
4.3.3. REZERVNE KOPIJE SISTEMSKIH BAZA PODATAKA
Kao dodatak korisnikim bazama podataka vano je i kreiranje rezervnih kopija sistemskih
baza podataka. Treba istai da nije potrebno ih sve oduhvatiti ve samo one koje sadre kljune
informacije. U SQL Server-u 2005 postoje:
Master sadri kljune informacije kao to su podaci o korisnikim nalozima,
podeavanjima servera, postojanje drugih baza podataka i lokacije fajlova,
Model sadri obrasce (templejte) baze podataka koji se koriste prilikom kreiranja novih
korisnikih baza podataka
Msdb sadri informacije o sigurnosnim kopijama i oporavku, SQL agent poslove i
replikacije
Tempdb obezbeuje privremen prostor za razne aktivnosti i kreira se ponovo svaki put
kad se SQL Server ponovo pokrene
Distribution prisutna je samo ukoliko se server koristi za distribuciju podataka pri
replikacijama
Resource sadri sve sistemske objekte koji su prisutni u SQL Server 2005 ali ne
ukljuuje korisnike podatke i metapodatke
AdventureWorks i AdventureWorksDW mogu se opciono instalirati prilikom
instalacije SQL Servera i slue za testiranje i uenje.

Sigurnosne kopije i oporavak baze podataka

10

Od svih nabrojanih najvanije su master i msdb. Budui da proces kreiranja rez. kopija ovih
sistemskih baza nekoliko sekundi mogue ga je ponavljati svaki dan. Pored ove dve potrebno je
obuhvatiti i distribution koja se primenjuje prilkom replikacije baze podataka.
Model se moe obuhvatiti ukoliko se povremeno prave izmene kao to je na primer
dodavanje novih korisnikih tipova podataka.
4.3.4. OGRANIENJA U SQL Server-u 2005
Rezervne kopije se mogu kreirati ukoliko je baza podataka online i u upotrebi. Meutim,
postoje situacije u kojima nije mogue krerati kopije:
Offline podaci nemogu biti ukljueni u kopiju tipini sluajevi su:
o Ukoliko se pokrene proces kreiranja pune rezervne kopije pri emu su obuhvaeni
i fajlovi koji su offline,
o Pokrene se kreiranje parcijalne rezervne kopije pri emu su read/write fajlovi
offline,
o Pokrene se kreiranje rezervne kopije pojedinih fajlova od kojih je jedan offline.
Tokom procesa kreiranja sigurnosne kopije baze podataka ili dnevnika nije mogue:
o Manipulisanje sa fajlovima kao na primer alter database naredbe sa add file ili
remove file,
o Smanjivanje baze podataka ili fajla korienjem opcije shrink i
o Kreiranje ili brisanje fajlova baze podataka.
4.4. OPORAVAK BAZE PODATAKA

U sluaju pojave bilo kakvog problema u radu baze podataka administrator moe upotrebiti
sigurnosne kopije podataka i dnevnika da bi izvrio oporavak. Bez obzira na uzrok problema
neophodno je da se brzo izvri oporavak kako bi se poslovanje organizacije moglo nesmetano
odvijati. Ve je ranije napomenuto da u sluaju da su podaci nedostupni preduzee moe gubiti
hiljade pa ak i milione dinara (ili dolara). Pod oporavkom baze podataka podrazumeva se
povratak u stanje neposredno pre nastanka problema. Uspean oporavak znai vraanje podataka
u eljeno stanje, pri emu se pod takvim stanjem podrazumeva ono u kojem su bili prole
nedelje, jue ili neposredno pre nastanka problema. Pre pristupanja postupku oporavka potrebno
je da administrator identifikuje obim problema. Sledea pitanju mogu biti od pomoi:
1. O kakvom je problemu re: da li su u pitanju diskovi, transakcije ili sama baza podataka?
2. ta je uzrok problema?
3. Na koji nain dolo do prekida u bazi podataka, tj. da li je baza podataka postala
nedosutpna, da li je re o padu ili normalnom gaenju?
4. Da li se pojavio problem u operativnom sistemu?
5. Da li je server ponovo startovan?
6. Da li postoje informacije u log fajlu operativnog sistema?
7. Koliko su kritini podaci?
8. Da li je ve pokuan da se izvri oporavak do sada? Ukolike jeste koji su koraci ve
uinjeni?
9. Kakvi tipovi rezervnih kopija su raspoloivi?
10. Da li je potrebno izvriti oporavak celokupne baze ili moda samo fajla ili fajlova?
Sigurnosne kopije i oporavak baze podataka

11

11. Da li implementirana strategija obezbeuje da se izvri uspean oporavak (oporavak na
stanje neposredno pre izbijanja problema ili bilo koje prethodno stanje)?
12. U sluaju da su prisutne cold sigurnosne kopije na koji nain je baza podataka
iskljuena kada su kreirane kopije?
13. Da li dostupne kopije dnevnika?
14. Da li su kreirane logike rezervne kopije?
15. Koje su konkurentne aktivnosti bile u toku kada je dolo do pada?
16. Da li se moe da pokrenuti SUBP?
17. Da li se moe pristupiti objektima baze podataka?
18. Kolika je potreba da sistem bude dostupan?
19. Koliko je potrebno podataka oporaviti?
20. Da li se koriste raw fajlovi?
Poseban problem kad je u pitanju oporavak moe predstavljati prelazak izmeu razliitih
verzija SUBP-a. Sledea situacija ilustruje problem koji se moe pojaviti:
Kreirana je rezervna kopija tabele A dok je u upotrebi bila SUBP u verziji 5,
Prelo se na novu verziju SUBP recimo 6,
Pojavi se problem u radu tako da je potrebno izvriti oporavak tabele A.
U zavisnosti od samog SUBP-a oporavak ove tabele moda nee biti mogu. Razlog lei u
injenici da ponekad proizvoai SUBP-a promene format rezervne kopije ime se gubi
mogunost upotrebe starog formata. Kada je u pitanju Microsoft-ov SQL Server, rezervne kopije
kreirane u verzijama 7.0 i 2000 se mogu koristiti ukoliko se pree na verziju 2005. Za ranije
verzije, 6.5 i dalje navedeno ne vai zbog pormena u formatu. Navedeno ne vai sistemske baze:
master, model i msdb. Treba jo dodati da rezervne kopije kreriane u verziji 2005 su
neupotrebljive u ranijim verzijama.
4.4.1. GLAVNI KORACI OPORAVKA
Sledei koraci su uobiajeni za najvei broj oporavaka:
1. Identifikacija greke - Detektovnanje problema ne treba da bude vei problem. Meutim
mogu se javiti tei sluajevi kao to je primera radi pojava korumpiranih fajlova,
2. Analiza situacije - Potrebno je da administrator analizira problem kako bi identifikovao
tip, uzrok i domet. Na osnovu samih rezultat analize administrator e odabrati metod
oporavka.
3. Identifikacija objekata baze i drugih komponenti koje zahtevaju oporavak:
4. Identifikacija zavisnosti izmeu objekata baze podataka koji zahtevaju oporavak -
Ukoliko se pojavi blio kakva greka u jednom objektu to moe imati uticaja i na druge
objekte u bazi,
5. Priprema potrebne rezervnu kopiju - potrebno je pronai potrebne diskove ili trake na
kojima se nalaze potrebne kopije
6. Izvravanje samog oporavka pomou rezervne kopije
7. Upotreba dnevnika baze podataka - da bi se izvrio oporavak u stanje neposredno pre
pojave problema potrebno je pripremiti i rezervne kopije dnevnika.
Uopteno govorei svaki oporavak baze podataka ukljuuje veinu od gore navedenih koraka
mada u zavisnosti od situacije pojedini koraci e se moi preskoiti ili e biti izmenjeni.
Sigurnosne kopije i oporavak baze podataka

12

4.4.2. TIPOVI OPORAVKA
Od svih razliitih tipova prvi na koji se obino pomisli jeste oporavak na stanje neposredno
pre nastanka problema. Da bi se izvrio oporavak podataka potrebne e biti puna rezervna kopija,
diferencijalne rezervne kopije (ukoliko postoje) i rezervne kopije dnevnika. Ve je ranije
napomenuto da se prilikom oporavka moe javiti problem sa poslednje kreiranom kopijom pa se
u takvim sluajevima moe upotrebiti ranije kreirana kopija.
Drugi tip oporavka vezuje se za oporavak podataka u stanje u nekom vremenskom trenutku
(eng. point-in-time) i obino se primenjuje u sluaju pojave problema sa nekom od aplikacija.
Ovaj tip oporavka mogue je izvriti na dva naina:
Prvi nain podrazumeva upotrebu kopije pa potom dnevnika pri emu e se iz dnevnika
iskoristiti zapisi samo do tano definisane take.
Drugi nain podrazumeva da se putem putem zapisa iz dnevnika otklone izmene nad
podacima sve do definisane take.
U sluaju da su oba naina podrana od strane SUBP-a administrator treba da se odlui za
onaj koji zahteva najmanje vremena. Ukoliko je potrebno otkloniti veliki broj izmena
preporuljivo je primeniti prvi nain.
Trei tip oporavka se vezuje za transakcije, gde se efekti pojedinih transakcija otklanjaju. U
ovakvim sluajevima je potrebno upotrebiti sofverske alate drugih proizvoaa Kada se jednom
identifikuje transakcija iji se efekti ele otkloniti na raspolaganju su tri opcije:
1. Point-in-time oporavak,
2. Undo oporavak i
3. Redo oporavak.
Budui da je o prvom bilo ve rei potrebno je objasniti druge dve opcije. Undo oporavak je
od sva tri najjednostavniji i podrazumeva da se otklanjaju efekti problematine transakcije.
Sutina procesa je da se nakon analize dnevnika i identifikacije transakcija generie takozvana
anti-SQL naredba da bi se ponitili efekti. Sutina anti-SQL naredbe je u sledeem:
Insert se konvertuje u delete,
Delete se konvertuje u insert i
U sluaju auriranja, vrednosti menjaju mesta i to tako da umesto update A to X
bude update X to A.
Redo oporavak predstavlja kombinaciju prethodne dve. Najpre se generie Redo SQL naredba
za transakcije ije izmene elimo da sauvamo nakon ega se pristupa klasinom oporavaku da
bi se potom pomou Redo SQL naredbi baza podataka dovelau u pispravno stanje.
4.5. OPORAVAK PODATAKA U SQL Server-u 2005

U SQL Server-u prisutno je nekoliko modela oporavka. Glavna razlika izmeu njih jeste u
koliini informacija koje e se zapisati u dnevniku.
1. Full oporavak u sluaju da se odabere sve izmene se zapisuju u transakcioni dnevnik.
Za pojedine aktivnosti (kao np. truncate table) vri se zapisivanje manje informacija.
Prednost ovog modela jeste da se moe izvriti oporavak bilo koje transakcije.
Nedostatak jeste u injenici da se sve izmene zapisuju u dnevnik to znai da e se
veliina fajla brzo poveavati. Zato je veoma vano da ukoliko se odabere ovaj model
redovno kreiraju rezervne kopije dnevnika.
Sigurnosne kopije i oporavak baze podataka

13

2. Bulk-Logged zamiljen je kao dodatak prvom. Glavna karakteristika jeste da se u
dnevniku vri minimalno zapisivanje informacija o sledeim aktivnostima:
1. create index,
2. alter index rebuild,
3. bulk insert
4. bulk kopiranje,
5. select into i
6. binary large object (blob) operacije.
Minimalno zapisivanje u ovom sluaju znai da se vri zapisivanje da su se nabrojane
aktivnosti izvrile ali ne i informacije o redovima koji su bili obuhvaeni izmenama.
3. Simple oporavak vri se manje zapisivanje u dnevniku pri emu e se dnevnik prazniti
svaki put kada se od strane SQL Servera postavi checkpoint. Ovaj model se obino koristi
kod baza podataka koje se koriste za razvoj i testiranje.
Izbor modela oporavka se moe izvriti preko Management Studia. Potrebno je odabrati bazu
podataka pa potom odabrati stranicu Options i preko padajueg menija u (odeljku Recovery
model) odabrati jedan od ponuena tri, slika 7. Jednom odabran reim oporavka mogue je
kasnije uvek lako menjati preko ovog prozora.



Slika 7. Management Studio odabir reima oporavka

Izmene reima oporavka se mogu izvriti i upotrebom T-SQL-a:

alter database ImeBaze set recovery model

Kada je u pitanju sam oporavak podataka potrebno je istai da je u SQL Server-u 2005
implementirana mogunost automatskog oporavka podataka. To je mogue iz prostog razloga to
se u dnevniku zapisuju potrebne informacije tako da e u sluaju nestanka el. energije ili
nepravilnog gaenja servera doi do automatskog oporavka podatka uz uslov da nije dolo do
oteenja podataka tako da su postali neitljivi.
Sigurnosne kopije i oporavak baze podataka

14

Oporavak se moe izvriti putem T-SQL naredbe gde je opti izgled sintakse kad je u pitanju
oporavak celokupne baza podataka:

restore database ImeBaze from disk=lokacija

U sluaju da je re o oporavku fajla ili fajlova opti oblik je:

restore database ImeBaze
file/filegroup
from disk =lokacija

U sluaju da se sigurnosna kopija ne nalazi na disku nego na traci umesto disk koristie se
tape.
Oporavak dnevnika putem T-SQL-a:

restore log ImeBaze from disk=lokacija

Da bi se izvrio oporavak baze podataka na neko stanje u vremenskom trenutku:

restore log ImeBaze from disk=lokacija with stopat=datum i vreme

gde e se putem naredbe stopat definisati datum i vreme.
Oporavak baze podataka, fajla/fajlova i dnevnika se moe izvriti i preko Management
Studia. Prozor preko kojeg se vri oporavak je prikazan na slici 8.



Slika 8. Oporavak putem Management Studia

Podrazumevana postavka jeste oporavak na tekue stanje. Ukoliko se eli izvriti oporavak na
stanje u nekom trenutku vremenu potrebno je odrediti vreme i datum preko posebnog ekrana,
slika 9.

Sigurnosne kopije i oporavak baze podataka

15



Slika 9. Definisanje datuma i vremena

4.6. ALTERNATIVNI PRISTUPI REZERVNIM KOPIJ AMA I
OPORAVKU PODATAKA

Sigurnosne kopije su najsigurniji metod obezbeivanja od gubitka podataka. Meutim postoji
nekoliko alternativa koje predstavljaju zamenu za sigurnosne kopije:
Standby baze
Replikacija
Standby baza podataka su se prvi put pojavile u Oraclu u verziji 7. Sutina je postojanje jo
jedne baze koja je identina online bazi podataka. Standby baza podataka se redovno aurira
mada je teko postii 100% aurnost. U sluaju da se pojavi bilo kakav problem sa online bazom
kontrola se prebacuje na standby bazu koja je tada online ime se omoguuje nesmetan nastavak
poslovanja. Obiajno se stanby baze kreiraju putem offline rezervnih kopija nakon ega e se
izvriti auriranje upotrebom dnevnika.
Replikacija (engl. replication) je postupak kopiranja i distribuiranja podataka i objekata iz
jedne baze podataka u drugu koji sadri mehanizam za sinhronizaciju podataka. Razlikujemo:
Snapshot replikaciju podrazumeva kreiranje kopije tabele baze podataka na osnovu
upita nad bazom podataka. Kada se kreira snapshot, specifian upit se izvrava ime se
podaci uitavaju u snapshot tabelu. Prednost ovakvog tipa jeste jednostavna impleme-
ntacija a nedostatak jeste da je potrebno konstantno auriranje to zahteva dodatan posao
administratora.
Simetrina replikaciju robusniji tip replikacije iz prostog razloga to se obezbeuje
automatsko auriranje replike to je i prednost ovog tipa. Kao nedostatak ovog tipa
replikacije se navodi da u sluaju velikog broja transakcija moe uzrokovati degradaciju
performansi, tei je za administraciju i u sluaju problema u mrei moe doi do pada
baze podataka usled nemogunosti sinhronizacije.
4.7. PLANOVI ZA SLUAJ GUBITKA PODATAKA
4.7.1. POTREBA ZA PLANIRANJEM
Planiranje oporavka za sluaj gubitka podataka predstavlja proces pripremanja preduzea u
sluaju nastanka vanrednih situacija. Moe se postaviti pitanje ta se podrazumeva pod tim?
Sungard Recovery Services prua sledeu definiciju:
Svaki neplanirani gubitak kritinih poslovnih aplikacija usled nedostatka sposobnosti obrade
podataka due od 48h.
Sigurnosne kopije i oporavak baze podataka

16

Prema DB2 Developers Guide: Svaki dogaaj koji ima malu verovatnou nastanka, visok
stepen nesigurnosti sa potencijalno razornim posledicama.
U vanredne situacije pre svega ubrajamo elementarne nepogode poput: poara, poplave,
zemljotresa, uragane. ovek takoe moe biti uzrok: loe projektovane instalacije (elektrine,
gasne, vodovodne), loe obezbeena klimatizacija u prostorijama u kojima su serveri, sigurnosni
propusti, sabotae u novije vreme i teroristiki napadi.
Potrebno je da se prepoznaju potencijalne opasnosti i razumeju njihove posledice po
poslovanje preduzea. Od lokacije firme e i zavisiti mogunost od izbijanja razliitih nepogoda.
Primera radi ukoliko je lokacija preduzea priobalno podruje preduzee je vie izloeno
poplavama i uraganima.
injenica da se organizacija nije jo susrela sa vanrednim situacijama ili da se ne nalazi
podruju sa visokim rizikom ne oslobaa od potrebe za planiranjem. U sluaju bilo kakve
elementarne nepogode preduzea bez plana su preputena milosti sluaja.
Svakako da se elementarne nepogode kao to su zemljotresi, poplave, poari i uragani ne
mogu spreiti. Meutim budui da ovek takoe moe biti uzronik, neke situacije je ipak
mogue spreiti Potrebno je definisati plan za sluaj gubitka podataka ail i je od iste vanosti i
izvriti analizu da bi se odredilo mogu li se pojedine opasnosti izbei.




Slika 10. Loa elektrina instalacija moe dovesti do
poara i unitenja servera a time i podataka u organizaciji

Plan oporavka treba da obuhvati najvanija pitanja: alternativne lokacije za poslovanje, oporavak
podataka, komunikacija sa zaposlenima, procedure i javno obavetenje da bi se informisali
kupci. Da bi se definisao plan oporavka u sluaju vanredne situacije potrebno je najpre analizirati
rizike i odrediti ciljeve.
4.7.2. RIZIK I OPORAVAK
Cilj plana oporavka u sluaju vanredne situacije jeste smanjenje sledeih trokova:
Finansijski trokovi usled nemogunosti pristupa podacima i aplikativnom softveru i
Trokovi gubitka kupca i poslovnih prilika.
Osim podataka neophodno je i da se izvri analiza aplikativnog softvera koji se primenjuje u
poslovanju. Sve aplikacije se mogu podeliti na sledee grupe u pogledu kritinosti:
Sigurnosne kopije i oporavak baze podataka

17

Vrlo kritine aplikacije predstavljaju aplikacije koje bi trebalo prvo osbosobiti. Budui
da je re o najkritinijoj grupi potrebno je ograniiti njihov broj.Za ove aplikacije su
potrebni tekui podaci.
Poslovno kritine aplikacije pretsvaljaju aplikacije koje su vane za organizaciju i kao
takve treba da su sledea grupa za oporavak. Kad su u pitanju podaci, za ove
aplikacije su bitni tekui podaci ali to nije od presudne vanosti kao u prethodnoj grupi.
Primera radi, ukoliko imamo organizaciju ija je delatnost pruanje telefonskih usluga
tada e aplikativni softver koji u okviru sistema koji obezbeuje telefonsku uslugu
pripadati prvoj grupi a aplikativni softver koji se koristi za obraun korisnikih rauna e
pripadati drugoj.
Kritine aplikacije mada je re o vanim aplikacijama za organizaciju nije potrebno da
se odmah izvri njihov oporavak.
Potrebne aplikacije re je oplikacijama koje nisu od presudne vanosti za organizaciju
ali to ne znai da za njih nisu potrebne rezervne kopije.
Nekritine aplikacije mali broj aplikacija se moe svrstati u ovu grupu.
4.7.3. PISANI PLAN OPORAVKA
Osnova bilo kog oporavka treba da bude pisani plan. Plan oporavka treba da bude dostavljen
svom kljunom osoblju u organizaciji. Svaki od uesnika bi trebao da ima jednu kopiju plana na
poslu a jednu kui. Takoe je bitno da se jedna kopija plana nalazi i na drugoj lokaciji.
Prednosti pisanja plana su:
Precizno se definiu aktivnosti,
Precizno se definie njihov redosled,
Precizno se definiu alati koji e se koristiti kao i informacije o potrebnim sigurnosnim
kopijama potrebnim za oporavak,
Dokumentuje se lokacija i
Obezbeuje se postupak za ostalo osoblje u sluaju da glavno osoblje za sluaj oporavka
nije prisutno.
Plan treba da obuhvati:
Podatke o drugoj lokaciji: adrese, telefonske brojeve, brojeve faksa kao i adresa kontakt
osoba. Pored toga treba jo i dodati podatke o hotelima u blizini, transportu, planu
trokova i druge sline informacije
Osoblje podatke o svakom lanu tima zaduenog za oporavak. Osim imena i adrese
potrebno je da se ukljue svi kontakt brojevi (na poslu, kod kue, brojevi mobilnog
telefona).
Ovlaenja potrebno je da postoji lista ovlaenja osobama zaduenim za oporavak
Procedure tokom oporavka kao i skripte za celokupan sistemski softver, aplikacije i
podatke - Potrebno je precizno definisati korak po korak sve procedure oporavka za sva-
ki deo sistemskog softvera, sve aplikacije i svakog objekta baze podataka. Spisak bi
trebalo jo da obuhvati podatke o svim diskovima ili trakama sa kojih se moe izvriti
instalacija i koje su se koristile za odravanje.
Izvetaje lista izvetaja koji e biti potrebni za oporavak. Izvetaji treba da obuhvate
podatke o svakom disku/traci gde su sigurnosne kopije, sadraju, vremenu kreiranja kao i
kada su dopremljene iz matine lokacije i kada su stigle.
Sigurnosne kopije i oporavak baze podataka

18

Nakon to se jednom napie plan potrebno je izvriti testiranje. Preporuljivo je da se
testiranje vri jednom godinje. Glavni cilj testiranja treba da bude identifikovanje slabosti
samog plana. Ukoliko se otkriju eventualni propusti potrebno je izvriti korekcije. Treba dodati
da ispravno testiranje ne mora uvek da vodi uspenom oporavku, iako je to poeljan rezultat.
Osim identifikovanja nedostataka, testiranje treba sprovoditi i da se proveri spremnost samog
osoblja. Takoe putem testiranja e se bolje upoznati alati i procedure koje e se upotrebiti
ukoliko se pojavi potreba za oporavkom.
Osim jednom godinje preporuljivo je sprovesti testiranje u sledeim situacijama:
1. Znaajne promene u dnevnim operacijama,
2. Izmene u hardveru,
3. Nadogradnja SUBP-a (ili softvera koji je u vezi sa njim),
4. Promene u osoblju zaduenom za oporavak,
5. Promena lokacije data centra,
6. Izmeneu proceduri kreiranja rezervne kopije,
7. Izmene aplikacija koje se koriste u dnevnom poslovanju,
8. Znaajno poveanje koliine podataka i broja transakcija.
Uspeno izvravanje plana odreeno je izborom pravog tima. Kada je re o SUBP-u tim mora
biti u stanju da instalira i ispravno konfigurie SUBP, obezbedi njegovu integraciju sa drugim
aplikativnim softverom, proveri integritet, pravilno i instalira aplikativni softver i rei niz
problema koji se mogu pojaviti. Od presudne vanosti je da se tim redovno okuplja da bi testirao
plan. Takoe je potrebno obezbediti i prava pristupa svakom lanu tima da bi mogao izvriti svoj
deo zadatka kod oporavka.