12 čestih grešaka pri pravljenju rezervnih kopija baza podataka

Autor: Alexey Kovyazin, 11. novembar 2015.

Preuzmi PDF (engleski) Ovaj članak je prvobitno bio namenjen programerima i administratorima Firebird DBMS-a, ali kontakti sa administratorima drugih baza podataka jasno su pokazali da su većina grešaka zajedničke i njima i da bukvalno svi sapliću o skoro isto kamenje. Ako možete da dodate nešto na ovu listu (čak i nešto specifično za određeni DBMS), kontaktirajte nas putem naše e-pošte [email protected].

1. Brisanje prethodne rezervne kopije pre nego što se kreira nova rezervna kopija

Ova greška je najčešća među početnicima koji ne shvataju da glavna svrha rezervne kopije baze podataka nije samo pravljenje kopije baze podataka, već da vreme zastoja informacionog sistema (čiji je važan deo baza podataka) bude što kraće.

Kao rezultat toga, sistem ostaje nezaštićen od trenutka brisanja najnovije rezervne kopije do trenutka kreiranja nove, jer baza podataka tokom tog perioda nema nijednu rezervnu kopiju. Pošto kreiranje rezervne kopije može da potraje prilično dugo, to je savršeno vreme da Murphyjev zakon stupi na snagu. Ovaj pristup posebno dobro funkcioniše kada se kombinuje sa problemom 7 (videti ispod).

Preporuke: ne brišite prethodnu rezervnu kopiju pre nego što se nova kreira! (i ne pravite novu rezervnu kopiju u postojeći fajl).

Preporuka za Firebird: Postoji alat FBDataGuard uključen u HQbird (napredni distribucioni paket Firebird) koji briše najstariju rezervnu kopiju u istoriji tek nakon što se nova kreira.

2. Prepisivanje postojeće baze podataka prilikom njenog vraćanja iz rezervne kopije

Ova greška je ređa, iako rezultati mogu biti mnogo gori. Ako rezervna kopija nije verifikovana i ispostavi se da je oštećena (videti problem 6), nećete imati ni prethodnu kopiju baze podataka ni ispravnu rezervnu kopiju.

Ovakav haos obično se dešava u petak uveče kada nastane gužva i kada su uputstva uprave pomalo kontradiktorna. Malo loše sreće i lenj vikend u server sali je tu za vas.

Firebird ima svojevrsnu zaštitu od ove greške - neće biti moguće vratiti bazu podataka iz rezervne kopije pomoću uslužnog programa gbak ako je njegov podrazumevani prekidač -create uključen i ako navedeno ime fajla ukazuje na postojeću bazu podataka. Nažalost, postoji način da se zaobiđe ova zaštita: prekidač -rep i dalje dozvoljava prepisivanje postojećeg fajla.

Preporuka: nikada ne prepisujte fajl radne baze podataka bez pismene direktive vaše uprave.

Preporuka za Firebird: Koristite FBDataGuard jer on nikada ne prepisuje fajl baze podataka.

3. Korišćenje jednokoračnog rezervnog kopiranja/vraćanja bez korišćenja međufajla rezervne kopije

Standardni ulazno/izlazni tokovi omogućavaju da se sa mnogim DBMS-ovima (uključujući Firebird) izvede zanimljiv trik: implementira se striming rezervno kopiranje sa istovremenim vraćanjem baze podataka iz njega. Kao rezultat, ne kreira se nikakav međufajl rezervne kopije. To je zgodno za rutinsko održavanje i za pokretanje testne operacije vraćanja (pod uslovom da je dostupna druga rezervna kopija), ali ne smete ga koristiti za automatsko rezervno kopiranje!

Na primer, ako se tokom ovog procesa rezervnog kopiranja/vraćanja dogodi ozbiljan kvar diska, početna baza podataka može postati oštećena, a nova baza podataka još nije kreirana. Naravno, ako uzmete u obzir problem 1 i postoji kopija baze podataka iz prethodnog pokušaja, izgubiće se samo podaci kreirani ili ažurirani u bazi podataka nakon što je ta kopija napravljena.

Preporuke: ne koristite jednokoračno rezervno kopiranje/vraćanje u automatskom režimu i uvek proverite dostupnost kopije koja je dovoljno ažurna u ručnom režimu.

4. Čuvanje rezervnih kopija i baze podataka na istom fizičkom uređaju

