ProHoster > Blog > Administrimi > Udhëzuesi për backup-in e bazave të të dhënave

Udhëzuesi për backup-in e bazave të të dhënave

– O, asnjĂ« strehĂ« nuk mund tĂ« pĂ«rballojĂ« goditjen e njĂ« meteori. Por, si gjithkush, ju keni njĂ« rezervĂ«, kĂ«shtu qĂ« mund tĂ« mos shqetĂ«soheni.

Stanislav Lem, «Dairy Star të Ijon Tichit»

Backup i referohet ruajtjes së një kopjeje të të dhënave diku jashtë vendit kryesor të ruajtjes së tyre.

Udhëzuesi për backup-in e bazave të të dhënave

Qëllimi kryesor i backup-it është rikthimi i të dhënave pas humbjes së tyre. Në këtë kontekst, shpesh dëgjohet se nëse ekziston një replikë e bazës së të dhënave, gjithmonë mund të rikuperoni të dhënat prej saj, dhe backup-i nuk është i nevojshëm. Në të vërtetë, backup-i lejon zgjidhjen e të paktën tre problemeve që nuk mund të zgjidhen përmes një replike, dhe gjithashtu nuk është e lehtë të inicializohet një replikë pa një kopje rezervë.

Së pari, një kopje rezervë lejon rikthimin e të dhënave pas një gabimi logjik. Për shembull, një accountant fshin një grup operacionesh ose një administrator i bazës së të dhënave shkatërron hapësirën e tabelave. Të dyja operacionet janë krejt legjitime nga pikëpamja e bazës së të dhënave, dhe procesi i replikimit do të i reproduktojë ato në bazën-ruajtes.

Së dyti, sistemet moderne të menaxhimit të të dhënave janë komplekse shumë të besueshme, megjithatë, ndonjëherë ndodhin shqetësime të brendshme në strukturat e bazës së të dhënave, pas të cilave humbet qasja në të dhëna. E veçanta është se kjo ndodhi shpesh ndodhi gjatë ngarkesës së lartë ose gjatë instalimit të ndonjë azhurnimi. Por ngarkesa e lartë, ashtu si dhe azhurnimet e rregullta, tregojnë se baza e të dhënave nuk është thjesht testuese dhe të dhënat që ruhen aty janë të vlefshme.

Së fundi, detyra e tretë që kërkon një kopje rezervë është klonimi i bazës, për shembull, për qëllime testi.

Backup-et e bazave të të dhënave janë, në një apo tjetër formë, të bazuara në një nga dy parimet:

  • E nxjerrĂ« e tĂ« dhĂ«nave pasuar nga ruajtja nĂ« njĂ« format tĂ« rastĂ«sishĂ«m;
  • NjĂ« snapshot i gjendjes sĂ« skedarĂ«ve tĂ« DB dhe ruajtja e ditarĂ«ve.

Le të shqyrtojmë këto parime dhe mjetet që i realizojnë ato më në detaje.

Nxjerrja e të dhënave

Në koleksionin e mjeteve që shoqërojnë çdo DBMS, patjetër që ekzistojnë mjete për nxjerrjen dhe ngarkimin e të dhënave. Të dhënat ruhen ose në format tekst, ose në format binar, specifik për secilin DBMS. Tabela më poshtë tregon një listë të tillë mjete:

Formati binar
Formati tekstual

Oracle
DataPump Export/DataPump Import
Export/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

Formati tekstual është i mirë sepse mund të redaktohet ose madje të krijohet nga programe të jashtme, ndërsa formati binar është i mirë sepse lejon shpërndarjen dhe ngarkimin më të shpejtë të të dhënave për shkak të kursimit të burimeve në konvertimin e formateve.

