Andmebaaside varundamise juhend

– Oh, ühtegi varjupaika ei suuda meteoriiditähet taluda. Kuid nagu igal inimesel, on ka teil varu, seega võite muretseda.

Stanislaw Lem, „Ijon Tichi tähtede päevikud“

Tagaistu tähendab andmete koopia salvestamist kuskil väljaspool nende põhikohta.

Tagaistumise peamine eesmärk on andmete taastamine nende kadumise korral. Seetõttu kuuleb sageli, et andmebaasi reklaami olemasolu tagab alati andmete taastamise ja tagaistmine pole vajalik. Tegelikult võimaldab tagaistus lahendada vähemalt kolm ülesannet, mida ei saa lahendada reklaami abil, ja reklaami ei saa ka ilma tagaistumiseta algatada.

Esiteks võimaldab tagaistus andmete taastamist loogilise vea korral. Näiteks kui raamatupidaja kustutas rühma kannet või andmebaasi administraator hävitas tabeliruumi. Mõlemad toimingud on andmebaasi vaatepunktist täiesti legitiimsed ning replikatsiooni protsess kopeerib need repliikas.

Teiseks, kaasaegsed andmebaasi haldustarkvarad on üsna usaldusväärsed, kuid vahel võivad andmebaasi sisemised struktuurid siiski kahjustuda, mille järel andmetele ligipääs kaob. Eriti vale meelestatus, et selline rikkumine toimub tavaliselt suure koormuse või mingite uuenduste paigaldamise ajal. Kuid nii suur koormus kui ka regulaarne uuendamine viitavad sellele, et andmebaas ei ole testimisel ja selles hoitavad andmed on väärtuslikud.

Lõpuks on kolmas ülesanne, mille lahendamiseks on vajalik varukoopia olemasolu, andmebaasi kloonimine, näiteks testimise eesmärkidel.

Andmebaaside varundamine põhineb ühel kahest põhimõttest:

• Andmete valimine järgnevaks salvestamiseks suvalises formaadis;
• Andmebaasi failide seisundi jäädvustamine ja logide salvestamine.

Vaatame neid põhimõtteid ja nende elluviimise tööriistu lähemalt.

Andmete eksportimine

Iga andmebaasi utiliidi komplekti kuuluvad andmete eksportimise ja importimise tööriistad. Andmed salvestatakse kas tekstivormingus või konkreetse andmebaasi jaoks mõeldud binaarsetes vormingutes. Allpool on tabel selliste tööriistade nimekirjaga:

Binaarne vorming
Tekstivorming

Oracle
DataPump Eksport/DataPump Import
Eksport/Import
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
unload/load
unload/load

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Tekstivorming on hea, kuna seda saab redigeerida või isegi luua väliste programmide abil, samas kui binaarne vorming võimaldab andmete kiiret eksportimist ja importimist, säästes ressursse vormingute konverteerimisel.

Kasuandmete eksportimine, hoolimata selle lihtsusest ja selgest ideest, ei ole koormatud tööstuslike andmebaaside varundamiseks sageli sobilik. Siin on põhjused, miks eksport ei sobi täielikuks varundamiseks:

• ekspordiprotsess koormab oluliselt lähte süsteemi;
• ekspordiks kulub palju aega – ekspordi lõpuks on see juba aegunud.
• Kogu andmebaasi kooskõlastatud väljund suure koormuse ajal on praktiliselt võimatu, sest andmebaasisüsteem peab säilitama oma oleku koopia väljundi algusaegadel. Mida rohkem tehinguid on olnud väljundi algusest peale, seda suurem on koopia maht (aktuaalsete andmete koopiad PostgreSQL-is, undo ala Oracle-is, tempdb Microsoft SQL Server-is jne);
• Väljund säilitab andmete loogilise struktuuri, kuid mitte füüsilise struktuuri – tabelite füüsilise salvestamise parameetrid, indeksid jne.

Kuid väljundil on ka eelised:

• kõrge valikuvõime: saab väljundada eraldi tabeleid, eraldi välju ja isegi eraldi ridu;
• Väljundatud andmeid saab laadida teise versiooni andmebaasi, ja kui väljund on tehtud tekstiformaadis, siis ka teise andmebaasi.