Mnogima od vas može biti smešno što je savet koji dajemo pomalo detinjast - azbuka rezervnog kopiranja. Tačno je, ali baza podataka i disk mogu završiti na istom sistemu za skladištenje podataka zbog popularnosti virtuelnih okruženja. I sigurno će otkazati u najnepovoljnijem trenutku. Uz to, još uvek ima ljudi koji veruju da se njihovim podacima ništa ne može dogoditi ako koriste RAID nizove (verzije 1 ili više :)). Osim toga, ima ljudi koji veruju da su neki “brendirani” serveri otporni na kvarove, ali to je poseban slučaj.

Preporuke: ne čuvajte rezervne kopije i bazu podataka na istom uređaju bez obzira koliko se pouzdanim činio.

5. Nema kontrole nad uspešnim završetkom procesa rezervnog kopiranja

To je prilično česta greška i kod administratora i kod rukovodilaca IT odeljenja. Ako ne proveravate rezultate procesa rezervnog kopiranja, mogli biste ga uopšte i ne izvršavati. Morate primati obaveštenja o uspešno završenom procesu rezervnog kopiranja putem e-pošte ili, još bolje, i putem SMS poruka. A odsustvo takvih obaveštenja je znak problema!

Pažljiv čitalac koji je stigao dovde u našem članku (iako je još rano za nagradu za to) može da pita: ‘Ali kakve to veze ima sa upravom?’ Evo kakve - administrator obično konfiguriše proces rezervnog kopiranja, ali mu je previše dosadno da proverava obaveštenja, posebno kada su sačuvana u posebnom folderu, pa nikad nije previše zatražiti dodatne izveštaje o statusu procesa. To se odnosi na pitanje ko je kriv kada se čini kao da su rezervne kopije postojale, ali ih zapravo nema u trenutku kada su vam potrebne :)

! kada se jednom kombinuje sa problemom 2, nemamo ni bazu podataka ni njenu rezervnu kopiju.

Preporuke: koristite alate za automatizaciju rezervnog kopiranja koji mogu da prate uspešne i neuspešne procese rezervnog kopiranja, obaveštavaju korisnike o problemima i nude alate za sumarno upravljanje (posebno je relevantno kada treba kontrolisati desetine i stotine procesa rezervnog kopiranja na različitim serverima).

Preporuka za Firebird: FBDataGuard proverava da li je proces rezervnog kopiranja završen i šalje odgovarajuće obaveštenje. Za sisteme sa mnogo baza podataka postoji sumarno praćenje drugog nivoa pomoću alata Control Center koji vam omogućava da vidite statuse svih nadgledanih servera i baza podataka na jednoj stranici.

6. Nema validacije rezervne kopije

Činjenica da su rezervne kopije negde sačuvane ne znači da se iz njih mogu pročitati.

Zato morate redovno verifikovati rezervne kopije koje kreirate kako biste bili sigurni da nisu oštećene ili kopirane u /dev/null.

Preporuka za Firebird: validaciju rezervnih kopija možete automatizovati pomoću FBDataGuard.

7. Nema provera zdravlja baze podataka dok se koriste neverifikovane rezervne kopije

Obično baze podataka koriste nekoliko vrsta rezervnog kopiranja - dumpove, redovne rezervne kopije itd. Ne ulazeći u detalje, možemo izdvojiti dve kategorije: verifikovane i neverifikovane. U slučaju Firebird, to su gbak i nbackup.

Gbak čita celu bazu podataka na nivou zapisa kako bi kreirao fajl rezervne kopije i kreira bazu podataka umetanjem zapisa u novu bazu podataka, čime se verifikuje rezervna kopija (postoje načini da se greške uvuku u vraćenu kopiju, ali to je drugi način da administrator baze podataka zabrlja stvari vezane za loše organizovanu migraciju) i sama baza podataka (ako se može čitati od početka do kraja, najverovatnije nije oštećena).

Nbackup (poznat i kao inkrementalno rezervno kopiranje) privremeno zaključava glavni fajl baze podataka za ažuriranja (u konzistentnom stanju) i omogućava brzo kopiranje fajla baze podataka (u celosti ili delimično/inkrementalno).

U slučaju velikih Firebird baza podataka (većih od 500 GB), preporučljivo je koristiti nbackup kako se ne bi usporavale korisničke operacije, ali istovremeno je neophodno validirati bazu podataka jer neverifikovane rezervne kopije koje on kreira su kopije stranica baze podataka i ako greška postoji na nivou zapisa (zbog kvara RAM-a) ili na logičkom nivou, neverifikovana rezervna kopija će je sadržati kao i originalna baza podataka.

Da biste to izbegli, trebalo bi da koristite onlajn validaciju za originalnu bazu podataka (onlajn validacija uz pomoć gfix je dostupna počevši od Firebird verzije 2.5.4, dok naš alat FBDataGuard podržava onlajn validaciju baze podataka za verzije 1.5-2.5).

