Sigurnosne Kopije i Oporavak Baze Podataka

4. SIGURNOSNE KOPIJE I OPORAVAK BAZE PODATAKA

Podaci predstavljaju jedan od najznačajnijih resursa u organizaciji. Tokom godina poslovanja

organizacije prikupe mnogo podataka o svojim kupcima, imovini, ulaganjima, prozvodima i sl.

Ti podaci se koriste u cilju unapreĎenja poslovanja organizacije. Zbog svog značaja za preduzeće

nemogućnost pristupa takvim podacima je neprihvatljiva i može biti pogubna za poslovanje.

Svaki sat nedostupnosti može značiti gubitak u milionskim iznosima. Da bi se obezbedilo

nesmetano poslovanje u preduzećima se implementiraju različita rešenja kojima se nastoji

obezbediti dostupnost podataka čak i u slučaju pojave nekih problema poput problema sa

električnom energijom, kvar na disku ili pad servera. Problemi poput greškom obrisanih

podataka od strane korisnika, nemogućnost pristupa podacima usled problema sa softverom nisu

pokriveni ovakvimm rešenjima. Sve nabrojano ukazuje na potrebu za stalnim kreiranjem

rezervnih kopija podataka da bi se sprečio njihov gubitak. Poseban problem predstavljaju

vanredne situacije poput: zemljotresa, poplava, požara i uragana koje mogu biti pogubne po

preduzeće. U takvim okolnostima nije dovoljno samo posedovanje rezervnih kopija već je

imperativ da one budu na drugoj lokaciji van opasnosti od uništenja.

4.1. POTREBA ZA REZERVNIM KOPIJAMA 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 može izvršiti oporavak baze i tako je dovesti u stanje pre pada. Samim tim

jedan od najvažnijih zadataka administratora treba da bude redovno kreiranje kopija. To

podrazumeva pravljenje konzistentnih kopija podataka obično u formi image fajlova.

Različiti su uzroci koji mogu dovesti do potrebe za oporavkom baze podataka. Možemo ih

podeliti na:

Hardver – nekada je hardver bio glavni uzrok oporavka. Mada je danas hardver

uglavnom pouzadan opet može doći do kvara pojedinih komponenti kao što su diskovi,

kontroleri i sl.

Greške u samim aplikacijama – u aplikacijama mogu postojati greške (tzv. bug) koje

mogu dovesti do neželjenih izmena nad podacima. Da bi se to sprečilo potrebno je da

aplikacije pre upotrebe budu podvrgnute testiranju. MeĎutim, ponekad se može desiti da

uprkos testiranjima aplikacija i dalje sadrži greške koje još nisu otkrivene.

Padovi operativnog sistema – poput baze podataka operativni sistem takoĎe može da

padne. Pogrešni drajveri, ne ažuriranje sigurnosnim zakrpama su samo neki od uzroka

koji mogu dovesti do problema u radu operativnog sistema.

Korisničke greške – pored grešaka u samim aplikacijama korisnici su najčešći uzrok

potrebe za oporavkom. Nepažljivo ažuriranje podataka često dovodi do potrebe za

oporavkom.

Sigurnosni propusti – danas sve više dobijaju na značenju. Loše podešavanje firewall-a,

odsustvo bilo kakvog antivirusnog programa, neadekvatno dodeljene privilegije

korisnicima sve to može dovesti do neovlaštenog pristupa i izmene nad podacima.

Vanredne situacije – elementarne nepogode kao što su: poplave, uragani, požari i sl.

Sigurnosne kopije i oporavak baze podataka

2

Prilikom kreiranja rezervne kopije potrebno je odlučiti da li će se kreiratu puna kopija ili

inkrementalna. Puna rezervna kopija predstavlja kompletnu kopiju svih podataka. U ovom

slučaju glavni problem može 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 znači da je za njih potrebno manje vremena da

se kreiraju kao i da zauzimaju manje prostora. Nedostatak jeste da se samo putem njih nemože

izvršiti oporavak već je potrebno da postoji i puna kopija koja će poslužiti kao osnova.

Osim podataka moguće 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 možda bolje rešenje ponovo ih kreirati kada se jednom izvrši oporavak. Ukoliko je reč o većim

bazama podataka gde je prisutno mnogo indeksa svakako da je bolje rešenje kreiranje

sigurnosnih kopija indeksa.

Administrator treba da odredi koliko će se često kreirati sigurnosne kopije. Pri tome treba

imati na umu sledeće:

Koliko su podaci važni za poslovanje? Koliki je gubitak u slučaju da podaci postanu

nepristupačni?

O kakvim podacima je reč? Da li su u pitanju podaci kojima se pristupa samo radi čitanja

ili su podložni i izmenama?

Da li postoji vremenski period u toku dana kada je smanjen broj pristupa bazi podataka

tako da se može pristupiti kreiranju sigurnosne kopije bez da se ometa poslovanje