Megjithëse ideja e nxjerrjes së të dhënave është e thjeshtë dhe e dukshme, ky metod nuk përdoret shpesh për rezervimin e bazave të dhënash industriale me ngarkesë. Këtu janë arsyet përse nxjerrja nuk është e përshtatshme për një backup të plotë:

  • procesi i nxjerrjes krijon ngarkesĂ« tĂ« konsiderueshme nĂ« sistemin burim;
  • nxjerrja merr shumĂ« kohĂ« – deri nĂ« kohĂ«n kur pĂ«rfundon nxjerrja, ajo do tĂ« bĂ«het tashmĂ« joaktuale;
  • tĂ« realizosh njĂ« nxjerrje tĂ« njĂ«jtĂ« tĂ« gjithĂ« bazĂ«s sĂ« tĂ« dhĂ«nave gjatĂ« ngarkesĂ«s sĂ« lartĂ« Ă«shtĂ« praktikisht e pamundur, pasi DBMS Ă«shtĂ« e detyruar tĂ« mbajĂ« njĂ« snapshot tĂ« gjendjes sĂ« saj nĂ« momentin e fillimit tĂ« nxjerrjes. Sa mĂ« shumĂ« transaksione tĂ« kryhen qĂ« nga fillimi i nxjerrjes, aq mĂ« i madh Ă«shtĂ« volumi i snapshot-it (kopjet joaktuale tĂ« tĂ« dhĂ«nave nĂ« PostgreSQL, hapĂ«sira e anullimit nĂ« Oracle, tempdb nĂ« Microsoft SQL Server, etj.);
  • nxjerrja ruan strukturĂ«n logjike tĂ« tĂ« dhĂ«nave, por nuk ruan strukturĂ«n fizike tĂ« tyre – parametrat e ruajtjes fizike tĂ« tabelave, indekset dhe tĂ« tjera.

Megjithatë, nxjerrja ka dhe përfitimet e saj:

  • zgjedhja e lartĂ«: mund tĂ« nxjerrni tabela tĂ« veçanta, fusha tĂ« veçanta dhe madje edhe rreshta tĂ« veçanta;
  • tĂ« dhĂ«nat e nxjerra mund tĂ« ngarkohen nĂ« njĂ« bazĂ« tĂ« dhĂ«nash tjetĂ«r versioni, dhe nĂ«se nxjerrja bĂ«het nĂ« format tekst, edhe nĂ« njĂ« bazĂ« tĂ« dhĂ«nash tjetĂ«r.

Kështu, nxjerrja përdoret kryesisht për detyra të tilla si rezervimi i tabelave të vogla (p.sh., listave) ose shpërndarja e grupeve të të dhënave me aktualizimin e fundit të aplikacionit.

Metoda më e zakonshme e rezervimit të bazave të të dhënave është kopjimi i skedarëve të bazës.

Ruajtja "e ftohtë" e skedarëve të DB

Ideja Ă«shtĂ« e qartĂ« – ndaloni bazĂ«n e tĂ« dhĂ«nave dhe kopjoni tĂ« gjithĂ« skedarĂ«t e saj. Kjo rezervĂ« quhet "e ftohtĂ«". Ky metod Ă«shtĂ« jashtĂ«zakonisht i besueshĂ«m dhe i thjeshtĂ«, por ka dy disavantazhe tĂ« dukshme:

  • nga njĂ« kopje "e ftohtĂ«" rezervĂ« mund tĂ« rikuperohet vetĂ«m gjendja e bazĂ«s sĂ« tĂ« dhĂ«nave qĂ« ishte nĂ« momentin e ndaljes; transaksionet e kryera pas rinisjes sĂ« bazĂ«s nuk do tĂ« pĂ«rfshihen nĂ« kopjen "e ftohtĂ«".
  • nuk çdo bazĂ« tĂ« dhĂ«nash ka njĂ« dritare teknologjike, kur mund tĂ« ndalet baza.

Nëse kopjimi "i ftohtë" ju përshtatet, duhet të mbani mend se

  • "kopja e ftohtĂ«" ndonjĂ«herĂ« duhet tĂ« pĂ«rfshijĂ« edhe regjistrat. Metodat pĂ«r pĂ«rcaktimin e regjistrave qĂ« duhet tĂ« jenĂ« pjesĂ« e kopjes "e ftohtĂ«" janĂ« individuale pĂ«r çdo DBMS. PĂ«r shembull, nĂ« Oracle Ă«shtĂ« e nevojshme tĂ« kopjohen regjistrat online redo, dhe kjo do tĂ« thotĂ« se njĂ« numĂ«r i caktuar i skedarĂ«ve regjistrues nĂ« njĂ« katalog tĂ« veçantĂ«, madje edhe kur baza ndalhet nĂ« mĂ«nyrĂ« korrekte. NĂ« PostgreSQL, tĂ« gjithĂ« regjistrat duhet tĂ« ruhet duke filluar nga regjistri qĂ« pĂ«rmban pikĂ«n e fundit tĂ« kontrollit, informacioni pĂ«r tĂ« cilin ndodhet nĂ« skedarin administrativ.
  • katalogu i bazĂ«s sĂ« tĂ« dhĂ«nave mund tĂ« pĂ«rmbajĂ« skedarĂ« tĂ« mĂ«dhenj tĂ« hapĂ«sirave tĂ« pĂ«rkohshme tĂ« tabelave, tĂ« cilat nuk Ă«shtĂ« e nevojshme tĂ« pĂ«rfshihen nĂ« kopjen rezervĂ«. PĂ«r mendje, ky vĂ«rejtje Ă«shtĂ« e vĂ«rtetĂ« edhe pĂ«r kopjimin "e nxehtĂ«".