Seega kasutatakse väljundit peamiselt selliste ülesannete jaoks nagu väikeste tabelite (nt registrite) varundamine või andmekogumite levitamine koos rakenduse järgmise versiooniga.

Andmebaaside varundamise kõige levinum meetod on andmebaasi failide kopeerimine.

„Külm“ andmebaasifailide salvestamine

Ilmselt on mõte see, et peatada andmebaas ja kopeerida kõik selle failid. Sellist varukoopiat nimetatakse „külmaks“. Meetod on äärmiselt usaldusväärne ja lihtne, kuid tal on kaks silmatorkavat puudust:

• „külma“ varukoopia abil on võimalik taastada ainult see andmebaasi seisund, mis oli peatamise hetkel; tehingud, mis toimusid pärast andmebaasi taaskäivitamist, ei sisaldu „külmas“ varukoopias;
• kaugeltki mitte igal andmebaasil ei ole tehnoloogilist akent, mil ajal saab andmebaasi peatada.

Kui aga „külm“ varukoopia sobib, tuleb meeles pidada, et

• „külm“ koopia peab mõnikord sisaldama ka žurnale. Meetodid, kuidas määrata, millised žurnalid peaksid jõudma „külma“ koopia, on iga DBMS jaoks individuaalsed. Näiteks Oracle'is tuleb kopeerida nn online redo, st kindel arv žurnalfailidest spetsiaalses kataloogis, isegi siis, kui andmebaas on õigesti peatatud. PostgreSQL-is tuleb salvestada kõik žurnalid alates žurnalist, mis sisaldab viimast kontrollpunkti, mille teave on haldusfailis.
• Andmebaasi kataloog võib sisaldada piisavalt suuri ajutiste tabeliruumide faile, mida ei ole vajalik varukoopiasse kaasata. Muide, see märkus kehtib ka „sooja” varukoopia kohta.

„Soe” failide salvestamine

Enamik tänapäevaste andmebaaside varukoopiaid tehakse andmebaasi faile kopeerides ilma andmebaasi seiskamata. Siin on mitu probleemi:

• Kopeerimise alguses võib andmebaasi sisu mitte kattuda failide sisuga, kuna osa teabest asub vahemälus ja pole veel kettale salvestatud.
• Kopeerimise ajal võib andmebaasi sisu muutuda. Kui kasutatakse muudetavaid andmestruktuure, siis muutub failide sisu, ja kui kasutatakse muutumatuid struktuure, muutub failide kogum: uued failid tekivad ja vanad kustutatakse.
• Kuna andmete kirjutamine andmebaasi ja andmebaasi failide lugemine ei ole omavahel sünkroniseeritud, võib varukoopia tarkvara lugeda vigast lehte, kus pool on vana versioon ja teine pool uus.

Kuna varukoopia oleks kooskõlas, on igal andmebaasisüsteemil käsk, mis teatab, et varukoopiate tegemise protsess on alanud. Sündaks see käsk võib erinevates süsteemides välja näha erinevalt:

• Oracle's on see eraldi käsk ALTER DATABASE/TABLESPACE BEGIN BACKUP;
• PostgreSQL'is – funktsioon pg_start_backup();
• Microsoft SQL Serveris ja DB2-s toimub ettevalmistus varukoopiamiseks kaudselt BACKUP DATABASE käsku täites;
• MySQL Enterprise'is, Cassandra's ja MongoDB-s toimub ettevalmistus kaudselt välistööriistade abil – vastavalt mysqlbackup, OpsCenter ja Ops Manager.

Hoolimata süntaktilistest erinevustest, näeb varukoopiate tegemise ettevalmistus välja ühtlaselt.

Nii näeb varukoopiate tegemise ettevalmistus välja andmebaasisüsteemides, kus on muudetavad ketasstruktuurid, st kõigis traditsioonilistes ketasrelatsioonilistes süsteemides:

1. Käitumise alguspunkt jääb meelde; varukoopia peab sisaldama andmebaasi logisid alates sellest hetkest.
2. Kontrollpunkt on käimas, mille käigus kõik andmelehtede muutused, mis on toimunud enne salvestatud hetkest, kirjutatakse kettale. See tagab, et varukoopia alguse hetkeni kehtinud logisid ei vajata taastamise ajal.
3. Käivitub eriline logimise režiim: kui andmeleht muutub esmakordselt pärast kettalt laadimist, siis selle asemel, et logisse kirja panna andmelehe muudatus, salvestab andmebaas sinna kogu lehe. Etteteatamise protseduuri käigus kirjutatakse kõik lehed kettale ja seetõttu on iga esmakordse muutuse korral leht alati logis tervikuna. Kuid kui andmeleht on jälle varukoopia käigus kettale kirjutatud, siis järgnev muudatus toob samuti kaasa logis terve lehe koopia. See tagab, et kui failiga andmed kopeerides peaks andmeleht osutuma vigaseks, siis logi rakendamine teeb selle taas korrektseks.
4. Failide päise muutmine on blokeeritud, see tähendab selle osa muutmine, mida ei kajastata žurnaalides. See tagab, et päis kopeeritakse õigesti ja seejärel rakendatakse žurnaalid õigesti andmefailile.

Kui kõik ülaltoodud protseduurid on lõpetatud, saab andmefaile kopeerida operatsioonisüsteemi tööriistadega – cp, rsync ja teistega. Varundusrežiimi sisselülitamine vähendab andmebaasi jõudlust: esiteks suureneb logifailide maht ja teiseks, kui varundusrežiimi ajal tekib rike, on taastamine kestvam, kuna andmefailide päiseid ei uuendata. Mida kiiremini varundus lõppeb, seda parem on andmebaasile, seega on siin asjakohane kasutada selliseid tööriistu nagu failisüsteemi hetkeseis (snapshot) või peegli katkestamine (BCV) diskiraidil. Mõned andmebaasi haldustarkvarad (nt Oracle, PostgreSQL) jätavad administraatorile võimaluse valida kopeerimise meetod, teised (nt Microsoft SQL Server) pakuvad liidest oma varundustööriistade integreerimiseks failisüsteemide või andmesalvestussüsteemidega.

Varundusprotsessi lõppedes tuleb andmebaas viia tagasi normaalsesse olekusse. Oracle'is tehakse seda käsklusega ALTER DATABASE/TABLESPACE END BACKUP, PostgreSQL'is funktsiooni pg_stop_backup() kutsumisega, teistes andmebaasides aga vastavate käskude või välist teenuseid kasutavate sisemiste alamprogrammidega.

Nii näeb välja protsessi varundamise ajaskaala:

• Varundamiseks ettevalmistamine (begin backup) võtab aega, mõnikord märkimisväärselt. Isegi kui kasutatakse peegeldavaid mahte või failisüsteeme, mis võimaldavad teha pilte, ei toimu varundamisprotsess kohe.
• Koos andmefailidega tuleb salvestada ajakirjad alates varundamise ettevalmistamise algusest kuni hetkest, mil andmebaas naaseb normaalsesse olekusse.
• Selle varukoopia põhjal on võimalik taastuda hetkel, mil andmebaas naaseb normaalsesse olekusse. Varundamine varasemaks ajaks ei ole võimalik.

Andmebaasidega, mis kasutavad muutumatuid andmestruktuure (mälu pildid, LSM-puude), on olukord lihtsam. Varundamiseks ettevalmistamise protsess koosneb järgmistest etappidest:

1. Mälu andmed salvestatakse kettale.
2. Loetakse failide nimekiri, mis kuuluvad varukoopiasse. Seni, kuni varundamisprotsess ei ole lõpetatud, on andmebaasil keelatud neid faile kustutada, isegi kui need enam ei ole vajalikud.

Varundamise lõppsignaali korral võib andmebaas muutumatute struktuuridega uuesti kustutada mittevajalikud failid.

Taastamine punktis

Varukoopia võimaldab taastada andmebaasi oleku hetkel, mil katkestati varundamisrežiimi taastumise käsk. Siiski võib õnnetus, mille puhul taastamine on vajalik, juhtuda igal ajal. Andmebaasi oleku taastamise ülesanne, mis on määratletud kindlal hetkel, nimetatakse "punktipõhiseks taastamiseks" (point-in-time recovery).