preduzeća?

Kolika je veličina baze podataka i koliko je vremena potrebno za različite 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 smeštaju rezervne kopije? Preporučljivo 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 može i na DVD-u.

Da li se rezervna kopija prebacuje na nekoliko različitih medija koji se potom šalju na

druge lokacije?

Preporučljivo je da se izvrši i analiza kritičnosti i dinamičnosti (podložnosti promenama)

podataka. U tu svrhu može se iskoristiti dijagram sa slike 1. na sledećoj strani. Apscisa prikazuje

važnost podataka i to od nekritičnih podataka koji su lako zamenljivi pa do kritičnih koji su

vitalni za preduzeće. Na ordinanti je prikazana njihova promenljivost i to od podataka koji su

statični (nepromenljivi) pa do dinamičnih podataka. Da bi se dijagram mogao koristiti potrebno

je prvo analizirati podatke i postaviti ih na dijagram. Nakon što se ustanovi položaj na dijagramu

može se odrediti koliko je često potrebno kreirati rezervnu kopiju svakog objekta. Potrebno je

često kreirati sigurnosne kopije podataka koji su kritični i promenljivi.

U prvom kvadrantu će biti podaci koji su kritični za poslovanje i podložni su čestim

izmenama. Budući da je reč o vrlo bitnim podacima potrebno je češće praviti rezervne kopije.

Preporučljivo je kreiranje svakodnevno.

U drugom kvadrantu se nalaze podaci koji su kritični za poslovanje preduzeća ali ih

karakteriše statičnost. Kada je u pitanju ova grupa podataka preporučuje se kreiranje kopija

jednom nedeljno.


3

U trećem kvadrantu su podaci koji su podložni čestim izmenama ali nisu toliko vitalni za

poslovanje preduzeća. Reč je o podacima kod kojih svi ne moraju biti obuhvaćeni sigurnosnom

kopijom.

U četvrtom kvadrantu su podaci koji su najmanje važni za poslovanje preduzeća. Reč je o

podacima koji se lako mogu ponovo obnoviti iz drugih izvora.

Ukoliko se u preduzeću nalazi više baza podataka potrebno je analizirati svaku od njih. Neke

od njih su kritične za poslovanje firme i ukoliko doĎe do njihovog pada potrebno ih je što je

moguće pre obnoviti.

Slika 1. Kritičnost i dinamičnost podataka

Osim rasporeda administrator treba da odluči i koliko verzija kopija želi da čuva. Čuvanjem

dodatnih verzija obezbeĎuje se oporavak baze podataka u slučaju 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 odgovarajući broj dnevnika.

Sledeći 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 oštećenja medija na kom se nalazi (trake ili diskovi),

Potrebno je da strategija kreiranja rezervnih kopija bude usklaĎena sa strategijom

oporavka u slučaju vanrednih situacija. Mnogi alati za rezervne kopije obezbeĎuju

mogućnost 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 može izvršiti oporavak

koristeći stariju verziju,

Rezervna kopija se može 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 smeštanje rezervnih kopija

preporučljivo je izršiti kompresovanje fajlova,

1 2

4 3

Statični Dinamični

Nek

riti

čni

Kri

tičn

i

Važ

nost

podat

aka

Promenljivost podataka


4

Neophodno je da u plan kreiranja rezervnih kopija i oporavka bude uključen i sistem

katalog objekata baze objekata.

Potrebno je obezbediti da se započeti proces kreiranja rezervnih kopija može nastaviti

ukoliko doĎe do prekida. Primera radi, ukoliko je za kreiranje rezervne kopije potrebno

3h, a do prekida doĎe nakon 2h i 30 minuta ukoliko se proces ne može nastaviti potrebno

je početi sve od početka.

Preporučljivo 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 takoĎe da su uključeni u rezervnu kopiju.

Različiti SUBP se meĎusobno razlikuju po opcijama koje poseduju kada je su u pitanju

rezervne kopije i oporavak podataka. Zbog toga je važno da administrator bude upoznat sa

mogućnostima konkretnog SUBP -a.

Na kraju potrebno je rešiti i čuvanje rezervnih kopija. Čuvanje na istoj lokaciji na kojoj je i

firma predstavlja loše rešenje. Glavni razlog za to leži u činjenici da u slučaju bilo kakve

vanredne situacije objekti firme mogu biti uništeni a time i sigurnosne kopije.

Slika 2. New Orleans (USA) nakon uragana Katrina 2005. godine

Preduzeća koja su čuvala sigurnosne kopije na istoj lokaciji gde je i sedište su nepovratno

izgubila svoje podatke

Da bi se to sprečilo organizacije pohranjuju podatke na udaljenim lokacijama (remote

locations). U slučaju da su finansijska sredstva ograničena alternativu predstavljaju kompanije

koje obezbeĎuju infrastrukturu za čuvanje u svojim objektima. Tipičan primer ovakve kompanije