"Kopjimi i nxehtë" i skedarëve

Shumica e kopjeve rezervë të bazave të të dhënave moderne kryhen duke kopjuar skedarët e bazës së të dhënave pa ndaluar bazën. Këtu dalin disa probleme:

  • NĂ« momentin e fillimit tĂ« kopjimit, pĂ«rmbajtja e bazĂ«s sĂ« tĂ« dhĂ«nave mund tĂ« mos pĂ«rputhet me pĂ«rmbajtjen e skedarĂ«ve, pasi njĂ« pjesĂ« e informacionit ndodhet nĂ« cache dhe ende nuk Ă«shtĂ« shkruar nĂ« disk.
  • GjatĂ« kopjimit, pĂ«rmbajtja e bazĂ«s mund tĂ« ndryshojĂ«. NĂ«se pĂ«rdoren struktura tĂ« dhĂ«nash tĂ« ndryshueshme, pĂ«rmbajtja e skedarĂ«ve ndryshon, ndĂ«rsa nĂ«se pĂ«rdoren struktura tĂ« pandryshueshme, ndryshon grupi i skedarĂ«ve: skedarĂ« tĂ« rinj shfaqen, ndĂ«rsa tĂ« vjetrat fshihen.
  • Duke qenĂ« se shkrimi i tĂ« dhĂ«nave nĂ« bazĂ« dhe leximi i skedarĂ«ve tĂ« DB nuk sinkronizohen nĂ« asnjĂ« mĂ«nyrĂ«, programi i rezervĂ«s mund tĂ« lexojĂ« njĂ« faqe tĂ« pavlefshme, ku njĂ« pjesĂ« do tĂ« jetĂ« nga versioni i vjetĂ«r i faqes, dhe pjesa tjetĂ«r nga versioni i ri.

Për të siguruar që kopja rezervë të jetë e qëndrueshme, çdo DBMS ka një komandë që njofton që procesi i kopjimit rezervë ka filluar. Sintaksikisht, kjo urdhër mund të duket ndryshe:

  • nĂ« Oracle kjo Ă«shtĂ« njĂ« komandĂ« e veçantĂ« ALTER DATABASE/TABLESPACE BEGIN BACKUP;
  • nĂ« PostgreSQL – funksioni pg_start_backup();
  • nĂ« Microsoft SQL Server dhe DB2, pĂ«rgatitja pĂ«r kopjimin rezervĂ« realizohet nĂ« mĂ«nyrĂ« implicite gjatĂ« ekzekutimit tĂ« komandĂ«s BACKUP DATABASE;
  • nĂ« MySQL Enterprise, Cassandra dhe MongoDB, pĂ«rgatitja realizohet nĂ« mĂ«nyrĂ« implicite nga njĂ« mjet tĂ« jashtĂ«m – mysqlbackup, OpsCenter dhe Ops Manager pĂ«rkatĂ«sisht.

Megjithëse ka dallime sintaksike, procesi i përgatitjes për kopjimin rezervë duket njësoj.