Selle võimaluse tagamiseks tuleks alates varukoopia lõppemisest säilitada andmebaasi logisid ning taastamise käigus jätkata logide rakendamist taastatud koopiale. Pärast seda, kui andmebaas on taastatud varukoopiast ajas, mis vastab koopia lõppemise hetkele, on andmebaasi olek (failide ja vahemälus hoitavate lehtede) korralikult tagatud, seetõttu ei ole erilist logimist vaja. Rakendades logisid soovitud momenti, on võimalik saavutada andmebaasi seisund mis tahes ajahetkeks.

Kui varukoopia taastamise kiirus on piiratud vaid ketta läbilaskevõimega, siis ajakirjade kasutamise kiirus on tavaliselt piiratud protsessori jõudlusega. Kui peamisemas andmebaasis toimuvad muudatused paralleelselt, siis taastamisel teostatakse kõik muudatused järjestikku - ajakirjast lugemise järjekorras. Seega sõltub taastamisaeg lineaarset sellest, kui kaugel taastamispunkt on varukoopia lõpp-punktist. Selle tõttu tuleb teha üsna sageli täisvarukoopiaid - vähemalt kord nädalas madala tehingukoormusega andmebaaside jaoks ja kuni igapäevaste varukoopiate tegemiseks kõrge koormusega andmebaaside jaoks.

Inkrementaalne varukoopia

Taastamise kiirus on soovitav, et varukoopiaid saaks teha võimalikult sageli, kuid samas mitte võtta liigset ruumi kettalt ja mitte koormata andmebaasi varukoopiate tegemise ülesannetega.

Probleemi lahendus on inkrementaalne varundamine, see tähendab ainult nende andmelehtede kopeerimist, mis on muutunud alates eelmise varundamise hetkest.
Inkrementaalne varundamine on mõttekas ainult andmebaasisüsteemides, mis kasutavad muudetavaid andmestruktuure.

Inkrement võib lähtuda kas täielikust varukoopiast (kumulatiivne koopia) või mis tahes eelnevast koopiast (diferentsiaalne koopia).

Kahjuks ei ole ühtegi ühtset terminoloogiat ja erinevad tootjad kasutavad erinevaid termineid:

Diferentsiaalne
Kumulatiivne

Oracle
Differential
Cumulative

PostgresPro
Inkrementaalne
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Inkrementaalne

Kuna inkrementaalsed kopeerid on olemas, näeb taastamisprotsess punktist välja järgmine:

• taastatakse viimane täisvarukoopia, mis tehti enne taastamispunkti;
• täisvarukoopia peale taastatakse inkrementaalsed koopiad;
• taastatakse logid varundamise alguspunktist taastamispunktini.

Kumulatiivne koopia kiirendab taastamisprotsessi. Näiteks, et taastada andmebaasi seisund ajavahemikus T3 ja T4, tuleb taastada kaks inkrementaalset koopiat, kuid ajavahemiku T4 järel taastamiseks piisab ainult ühest.
On selge, et ühe kumulatiivse koopia maht on väiksem kui mitme diferentsiaalse koopia maht, sest mõned lehed on mitu korda muutunud ja iga inkrementaalne koopia sisaldab oma versiooni lehelt.

Inkrementaalse koopia loomise kolme meetodit on:

1. täieliku koopia loomine ja erinevuse arvutamine eelmise täieliku koopia suhtes;
2. logide analüüs, muudetud lehtede nimekirja koostamine ja loendis olevate lehtede varundamine;
3. muudetud lehtede pärimine andmebaasist.