jeste Iron Mountain (slika 3.) sa sedištem u Bostonu. Podaci se čuvaju daleko od bilo kog grada

u zabačenom planinskom mestu, duboko ispod površine zemlje. Iron Mountain je osnovana

1951. godine kada je otkupljen veliki napušten rudnik. Objekat je ureĎen i sadrži veliki broj

nivoa sa prostranim hodnicima štoje bilo idealno za stvaranje podzemne baze. Rudnik je i u

vreme hladnog rata služio za slične stvari za koje služi i danas, brojne firme i ustanove su

odlagale svoje arhive, proizvode ili predmete od vrednosti. Sa sve većim prisustvom računara u

savremenom poslovanju i budući da su firme ukinule papirno poslovanje to je i ova kompanija

svoj podzemni objekat dobrim delom preorijentisala, te on danas služi za arhiviranje elektronskih

dokumenata. U podzemnim hodnicima se nalaze računari, monitori, bekap serveri čime je


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 američkoj državi Pensilvanija. Nepostoje nikakvi

putokazi niti natpisi, već oni koji dolaze, dolaze isključivo po pozivu i dobijaju pisana uputstva.

Slika 3. Iron Mountain, ulaz u objekat (levo), računaski centar (u sredini), serveri

za smeštanje podataka (desno)

U Evropi postoji slično rešenje koje postoji u okolini Kampfberga u Austriji. Objekat je po

svojoj nameni i načinu funkcionisanja veoma sličan prethodnom. earthDATAsafe (slika 4.) je

otvoren novembra 2003. godine. Pokretač projekta je kompanija Daimler Chrysler Consult Graz

Gmbh. Računarski centar je ukopan 250 metara ispod planine i od početka je zamišljen kao

bezbedan računarski centar za razliko od američkog objekta koji je nastao adaptacijom

napuštenog rudnika.

Slika 4. earthDATAsafe: levo unutrašnjost objekta. Jedan od ulaza u objekat (desno)

4.2. ALTERNATIVNI PRISTUPI IZRADI REZERVNIH KOPIJA

4.2.1. Upotreba opcije export za kreiranje logičkih kopija

Alternativa tradicionalnoj izradi rezervnih kopija baze podataka jeste da se umesto kreiranja

kopija vrši se export ili unload podataka. Kopije podataka koje su dobijene na ovaj način

nazivaju još i logičke budući da se obuhvataju samo podaci. Njihova prednost je u sledećim

slučajevima:

Nadogradnja SUBP-a – ponekad se desi da proizvoĎač SUBP-a izvrši izmene u samoj

strukturi baze podataka,

Oporavak objekta ili reda – u slučaju da doĎe do brisanja tabele ili redova u tabeli mnogo

će se brže izvršiti oporavk primenom logičkih kopija,


6

Migracije između različitih baza podataka i različitih operatvinih sistema – primera radi,

ukoliko se u organizaciji koristi Oracle, različita će biti struktura fajla na OS/390 od one

na WindowsNT.

Migracije podataka – često se može ukazati potreba da se podaci sele unutar

organizacije: na druge SUBP, u programima za tabelarna izračunavanja i sl. Logičke

kopije obezbeĎuju laku migraciju podataka kad i gde je to potrebno.

4.2.2. Upotreba Storage Management softvera za izradu kopija

Storage management softver pruža mogućnost kreiranja kopija fajlova. Pojedini SUBP mogu

i da saraĎuju sa Storage Management softverom kao na što je slučaj 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 režimu čitanja. Ukoliko se kasnije ukaže potreba za oporavkom

objekta njegov oporavak će se izvršiti upotrebom storage managment.

4.3. REZERVNE KOPIJE U SQL Server-u 2005

U SQL Serveru 2005 korisnicima je omogućeno da biraju izmeĎu 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. Budući da uključuje sve potrebne elemente ovaj tip rezervnih kopija se može

posmatrati kao osnova za oporavak. Prilikom samog procesa kreiranja kopije SQL Server vrši

zapisivanje u dnevnik da bi se po završetku nastali zapis zajedno sa kopijom smeštao na medij

(disk ili traku). Prednost ovog tipa je svakako jednostavnost njegove upotrebe dok je glavni

nedostatak pre svega vreme i potreban prostor za smeštanje kopije ukoliko su u pitanju velike

bazama podataka. SQL Server pruža mogućnost 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 opšti izgled sintakse je:

backup database ImeBaze

to disk=’Lokacija’

with description=’ImeBaze_Puna rezervna kopija’

SQL Server putem Management Studia pruža mogućnost kreiranja sigurnosne kopije putem

grafičkog interfejsa. Da bi se kreirala rezervna kopija potrebno je prvo odabrati bazu podataka,

pritisnuti desni taster miša i odabrati Tasks pa zatim Backup. Pojaviće 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 bliži opis. U okviru Back up to potrebno je dodati lokaciju na

