sigurnosne kopije i oporavak baze podataka
DESCRIPTION
Sigurnosne Kopije i Oporavak Baze PodatakaTRANSCRIPT
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.
Sigurnosne kopije i oporavak baze podataka
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
Sigurnosne kopije i oporavak baze 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
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 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,
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.
Opšti 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 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.
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.
Opšti 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 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:
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
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
to disk=’lokacija’
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.
Sigurnosne kopije i oporavak baze podataka
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?
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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:
Sigurnosne kopije i oporavak baze podataka
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.
Sigurnosne kopije i oporavak baze podataka
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.