Esimene meetod säästab kettaruum, kuid ei lahenda andmebaasi koormuse vähendamise probleemi. Veelgi enam, kui meil on täisvarukoopia, pole mõtet seda inkrementaalseks muuta, kuna täiskoopiate taastamine on kiirem kui eelneva täiskoopiat ja inkrementi taastamine. Diskiruumi kokkuhoidu on parem usaldada spetsiaalsetele komponentidele koos sisseehitatud dedupikatsioonimehhanismidega. Need võivad olla näiteks spetsiaalsed salvestussüsteemid (EMC DataDomain, HPE StorageWorks VLS, kogu NetAppi tootevalik) või tarkvaralahendused (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Teine ja kolmas meetod erinevad muudetud lehekülgede loendi määramise mehhanismi poolest. Logide analüüs on ressursimahukas, lisaks peab selle rakendamiseks olema teadmisi logifailide struktuurist. Küsimine andmebaasilt, millised leheküljed täpselt on muutunud, on kõige lihtsam, kuid selleks peab DBMS-i südamik omama muudetud plokkide jälgimise funktsionaalsust (block change tracking).

Esmakordselt loodi inkrementaalse varundamise funktsionaalsus Oracle Recovery Manageri (RMAN) tarkvaras, mis ilmus Oracle 8i versioonis. Oracle rakendas kohe muudetud blokki jälgimist, seega ei ole ajaloos kirjutatud logide analüüsimiseks vajadust.

PostgreSQL ei jälgi muudetud bloke, seetõttu määrab Venemaa ettevõtte Postgres Professional välja töötatud utiliit pg_probackup muudetud lehed logi analüüsimise kaudu. Ettevõte tarnib ka andmebaasi PostgresPro, mis sisaldab laiendust ptrack, mis jälgib lehtede muutusi. Kasutades pg_probackup'i koos andmebaasiga PostgresPro, küsib utiliit muudetud lehti otse andmebaasilt — just nagu RMAN.

Microsoft SQL Server jälgib muudetud lehti nagu Oracle, kuid BACKUP käsk võimaldab teha ainult täielikke ja kumulatiivseid varukoopiaid.

DB2-s on võimalik jälgida muudetud lehti, kuid vaikimisi on see välja lülitatud. Pärast aktiveerimist võimaldab DB2 luua täis-, erineva ja kumulatiivseid varukoopiaid.

Oluline erinevus selles osas kirjeldatud tööriistade (välja arvatud pg_probackup) ja failipõhiste varundustööriistade vahel on see, et need küsivad andmebaasilt lehekülje pilte, mitte ei loe andmeid ise kettalt. Selle lähenemise puuduseks on väike lisakoormus andmebaasile. Siiski kompenseeritakse see puudus kenasti sellega, et loetud lehekülg on alati korrektne, mistõttu pole varundamise ajaks erijuhtimise režiimi kasutamise vajadust.

Veel kord tõstke tähelepanu, et inkrementaalsete koopia olemasolu ei tühista nõudeid ajalooraamatute olemasolu kohta, et taastada andmed suvalisse ajapunkti. Seetõttu kirjutatakse tööstuslikes andmebaasides ajalooraamatud pidevalt välisele meediale, samas kui varukoopiad, olgu need täis- ja/või inkrementaalsed, luuakse graafiku alusel.

Praegu parim inkrementaalse varunduse idee elluviimine on tarkvara-riistvara kompleks (Oracle'i terminoloogias - engineered system) Zero Data Loss Recovery Appliance - spetsialiseeritud Oracle'i lahendus oma andmebaasi varundamiseks. Kompleks koosneb klastrist serverite suurt kõvakettamahtu, millel on installitud muudetud versioon tarkvarast Recovery Manager ja mis saab töötada koos teiste Oracle’i riist- ja tarkvarakompleksidega (Database Appliance, Exadata, SPARC Supercluster), samuti Oracle’i andmebaasidega traditsioonilises infrastruktuuris. Erinevalt 'tavalisest' RMAN-ist on ZDLRA-s rakendatud 'igavese inkremendi' (incremental forever) kontseptsioon. Süsteem loob ühekordselt täieliku andmebaasi koopia ja seejärel teeb ainult inkrementaalseid koopiaid. Täiendavad RMAN-moodulid võimaldavad koopiaid liita, luues uusi täielikke koopiaid inkrementaalsetest.

Venemaa arendajate au on märkida, et ka pg_probackup oskab inkrementaalseid koopiaid liita.

Erinevalt paljusid sarnaseid küsimusi, küsimusel 'milline varundusmeetod on parem' on üheselt mõistetav vastus - parim on kõige sobivam oma kasutatava andmebaasi haldussüsteemi (SÜB) utiliit, mis toetab inkrementaalset varundamist.

Andmebaasi administratori jaoks on palju olulisemad küsimused varundusstrateegia valik ja andmebaasi varundamise vahendite integreerimine ettevõtte infrastruktuuri. Kuid need küsimused jäävad selle artikli raamidest välja.

Allikas: habr.com