kojoj želimo da se kreira kopija.


7

Slika 5. Prozor za kreiranje sigurnosne kopije

Parcijalne sigurnosne kopije predstavljaju 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.

Opšti 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 pruža mogućnost da se umesto kreiranja

rezervne kopije celokupne baze podataka odabere fajl ili odreĎena grupa fajlova. Ovaj tip je

primenljiv uslučaju da baza podataka sadrži veliki broj fajlova što može biti pogodno ukoliko je

reč o velikim bazama podataka.



filegroup=’ImeGrupeFajlova’


with description=’ImeBaze ImeGrupeFajlova reyervna kopija fajlova’

Osim T-SQL sigurnosne kopije fajla/fajlova se mogu kreirati i putem Management Studia.

Koraci su slični 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 uključimo u

kopiju.


8

Slika 6 Kreiranje sigurnosne kopije fajlova

Diferencijalne rezervne kopije obuhvataju samo podatke koji su pretrpeli izmene od poslednje

rezervne kopije.




with diferential, description=’ImeBaze diferencijalna rezervna kopija’

Kreiranje diferencijalnih kopija putem Management Studia podrazumeva korake kao i u slučaju

punih kopija s tim što je pod Backup type potrebno odabrati Diferential.

4.3.1. COPY-ONLY KOPIJE U SQL Server–u 2005

Predstavljaju novinu u verziji 2005. Glavni razlog za njihovu implementaciju jeste da

prilikom kreiranja copy-only kopija SQL Server ne vrši zapisivanje informacija o njihovom

kreiranju. Ukoliko to ne bi bio slučaj mogao bi se javiti problem koji najbolje ilustruje sledeći

primer. U organizaciji je implemetirana strategija da se pune rezervne kopije kreiraju vikendom

dok se preko nedelje svakodnevno kreiraju diferencijalne. Primera radi, ukaže se potreba da se

kreira kopija baze koja će se iskoristiti za testiranja. U slučaju da se kreira puna rezervna kopija,

SQL Server će vršiti zapis o procesu tako da će kada se pristupi redovnom kreiranju

diferencijalne kopije biće obuhvaćeni 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 više

nije raspoloživa. Ovaj tip kopija se može krerati samo putem T-SQL -a:


to disk = 'lokacija'

with copy-only


9

4.3.2. REZERVNE KOPIJE DNEVNIKA

Izmene nad podacima u bazi podataka se zapisuju od strane SUBP-a u poseban fajl koji se

obično zove transakcioni dnevnik. Transakcioni dnevnik sadrži zapise o transakcijama (drugim

rečima modifikacijama) učinjenim nad podacima u bazi podataka. U fajlu će se vršiti zapisi za

svako uspešno izvršavanje SQL iskaza insert, update i delete. Kako vreme prolazi broj izmena

nad bazom podataka će rasti čime će se povećavati i dnevnik baze. Budući da se putem rezervne

kopije dnevnika može izvršiti oporavak baze podataka na tekuće 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 slučaju da su odabrani Full ili Bulk-Logged režimi oporavka. U

slučaju da je Simple režima nije moguće kreirati sigurnosnu kopiju dnevnika.

Dnevnik baze podataka se može kreirati putem T-SQL-a pri čemu će sintaksa imati sledeći

oblik:

backup log ImeBaze


with description=’ImeBaze sigurnosna kopija log fajla’

Kada je u pitanju Management Studio koraci su slični 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 došlo do pada baze podataka moguće je pristupiti

kreiranju rezervne kopije dnevnika čime se tako obezbeĎuje da se izvrši oporavak baze podataka

u neposredno stanje pre samog pada.

4.3.3. REZERVNE KOPIJE SISTEMSKIH BAZA PODATAKA

Kao dodatak korisničkim bazama podataka važno je i kreiranje rezervnih kopija sistemskih

baza podataka. Treba istaći da nije potrebno ih sve oduhvatiti već samo one koje sadrže ključne

informacije. U SQL Server-u 2005 postoje:

Master – sadrži ključne informacije kao što su podaci o korisničkim nalozima,

podešavanjima servera, postojanje drugih baza podataka i lokacije fajlova,

Model – sadrži obrasce (templejte) baze podataka koji se koriste prilikom kreiranja novih

korisničkih baza podataka

Msdb – sadrži informacije o sigurnosnim kopijama i oporavku, SQL agent poslove i

replikacije

Tempdb – obezbešuje 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 – sadrži sve sistemske objekte koji su prisutni u SQL Server 2005 ali ne

uključuje korisničke podatke i metapodatke

AdventureWorks i AdventureWorksDW – mogu se opciono instalirati prilikom

instalacije SQL Servera i služe za testiranje i učenje.


10

Od svih nabrojanih najvažnije su master i msdb. Budući da proces kreiranja rez. kopija ovih