Ja si duket përgatitja për kopjimin rezervë në DBMS me struktura disku të ndryshueshme, dmth., në të gjitha sistemet tradicionale relacionalë të diskut:

  1. Ruhet momenti i fillimit të kopjimit rezervë; kopja rezervë do të përfshijë regjistrat e bazës së të dhënave që fillojnë nga ky moment.
  2. Kryhet një pikë kontrolli, dmth. të gjitha ndryshimet që ndodhin në faqet e të dhënave deri në momentin e mbajtur, shkruhen në disk. Kjo garanton që regjistrat deri në momentin e fillimit të kopjimit rezervë nuk do të nevojiten gjatë rikuperimit.
  3. Aktivizohet një mod për regjistrim të veçantë: nëse një faqe të dhënash është ndryshuar për herë të parë pas ngarkimit nga disku, atëherë në vend që të regjistrohet në regjistër ndryshimi i faqes, baza do të regjistrojë faqen e plotë. Gjatë procedurës përgatitëse, të gjitha faqet shkruhen në disk, dhe kështu, me ndryshimin e parë, blloku gjithmonë do të regjistrohet në regjistër tërësisht. Por, nëse gjatë procesit të kopjimit, faqja përsëri do të shkruhet në disk, atëherë ndryshimi i saj të ardhshëm gjithashtu do të sjellë paraqitjen në regjistër të kopjes së plotë të faqes. Kjo garanton se nëse papritmas gjatë kopjimit të skedarëve me të dhëna faqeja del e pavlefshme, përdorimi i regjistrit do ta bëjë atë të vlefshme përsëri.
  4. Bllokohet ndryshimi i titujve të skedarëve të të dhënave, dmth. pjesa e saj që ndryshimet nuk reflektohen në regjistra. Kjo garanton që titulli do të kopjohet në mënyrë korrekte, dhe pastaj regjistrat do të aplikohen në mënyrë korrekte në skedarin e të dhënave.

Pas pĂ«rfundimit tĂ« tĂ« gjitha procedurave tĂ« lartpĂ«rmendura, mund tĂ« kopjoni skedarĂ«t e tĂ« dhĂ«nave me ndihmĂ«n e sistemit operativ – cp, rsync dhe tĂ« tjera. Aktivizimi i modit tĂ« kopjimit redukton performancĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave: sĂ« pari, rritet volumi i regjistrave, dhe sĂ« dyti, nĂ«se ndodhin probleme gjatĂ« modit tĂ« kopjimit, rikuperimi do tĂ« jetĂ« mĂ« i gjatĂ«, pasi titujt e skedarĂ«ve tĂ« tĂ« dhĂ«nave nuk pĂ«rditĂ«sohen. Sa mĂ« shpejt tĂ« pĂ«rfundojĂ« kopjimi, aq mĂ« mirĂ« Ă«shtĂ« pĂ«r bazĂ«n e tĂ« dhĂ«nave, prandaj Ă«shtĂ« e pĂ«rshtatshme tĂ« pĂ«rdoren mjete tĂ« tillĂ« si skedari (snapshot) i sistemit tĂ« skedarĂ«ve ose ndarĂ«sja e pasqyrĂ«s (BCV) nĂ« grumbullin e diskut. Disa DBMS (Oracle, PostgreSQL) lejojnĂ« administratorin tĂ« zgjedhĂ« mĂ«nyrĂ«n e kopjimit, ndĂ«rsa tĂ« tjerat (Microsoft SQL Server) ofrojnĂ« njĂ« ndĂ«rfaqe pĂ«r integrimin e mjeteve tĂ« tyre tĂ« kopjimit me mekanizmat e sistemeve tĂ« skedarĂ«ve ose tĂ« ruajtjes sĂ« tĂ« dhĂ«nave.

Pas pĂ«rfundimit tĂ« kopjimit, duhet tĂ« kthehet baza e tĂ« dhĂ«nave nĂ« gjendjen e zakonshme. NĂ« Oracle, kjo bĂ«het me komandĂ«n ALTER DATABASE/TABLESPACE END BACKUP, nĂ« PostgreSQL – duke thirrur funksionin pg_stop_backup(), dhe nĂ« bazat e tjera – me nĂ«nprograme tĂ« brendshme tĂ« komandave pĂ«rkatĂ«se ose shĂ«rbimeve tĂ« jashtme.

Kështu duket diagrami preliminar i procesit të kopjimit:

