{"id":92367,"date":"2020-08-26T07:42:09","date_gmt":"2020-08-26T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh"},"modified":"2020-08-26T07:42:09","modified_gmt":"2020-08-26T05:42:09","slug":"putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","title":{"rendered":"Ghid pentru backup-ul bazelor de date","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<blockquote><p>\u2013 O, niciun ad\u0103post nu va rezista impactului unui meteorit. Dar, ca fiecare, ave\u021bi un rezervor, deci nu trebuie s\u0103 v\u0103 face\u021bi griji.<\/p>\n<p><i>Stanislav Lem, \u201eJurnalele stelare ale lui Iyon Tihy\u201d<\/i><\/p><\/blockquote>\n<p>\nBackup-ul se refer\u0103 la salvarea unei copii a datelor undeva \u00een afara locului principal de stocare.<\/p>\n<p><img decoding=\"async\" alt=\"Ghid pentru backup-ul bazelor de date\" src=\"\/wp-content\/uploads\/2020\/08\/c1dba0d8999cab69315560dfc57546e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrincipala destina\u021bie a backup-ului este recuperarea datelor dup\u0103 pierderea acestora. \u00cen acest context se aude adesea c\u0103, av\u00e2nd o replic\u0103 a bazei de date, se pot recupera \u00eentotdeauna datele, iar backup-ul nu este necesar. De fapt, backup-ul permite rezolvarea a cel pu\u021bin trei sarcini care nu pot fi rezolvate printr-o replic\u0103, iar replica nu poate fi ini\u021biat\u0103 f\u0103r\u0103 un backup.<\/p>\n<p>\u00cen primul r\u00e2nd, un backup permite recuperarea datelor dup\u0103 o eroare logic\u0103. De exemplu, un contabil a \u0219ters un grup de \u00eenregistr\u0103ri sau un administrator de baze de date a distrus un spa\u021biu de tabel. Ambele opera\u021biuni sunt complet legitime din punctul de vedere al bazei de date, iar procesul de replicare le va reproduce \u00een baza-replic\u0103.<\/p>\n<p>\u00cen al doilea r\u00e2nd, sistemele moderne de gestionare a bazelor de date sunt programe relativ fiabile, \u00eens\u0103, ocazional, se \u00eent\u00e2mpl\u0103 deterior\u0103ri ale structurilor interne ale bazei de date, dup\u0103 care accesul la date devine imposibil. Ceea ce este cu adev\u0103rat frustrant este c\u0103 aceste daune apar de obicei \u00een timpul unei \u00eenc\u0103rc\u0103ri mari sau \u00een timpul instal\u0103rii unui fel de actualizare. Dar at\u00e2t \u00eenc\u0103rc\u0103rile mari, c\u00e2t \u0219i actualiz\u0103rile regulate indic\u0103 c\u0103 baza de date nu este, cu siguran\u021b\u0103, una de testare, iar datele stocate \u00een aceasta sunt valoroase.<\/p>\n<p>\u00cen cele din urm\u0103, a treia sarcin\u0103, a c\u0103rei rezolvare necesit\u0103 un backup, este clonarea bazei de date, de exemplu, \u00een scopuri de testare.<\/p>\n<p>Backup-ul bazelor de date se bazeaz\u0103, \u00eentr-un fel sau altul, pe unul dintre cele dou\u0103 principii:<\/p>\n<ul>\n<li>Extrac\u021bia datelor cu salvarea lor ulterioar\u0103 \u00eentr-un format arbitrar;<\/li>\n<li>Captura st\u0103rii fi\u0219ierelor bazei de date \u0219i salvarea jurnalelor.<\/li>\n<\/ul>\n<p>\nS\u0103 analiz\u0103m aceste principii \u0219i instrumentele care le implementeaz\u0103 mai \u00een detaliu.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Exportul de date<\/h3>\n<p>\n\u00cen setul de instrumente care vin \u00eempreun\u0103 cu orice SGBD, exist\u0103 cu siguran\u021b\u0103 instrumente pentru exportul \u0219i importul datelor. Datele sunt salvate fie \u00een format text, fie \u00een format binar specific pentru SGBD-ul respectiv. \u00cen tabelul de mai jos este prezentat\u0103 o list\u0103 a acestor instrumente:<\/p>\n<p>Format binar<br \/>\nFormat text<\/p>\n<p>Oracle<br \/>\nDataPump Export\/DataPump Import<br \/>\nExport\/Import<br \/>\nSQL*Plus\/SQL*Loader<\/p>\n<p>PostgreSQL<br \/>\npg_dump, pg_dumpall\/pg_restore<br \/>\npg_dump, pg_dumpall\/psql<\/p>\n<p>Microsoft SQL Server<br \/>\nbcp<br \/>\nbcp<\/p>\n<p>DB2<br \/>\nunload\/load<br \/>\nunload\/load<\/p>\n<p>MySQL<\/p>\n<p>mysqldump, mysqlpump\/mysql, mysqlimport<\/p>\n<p>MongoDB<br \/>\nmongodump\/mongorestore<br \/>\nmongoexport\/mongoimport<\/p>\n<p>Cassandra<br \/>\nnodetool snapshot\/sstableloader<br \/>\ncqlsh<\/p>\n<p>\nFormatul text este avantajos deoarece poate fi editat sau chiar creat de programe externe, iar formatul binar este bun deoarece permite \u00eenc\u0103rcarea \u0219i desc\u0103rcarea mai rapid\u0103 a datelor datorit\u0103 economiei de resurse pentru conversia formatelor.<\/p>\n<p>\u00cen ciuda simplit\u0103\u021bii \u0219i eviden\u021bei ideii de desc\u0103rcare a datelor, aceast\u0103 metod\u0103 este utilizat\u0103 rar pentru rezervarea bazelor de date industriale supraaglomerate. Iat\u0103 motivele pentru care desc\u0103rcarea nu este potrivit\u0103 pentru o rezervare complet\u0103:<\/p>\n<ul>\n<li>procesul de desc\u0103rcare genereaz\u0103 o sarcin\u0103 semnificativ\u0103 pe sistemul surs\u0103;<\/li>\n<li>desc\u0103rcarea dureaz\u0103 mult timp - la momentul finaliz\u0103rii, aceasta devine deja inactual\u0103;<\/li>\n<li>este practic imposibil s\u0103 faci o desc\u0103rcare consistent\u0103 a \u00eentregii baze de date \u00een condi\u021bii de sarcin\u0103 mare, deoarece SGBD-ul este obligat s\u0103 p\u0103streze o captur\u0103 a st\u0103rii sale \u00een momentul \u00eenceperii desc\u0103rc\u0103rii. Cu c\u00e2t mai multe tranzac\u021bii au avut loc de la \u00eenceputul desc\u0103rc\u0103rii, cu at\u00e2t volumul capturii este mai mare (copia inactual\u0103 a datelor \u00een PostgreSQL, spa\u021biul undo \u00een Oracle, tempdb \u00een Microsoft SQL Server etc.);<\/li>\n<li>desc\u0103rcarea p\u0103streaz\u0103 structura logic\u0103 a datelor, dar nu p\u0103streaz\u0103 structura lor fizic\u0103 - parametrii de stocare fizic\u0103 a tabelelor, indec\u0219ii etc.<\/li>\n<\/ul>\n<p>\nCu toate acestea, desc\u0103rcarea are \u0219i avantajele sale:<\/p>\n<ul>\n<li>selectivitate ridicat\u0103: se pot desc\u0103rca tabele individuale, c\u00e2mpuri individuale \u0219i chiar linii individuale;<\/li>\n<li>datele desc\u0103rcate pot fi \u00eenc\u0103rcate \u00eentr-o baz\u0103 de date de o alt\u0103 versiune, iar dac\u0103 desc\u0103rcarea a fost realizat\u0103 \u00een format text, atunci \u0219i \u00eentr-o alt\u0103 baz\u0103 de date.<\/li>\n<\/ul>\n<p>\nAstfel, desc\u0103rcarea este utilizat\u0103 \u00een principal pentru sarcini precum rezervarea tabelelor mici (de exemplu, a dic\u021bionarelor) sau distribuirea seturilor de date \u00eempreun\u0103 cu o nou\u0103 versiune a aplica\u021biei. <\/p>\n<p>Cea mai comun\u0103 metod\u0103 de rezervare a bazelor de date este copierea fi\u0219ierelor bazei.<\/p>\n<h3>\"Salvarea\" rece a fi\u0219ierelor DB<\/h3>\n<p>\nIdeea evident\u0103 este de a opri baza de date \u0219i a copia toate fi\u0219ierele sale. Aceast\u0103 copie de rezerv\u0103 se nume\u0219te \"rece\". Metoda este extrem de fiabil\u0103 \u0219i simpl\u0103, dar are dou\u0103 dezavantaje evidente:<\/p>\n<ul>\n<li>Dintr-o copie de rezerv\u0103 \u201erece\u201d se poate restaura doar starea bazei de date care era \u00een momentul opririi; tranzac\u021biile efectuate dup\u0103 repornirea bazei nu vor fi incluse \u00een copia de rezerv\u0103 \u201erece\u201d.<\/li>\n<li>Nu toate bazele de date au un fereastr\u0103 tehnologic\u0103 \u00een care baza poate fi oprit\u0103.<\/li>\n<\/ul>\n<p>\nDac\u0103 backupul \u201erece\u201d este ceea ce dori\u021bi, trebuie s\u0103 re\u021bine\u021bi c\u0103<\/p>\n<ul>\n<li>Copia \u201erece\u201d trebuie uneori s\u0103 includ\u0103 \u0219i jurnalele. Metodele de determinare a jurnalelor care trebuie incluse \u00een copia de rezerv\u0103 \u201erece\u201d sunt individuale pentru fiecare SGBD. De exemplu, \u00een Oracle este necesar s\u0103 copia\u021bi a\u0219a-numitele online redo, adic\u0103 un num\u0103r fix de fi\u0219iere jurnal \u00eentr-un director special, chiar \u0219i atunci c\u00e2nd baza este oprit\u0103 corect. \u00cen PostgreSQL trebuie s\u0103 salva\u021bi toate jurnalele \u00eencep\u00e2nd cu jurnalul care con\u021bine ultima punct de control, informa\u021bia despre care este con\u021binut\u0103 \u00een fi\u0219ierul de control.<\/li>\n<li>Directorul bazei de date poate con\u021bine fi\u0219iere destul de mari de spa\u021bii de tabel temporar, care nu trebuie incluse \u00een copia de rezerv\u0103. Apropo, aceast\u0103 observa\u021bie este valabil\u0103 \u0219i pentru backupul \u201efierbinte\u201d.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Salvarea \u201efierbinte\u201d a fi\u0219ierelor<\/h3>\n<p>\nCea mai mare parte a copiilor de rezerv\u0103 ale bazelor de date moderne se efectueaz\u0103 prin copierea fi\u0219ierelor bazei de date f\u0103r\u0103 oprirea acesteia. Aici apar c\u00e2teva probleme:<\/p>\n<ul>\n<li>\u00cen momentul \u00eenceperii copiei, con\u021binutul bazei de date poate s\u0103 nu corespund\u0103 cu con\u021binutul fi\u0219ierelor, deoarece o parte din informa\u021bie se afla \u00een cache \u0219i nu a fost \u00eenc\u0103 scris\u0103 pe disk.<\/li>\n<li>\u00cen timpul copierii, con\u021binutul bazei poate fi modificat. Dac\u0103 se utilizeaz\u0103 structuri de date modificabile, con\u021binutul fi\u0219ierelor se schimb\u0103, iar dac\u0103 se utilizeaz\u0103 structuri imuabile, setul de fi\u0219iere se schimb\u0103: fi\u0219iere noi apar, iar cele vechi sunt eliminate.<\/li>\n<li>Deoarece scrierea datelor \u00een baz\u0103 \u0219i citirea fi\u0219ierelor DB nu sunt sincronizate, programul de backup poate citi o pagin\u0103 incorect\u0103, \u00een care o jum\u0103tate provine din versiunea veche a paginii, iar cealalt\u0103 jum\u0103tate din cea nou\u0103.<\/li>\n<\/ul>\n<p>\nPentru ca o copie de rezerv\u0103 s\u0103 fie consistent\u0103, fiecare SGBD are o comand\u0103 care comunic\u0103 c\u0103 a \u00eenceput procesul de backup. Sintactic, aceast\u0103 comand\u0103 poate p\u0103rea diferit\u0103: <\/p>\n<ul>\n<li>\u00een Oracle, aceasta este o comand\u0103 separat\u0103 ALTER DATABASE\/TABLESPACE BEGIN BACKUP;<\/li>\n<li>\u00een PostgreSQL \u2013 func\u021bia pg_start_backup();<\/li>\n<li>\u00cen Microsoft SQL Server \u0219i DB2, preg\u0103tirea pentru backup se efectueaz\u0103 implicit \u00een timpul execut\u0103rii comenzii BACKUP DATABASE;<\/li>\n<li>\u00cen MySQL Enterprise, Cassandra \u0219i MongoDB, preg\u0103tirea se face implicit printr-un utilitar extern \u2013 mysqlbackup, OpsCenter \u0219i Ops Manager respectiv.<\/li>\n<\/ul>\n<p>\n\u00cen ciuda diferen\u021belor sintaxice, procesul de preg\u0103tire pentru backup arat\u0103 similar.<\/p>\n<p>Iat\u0103 cum se desf\u0103\u0219oar\u0103 preg\u0103tirea pentru backup \u00een SGBD-urile cu structuri de disc modulabile, adic\u0103 \u00een toate sistemele rela\u021bionale tradi\u021bionale pe disc:<\/p>\n<ol>\n<li>Se \u00eenregistreaz\u0103 momentul \u00eenceputului backup-ului; copia de rezerv\u0103 va trebui s\u0103 con\u021bin\u0103 jurnalele bazei de date \u00eencep\u00e2nd din acest moment.<\/li>\n<li>Se efectueaz\u0103 o punctare, adic\u0103 toate modific\u0103rile care au avut loc pe paginile de date p\u00e2n\u0103 la momentul \u00eenregistrat sunt scrise pe disc. Aceasta garanteaz\u0103 c\u0103 jurnalele de dinainte de \u00eenceputul backup-ului nu vor fi necesare la restaurare.<\/li>\n<li>Se activeaz\u0103 un mod special de jurnalizare: dac\u0103 o pagin\u0103 de date a fost modificat\u0103 prima dat\u0103 dup\u0103 ce a fost \u00eenc\u0103rcat\u0103 de pe disc, atunci \u00een loc s\u0103 scrie \u00een jurnal modificarea paginii, baza de date va \u00eenregistra \u00eentreaga pagin\u0103. \u00cen timpul procedurii de preg\u0103tire, toate paginile sunt scrise pe disc, iar prin urmare, la prima modificare, blocul va fi \u00eentotdeauna \u00eenregistrat \u00een jurnal \u00een \u00eentregime. Dar dac\u0103 \u00een timpul backup-ului pagina este din nou scris\u0103 pe disc, atunci urm\u0103toarea sa modificare va duce, de asemenea, la apari\u021bia unei copii complete a paginii \u00een jurnal. Acest lucru garanteaz\u0103 c\u0103, \u00een cazul \u00een care, dintr-un motiv necunoscut, pagina este corupt\u0103 \u00een timpul copieri fi\u0219ierului cu date, aplicarea jurnalului o va reface corect.<\/li>\n<li>Se blocheaz\u0103 modificarea antetelor fi\u0219ierelor de date, adic\u0103 acelei p\u0103r\u021bi care nu apare \u00een jurnale. Acest lucru garanteaz\u0103 c\u0103 antetul va fi copiat corect, iar apoi jurnalele vor fi aplicate corect fi\u0219ierului de date.<\/li>\n<\/ol>\n<p>\nDup\u0103 ce toate procedurile enumerate mai sus au fost finalizate, se pot copia fi\u0219ierele de date folosind mijloacele sistemului de operare \u2013 cp, rsync \u0219i altele. Activarea modului de rezerv\u0103 reduce performan\u021ba bazei de date: pe de o parte, volumul jurnalelor cre\u0219te, iar pe de alt\u0103 parte, dac\u0103 \u00een timpul modului de rezerv\u0103 apare o eroare, restaurarea va dura mai mult, deoarece anteturile fi\u0219ierelor de date nu sunt actualizate. Cu c\u00e2t rezervarea se termin\u0103 mai repede, cu at\u00e2t mai bine pentru baza de date, a\u0219a c\u0103 utilizarea unor instrumente precum snapshot-ul sistemului de fi\u0219iere sau \u00eentreruperea miroirului (BCV) \u00een matricea de discuri este adecvat\u0103. Unele SGBD-uri (Oracle, PostgreSQL) las\u0103 administratorilor posibilitatea de a alege modalitatea de copiere, iar altele (Microsoft SQL Server) ofer\u0103 o interfa\u021b\u0103 pentru integrarea propriilor utilitare de rezervare cu mecanismele sistemelor de fi\u0219iere sau SCD.<\/p>\n<p>Dup\u0103 finalizarea rezerv\u0103rii, baza de date trebuie returnat\u0103 la starea normal\u0103. \u00cen Oracle, acest lucru se face cu comanda ALTER DATABASE\/TABLESPACE END BACKUP, \u00een PostgreSQL \u2013 prin apelarea func\u021biei pg_stop_backup(), iar \u00een alte baze \u2013 prin subprograme interne ale comenzii corespunz\u0103toare sau servicii externe.<\/p>\n<p>Iat\u0103 cum arat\u0103 o diagram\u0103 temporar\u0103 a procesului de rezervare:<\/p>\n<p><img decoding=\"async\" alt=\"Ghid pentru backup-ul bazelor de date\" src=\"\/wp-content\/uploads\/2020\/08\/4e74f865e9f35acec083b747da4449cf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>Preg\u0103tirea pentru rezervare (begin backup) consum\u0103 timp, uneori semnificativ. Chiar \u0219i atunci c\u00e2nd se utilizeaz\u0103 volumuri miroir sau sisteme de fi\u0219iere capabile s\u0103 realizeze snapshot-uri, procesul de rezervare nu va fi instantaneu.<\/li>\n<li>\u00cempreun\u0103 cu fi\u0219ierele de date, este necesar s\u0103 se p\u0103streze jurnalele \u00eencep\u00e2nd de la momentul \u00eenceperii preg\u0103tirii pentru rezervare \u0219i p\u00e2n\u0103 la momentul \u00een care baza revine la starea normal\u0103.<\/li>\n<li>Se poate restaura din aceast\u0103 rezerv\u0103 <b>la momentul \u00eentoarcerii bazei la starea normal\u0103<\/b>. Restaurarea la un moment anterior nu este posibil\u0103.<\/li>\n<\/ul>\n<p>\nSitua\u021bia este mai simpl\u0103 cu bazele de date care folosesc structuri de date imuabile (snapshot-uri de memorie, arbori LSM). Preg\u0103tirea pentru rezervare const\u0103 \u00een urm\u0103torii pa\u0219i:<\/p>\n<ol>\n<li>Datele din memorie sunt scrise pe disc.<\/li>\n<li>Se fixeaz\u0103 lista fi\u0219ierelor care intr\u0103 \u00een rezerv\u0103. P\u00e2n\u0103 la finalizarea procesului de rezervare, bazei \u00eei este interzis s\u0103 \u0219tearg\u0103 aceste fi\u0219iere, chiar dac\u0103 ele devin inutile.<\/li>\n<\/ol>\n<p>\nLa semnalul de \u00eencheiere a copiei de rezerv\u0103, baza cu structuri nemodificabile poate din nou s\u0103 \u0219tearg\u0103 fi\u0219ierele inutile.<\/p>\n<h3>Restaurare la un punct<\/h3>\n<p>\nCopia de rezerv\u0103 permite restaurarea st\u0103rii bazei de date la momentul \u00een care comanda de revenire din modul de rezervare s-a \u00eencheiat. Cu toate acestea, o defec\u021biune, dup\u0103 care va fi necesar\u0103 restaurarea, se poate produce \u00een orice moment. Sarcina de a restaura starea Bazei de Date la un moment ales se nume\u0219te \u201erestaurare la un punct\u201d (point-in-time recovery).<\/p>\n<p>Pentru a asigura aceast\u0103 posibilitate, trebuie s\u0103 se p\u0103streze jurnalul Bazei de Date \u00eencep\u00e2nd din momentul \u00eencheierii copiei de rezerv\u0103, iar \u00een timpul restaur\u0103rii s\u0103 se aplice \u00een continuare jurnalele la copia restaurat\u0103. Dup\u0103 ce Baza de Date este restaurat\u0103 din copia de rezerv\u0103 la momentul \u00eencheierii copiilor, starea bazei (fi\u0219ierele \u0219i paginile de memorie cache) este garantat corect\u0103, a\u0219adar nu este nevoie de un mod special de jurnalizare. Aplic\u00e2nd jurnalele p\u00e2n\u0103 la momentul dorit, se poate ob\u021bine starea bazei de date \u00een orice punct \u00een timp.<\/p>\n<p>Dac\u0103 viteza de restaurare a copiei de rezerv\u0103 este limitat\u0103 doar de l\u0103\u021bimea de band\u0103 a discului, atunci viteza de aplicare a jurnalelelor este de obicei limitat\u0103 de performan\u021ba procesorului. Dac\u0103 \u00een baza de date principal\u0103 se produc modific\u0103ri \u00een mod paralel, atunci la restaurare toate modific\u0103rile sunt efectuate secven\u021bial - \u00een ordinea citirii din jurnal. Astfel, timpul de restaurare depinde liniar de c\u00e2t de departe este punctul de restaurare fa\u021b\u0103 de punctul de \u00eencheiere a copiei de rezerv\u0103. Din aceast\u0103 cauz\u0103, este necesar s\u0103 se fac\u0103 destul de frecvent copii de rezerv\u0103 complete - cel pu\u021bin o dat\u0103 pe s\u0103pt\u0103m\u00e2n\u0103 pentru bazele cu o sarcin\u0103 de tranzac\u021bii mic\u0103 \u0219i p\u00e2n\u0103 la copii zilnice pentru bazele cu o \u00eenc\u0103rcare mare.<\/p>\n<h3>Copia de rezerv\u0103 incremental\u0103<\/h3>\n<p>\nPentru a accelera restaurarea la un punct, s-ar dori s\u0103 avem posibilitatea de a efectua copii de rezerv\u0103 c\u00e2t mai des posibil, dar f\u0103r\u0103 a ocupa spa\u021biu suplimentar pe discuri \u0219i f\u0103r\u0103 a suprasolicita baza cu sarcini de copiere.<\/p>\n<p>Solu\u021bia problemei este copierea de rezerv\u0103 incremental\u0103, adic\u0103 copierea doar a acelora pagini de date care s-au modificat de la ultima copiere de rezerv\u0103.<br \/>\nBackup-urile incrementale au sens doar pentru SGBD-uri care utilizeaz\u0103 structuri de date modificabile.<\/p>\n<p>Incrementul poate fi calculat fie de la o copie de rezerv\u0103 complet\u0103 (copie cumulativ\u0103), fie de la orice copie anterioar\u0103 (copie diferen\u021bial\u0103). <\/p>\n<p><img decoding=\"async\" alt=\"Ghid pentru backup-ul bazelor de date\" src=\"\/wp-content\/uploads\/2020\/08\/10e3bb87445cb36693c7b5469d62eeaf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDin p\u0103cate, nu exist\u0103 o terminologie unificat\u0103, iar diferi\u021bi furnizori folosesc termeni diferi\u021bi:<\/p>\n<p>Diferen\u021bial\u0103<br \/>\nCumulativ\u0103<\/p>\n<p>Oracle<br \/>\nDiferen\u021bial<br \/>\nCumulativ<\/p>\n<p>PostgresPro<br \/>\nIncremental<br \/>\n\u2014<\/p>\n<p>Microsoft SQL Server<br \/>\n\u2014<br \/>\nDiferen\u021bial<\/p>\n<p>IBM DB2<br \/>\nDelta<br \/>\nIncremental<\/p>\n<p>\n\u00cen cazul copiilor incrementale, procesul de restaurare la un punct arat\u0103 astfel:<\/p>\n<ul>\n<li>se restaureaz\u0103 ultima copie de rezerv\u0103 complet\u0103 efectuat\u0103 \u00eenainte de momentul restaur\u0103rii;<\/li>\n<li>peste copia complet\u0103 se restaureaz\u0103 copiile incrementale;<\/li>\n<li>se aplic\u0103 jurnalele de la punctul de \u00eenceput al copiei de rezerv\u0103 p\u00e2n\u0103 la punctul de restaurare.<\/li>\n<\/ul>\n<p>\nExistenta unei copii cumulative accelereaz\u0103 procesul de restaurare. De exemplu, pentru a restaura starea bazei de date la un punct \u00eentre T3 \u0219i T4 este necesar\u0103 restaurarea a dou\u0103 copii incrementale, iar pentru restaurarea la un punct dup\u0103 T4 \u2013 doar una.<br \/>\nEste evident c\u0103 volumul unei copii cumulative este mai mic dec\u00e2t volumul mai multor copii diferentiale, deoarece unele pagini s-au modificat de mai multe ori, iar fiecare copie incremental\u0103 con\u021bine propria versiune a paginii.<\/p>\n<p>Exist\u0103 trei moduri de a crea o copie incremental\u0103:<\/p>\n<ol>\n<li>crearea unei copii complete \u0219i calcularea diferen\u021bei fa\u021b\u0103 de copia complet\u0103 anterioar\u0103;<\/li>\n<li>analiza jurnale, crearea unei liste de pagini modificate \u0219i rezervarea paginilor incluse \u00een list\u0103;<\/li>\n<li>solicitarea paginilor modificate din baza de date.<\/li>\n<\/ol>\n<p>\nPrima metod\u0103 economise\u0219te spa\u021biu pe disc, dar nu rezolv\u0103 problema reducerii \u00eenc\u0103rc\u0103rii pe baza de date. Mai mult, dac\u0103 avem o copie de rezerv\u0103 complet\u0103, transformarea acesteia \u00eentr-o copie incremental\u0103 nu are sens, deoarece restaurarea unei copii complete este mai rapid\u0103 dec\u00e2t restaurarea unei copii complete anterioare \u0219i a unui increment. Problema economiei de spa\u021biu pe disc cu aceast\u0103 abordare ar trebui mai bine transfomat\u0103 pe componente speciale cu mecanisme integrate de deduplicare. Acestea pot fi fie sisteme de stocare specializate (EMC DataDomain, HPE StorageWorks VLS, \u00eentreaga gam\u0103 NetApp), fie produse software (ZFS, Veritas NetBackup PureFile, Deduplicare de date Windows Server).<\/p>\n<p>Al doilea \u0219i al treilea mod difer\u0103 prin mecanismul de determinare a listei paginilor modificate. Analiza jurnalelor este mai consumatoare de resurse, plus c\u0103 pentru implementarea sa este necesar s\u0103 se cunoasc\u0103 structura fi\u0219ierelor jurnal. Cel mai simplu este s\u0103 \u00eentrebi baza de date care pagini s-au modificat, dar pentru aceasta nucleul SGBD-ului trebuie s\u0103 aib\u0103 func\u021bionalitatea de urm\u0103rire a blocurilor modificate (block change tracking).<\/p>\n<p>Func\u021bionalitatea de backup incrementale a fost creat\u0103 pentru prima dat\u0103 \u00een software-ul Oracle Recovery Manager (RMAN), ap\u0103rut \u00een versiunea Oracle 8i. Oracle a implementat imediat urm\u0103rirea blocurilor modificate, a\u0219a c\u0103 nu este necesar\u0103 analiza jurnalelor.<\/p>\n<p>PostgreSQL nu urm\u0103re\u0219te blocurile modificate, astfel c\u0103 utilitarul pg_probackup, dezvoltat de compania rus\u0103 Postgres Professional, determin\u0103 paginile modificate prin analiza jurnalului. Totu\u0219i, compania furnizeaz\u0103 \u0219i SGBD-ul PostgresPro, care include extensia ptrack, ce urm\u0103re\u0219te modific\u0103rile paginilor. Atunci c\u00e2nd se folose\u0219te pg_probackup cu SGBD-ul PostgresPro, utilitarul solicit\u0103 paginile modificate direct de la baza de date \u2013 la fel ca RMAN.<\/p>\n<p>Microsoft SQL Server, la fel ca Oracle, urm\u0103re\u0219te paginile modificate, dar comanda BACKUP permite realizarea doar a backup-urilor complete \u0219i cumulative.<\/p>\n<p>\u00cen DB2 exist\u0103 posibilitatea de a urm\u0103ri paginile modificate, dar \u00een mod implicit aceasta este dezactivat\u0103. Dup\u0103 activare, DB2 va permite realizarea de backup-uri complete, diferen\u021biale \u0219i cumulative.<\/p>\n<p>O diferen\u021b\u0103 important\u0103 \u00eentre instrumentele descrise \u00een aceast\u0103 sec\u021biune (cu excep\u021bia pg_probackup) \u0219i instrumentele de backup pe fi\u0219iere este c\u0103 acestea solicit\u0103 imagini ale paginilor de la baza de date, \u0219i nu citesc datele de pe disc pe cont propriu. Dezavantajul acestui abord\u0103ri este o sarcin\u0103 suplimentar\u0103 minor\u0103 pe baza de date. Totu\u0219i, acest dezavantaj este compensat pe deplin de faptul c\u0103 pagina citit\u0103 este \u00eentotdeauna corect\u0103, deci nu este necesar s\u0103 se activeze un mod special de jurnalizare \u00een timpul backup-ului.<\/p>\n<p>\u00cenc\u0103 o dat\u0103, re\u021bine\u021bi c\u0103 existen\u021ba copiilor incrementale nu anuleaz\u0103 cerin\u021bele de a avea jurnale pentru restaurarea la un punct arbitrar \u00een timp. De aceea, \u00een bazele de date industriale, jurnalele sunt scrise constant pe un mediu extern, iar backup-urile, complete \u0219i\/sau incrementale, sunt realizate conform unui program.<\/p>\n<p>Cea mai bun\u0103 implementare a ideii de backup incremental disponibil\u0103 ast\u0103zi este complexul software-hardware (\u00een terminologia Oracle - sistem proiectat) Zero Data Loss Recovery Appliance - o solu\u021bie specializat\u0103 Oracle pentru backup-ul bazei de date proprii. Complexul reprezint\u0103 un cluster <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/ro\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1521\">servere<\/a> cu un volum mare de discuri, pe care este instalat\u0103 o versiune modificat\u0103 a software-ului Recovery Manager \u0219i poate func\u021biona at\u00e2t cu alte complexe software-hardware Oracle (Database Appliance, Exadata, SPARC Supercluster), c\u00e2t \u0219i cu bazele de date Oracle pe o infrastructur\u0103 tradi\u021bional\u0103. Spre deosebire de RMAN \u201eobi\u0219nuit\u201d, \u00een ZDLRA este implementat\u0103 concep\u021bia de \u201eincremental forever\u201d. Sistemul creeaz\u0103 o copie complet\u0103 a bazei de date o singur\u0103 dat\u0103, iar apoi realizeaz\u0103 doar copii incrementale. Modulele suplimentare RMAN permit combinarea copiilor, cre\u00e2nd noi copii complete din cele incrementale. <\/p>\n<p>\u00cen onoarea dezvoltatorilor ru\u0219i, trebuie men\u021bionat c\u0103 \u0219i pg_probackup poate combina copiile incrementale.<\/p>\n<p><img decoding=\"async\" alt=\"Ghid pentru backup-ul bazelor de date\" src=\"\/wp-content\/uploads\/2020\/08\/275b649ce74614c04410618a062dddbd.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSpre deosebire de multe \u00eentreb\u0103ri asem\u0103n\u0103toare, \u00eentrebarea \u201ecare metod\u0103 de backup este cea mai bun\u0103\u201d are un r\u0103spuns clar - cel mai bine este utilizat\u0103 utilitarul nativ pentru SGBD-ul utilizat, care ofer\u0103 posibilitatea de backup incremental.<\/p>\n<p>Pentru administratorul de baze de date, \u00eentreb\u0103rile legate de alegerea strategiei de backup \u0219i integrarea instrumentelor de backup ale bazelor de date \u00een infrastructura corporativ\u0103 sunt mult mai importante. Dar aceste \u00eentreb\u0103ri dep\u0103\u0219esc cadrul acestui articol.<br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/516428\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430. \u041d\u043e \u0432\u0435\u0434\u044c \u0443 \u0432\u0430\u0441, \u043a\u0430\u043a \u0438 \u0443 \u043a\u0430\u0436\u0434\u043e\u0433\u043e, \u0435\u0441\u0442\u044c \u0440\u0435\u0437\u0435\u0440\u0432, \u0442\u0430\u043a \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442\u0435 \u043d\u0435 \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f. \u0421\u0442\u0430\u043d\u0438\u0441\u043b\u0430\u0432 \u041b\u0435\u043c, \u00ab\u0417\u0432\u0451\u0437\u0434\u043d\u044b\u0435 \u0434\u043d\u0435\u0432\u043d\u0438\u043a\u0438 \u0418\u0439\u043e\u043d\u0430 \u0422\u0438\u0445\u043e\u0433\u043e\u00bb \u0420\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u043c \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u043a\u043e\u043f\u0438\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0433\u0434\u0435-\u0442\u043e \u0432\u043d\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u043c\u0435\u0441\u0442\u0430 \u0438\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0413\u043b\u0430\u0432\u043d\u043e\u0435 \u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u2013 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0441\u043b\u0435 \u0438\u0445 \u043f\u043e\u0442\u0435\u0440\u0438. \u0412 \u0441\u0432\u044f\u0437\u0438 \u0441 \u044d\u0442\u0438\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92368,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-26T05:42:09+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-26T05:42:09+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ghid de backup pentru baze de date | ProHoster","description":"\u2013 Oh, nicio ad\u0103post nu va rezista la impactul unui meteorit.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster","og:description":"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-26T05:42:09+00:00","article:modified_time":"2020-08-26T05:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92367","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:09:36","updated":"2026-02-09 16:50:36","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/92367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=92367"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/92367\/revisions"}],"predecessor-version":[{"id":158765,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/92367\/revisions\/158765"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/92368"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=92367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=92367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=92367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}