sistemskih baza nekoliko sekundi moguće ga je ponavljati svaki dan. Pored ove dve potrebno je

obuhvatiti i distribution koja se primenjuje prilkom replikacije baze podataka.

Model se može obuhvatiti ukoliko se povremeno prave izmene kao što je na primer

dodavanje novih korisničkih tipova podataka.

4.3.4. OGRANIČENJA U SQL Server-u 2005

Rezervne kopije se mogu kreirati ukoliko je baza podataka online i u upotrebi. MeĎutim,

postoje situacije u kojima nije moguće krerati kopije:

Offline podaci nemogu biti uključeni u kopiju – tipični slučajevi su:

o Ukoliko se pokrene proces kreiranja pune rezervne kopije pri čemu su obuhvaćeni

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 moguće:

o Manipulisanje sa fajlovima kao na primer alter database naredbe sa add file ili

remove file,

o Smanjivanje baze podataka ili fajla korišćenjem opcije shrink i

o Kreiranje ili brisanje fajlova baze podataka.

4.4. OPORAVAK BAZE PODATAKA

U slučaju pojave bilo kakvog problema u radu baze podataka administrator može upotrebiti

sigurnosne kopije podataka i dnevnika da bi izvršio oporavak. Bez obzira na uzrok problema

neophodno je da se brzo izvrši oporavak kako bi se poslovanje organizacije moglo nesmetano

odvijati. Već je ranije napomenuto da u slučaju da su podaci nedostupni preduzeće može gubiti

hiljade pa čak i milione dinara (ili dolara). Pod oporavkom baze podataka podrazumeva se

povratak u stanje neposredno pre nastanka problema. Uspešan oporavak znači vraćanje podataka

u željeno stanje, pri čemu se pod takvim stanjem podrazumeva ono u kojem su bili prošle

nedelje, juče ili neposredno pre nastanka problema. Pre pristupanja postupku oporavka potrebno

je da administrator identifikuje obim problema. Sledeća pitanju mogu biti od pomoći:

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 način došlo do prekida u bazi podataka, tj. da li je baza podataka postala

nedosutpna, da li je reč o padu ili normalnom gašenju?

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 kritični podaci?

8. Da li je već pokušan da se izvrši oporavak do sada? Ukolike jeste koji su koraci već

učinjeni?

9. Kakvi tipovi rezervnih kopija su raspoloživi?

10. Da li je potrebno izvršiti oporavak celokupne baze ili možda samo fajla ili fajlova?


11

11. Da li implementirana strategija obezbeĎuje da se izvrši uspešan oporavak (oporavak na

stanje neposredno pre izbijanja problema ili bilo koje prethodno stanje)?

12. U slučaju da su prisutne „cold“ sigurnosne kopije na koji način je baza podataka

isključena kada su kreirane kopije?

13. Da li dostupne kopije dnevnika?

14. Da li su kreirane logičke rezervne kopije?

15. Koje su konkurentne aktivnosti bile u toku kada je došlo do pada?

16. Da li se može da pokrenuti SUBP?

17. Da li se može 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 može predstavljati prelazak izmeĎu različitih

verzija SUBP-a. Sledeća situacija ilustruje problem koji se može pojaviti:

Kreirana je rezervna kopija tabele A dok je u upotrebi bila SUBP u verziji 5,

Prešlo se na novu verziju SUBP recimo 6,

Pojavi se problem u radu tako da je potrebno izvršiti oporavak tabele A.

U zavisnosti od samog SUBP-a oporavak ove tabele možda neće biti moguć. Razlog leži u

činjenici da ponekad proizvoĎači SUBP-a promene format rezervne kopije čime se gubi

mogućnost 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 preĎe na verziju 2005. Za ranije

verzije, 6.5 i dalje navedeno ne važi zbog pormena u formatu. Navedeno ne važi 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

Sledeći koraci su uobičajeni za najveći broj oporavaka:

1. Identifikacija greške - Detektovnanje problema ne treba da bude veći problem. MeĎutim

mogu se javiti teži slučajevi 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 između objekata baze podataka koji zahtevaju oporavak -

Ukoliko se pojavi blio kakva greška u jednom objektu to može imati uticaja i na druge

objekte u bazi,

5. Priprema potrebne rezervnu kopiju - potrebno je pronaći potrebne diskove ili trake na

kojima se nalaze potrebne kopije

6. Izvršavanje samog oporavka pomoću rezervne kopije

7. Upotreba dnevnika baze podataka - da bi se izvršio oporavak u stanje neposredno pre

pojave problema potrebno je pripremiti i rezervne kopije dnevnika.

Uopšteno govoreći svaki oporavak baze podataka uključuje većinu od gore navedenih koraka

mada u zavisnosti od situacije pojedini koraci će se moći preskočiti ili će biti izmenjeni.


12

4.4.2. TIPOVI OPORAVKA