Takođe, preporučljivo je s vremena na vreme izvršiti verifikovanu rezervnu kopiju (na primer, jednom nedeljno) pored neverifikovane rezervne kopije.

Preporuka za Firebird: pored onlajn provere zdravlja, FBDataGuard vam omogućava da testirate proces vraćanja rezervne kopije u automatskom režimu.

8. Nema kontrole nad slobodnim prostorom za rezervne kopije

Zapravo, to je klasična greška: ako nema dovoljno prostora, rezervne kopije zauzimaju sav slobodan prostor i proces se završava greškom. Čuvanje rezervnih kopija na istom disku sa bazom podataka može dovesti do prekida u radu baze podataka, a njihovo čuvanje na sistemskom disku može rezultirati otkazom sistema.

U kombinaciji sa problemom 4, najbolji mogući ishod biće onaj kada sistem prestane da funkcioniše jer je bazi podataka takođe potreban slobodan prostor, ali ga zauzimaju rezervne kopije. Što se tiče kombinacije sa problemima 5 i 2, ona nas opet ostavlja bez baze podataka i bez njene rezervne kopije.

Preporuke: koristite alate za rezervne kopije koji predviđaju veličinu rezervne kopije i upozoravaju vas na mogući nedostatak slobodnog prostora.

Preporuka za Firebird: FBDataGuard kontroliše veličinu slobodnog prostora za potrebe rezervnih kopija, kao i veličinu slobodnog prostora na disku sa bazama podataka, kao i na sistemskom disku.

9. Nema kontrole nad vremenom potrebnim za kreiranje rezervne kopije

Proces rezervne kopije je trajao 40 minuta bukvalno pre pola godine, a onda odjednom već traje tri sata - zašto? Veličina baze podataka je možda porasla ili je disk možda ispao iz vašeg RAID niza, što je rezultiralo znatno sporijim performansama upisa, i sve vaše rezervne kopije su možda na ivici propasti. Ili je vaš dobar kolega možda pokrenuo još jedan sistem za rezervne kopije u isto vreme (uzgred, Firebird vam omogućava da pokrenete nekoliko procesa rezervnih kopija odjednom, iako nije sasvim jasno zašto bi to ikome uopšte trebalo). Ako ne kontrolišete vreme potrebno za pravljenje rezervne kopije, možete prevideti novonastali problem i propustiti priliku da ga rešite pre nego što postane masivan.

Osim toga, ako sistem za rezervne kopije ne prati statuse zadataka rezervnih kopija i pokreće ih samo po rasporedu, lako možete „preterati", što znači situaciju kada sistem pokrene novi proces rezervne kopije dok prethodni još nije završen.

Preporuke: koristite alate koji kontrolišu vreme koje proces rezervne kopije traje!

Preporuka za Firebird: FBDataGuard kontroliše vreme koje proces rezervne kopije traje.

10. Praćenje rezervne kopije baze podataka dok se primenjuju ažuriranja operativnog sistema

To je vrlo čest problem, posebno u kombinaciji sa problemom 9 i omogućenim automatskim Windows ažuriranjima (podrazumevano, ažuriranja se primenjuju u 3 ujutru). U najboljem slučaju to dovodi do usporavanja, ali ako se operativni sistem restartuje radi primene ažuriranja, rezervna kopija će biti oštećena. Barem je dobra vest da se operativni sistem ne ažurira svakog dana.

Preporuke: zakažite ažuriranja operativnog sistema kada ne ometaju proces rezervne kopije.

11. Praćenje rezervne kopije baze podataka uz pomoć alata za rezervne kopije datoteka ili alata za rezervne kopije virtuelnih mašina dok server baze podataka radi

Mnogi administratori zaboravljaju da svaki DBMS ima aktivan i složen keš koji sadrži podatke koji se čitaju i upisuju dok su same datoteke baze podataka otvorene u režimu slučajnog pristupa. Zbog toga je neophodno koristiti posebne tipove rezervnih kopija umesto pukog pravljenja rezervne kopije datoteka (uključujući samo kopiranje datoteka baze podataka) ili rezervne kopije virtuelne mašine. Alati za rezervne kopije datoteka čitaju bazu podataka sekvencijalno i to može potrajati prilično dugo, posebno u slučaju velikih baza podataka, pa je nemoguće garantovati integritet kreirane rezervne kopije.

Virtuelne mašine mogu koristiti mehanizme snimaka (snapshots) i praćenja promenjenih blokova (Changed Block Tracking), ali je neophodno sinhronizovati kreirane rezervne kopije kako bi se dobila konzistentna rezervna kopija baze podataka, jer će rezervna kopija biti nekonzistentna u slučaju bilo kakvih aktivnih operacija upisa u bazu podataka u trenutku sortiranja kolekcije promenjenih blokova.