Udhëzuesi për backup-in e bazave të të dhënave

  • PĂ«rgatitja pĂ«r kopjimin (begin backup) merr kohĂ«, ndonjĂ«herĂ« duke qenĂ« e konsiderueshme. Edhe kur pĂ«rdoren vĂ«llime pasqyruese ose sisteme skedarĂ«sh me mundĂ«si pĂ«r tĂ« bĂ«rĂ« skedare, procesi i kopjimit nuk do tĂ« jetĂ« i menjĂ«hershĂ«m.
  • SĂ« bashku me skedarĂ«t e tĂ« dhĂ«nave, duhet tĂ« ruani regjistrat duke filluar nga momenti i pĂ«rgatitjes pĂ«r kopjim dhe pĂ«rfunduar me momentin e kthimit tĂ« bazĂ«s nĂ« gjendjen normale.
  • Mund tĂ« rikuperoheni nga ky kopjim nĂ« momentin e kthimit tĂ« bazĂ«s nĂ« gjendjen normale. Rikuperimi nĂ« njĂ« moment mĂ« tĂ« hershĂ«m nuk Ă«shtĂ« i mundur.

Me bazat e të dhënave që përdorin struktura të pandryshueshme të të dhënave (skedare memorie, pemë LSM) situata është më e thjeshtë. Përgatitja për kopjimin përbëhet nga hapat e mëposhtëm:

  1. Të dhënat nga memoria hidhen në disk.
  2. Regjistrohet lista e skedarëve që do të hyjnë në kopjim. Deri sa procesi i kopjimit të përfundojë, baza ndalohet të fshijë këta skedarë, madje edhe nëse ata nuk janë më të nevojshëm.

Me sinjalin që kopjimi ka përfunduar, baza me struktura të pandryshueshme mund të fshijë përsëri skedarët që nuk i nevojiten.

Rikuperimi në pikën

Kopja e rezervës lejon rikuperimin e gjendjes së bazës së të dhënave në momentin kur përfundoi urdhri për kthim nga moda e kopjimit. Megjithatë, një aksident, pas të cilit kërkohet rikuperimi, mund të ndodhë në çdo moment. Detyra e rikuperimit të gjendjes së DB në një moment të caktuar quhet "rikuperim në pikë" (point-in-time recovery).

Për të siguruar këtë mundësi, duhet të ruani regjistrat e DB duke filluar nga momenti i përfundimit të kopjimit, dhe gjatë rikuperimit të vazhdoni të aplikoni regjistrat në kopjen e rikuperuar. Pas rikuperimit të DB nga kopja në momentin e përfundimit të kopjimit, gjendja e bazës (skedarëve dhe faqeve të memorizuara) është garantuar të jetë e saktë, prandaj nuk nevojitet një mod regjistrimi të veçantë. Duke aplikuar regjistrat deri në momentin e nevojshëm, mund të sigurohet gjendja e bazës së të dhënave në çdo moment në kohë.

NĂ«se shpejtĂ«sia e rikuperimit tĂ« kopjes Ă«shtĂ« e kufizuar vetĂ«m nga kapaciteti i diskut, atĂ«herĂ« shpejtĂ«sia e aplikimit tĂ« regjistrave zakonisht kufizohet nga performanca e procesorit. NĂ«se nĂ« bazĂ«n e tĂ« dhĂ«nave kryesore ndodhin ndryshime paralelisht, atĂ«herĂ« gjatĂ« rikuperimit tĂ« gjitha ndryshimet kryhen nĂ« mĂ«nyrĂ« tĂ« njĂ«pasnjĂ«shme – nĂ« rendin e leximit nga regjistri. Si rrjedhojĂ«, koha e rikuperimit Ă«shtĂ« linearisht e varur nga sa larg Ă«shtĂ« pika e rikuperimit nga pika e pĂ«rfundimit tĂ« kopjimit. PĂ«r kĂ«tĂ« arsye, detyrohemi tĂ« bĂ«jmĂ« kopje tĂ« plota mjaft shpesh – minimum njĂ« herĂ« nĂ« javĂ« pĂ«r bazat me ngarkesĂ« tĂ« vogĂ«l transaksionesh dhe deri nĂ« kopjime ditore pĂ«r bazat me ngarkesa tĂ« larta.

Kopjimi inkremental

Për të përshpejtuar rikuperimin në pikën, do të donim të kishim mundësinë të realizonim kopjime sa më shpesh, por, në të njëjtën kohë, të mos zënë vend të tepërt në disqe dhe të mos ngarkojnë bazën me detyra kopjimi.