Od svih različitih tipova prvi na koji se obično pomisli jeste oporavak na stanje neposredno

pre nastanka problema. Da bi se izvršio 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 može javiti problem sa poslednje kreiranom kopijom pa se

u takvim slučajevima može upotrebiti ranije kreirana kopija.

Drugi tip oporavka vezuje se za oporavak podataka u stanje u nekom vremenskom trenutku

(eng. point-in-time) i obično se primenjuje u slučaju pojave problema sa nekom od aplikacija.

Ovaj tip oporavka moguće je izvršiti na dva načina:

Prvi način podrazumeva upotrebu kopije pa potom dnevnika pri čemu će se iz dnevnika

iskoristiti zapisi samo do tačno definisane tačke.

Drugi način podrazumeva da se putem putem zapisa iz dnevnika otklone izmene nad

podacima sve do definisane tačke.

U slučaju da su oba načina podržana od strane SUBP-a administrator treba da se odluči za

onaj koji zahteva najmanje vremena. Ukoliko je potrebno otkloniti veliki broj izmena

preporučljivo je primeniti prvi način.

Treći tip oporavka se vezuje za transakcije, gde se efekti pojedinih transakcija otklanjaju. U

ovakvim slučajevima je potrebno upotrebiti sofverske alate drugih proizvoĎača 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.

Budući da je o prvom bilo već reči potrebno je objasniti druge dve opcije. Undo oporavak je

od sva tri najjednostavniji i podrazumeva da se otklanjaju efekti problematične transakcije.

Suština procesa je da se nakon analize dnevnika i identifikacije transakcija generiše takozvana

anti-SQL naredba da bi se poništili efekti. Suština anti-SQL naredbe je u sledećem:

Insert se konvertuje u delete,

Delete se konvertuje u insert i

U slučaju ažuriranja, 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 generiše Redo SQL naredba

za transakcije čije izmene želimo da sačuvamo nakon čega se pristupa klasičnom oporavaku da

bi se potom pomoću 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 izmeĎu njih jeste u

količini informacija koje će se zapisati u dnevniku.

1. Full oporavak – u slučaju da se odabere sve izmene se zapisuju u transakcioni dnevnik.

Za pojedine aktivnosti (kao np. truncate table) vrši se zapisivanje manje informacija.

Prednost ovog modela jeste da se može izvršiti oporavak bilo koje transakcije.

Nedostatak jeste u činjenici da se sve izmene zapisuju u dnevnik što znači da će se

veličina fajla brzo povećavati. Zato je veoma važno da ukoliko se odabere ovaj model

redovno kreiraju rezervne kopije dnevnika.


13

2. Bulk-Logged – zamišljen je kao dodatak prvom. Glavna karakteristika jeste da se u

dnevniku vrši minimalno zapisivanje informacija o sledećim 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 slučaju znači da se vrši zapisivanje da su se nabrojane

aktivnosti izvršile ali ne i informacije o redovima koji su bili obuhvaćeni izmenama.

3. Simple oporavak– vrši se manje zapisivanje u dnevniku pri čemu će se dnevnik prazniti

svaki put kada se od strane SQL Servera postavi checkpoint. Ovaj model se obično koristi

kod baza podataka koje se koriste za razvoj i testiranje.

Izbor modela oporavka se može izvršiti preko Management Studia. Potrebno je odabrati bazu

podataka pa potom odabrati stranicu Options i preko padajućeg menija u (odeljku Recovery

model) odabrati jedan od ponuĎena tri, slika 7. Jednom odabran režim oporavka moguće je

kasnije uvek lako menjati preko ovog prozora.

Slika 7. Management Studio – odabir režima oporavka

Izmene režima oporavka se mogu izvršiti i upotrebom T-SQL-a:

alter database ImeBaze set recovery model

Kada je u pitanju sam oporavak podataka potrebno je istaći da je u SQL Server-u 2005

implementirana mogućnost automatskog oporavka podataka. To je moguće iz prostog razloga što

se u dnevniku zapisuju potrebne informacije tako da će u slučaju nestanka el. energije ili

nepravilnog gašenja servera doći do automatskog oporavka podatka uz uslov da nije došlo do

oštećenja podataka tako da su postali nečitljivi.


14

Oporavak se može izvršiti putem T-SQL naredbe gde je opšti izgled sintakse kad je u pitanju

oporavak celokupne baza podataka:

restore database ImeBaze from disk=’lokacija’

U slučaju da je reč o oporavku fajla ili fajlova opšti oblik je:

restore database ImeBaze

file/filegroup

from disk =’lokacija’

U slučaju da se sigurnosna kopija ne nalazi na disku nego na traci umesto disk koristiće se

tape.

Oporavak dnevnika putem T-SQL-a:

restore log ImeBaze from disk=’lokacija’

Da bi se izvršio 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 može izvršiti i preko Management

Studia. Prozor preko kojeg se vrši oporavak je prikazan na slici 8.

Slika 8. Oporavak putem Management Studia

Podrazumevana postavka jeste oporavak na tekuće stanje. Ukoliko se želi izvršiti oporavak na

stanje u nekom trenutku vremenu potrebno je odrediti vreme i datum preko posebnog ekrana,

slika 9.


15

Slika 9. Definisanje datuma i vremena

4.6. ALTERNATIVNI PRISTUPI REZERVNIM KOPIJAMA I OPORAVKU PODATAKA

Sigurnosne kopije su najsigurniji metod obezbeĎivanja od gubitka podataka. MeĎutim 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. Suština je postojanje još

jedne baze koja je identična online bazi podataka. Standby baza podataka se redovno ažurira

mada je teško postići 100% ažurnost. U slučaju da se pojavi bilo kakav problem sa online bazom

kontrola se prebacuje na standby bazu koja je tada online čime se omogućuje nesmetan nastavak

poslovanja. Običajno se stanby baze kreiraju putem offline rezervnih kopija nakon čega će se

izvršiti ažuriranje upotrebom dnevnika.

Replikacija (engl. replication) je postupak kopiranja i distribuiranja podataka i objekata iz

jedne baze podataka u drugu koji sadrži mehanizam za sinhronizaciju podataka. Razlikujemo:

Snapshot replikaciju – podrazumeva kreiranje kopije tabele baze podataka na osnovu

upita nad bazom podataka. Kada se kreira snapshot, specifičan upit se izvršava čime se

podaci učitavaju u snapshot tabelu. Prednost ovakvog tipa jeste jednostavna impleme-

ntacija a nedostatak jeste da je potrebno konstantno ažuriranje što zahteva dodatan posao

administratora.

Simetrična replikaciju – robusniji tip replikacije iz prostog razloga što se obezbeĎuje

automatsko ažuriranje replike što je i prednost ovog tipa. Kao nedostatak ovog tipa

replikacije se navodi da u slučaju velikog broja transakcija može uzrokovati degradaciju

performansi, teži je za administraciju i u slučaju problema u mreži može doći do pada

baze podataka usled nemogućnosti sinhronizacije.

4.7. PLANOVI ZA SLUČAJ GUBITKA PODATAKA

4.7.1. POTREBA ZA PLANIRANJEM

Planiranje oporavka za slučaj gubitka podataka predstavlja proces pripremanja preduzeća u

slučaju nastanka vanrednih situacija. Može se postaviti pitanje šta se podrazumeva pod tim?

Sungard Recovery Services pruža sledeću definiciju:

Svaki neplanirani gubitak kritičnih poslovnih aplikacija usled nedostatka sposobnosti obrade

podataka duže od 48h.


16

Prema DB2 Developer’s Guide: Svaki događaj koji ima malu verovatnoću nastanka, visok

stepen nesigurnosti sa potencijalno razornim posledicama.

U vanredne situacije pre svega ubrajamo elementarne nepogode poput: požara, poplave,

zemljotresa, uragane. Čovek takoĎe može biti uzrok: loše projektovane instalacije (električne,

gasne, vodovodne), loše obezbeĎena klimatizacija u prostorijama u kojima su serveri, sigurnosni

propusti, sabotaže u novije vreme i teroristički napadi.

Potrebno je da se prepoznaju potencijalne opasnosti i razumeju njihove posledice po

poslovanje preduzeća. Od lokacije firme će i zavisiti mogućnost od izbijanja različitih nepogoda.

Primera radi ukoliko je lokacija preduzeća priobalno područje preduzeće je više izloženo

poplavama i uraganima.

Činjenica da se organizacija nije još susrela sa vanrednim situacijama ili da se ne nalazi

području sa visokim rizikom ne oslobaĎa od potrebe za planiranjem. U slučaju bilo kakve

elementarne nepogode preduzeća bez plana su prepuštena milosti slučaja.

Svakako da se elementarne nepogode kao što su zemljotresi, poplave, požari i uragani ne

mogu sprečiti. MeĎutim budući da čovek takoĎe može biti uzročnik, neke situacije je ipak

moguće sprečiti Potrebno je definisati plan za slučaj gubitka podataka ail i je od iste važnosti i

izvršiti analizu da bi se odredilo mogu li se pojedine opasnosti izbeći.

Slika 10. Loša električna instalacija može dovesti do

požara i uništenja servera a time i podataka u organizaciji

Plan oporavka treba da obuhvati najvažnija pitanja: alternativne lokacije za poslovanje, oporavak

podataka, komunikacija sa zaposlenima, procedure i javno obaveštenje da bi se informisali

kupci. Da bi se definisao plan oporavka u slučaju vanredne situacije potrebno je najpre analizirati

rizike i odrediti ciljeve.

4.7.2. RIZIK I OPORAVAK

Cilj plana oporavka u slučaju vanredne situacije jeste smanjenje sledećih troškova:

Finansijski troškovi usled nemogućnosti pristupa podacima i aplikativnom softveru i

Troškovi gubitka kupca i poslovnih prilika.

Osim podataka neophodno je i da se izvrši analiza aplikativnog softvera koji se primenjuje u

poslovanju. Sve aplikacije se mogu podeliti na sledeće grupe u pogledu kritičnosti:


17

Vrlo kritične aplikacije – predstavljaju aplikacije koje bi trebalo prvo osbosobiti. Budući

da je reč o najkritičnijoj grupi potrebno je ograničiti njihov broj.Za ove aplikacije su

potrebni tekući podaci.

Poslovno – kritične aplikacije – pretsvaljaju aplikacije koje su važne za organizaciju i kao

takve treba da su sledeća grupa za oporavak. Kad su u pitanju podaci, za ove

aplikacije su bitni tekući podaci ali to nije od presudne važnosti kao u prethodnoj grupi.

Primera radi, ukoliko imamo organizaciju čija je delatnost pružanje telefonskih usluga

tada će aplikativni softver koji u okviru sistema koji obezbeĎuje telefonsku uslugu

pripadati prvoj grupi a aplikativni softver koji se koristi za obračun korisničkih računa će

pripadati drugoj.

Kritične aplikacije – mada je reč o važnim aplikacijama za organizaciju nije potrebno da

se odmah izvrši njihov oporavak.

Potrebne aplikacije – reč je oplikacijama koje nisu od presudne važnosti za organizaciju

ali to ne znači da za njih nisu potrebne rezervne kopije.

Nekritične aplikacije – mali broj aplikacija se može 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 ključnom osoblju u organizaciji. Svaki od učesnika bi trebao da ima jednu kopiju plana na

poslu a jednu kući. TakoĎe je bitno da se jedna kopija plana nalazi i na drugoj lokaciji.

Prednosti pisanja plana su:

Precizno se definišu aktivnosti,

Precizno se definiše njihov redosled,

Precizno se definišu alati koji će se koristiti kao i informacije o potrebnim sigurnosnim

kopijama potrebnim za oporavak,

Dokumentuje se lokacija i

ObezbeĎuje se postupak za ostalo osoblje u slučaju da glavno osoblje za slučaj 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

troškova i druge slične informacije

Osoblje – podatke o svakom članu tima zaduženog za oporavak. Osim imena i adrese

potrebno je da se uključe svi kontakt brojevi (na poslu, kod kuće, brojevi mobilnog

telefona).

Ovlašćenja – potrebno je da postoji lista ovlašćenja osobama zaduženim 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 može izvršiti

instalacija i koje su se koristile za održavanje.

Izveštaje – lista izveštaja koji će biti potrebni za oporavak. Izveštaji treba da obuhvate

podatke o svakom disku/traci gde su sigurnosne kopije, sadržaju, vremenu kreiranja kao i

kada su dopremljene iz matične lokacije i kada su stigle.


18

Nakon što se jednom napiše plan potrebno je izvršiti testiranje. Preporučljivo je da se

testiranje vrši jednom godišnje. Glavni cilj testiranja treba da bude identifikovanje slabosti

samog plana. Ukoliko se otkriju eventualni propusti potrebno je izvršiti korekcije. Treba dodati

da ispravno testiranje ne mora uvek da vodi uspešnom oporavku, iako je to poželjan rezultat.

Osim identifikovanja nedostataka, testiranje treba sprovoditi i da se proveri spremnost samog

osoblja. TakoĎe putem testiranja će se bolje upoznati alati i procedure koje će se upotrebiti

ukoliko se pojavi potreba za oporavkom.

Osim jednom godišnje preporučljivo je sprovesti testiranje u sledećim situacijama:

1. Značajne promene u dnevnim operacijama,

2. Izmene u hardveru,

3. Nadogradnja SUBP-a (ili softvera koji je u vezi sa njim),

4. Promene u osoblju zaduženom za oporavak,

5. Promena lokacije data centra,

6. Izmeneu proceduri kreiranja rezervne kopije,

7. Izmene aplikacija koje se koriste u dnevnom poslovanju,

8. Značajno povećanje količine podataka i broja transakcija.

Uspešno izvršavanje plana odreĎeno je izborom pravog tima. Kada je reč o SUBP-u tim mora

biti u stanju da instalira i ispravno konfiguriše SUBP, obezbedi njegovu integraciju sa drugim

aplikativnim softverom, proveri integritet, pravilno i instalira aplikativni softver i reši niz

problema koji se mogu pojaviti. Od presudne važnosti je da se tim redovno okuplja da bi testirao

plan. TakoĎe je potrebno obezbediti i prava pristupa svakom članu tima da bi mogao izvršiti svoj

deo zadatka kod oporavka.

Documents

Sigurnosne Kopije i Oporavak Baze Podataka