Za one koji žele da naprave rezervne kopije svojih baza podataka uz pomoć alata za rezervne kopije datoteka ili virtuelnih mašina, možemo ponuditi dve metode:

1. potpuno isključite DBMS usluge i procese tako da u kešu nema ničega,
2. koristite agente i/ili skripte koje prebacuju bazu podataka u poseban režim koji čini bezbednim sekvencijalno kopiranje datoteke baze podataka. Na primer, postoji mehanizam koji se zove VSS writer za MSSQL baze podataka. Na zahtev, on prebacuje bazu podataka u režim pogodan za snimke u trenutku kada se snimak pravi. Ako koristite mehanizme zasnovane na praćenju promenjenih blokova (Changed Block Tracking), sami biste trebali da se pobrinete da baza podataka bude konzistentna u trenutku sinhronizacije.

Ako ne prebacite bazu podataka u režim pogodan za rezervne kopije, rezultujuća kopija baze podataka će izgledati kao da je došlo do hard reset-a (na primer, nestanka struje) na host računaru. Ovaj nivo pouzdanosti je apsolutno nedovoljan za većinu preduzeća. Više o tome možete saznati u članku „Peculiarities of Working with Databases on Virtual Machines".

Za Firebird, neophodno je zaključati glavnu datoteku baze podataka uz pomoć nbackup pre nego što proces rezervne kopije počne i otključati je nakon što se proces završi. Za druge DBMS postoje slični alati za uključivanje/isključivanje odgovarajućih režima.

Neki administratori baza podataka su sigurni da mogu bezbedno da naprave rezervne kopije svojih baza podataka uz pomoć standardnih alata za rezervne kopije datoteka ako DBMS ima transakcioni dnevnik, jer će u najgorem slučaju samo taj dnevnik biti oštećen. To je opasna zabluda koju programeri DBMS-a ne podržavaju.

Koreni ove zablude su jasni: agresivno oglašavanje od strane programera virtuelnih mašina i alata za rezervne kopije obično ne pominje da baze podataka, kao i druge datoteke koje se intenzivno ažuriraju, zahtevaju naprednu konfiguraciju. Ne verujte hajpu - nisu svi jogurti jednako korisni.

Preporuke: ne koristite alate za rezervne kopije datoteka i virtuelnih mašina bez odgovarajućih alata za automatizaciju za baze podataka.

Preporuka za Firebird: koristite FBDataGuard (iz distributivnog paketa HQbird), on pruža integraciju sa alatima za rezervne kopije koji podržavaju VSS.

12. Zamenjivanje rezervne kopije replikacijom

Rezervne kopije podataka i replikacija podataka se koriste za povećanje pouzdanosti i sprečavanje gubitka podataka, ali su ipak prilično različite.

Svi vole replikaciju zbog mogućnosti sinhronizacije podataka na drugom serveru sa minimalnim kašnjenjem, ali i rezervna kopija ima neke neosporne prednosti. Na primer, u slučaju slučajnog (ili namernog) brisanja podataka, replikacija će brzo i nepokolebljivo poslati promene na repliku, dok je rezervna kopija (posebno sa kopijama na medijima samo za čitanje) imuna na takve operacije. Potreban je određeni napor da se pravilno konfigurišu i replikacija i rezervna kopija, a mogućnost grešaka i dalje postoji.

Preporuke: Ako imate konfigurisanu replikaciju, ne zanemarujte rezervne kopije, koristite obe.

Preporuka za Firebird: koristite distributivni paket HQbird Enterprise, on uključuje i alate za rezervne kopije i alate za replikaciju.

Rezime

Nije tako lako konfigurisati rezervne kopije za vaš omiljeni DBMS, pa administratori baza podataka iz organizacija u kojima cene svoje podatke obično koriste profesionalne alate za rezervne kopije koji im omogućavaju da uzmu u obzir gore pomenute probleme i spreče ih.

Za Firebird (izvinjavamo se zbog reklame) postoji paket koji se zove HQbird i koji uključuje FBDataGuard.

Takođe, naša kompanija pruža kompletnu podršku za rezervne kopije i održavanje za Firebird i druge baze podataka, što je dobar izbor za one koji nisu upoznati sa svim tehničkim detaljima rezervnih kopija.

I, naravno, nastavite da negujete svoju administratorsku paranoju, na primer, ustanite i proverite svoje rezervne kopije odmah :)

Kontakti

Slobodno postavite bilo koje pitanje: [email protected]

Želite da dobijate vesti i članke o Firebird? Pridružite nam se na Telegramu https://t.me/firebirdsql