Zgjidhja e problemit është kopjimi inkremental, domethënë kopjimi vetëm i faqeve të të dhënave që janë ndryshuar që nga kopjimi i mëparshëm.
Kopjimi incremental ka kuptim vetëm për DB-të që përdorin struktura të dhënash të ndryshueshme.

Inkrementi mund të matet si nga kopja e plotë rezervë (kopja kumulative), ashtu edhe nga çdo kopje të mëparshme (kopja diferenciale).

Udhëzuesi për backup-in e bazave të të dhënave

Fatkeqësisht, nuk ekziston një terminologji e vetme, dhe prodhues të ndryshëm përdorin terma të ndryshëm:

Diferenciale
Kumulative

Oracle
Differential
Cumulative

PostgresPro
Incremental
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Incremental

Nëse ekzistojnë kopje inkrementale, procesi i rikuperimit në pikën e caktuar duket si vijon:

  • rikuperohet kopja e fundit e plotĂ« rezervĂ«, e bĂ«rĂ« para momentit tĂ« rikuperimit;
  • sipĂ«r kopjĂ«s sĂ« plotĂ« rikuperohen kopjet inkrementale;
  • ngarkohen ditarĂ«t nga pika e fillimit tĂ« kopjimit tĂ« rezervĂ«s deri nĂ« pikĂ«n e rikuperimit.

Prania e njĂ« kopje kumulative e pĂ«rshpejton procesin e rikuperimit. PĂ«r shembull, pĂ«r tĂ« rikuperuar gjendjen e bazĂ«s nĂ« njĂ« pikĂ« midis T3 dhe T4 Ă«shtĂ« e nevojshme tĂ« rikuperohen dy kopje inkrementale, ndĂ«rsa pĂ«r tĂ« rikuperuar nĂ« njĂ« pikĂ« pas T4 – vetĂ«m njĂ«.
Sigurisht, qëllimi i një kopje kumulative është më i vogël se ai i disa kopjeve diferenciale, pasi disa faqe kanë ndryshuar disa herë, dhe çdo kopje inkrementale përmban versionin e saj të faqes.

Ka tri mënyra për të krijuar një kopje inkrementale:

  1. krijimi i një kopje të plotë dhe llogaritja e diferencës me kopjen e fundit të plotë;
  2. analiza e ditarëve, përgatitja e një liste të faqeve të ndryshuara dhe rezervimi i faqeve të përfshira në listë;
  3. kërkesa për faqet e ndryshuara në bazën e të dhënave.

Mënyra e parë kursen hapësirë diskun, por nuk zgjidh ngarkesën mbi bazën e të dhënave. Më shumë, nëse kemi një kopje të plotë rezervë, atëherë kthimi në një inkrementale është pa kuptim, pasi rikuperimi i kopjes së plotë është më i shpejtë se rikuperimi i kopjës së plotë të mëparshme dhe inkrementaleve. Problemin e kursimit të hapësirës diskun duhet ta delegohet në komponentë të veçantë me mekanizma të integruar deduplication. Këto mund të jenë si sisteme të veçanta ruajtjeje (EMC DataDomain, HPE StorageWorks VLS, e gjithë gama NetApp), ashtu edhe produkte softuerike (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Mënyra e dytë dhe e tretë dallohen nga mekanizmi i përcaktimit të listës së faqeve të ndryshuara. Analiza e ditarëve është më e rëndë për resurset, përveç kësaj, për ta realizuar është e nevojshme të njohësh strukturën e skedarëve të ditarëve. Të pyesësh vetë bazën se cilat faqe kanë ndryshuar është më e thjeshtë, por për këtë, bërthama e DB-së duhet të ketë funksionalitetin për të ndjekur ndryshimet në blloqe (block change tracking).

Funksionaliteti i kopjimit të rezervave inkrementale u krijua për herë të parë në softuerin Oracle Recovery Manager (RMAN), i cili u shfaq në versionin Oracle 8i. Oracle menjëherë zbatoi ndjekjen e blloqeve të ndryshuara, prandaj nuk kishte nevojë për analizën e ditarëve.

PostgreSQL nuk ndjek blloqet e ndryshuara, prandaj utilitarja pg_probackup, e zhvilluar nga kompania ruse Postgres Professional, pĂ«rcakton faqe tĂ« ndryshuara duke analizuar ditarĂ«t. MegjithatĂ«, kompania ofron gjithashtu DB-nĂ« PostgresPro, e cila pĂ«rfshin zgjerimin ptrack, qĂ« ndjek ndryshimet nĂ« faqe. Kur pĂ«rdoret pg_probackup me DB-nĂ« PostgresPro, utilitarja kĂ«rkon faqet e ndryshuara direkt nga vetĂ« baza – ashtu si RMAN.

Microsoft SQL Server ashtu si Oracle, ndjek faqet e ndryshuara, por komandës BACKUP i lejon të bëjë vetëm kopje të plota dhe kumulative.

Në DB2 ekziston mundësia për të ndjekur faqet e ndryshuara, por për më shumë është e çaktivizuar nga e drejta. Pas aktivizimit, DB2 do të lejojë krijimin e kopjeve të plota, diferenciale dhe kumulative.

Një dallim i rëndësishëm midis mjeteve të përshkruara në këtë seksion (përveç pg_probackup) dhe mjeteve të kopjimit të skedarëve është se ato kërkojnë imazhet e faqeve nga databaza, jo lexojnë të dhënat nga disku vetë. Mangësia e këtij qasja është ngarkesa e vogël shtesë mbi databazën. Megjithatë, kjo mangësi përmbushet plotësisht nga fakti se faqja e lexuar është gjithmonë e saktë, prandaj nuk ka nevojë për aktivizimin e një regjimi të veçantë në kohën e kopjimit të rezervës.

Kujtoni përsëri që prania e kopjeve inkrementale nuk heq kërkesat për praninë e ditarëve për rikuperim në një pikë të caktuar në kohë. Prandaj në databazat industriale, ditarët vazhdimisht shkruhen në një mbështetje të jashtme, ndërsa kopjet rezervë, të plota dhe/ose inkrementale, krijohen sipas një orari.

Implementimi mĂ« i mirĂ« deri mĂ« tani i idesĂ« sĂ« kopjimit incremental Ă«shtĂ« kompleksi softuerik-hardware (nĂ« terminologjinĂ« e Oracle – sistemi i projektuar) Zero Data Loss Recovery Appliance – njĂ« zgjidhje e specializuar e Oracle pĂ«r kopjimin e bazĂ«s sĂ« tĂ« dhĂ«nave tĂ« saj. Kompleksi pĂ«rbĂ«het nga njĂ« grup servera me njĂ« volum tĂ« madh disqesh, mbi tĂ« cilat Ă«shtĂ« instaluar njĂ« version i modifikuar i softuerit Recovery Manager dhe mund tĂ« punojĂ« me komplekse tĂ« tjera softuerike-hardware tĂ« Oracle (Database Appliance, Exadata, SPARC Supercluster), si dhe me bazat e tĂ« dhĂ«nave Oracle nĂ« infrastrukturĂ«n tradicionale. Ndryshe nga RMAN-i 'i zakonshĂ«m', nĂ« ZDLRA Ă«shtĂ« realizuar koncepti i 'incremental forever'. Sistemi krijon njĂ« kopje tĂ« plotĂ« tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave njĂ« herĂ«, dhe pastaj bĂ«n vetĂ«m kopje inkrementale. Modul tĂ« tjera RMAN-i lejojnĂ« bashkimin e kopjave, duke krijuar kopje tĂ« reja tĂ« plota nga ato inkrementale.

Për nder të zhvilluesve rusë, duhet të theksohet se edhe pg_probackup di të bashkojë kopjat inkrementale.

Udhëzuesi për backup-in e bazave të të dhënave

NĂ« kundĂ«rshtim me shumĂ« pyetje tĂ« ngjashme, pyetja 'cili Ă«shtĂ« metoda mĂ« e mirĂ« pĂ«r kopjimin' ka njĂ« pĂ«rgjigje tĂ« qartĂ« – mĂ« sĂ« miri Ă«shtĂ« utilitari i lindur pĂ«r DBMS-nĂ« e pĂ«rdorur qĂ« siguron mundĂ«sinĂ« e kopjimit inkrementale.

Për administratorin e DB-së, pyetjet mbi zgjedhjen e strategjisë së kopjimit dhe integrimin e mjeteve të kopjimit të bazave të dhënave në infrastrukturën korporative janë shumë më të rëndësishme. Por këto çështje janë jashtë scope-it të këtij artikulli.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster