Crearea unui backup automat al bazei de date SQL pe serverul SQL Express Edition. Backup de bază de date Microsoft SQL Server Backup de la studioul de management Sql

Serverele de baze de date sunt unul dintre serverele cheie din orice organizație. Ei sunt cei care stochează informații și oferă rezultate la cerere și este extrem de important să păstrezi baza de date în orice situație. Pachetul de bază include de obicei utilitățile necesare, dar un administrator care nu a întâlnit anterior o bază de date va trebui să petreacă ceva timp înțelegând particularitățile lucrării pentru a asigura automatizarea.

Tipuri de copii de siguranță ale bazei de date

Mai întâi, să ne dăm seama ce fel de copii de rezervă există. Un server de baze de date nu este o aplicație desktop obișnuită și pentru a se asigura că toate proprietățile ACID (Atomic, Consistency, Isolated, Durable) sunt îndeplinite, sunt utilizate o serie de tehnologii și, prin urmare, crearea și restaurarea unei baze de date dintr-o arhivă are propriile sale caracteristici . Există trei abordări diferite pentru salvarea datelor, fiecare cu propriile avantaje și dezavantaje.

Cu o copie de rezervă logică sau SQL (pg_dump, mysqldump, SQLCMD), este creat un instantaneu al conținutului bazei de date, ținând cont de integritatea tranzacțională și salvat ca fișier cu comenzi SQL (puteți selecta întreaga bază de date sau tabele individuale ), cu care puteți recrea baza de date pe alt server. Acest lucru necesită timp (în special pentru bazele de date mari) pentru salvare și restaurare, așa că de foarte multe ori această operațiune nu poate fi efectuată și este efectuată în timpul sarcinii minime (de exemplu, noaptea). În timpul recuperării, administratorul va trebui să execute mai multe comenzi pentru a pregăti tot ce este necesar (crearea unei baze de date goale, conturi etc.).

Copiere de rezervă fizică (nivel de sistem de fișiere) - copierea fișierelor pe care SGBD-ul le utilizează pentru a stoca date în baza de date. Dar o simplă copie ignoră blocările și tranzacțiile, care sunt probabil să fie salvate incorect și sparte. Dacă încercați să atașați acest fișier, acesta va fi într-o stare inconsistentă și va avea ca rezultat erori. Pentru a obține o copie de rezervă actualizată, baza de date trebuie oprită (puteți reduce timpul de nefuncționare folosind rsync de două ori - mai întâi pe unul care rulează, apoi pe unul oprit). Dezavantajul acestei metode este evident - nu puteți restaura date specifice, ci doar întreaga bază de date. Când porniți o bază de date restaurată dintr-o arhivă de sistem de fișiere, va trebui să verificați integritatea acesteia. Aici sunt folosite diverse tehnologii de asistență. De exemplu, în PostgreSQL există jurnalele de înregistrare proactive WAL (Write Ahead Logs) și o funcție specială (Point in Time Recovery - PITR) care vă permite să reveniți la o anumită stare a bazei de date. Cu ajutorul lor, al treilea scenariu este ușor de implementat, atunci când o copie de siguranță la nivel de sistem de fișiere este combinată cu o copie de rezervă a fișierelor WAL. Mai întâi, restaurăm fișierele de rezervă ale sistemului de fișiere și apoi, folosind WAL, baza de date este adusă la starea curentă. Aceasta este o abordare puțin mai complexă pentru administrare, dar nu există probleme cu integritatea bazei de date și restaurarea bazelor de date la un anumit timp.

Backup-ul logic este utilizat în cazurile în care este necesar să se facă o singură copie completă a bazei de date sau în utilizarea de zi cu zi, crearea unei copii nu necesită mult timp sau spațiu. Când descărcarea bazelor de date necesită mult timp, ar trebui să acordați atenție arhivării fizice.

Barman

Licență: GNU GPL

SGBD acceptat: PostgreSQL

PostgreSQL acceptă capabilități de backup fizice și logice, adăugându-le un alt strat WAL (vezi bara laterală), care poate fi numită copiere continuă. Dar gestionarea mai multor servere folosind instrumente standard nu este foarte convenabilă nici măcar pentru un administrator experimentat, iar în cazul unei eșecuri, secundele contează.

Barman (manager de backup și recuperare) este o dezvoltare internă a companiei 2ndQuadrant, care oferă servicii bazate pe PostgreSQL. Proiectat pentru backup fizic PostgreSQL (logica nu acceptă), arhivare WAL și recuperare rapidă după eșecuri. Acceptă backup și recuperare de la distanță a mai multor servere, funcții de recuperare punct-in-time (PITR) și management WAL. SSH este folosit pentru a copia și trimite comenzi către o gazdă de la distanță; sincronizarea și copierea de rezervă folosind rsync vă permit să reduceți traficul. Barman se integrează, de asemenea, cu utilitățile standard bzip2, gzip, tar și altele asemenea. În principiu, puteți folosi orice program de compresie și arhivare, integrarea nu va dura mult timp. Au fost implementate diverse funcții de service și diagnosticare pentru a monitoriza starea serviciilor și pentru a regla lățimea de bandă. Sunt acceptate scripturile pre/post.

Barman este scris în Python, iar politicile de backup sunt gestionate utilizând fișierul INI ușor de utilizat barman.conf, care poate fi localizat în /etc sau în directorul principal al utilizatorului. Livrarea include un șablon gata făcut cu comentarii detaliate în interior. Funcționează numai pe sisteme *nix. Pentru a instala pe RHEL, CentOS și Scientific Linux, ar trebui să conectați EPEL, un depozit care conține pachete suplimentare. Depozitul oficial este disponibil pentru utilizatorii Debian/Ubuntu:

$ sudo apt-get install barman

Depozitul nu are întotdeauna cea mai recentă versiune; pentru a o instala, va trebui să vă referiți la textele sursă. Există puține dependențe și procesul este ușor de înțeles.

Dumper Sypex

Licență: BSD

SGBD acceptat: MySQL

MySQL vine cu utilitatile mysqldump și mysqlhotcopy, care vă permit să creați cu ușurință un dump de bază de date; acestea sunt bine documentate și puteți găsi un număr mare de exemple și interfețe gata făcute pe Internet. Acestea din urmă permit unui începător să înceapă rapid. Sypex Dumper este un script PHP care vă permite să creați și să restaurați cu ușurință o copie a unei baze de date MySQL. Creat pentru a funcționa cu baze de date mari, funcționează foarte rapid, este ușor de înțeles și ușor de utilizat. Știe cum să lucreze cu obiecte MySQL - vizualizări, proceduri, funcții, declanșatoare și evenimente.

Un alt plus, spre deosebire de alte instrumente care efectuează transcodarea în UTF-8 la export, în Dumper exportul se realizează în codificarea nativă. Fișierul rezultat ocupă mai puțin spațiu, iar procesul în sine este mai rapid. Un dump poate conține obiecte cu diferite codificări. Mai mult, este ușor de importat/exportat în mai multe etape, oprind procesul în timpul încărcării. La reluare, procedura va începe de unde s-a oprit. Există patru opțiuni disponibile pentru recuperare:

• CREATE + INSERT - mod standard de recuperare;
• TRUNCATE + INSERT - mai puțin timp pentru crearea tabelelor;
• ÎNLOCUIRE - restaurăm datele vechi din baza de date de lucru fără a le suprascrie pe cele noi;
• INSERT IGNORE - adăugăm date șterse sau noi în baza de date fără a le atinge pe cele existente.

Acceptă compresia copierii (gzip sau bzip2), ștergerea automată a vechilor copii de siguranță, vizualizarea conținutului unui fișier dump și restaurarea numai a structurii tabelului. Există și funcții de serviciu pentru gestionarea bazei de date (crearea, ștergerea, verificarea, restaurarea bazei de date, optimizarea, curățarea tabelelor, lucrul cu indici etc.), precum și un manager de fișiere care vă permite să copiați fișiere pe server.

Gestionarea se realizează folosind un browser web, interfața care utilizează AJAX este localizată din cutie și creează impresia de a lucra cu o aplicație desktop. De asemenea, este posibil să rulați joburi din consolă și pe un program (prin cron).

Pentru ca Dumper să funcționeze, veți avea nevoie de un server clasic L|WAMP; instalarea este standard pentru toate aplicațiile scrise în PHP (copiați fișiere și setați permisiuni) și nu va fi dificilă nici măcar pentru un începător. Proiectul oferă documentație detaliată și tutoriale video care demonstrează cum se utilizează Sypex Dumper.

Există două ediții: Sypex Dumper (gratuit) și Pro (10 USD). Al doilea are mai multe caracteristici, toate diferențele sunt enumerate pe site.

Backup SQL și FTP

Licență:

SGBD acceptat: MS SQL Server

MS SQL Server este una dintre soluțiile populare și, prin urmare, apare destul de des. O lucrare de rezervă este creată folosind SQL Server Management Studio, Transact-SQL însuși și cmdlet-urile modulului SQL PowerShell (Backup-SqlDatabase). Pe site-ul MS puteți găsi o cantitate imensă de documentație care vă permite să înțelegeți procesul. Documentația, deși completă, este foarte specifică, iar informațiile de pe Internet se contrazic adesea. Un începător va trebui, de fapt, să exerseze mai întâi, „băgând capul”, așa că, chiar și în ciuda a tot ceea ce s-a spus, dezvoltatorii terți au loc să se extindă. În plus, versiunea gratuită a SQL Server Express nu are instrumente de backup încorporate. Pentru versiunile anterioare de MS SQL (înainte de 2008), puteți găsi utilități gratuite, de exemplu backup SQL Server, dar în majoritatea cazurilor astfel de proiecte au fost deja comercializate, deși oferă toate funcționalitățile adesea pentru o sumă simbolică.

De exemplu, dezvoltarea SQL Backup And FTP și One-Click SQL Restore urmează principiul „set-o și uita-l”. Având o interfață foarte simplă și intuitivă, acestea vă permit să creați copii ale bazelor de date MS SQL Server (inclusiv Express) și Azure, să salvați fișiere criptate și comprimate pe FTP și servicii cloud (Dropbox, Box, Google Drive, MS SkyDrive sau Amazon S3) , rezultatul poate fi vizualizat imediat. Este posibil să lansați procesul fie manual, fie conform unui program, să trimiteți un mesaj despre rezultatul sarcinii prin e-mail sau să rulați scripturi personalizate.

Sunt acceptate toate opțiunile de backup: complet, diferențial, jurnal de tranzacții, copierea unui folder cu fișiere și multe altele. Copiile de rezervă vechi sunt șterse automat. SQL Management Studio este folosit pentru a se conecta la gazda virtuală, deși pot exista nuanțe și acest lucru nu va funcționa în toate astfel de configurații. Există cinci versiuni disponibile pentru descărcare - de la gratuit gratuit la sofisticatul Prof Lifetime (la momentul scrierii acestor rânduri costa doar 149 USD). Funcționalitatea Free este destul de suficientă pentru rețelele mici cu unul sau două servere SQL instalate, toate funcțiile de bază sunt active. Numărul de baze de date de rezervă, capacitatea de a trimite fișiere către Google Drive și SkyDrive și criptarea fișierelor sunt limitate. Deși interfața nu este localizată, este foarte simplă și de înțeles chiar și pentru un începător. Trebuie doar să vă conectați la serverul SQL, după care va fi afișată o listă de baze de date, ar trebui să le selectați pe cele de care aveți nevoie, să configurați accesul la resursele de la distanță și să specificați timpul de finalizare a sarcinii. Și toate acestea într-o singură fereastră.

Dar există un „dar”. Programul în sine nu este destinat recuperării arhivelor. Pentru aceasta, este oferit un utilitar gratuit separat, One-Click SQL Restore, care înțelege și formatul creat de comanda BACKUP DATABASE. Administratorul trebuie doar să specifice arhiva și serverul pe care să restaureze datele și să apese un buton. Dar în scenarii mai complexe va trebui să utilizați RESTORE.

Caracteristici ale backup-ului MS SQL Server

Crearea unei copii de rezervă și restaurarea unui DBMS are propriile diferențe care trebuie luate în considerare, mai ales atunci când se transferă o arhivă pe un alt server. De exemplu, să ne uităm la unele dintre nuanțele MS SQL Server. Pentru a arhiva folosind Transact-SQL, utilizați comanda BACKUP DATABASE (există și o comandă DIFERENȚIAL) și jurnalul de tranzacții BACKUP LOG.

Dacă backup-ul este implementat pe un alt server, trebuie să vă asigurați că sunt prezente aceleași unități logice. Ca opțiune, puteți specifica manual căile corecte pentru fișierele bazei de date folosind opțiunea WITH MOVE a comenzii RESTORE DATABASE.

O situație simplă - backup și transferul bazelor de date pe alte versiuni de SQL Server. Această operație este acceptată, dar în cazul SQL Server va funcționa dacă versiunea serverului pe care este implementată copia este aceeași sau mai nouă decât cea pe care a fost creată. Mai mult, există o limitare: nu mai mult de două versiuni sunt mai noi. După restaurare, baza de date va fi în modul de compatibilitate cu versiunea cu care s-a făcut tranziția, adică funcții noi nu vor fi disponibile. Acest lucru poate fi remediat cu ușurință prin schimbarea COMPATIBILITY_LEVEL. Puteți face acest lucru folosind GUI sau SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Puteți determina în ce versiune a fost creată copia uitându-vă la antetul fișierului arhivă. Pentru a evita experimentarea, atunci când faceți upgrade la o nouă versiune de SQL Server, ar trebui să rulați utilitarul gratuit Microsoft Upgrade Advisor.

Iperius

Licență: comercial, există o versiune gratuită

SGBD acceptat: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL și MS SQL Server

Când trebuie să gestionați mai multe tipuri de SGBD, nu puteți face fără combine. Alegerea este mare. De exemplu, Iperius este un program ușor de utilizat, foarte ușor de utilizat, dar puternic, care oferă copii de siguranță ale bazei de date, fără întrerupere sau blocare. Oferă backup complet sau incremental. Poate crea imagini de disc complet pentru a reinstala automat întregul sistem. Suportă backup pe NAS, dispozitive USB, streamer, FTP/FTPS, Google Drive, Dropbox și SkyDrive. Acceptă compresia zip fără limită de dimensiune a fișierului și criptare AES256, lansând scripturi și programe externe. Include un planificator de sarcini foarte funcțional, execuția paralelă sau secvențială a mai multor sarcini este posibilă, rezultatul este trimis prin e-mail. Sunt acceptate numeroase filtre, variabile pentru personalizarea căilor și setărilor.

Capacitatea de încărcare FTP facilitează actualizarea informațiilor pe mai multe site-uri web. Fișierele deschise sunt copiate de rezervă folosind tehnologia VSS (copie umbra a volumului), care vă permite să faceți copii de siguranță la cald nu numai ale fișierelor DBMS, ci și ale altor aplicații. Pentru Oracle, este folosit și instrumentul de backup și recuperare RMAN (Recovery Manager). Pentru a evita supraîncărcarea canalului, este posibilă configurarea lățimii de bandă. Backup-ul și recuperarea sunt gestionate folosind o consolă locală și web. Toate funcțiile sunt vizibile, așa că pentru a configura o sarcină trebuie doar să înțelegeți procesul; nici măcar nu trebuie să vă uitați la documentație. Urmăm doar instrucțiunile vrăjitorului. Puteți observa și managerul de cont, ceea ce este foarte convenabil atunci când aveți un număr mare de sisteme.

Funcțiile de bază sunt oferite gratuit, dar capacitatea de a crea copii de rezervă a unei baze de date este inclusă numai în versiunile Advanced DB și Full. Instalarea de la XP la Windows Server 2012 este acceptată.

Backup la îndemână

Licență: o reclamă

SGBD acceptat: Oracle, MySQL, IBM DB2 (7–9.5) și MS SQL Server

Unul dintre cele mai puternice sisteme de gestionare a bazelor de date relaționale este IBM DB2, care are caracteristici unice de scalare și suportă mai multe platforme. Vine în mai multe ediții, care sunt construite pe aceeași bază și diferă funcțional. Arhitectura bazei de date DB2 vă permite să gestionați aproape toate tipurile de date: documente, XML, fișiere media și așa mai departe. DB2 Express-C gratuit este deosebit de popular. Backup-ul este foarte simplu:

Exemplu de bază de rezervă Db2

Sau un instantaneu folosind funcția Advanced Copy Services (ACS):

Db2 backup db sample use snapshot

Dar trebuie să ne amintim că, în cazul instantaneelor, nu putem recupera (db2 recover db) tabele individuale. Există, de asemenea, oportunități pentru backup automat și multe altele. Produsele sunt bine documentate, deși manualele sunt rare pe internetul în limba rusă. De asemenea, nu toate soluțiile personalizate oferă suport DB2.

De exemplu, Handy Backup vă permite să faceți backup mai multor tipuri de servere de baze de date și să salvați fișiere pe aproape orice suport (hard disk, CD/DVD, stocare în cloud și în rețea, FTP/S, WebDAV și altele). Backup-ul bazei de date este posibil prin ODBC (numai tabele). Este una dintre puținele soluții care acceptă DB2 și poartă, de asemenea, sigla „Ready for IBM DB2 Data Server Software”. Întreaga procedură este efectuată folosind un expert obișnuit, în care trebuie doar să selectați elementul dorit și să creați o sarcină. Procesul de configurare în sine este atât de simplu încât chiar și un începător își poate da seama. Puteți crea mai multe sarcini care vor rula conform unui program. Rezultatul este înregistrat într-un jurnal și trimis prin e-mail. Nu este nevoie să opriți serviciul în timp ce lucrarea rulează. Arhiva este automat comprimată și criptată, ceea ce asigură securitatea acesteia.

Două versiuni de Handy Backup acceptă lucrul cu DB2 - Office Expert (local) și Server Network (rețea). Funcționează pe computere care rulează Win8/7/Vista/XP sau 2012/2008/2003. Procesul de implementare în sine este simplu pentru orice administrator.

Și, de asemenea: backup SQL, backup 1C.

Camera serverului 1C conține date într-o bază de date situată pe un server SQL. Astăzi luăm în considerare opțiunea MS SQL 2005/2008.

Pentru a vă asigura că datele nu se pierd în cazul unui disc de server ars sau în alte situații de forță majoră, este necesar să faceți copii de siguranță încă de la început.

Desigur, nimeni nu vrea să facă manual Backup SQL a bazelor de date 1C în fiecare zi. Există instrumente automate pentru aceasta. Să-i cunoaștem.

Configurarea Backup SQL

Configurarea Backup SQL pentru o bază de date 1C nu este diferită de configurarea unei copii de rezervă pentru orice altă bază de date.

Pentru a configura, lansați MS SQL Management Studio. Acest program se află în grupul de programe MS SQL.

Adăugarea unei sarcini de copiere a bazei de date SQL 1C

Sarcinile de copiere automată a bazei de date SQL sunt situate în ramura Planuri de management / întreținere.

Pentru a adăuga o nouă sarcină de rezervă, faceți clic dreapta pe grupul Planuri de întreținere și selectați Plan de întreținere nou.

Introduceți un titlu pentru sarcină. Numele contează doar pentru tine. Este mai bine să folosiți caractere englezești pentru orice eventualitate.

Configurarea unui job de backup al bazei de date SQL 1C

Se va deschide editorul de activități. Vă rugăm să rețineți că joburile pot efectua diverse operațiuni cu baza de date, nu doar copii de rezervă.

O listă de opțiuni de operare este afișată în stânga jos. Selectați Backup Database Task făcând dublu clic sau pur și simplu trăgând spre dreapta.

Acordați atenție săgeții. Puteți trage mai multe operațiuni diferite sau identice și le puteți lega cu săgeți. Apoi mai multe sarcini vor fi efectuate simultan în secvența pe care o definiți.

În fereastra de setări, selectați bazele de date SQL 1C necesare (puteți avea mai multe sau una odată).

Selectați o locație pentru a salva backupul bazei de date SQL 1C. Trebuie să selectați un hard disk diferit din punct de vedere fizic. În scopuri organizatorice, puteți bifa caseta de selectare „Creați subdosare”.

Acum să stabilim un program de rezervă. Programul de rezervă a fost adăugat în mod implicit. Dar puteți adăuga mai multe programe (de exemplu, unul este zilnic, unul săptămânal etc.). Faceți clic pe butonul pentru setările programului de rezervă.

Captura de ecran arată un exemplu de Backup SQL zilnic al unei baze de date 1C la ora 3 dimineața.

Pentru ca programul de rezervă din listă să fie frumos și clar, îl puteți modifica.

Salvarea unei sarcini de backup a bazei de date SQL 1C

Faceți clic pe înregistrare. Sarcina va apărea în partea stângă a listei.

Este important! Verificați dacă jobul de bază de date Backup SQL a fost creat corect. Pentru a face acest lucru, faceți clic dreapta pe sarcină și selectați Executare.

Ca rezultat, un fișier de rezervă ar trebui să apară la calea specificată. Dacă ceva nu este în regulă, ștergeți sarcina (Del) și începeți de la capăt.

Acest articol vă va spune cum să faceți manual o copie de rezervă completă a bazei de date folosind programul Microsoft SQL Server Management Studio.

1. Creați o copie de rezervă

De fapt, este destul de simplu. Lansați echipamentul " » (« start» — « Toate programele» — « SQL Server 2008 R2» — « Microsoft SQL Server Management Studio") și introduceți informațiile dvs. de conectare.

Apoi, în Browserul de obiecte, deschideți fila „ Bază de date» și faceți clic dreapta pe baza de date pentru care trebuie să faceți o copie de rezervă. În meniul contextual care apare, selectați „ Sarcini» ( Sarcini) — « Creați o copie de rezervă» ( Faceți backup...) .

Fereastra " Backup pentru baze de date» ( Faceți backup bazei de date) . Să ne asigurăm că merită" Deplin» ( Deplin), dacă este necesar, setați un nume și o descriere și indicați, de asemenea, scopul copiei de rezervă. În mod implicit, este selectată calea de pe hard diskul computerului către folderul Backup din locația principală a bazelor de date server SQL. Pentru a schimba locația copiei, mai întâi faceți clic pe „ Șterge» ( Elimina) pentru a șterge o atribuire existentă, apoi „ Adăuga» ( Adăuga...) pentru a adăuga unul nou.

Aici vom seta locația și numele fișierului de rezervă și vom face clic pe „ Bine". Puteți specifica mai multe astfel de destinații. În acest caz, backup-ul va fi împărțit în părți egale, fiecare parte din fișierul specificat.

Când toate setările sunt setate, faceți clic pe „ Bine" și așteptați finalizarea sarcinii. Dacă totul este făcut corect, în directorul specificat vom găsi fișierul de backup al bazei de date SQL.

2. Restaurarea unei baze de date dintr-o copie de rezervă

Recuperarea urmează un model similar. IN " Mediul Microsoft SQL Server Management Studio» selectați o bază din care s-a făcut backup-ul, faceți clic dreapta pe el, selectați „ Sarcini» ( Sarcini) — « Restabili» ( Restabili) — « Bază de date…» ( Bază de date…).

Fereastra " Recuperarea bazei de date» ( Restaurați baza de date). Aici, ca sursă indicăm „ De la dispozitiv» ( De la dispozitiv) și selectați fișierul de rezervă (creat la pasul 1).

Setați steagul " Restabili» ( Restabili) lângă backup-ul selectat. Dacă este necesar, pe " Opțiuni» ( Opțiuni), puteți specifica parametri suplimentari de recuperare, a căror semnificație poate fi citită.

După ce au fost făcute toate setările, faceți clic pe „ Bine" și așteptați un mesaj despre restaurarea cu succes a bazei de date.

3. Restaurarea unei copii de rezervă într-o altă bază de date (copierea datelor)

Dacă trebuie să încărcați date în baza de date, diferit de cel din care s-a făcut backup-ul, apoi la încărcare, pe lângă acțiunile descrise la paragraful 2, este necesar pe „ Opțiuni" (Opțiuni) setați numele fișierelor acestei baze de date și setați steag-ul " Suprascrieți baza de date existentă„(CU ÎNLOCUIRE).

Te-a ajutat acest articol?

În ciuda faptului că în materialele noastre anterioare am abordat deja problema copierii de rezervă a bazelor de date Microsoft SQL Server, răspunsul cititorului a arătat nevoia de a crea un material cu drepturi depline, cu un studiu mai profund al părții teoretice. Într-adevăr, articolele, scrise cu accent pe instrucțiuni practice, vă permit să configurați rapid backup-uri, dar nu explică motivele alegerii anumitor setări. Să încercăm să corectăm acest decalaj.

Modele de recuperare

Înainte de a configura o copie de rezervă, ar trebui să selectați un model de recuperare. Pentru a face alegerea optimă, ar trebui să evaluați cerințele de recuperare și criticitatea pierderii datelor, comparându-le cu costurile generale ale implementării unui anumit model.

După cum știți, baza de date MS SQL constă din două părți: baza de date în sine și jurnalul de tranzacții pentru aceasta. Baza de date conține date despre utilizatori și servicii la momentul curent, jurnalul de tranzacții include istoricul tuturor modificărilor din baza de date pentru o anumită perioadă, cu jurnalul de tranzacții putem derula înapoi starea bazei de date în orice moment arbitrar.

Există două modele de recuperare disponibile pentru utilizare în medii de producție: simplu si complet. Exista si un model cu înregistrare incompletă, dar este recomandat doar ca o completare la modelul complet pentru perioadele de operațiuni în masă la scară largă, când nu este nevoie să restabiliți baza la un anumit moment în timp.

Model simplu prevede doar backup-ul bazei de date; în consecință, putem restabili starea bazei de date numai în momentul în care a fost creată backup-ul; toate modificările din perioada de timp dintre crearea ultimei copii de siguranță și eșec se vor pierde. În același timp, o schemă simplă are o supraîncărcare redusă: trebuie doar să stocați copii ale bazei de date; jurnalul de tranzacții este trunchiat automat și nu crește în dimensiune. De asemenea, procesul de recuperare este cel mai simplu și nu necesită mult timp.

Model complet vă permite să restaurați baza de date în orice moment arbitrar, dar necesită, pe lângă copiile de siguranță ale bazei de date, să stocați copii ale jurnalului de tranzacții pentru întreaga perioadă pentru care poate fi necesară restaurarea. Când se lucrează activ cu baza de date, dimensiunea jurnalului de tranzacții și, în consecință, dimensiunea arhivelor, pot atinge dimensiuni mari. Procesul de recuperare este, de asemenea, mult mai complex și consumator de timp.

Atunci când alegeți un model de recuperare, ar trebui să comparați costurile de recuperare cu costurile de stocare a copiilor de rezervă și, de asemenea, trebuie să luați în considerare disponibilitatea și calificările personalului care va efectua recuperarea. Restaurarea cu un model complet necesită ca personalul să aibă anumite calificări și cunoștințe, în timp ce cu o schemă simplă va fi suficient să urmați instrucțiunile.

Pentru bazele de date cu o cantitate mică de informații adăugate, poate fi mai profitabil să folosiți un model simplu cu o frecvență mare de copii, care vă va permite să recuperați rapid și să continuați să lucrați prin introducerea manuală a datelor pierdute. Modelul complet ar trebui utilizat în primul rând acolo unde pierderea de date este inacceptabilă și unde eventuala recuperare ar fi costisitoare.

Tipuri de copii de rezervă

Copie integrală a bazei de date- după cum sugerează și numele, reprezintă conținutul bazei de date și o parte a jurnalului de tranzacții activ pentru momentul în care a fost formată backup-ul (adică, informații despre toate tranzacțiile curente și incomplete). Vă permite să restaurați complet baza de date în momentul în care a fost creată copierea de rezervă.

Copie a bazei de date Delta- o copie completă are un dezavantaj semnificativ: conține toate informațiile bazei de date. Dacă backup-urile trebuie făcute destul de des, atunci se pune imediat problema utilizării irosite a spațiului pe disc, deoarece majoritatea spațiului de stocare va fi ocupat de aceleași date. Pentru a elimina acest dezavantaj, puteți utiliza copii diferențiate ale bazei de date, care conțin doar informații care s-au modificat de la ultima copie completă.

Vă rugăm să rețineți că o copie diferențială reprezintă date din ultima dată deplin copierea, adică Fiecare copie diferențială ulterioară conține datele celei anterioare (dar poate fi modificată) iar dimensiunea copiei va crește constant. Pentru restaurare, este suficientă o copie completă și una diferențială, de obicei ultima. Numărul de copii diferențiale trebuie selectat în funcție de creșterea dimensiunii acestora; de îndată ce dimensiunea copiei diferențiale este egală cu dimensiunea a jumătate din cea completă, este logic să faceți o nouă copie completă.

Backup pentru jurnalul tranzacțiilor- se aplică doar modelului de recuperare completă și conține o copie a jurnalului de tranzacții începând din momentul în care a fost creată copia anterioară.

Este important să rețineți următorul punct - copiile jurnalului de tranzacții nu sunt în niciun fel legate de copiile bazei de date și nu conțin informații din copiile anterioare, așa că pentru a restaura o bază de date trebuie să aveți un lanț neîntrerupt de copii pentru perioada în care doriți. pentru a putea derula înapoi starea bazei de date. În acest caz, momentul ultimei copieri reușite trebuie să fie în această perioadă.

Să ne uităm la figura de mai sus, dacă prima copie a fișierului jurnal este pierdută, atunci veți putea restabili starea bazei de date numai în momentul copierii complete, care va fi similară cu modelul de recuperare simplă; va putea restabili starea bazei de date în orice moment numai după următoarea copie diferențială (sau completă), cu condiția ca lanțul de copii de jurnal începând cu cel care precede copierea bazei de date și în continuare va fi continuu (în figură - de la a treia și mai departe).

Jurnal de tranzacții

Pentru a înțelege procesele de recuperare și scopul diferitelor tipuri de backup, ar trebui să aruncați o privire mai atentă asupra structurii și funcționării jurnalului de tranzacții. O tranzacție este operațiunea logică minimă posibilă care are sens și poate fi finalizată doar complet. Această abordare asigură integritatea și consistența datelor în toate situațiile, deoarece o stare intermediară a operațiunii este inacceptabilă. Un jurnal de tranzacții este utilizat pentru a controla orice modificări în baza de date.

Când se efectuează orice operațiune, o înregistrare despre începutul tranzacției este adăugată în jurnalul de tranzacții, fiecărei înregistrări i se atribuie un număr unic (LSN) dintr-o secvență neîntreruptă, când orice date se modifică, se face o intrare corespunzătoare în jurnal, iar după finalizarea operațiunii, în jurnal apare un semn care indică închiderea (angajarea) tranzacției.

La fiecare pornire, sistemul analizează jurnalul de tranzacții și derulează înapoi toate tranzacțiile necommitate, în timp ce anulează simultan modificările care au fost înregistrate în jurnal, dar nu au fost scrise pe disc. Acest lucru face posibilă utilizarea memoriei cache și a scrierii leneșe fără a vă face griji cu privire la integritatea datelor, chiar și în absența sistemelor de alimentare de rezervă.

Partea din jurnal care conține tranzacții active și este utilizată pentru recuperarea datelor se numește partea activă a jurnalului. Începe cu un număr numit numărul minim de recuperare (MinLSN).

În cel mai simplu caz, MinLSN este numărul de înregistrare al primei tranzacții în așteptare. Dacă te uiți la figura de mai sus, prin deschiderea tranzacției albastre vom obține un MinLSN egal cu 321, după ce acesta este fixat în înregistrarea 324, numărul MinLSN se va schimba în 323, care va corespunde numărului verde, nu încă. comis, tranzacție.

În practică, totul este puțin mai complicat, de exemplu, este posibil ca datele unei tranzacții albastre închise să nu fie încă spălate pe disc și mutarea MinLSN la 323 va face recuperarea acestei operațiuni imposibilă. Pentru a evita astfel de situații a fost introdus conceptul de punct de control. Un punct de control este creat automat atunci când apar următoarele condiții:

• Când se execută în mod explicit instrucțiunea CHECKPOINT. Punctul de control este declanșat în baza de date a conexiunii curente.
• Când efectuați o operațiune înregistrată minim pe o bază de date, cum ar fi atunci când efectuați o operațiune de copiere în bloc pe o bază de date care este supusă modelului de recuperare înregistrată în bloc.
• Când adăugați sau eliminați fișiere de bază de date folosind instrucțiunea ALTER DATABASE.
• Când opriți o instanță a SQL Server folosind instrucțiunea SHUTDOWN sau când opriți serviciul SQL Server (MSSQLSERVER). În ambele cazuri, un punct de control va fi creat pentru fiecare bază de date din instanța SQL Server.
• Dacă instanța dvs. de SQL Server creează periodic puncte de control automate pe fiecare bază de date pentru a reduce timpul de recuperare a bazei de date.
• Când se creează o copie de rezervă a bazei de date.
• Când efectuați o acțiune care necesită închiderea bazei de date. Exemplele includ setarea parametrului AUTO_CLOSE la ON și închiderea ultimei conexiuni a utilizatorului la baza de date sau modificarea unei setări a bazei de date care necesită o repornire a bazei de date.

În funcție de evenimentul care a avut loc primul, MinLSN va fi setat fie la numărul de înregistrare a punctului de control, fie la începutul celei mai vechi tranzacții în așteptare.

Trunchierea jurnalului de tranzacții

Jurnalul de tranzacții, ca orice jurnal, necesită curățarea periodică a intrărilor învechite, altfel va crește și va ocupa tot spațiul disponibil. Având în vedere că atunci când se lucrează în mod activ cu baza de date, dimensiunea jurnalului de tranzacții poate depăși semnificativ dimensiunea bazei de date, această problemă este relevantă pentru mulți administratori.

Din punct de vedere fizic, fișierul jurnal de tranzacții este un container pentru jurnalele virtuale, care sunt completate secvenţial pe măsură ce jurnalul crește. Jurnalul logic care conține intrarea MinLSN este începutul jurnalului activ; jurnalele logice care îl preced sunt inactive și nu sunt necesare pentru recuperarea automată a bazei de date.

Dacă este selectat un model de recuperare simplu, atunci când jurnalele logice ating o dimensiune egală cu 70% din fișierul fizic, partea inactivă a jurnalului este ștearsă automat, așa-numita. trunchiere. Cu toate acestea, acest lucru nu micșorează fișierul jurnal fizic; trunchiază doar jurnalele logice, care pot fi apoi reutilizate după această operațiune.

Dacă numărul de tranzacții este mare și până la atingerea a 70% din dimensiunea fișierului fizic nu există jurnale logice inactive, atunci dimensiunea fișierului fizic va fi mărită.

Astfel, fișierul jurnal de tranzacții cu un model simplu de recuperare va crește în funcție de activitatea de lucru cu baza de date, până când va conține în mod fiabil întreaga parte activă a jurnalului. După care creșterea sa se va opri.

Cu modelul complet, porțiunea inactivă a jurnalului nu poate fi trunchiată până când nu se face backup complet. Trunchierea jurnalului are loc dacă s-a făcut o copie de rezervă a jurnalului de tranzacții și a fost creat un punct de control.

Configurarea incorectă a copiei de rezervă a jurnalului de tranzacții într-un model complet poate duce la creșterea necontrolată a fișierelor jurnal, care este adesea o problemă pentru administratorii fără experiență. De asemenea, întâlniți adesea sfaturi despre trunchierea manuală a jurnalului de tranzacții. Cu un model de recuperare completă, acest lucru nu ar trebui făcut categoric, deoarece acest lucru va încălca integritatea lanțului de copii de jurnal și veți putea restaura baza de date numai în momentul în care au fost create copiile, ceea ce va corespunde modelului simplu. .

În acest caz, este timpul să ne amintim despre ce am vorbit la începutul articolului; dacă costurile unui model complet depășesc costurile de restaurare, ar trebui să se acorde preferință unui model simplu.

Model simplu de recuperare

Acum, după obținerea minimului necesar de cunoștințe, putem trece la o analiză mai detaliată a modelelor de recuperare. Să începem cu unul simplu. Să presupunem că în momentul eșecului avem un exemplar complet și două copii diferențiate:

Backup-urile au fost efectuate o dată pe zi, iar ultima copie a fost creată noaptea între 21 și 22. Eșecul are loc în seara zilei de 22 înainte de crearea următoarei copii. În acest caz, va trebui să restabilim secvențial copiile diferențiale complete și ultimele, iar datele pentru ultima zi lucrătoare se vor pierde. Dacă dintr-un motiv oarecare și copia din data de 21 se dovedește a fi deteriorată, atunci putem restabili copia anterioară, pierzând încă o zi de muncă, în timp ce, în același timp, deteriorarea copiei pentru data de 20 nu ne va împiedica în niciun fel de la restabilirea cu succes a datelor în seara zilei de 21, când este disponibilă o copie corespunzătoare.

Model de recuperare completă

Să luăm în considerare o situație similară, dar folosind modelul de recuperare completă. De asemenea, facem copii de rezervă zilnic, folosind principiul complet + diferențial și, de asemenea, copiem jurnalul de tranzacții de mai multe ori pe zi.

Procesul de recuperare în acest caz va fi mai complicat. În primul rând, va trebui să faceți o copie de rezervă manuală a cozii jurnalului (indicată cu roșu), adică. parte a jurnalului din momentul în care a fost creată ultima copie până la accident.

Dacă acest lucru nu se face, atunci va fi posibilă restaurarea bazei de date numai la starea la momentul în care a fost creată ultima copie a jurnalului de tranzacții.

În acest caz, deteriorarea fișierului de copiere a jurnalului din ziua anterioară nu ne va împiedica să restabilim starea curentă a bazei de date, ci ne va limita la momentul în care a fost creată ultima copie, adică. zilele curente.

Apoi restaurăm secvențial copiile complete și diferențiale și lanțul de copii ale jurnalului creat după ultima copie de rezervă, ultima pe care o restaurăm este o copie a fragmentului final al jurnalului, care ne va oferi posibilitatea de a restaura dreptul de bază de date. la momentul accidentului sau unul arbitrar care l-a precedat.

Dacă ultima copie diferențială este deteriorată, atunci în cazul unui model simplu, acest lucru va duce la pierderea unei alte zile lucrătoare; modelul complet vă permite să restaurați penultima copie, după care va trebui să restabiliți întregul lanț de tranzacții copii de jurnal din momentul penultimei copii până la eșec. Adâncimea de recuperare depinde doar de adâncimea lanțului continuu de bușteni.

Pe de altă parte, dacă una dintre copiile jurnalului de tranzacții este deteriorată, să zicem penultima, atunci vom putea restabili datele doar la momentul ultimei backup + perioada din lanțul intact de copii de jurnal. De exemplu, dacă jurnalele au fost făcute la ora 12, 14 și 16 și jurnalul creat la ora 14 este deteriorat, atunci având o copie zilnică putem restabili baza de date până la sfârșitul lanțului continuu, adică. pana la ora 12.

Funcționalitatea extinsă a Bacula Enterprise Edition, printre altele, vă permite să creați rapid și ușor copii de siguranță ale bazei de date pentru . De exemplu, vorbim despre un instrument cu care poți face backup pentru MS SQL Server. Utilizatorul poate face o copie de rezervă a MS SQL prin crearea de copii de siguranță în volum mare ale bazelor de date MS SQL specifice utilizate de platforma Windows, la costuri mai mici pentru software-ul terților, cu posibilitatea de a restaura datele la un anumit moment în timp (recuperare PITR ) la o rețea și o unitate locală.

Scriptul Bacula Systems pentru crearea de backup-uri MS SQL Server se caracterizează printr-o eficiență extremă, realizată prin implementarea unei arhitecturi moderne, de mare încredere. Mai mult, software-ul vă permite să faceți o copie de rezervă a MS SQL Server și să utilizați o varietate de opțiuni pentru a crea copii de rezervă MS SQL.

Scriptul de backup MS SQL Bacula Systems funcționează independent de VSS. Aceasta înseamnă că instrumentul de backup MS SQL nu utilizează instantanee VSS pentru a crea copii de rezervă. Prin urmare, utilizatorul poate seta următoarea valoare „Enable VSS = no” în Bacula FileSet. Crearea eficientă a backup-urilor MS SQL Server și restaurarea lor folosind această soluție se realizează prin utilizarea API-ului Microsoft pentru SQL Server. Acest lucru permite Bacula Systems să suporte mecanismele de securitate și toate tipurile de autentificare implementate în Microsoft SQL Server.

Copiere de rezervă a jurnalului de tranzacții MS SQL și recuperare punct-in-time MS SQL: software-ul Bacula Enterprise Edition vă permite să recuperați blocuri de date MS SQL sau setări specifice la un anumit moment în timp. Odată cu implementarea modelelor de recuperare completă și în bloc, puteți recupera MS SQL folosind recuperarea PITR sau puteți utiliza LSN pentru a restaura sistemul la o anumită stare. Puteți restaura o anumită stare a unei baze de date MS SQL în orice moment specific, până la al doilea. În cazul unei copii de rezervă a jurnalului de tranzacții MS SQL, la restaurare, starea bazei de date va fi restabilită din diferite copii de rezervă selectate.

Caracteristici dintr-o privirebackup și recuperare automată a MS SQL cu Bacula Enterprise

Bacula Systems a creat un plugin de backup MS SQL Server pentru utilizare cu Bacula Enterprise Edition. Backup-ul MS SQL Server cu Bacula are următoarele caracteristici:

• Suportă backup-uri MS SQL complete și diferențiate
• Suport pentru backup incremental MS SQL
• Backup MS SQL în rețea și unitatea locală
• Backup programat MS SQL
• Crearea de copii de rezervă la nivelul bazei de date MS SQL Server
• Abilitatea de a include/exclude baze de date din procedura de creare a backupului
• Suport pentru crearea de copii de rezervă numai pentru citire
• Restaurarea backup-urilor MS SQL pe disc
• Trimiterea unui flux de rezervă direct către Storage Daemon
• MS SQL punct în timp de recuperare

Revizuirea și configurarea backupului MS SQL 2008, 2008 R2, 2012 și 2014

Acest document oferă soluții pentru Bacula Enterprise Edition 8.4 și ulterioare, care nu sunt acceptate de versiunile anterioare ale software-ului. Backup-ul bazei de date MS SQL a fost testat și este susținut de MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. Backup-ul MS SQL de la Bacula poate funcționa cu SQL Express.

Glosar MS SQL Backup 2008, 2008 R2, 2012 și 2014

• MS SQL reprezintă Microsoft SQL Server.
• Jurnal de tranzacții. Orice bază de date MS SQL Server are un jurnal de tranzacții, care înregistrează toate tranzacțiile și modificările bazei de date efectuate în timpul acestor tranzacții. Jurnalul de tranzacții este un element important al bazei de date. În cazul unei defecțiuni a sistemului, jurnalul de tranzacții poate fi necesar pentru a restabili baza de date la starea de funcționare. Mai multe informații pot fi găsite la https://msdn.microsoft.com/en-us/library/ms190925.aspx.
• Backup diferențial al bazei de date MS SQL Server. Backup-ul diferențial se bazează pe ultimul complet. În timpul unei copii de rezervă diferențiale, sunt capturate numai datele care s-au modificat de la crearea ultimei copii de siguranță completă. Mai multe informații pot fi găsite la https://msdn.microsoft.com/en-us/library/ms175526.aspx.
• Backup complet al bazei de date MS SQL Server.În timpul unui backup complet al bazei de date, este creată o copie de rezervă a întregii baze de date. Backup-ul include o parte din jurnalul de tranzacții cu scopul de a restaura baza de date completă din backup. Backup-urile complete ale bazei de date conțin baza de date la momentul finalizării copiei de rezervă. Mai multe informații pot fi găsite la https://msdn.microsoft.com/en-us/library/ms186289.aspx.
• Backup „numai copiere” (CopyOnly). Copierele de rezervă numai pentru copiere sunt copii de rezervă MS SQL care sunt independente de fluxul normal al backup-urilor tradiționale SQL Server. Uneori este util să creați copii de rezervă pentru nevoi specifice, fără a afecta procesul general de backup și recuperare a bazei de date. Mai multe informații pot fi găsite la https://msdn.microsoft.com/en-us/library/ms191495.aspx.
• VDI(Virtual Device Interface) este o tehnologie Microsoft care vă permite să creați conductă numităîntre programe.
• măștile standard specifică seturi de șiruri de caractere cu metacaractere. De exemplu, masca standard de producție* va include liniile producție1 și producție2.
• linia
• întreg.
• LSN Fiecare intrare din jurnalul de tranzacții MS SQL Server este identificată printr-un număr de serie unic al tranzacției (LSN). Informații mai detaliate pot fi găsite la https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.

Backup MS SQL Server 2008, 2008 R2, 2012 și 2014

Backup complet al bazelor de date MS SQL Server 2008, 2008 R2, 2012 și 2014

În timpul unei copii de siguranță completă a unei baze de date MS SQL, fișierele bazei de date și jurnalul de tranzacții sunt salvate, ceea ce vă permite să protejați complet baza de date MS SQL în caz de defecțiune a media. Dacă unul sau mai multe fișiere sunt deteriorate, restaurarea bazei de date MS SQL dintr-o copie de rezervă vă va permite să restaurați toate tranzacțiile finalizate. Toate tranzacțiile care erau în curs vor fi, de asemenea, anulate. În acest mod, sunt create copii de rezervă ale bazelor de date master și mbdb.

Backup diferențial al bazelor de date MS SQL Server 2008, 2008 R2, 2012 și 2014

Copierea de rezervă diferențială a bazei de date MS SQL Server se bazează pe cea mai recentă copie de rezervă completă a bazei de date MS SQL. Când se creează o copie de rezervă MS SQL diferențială, sunt capturate numai datele care au fost modificate de la crearea ultimului backup complet MS SQL. Pentru funcția de backup diferențial MS SQL, succesiunea backup-urilor este extrem de importantă. Dacă, dintr-un motiv oarecare, copia de rezervă completă la care face referire MS SQL nu este disponibilă, copiile de rezervă diferențiate ale bazei de date MS SQL Server nu pot fi utilizate. MS SQL Backup de la Bacula folosește tehnici specifice pentru a rezolva această problemă. Prin urmare, dacă apar dificultăți, starea unei copii de siguranță diferențiate a bazei de date poate fi actualizată automat la o copie de rezervă completă.

Backup jurnal de tranzacții pentru MS SQL 2008, 2008 R2, 2012 și 2014

Configurarea backupului MS SQL și configurarea bazei de date

Restaurarea unei baze de date MS SQL dintr-o copie de rezervă

Puteți folosi toate metodele standard pentru a începe procedura de restaurare a unei baze de date MS SQL dintr-o copie de rezervă. Cu toate acestea, trebuie să vă asigurați că, în cazul restaurării datelor diferențiale, va fi restaurată și backupul complet anterioar al bazei de date MS SQL. În acest caz, recuperarea are loc automat dacă o rulați în consolă bconsole folosind opțiunile de recuperare 5 sau 12. În structura de fișiere generată, trebuie să marcați recuperarea bazelor de date complete sau a instanțelor DB.

Opțiuni pentru restaurarea unei baze de date MS SQL dintr-o copie de rezervă

Software-ul Bacula Enterprise Edition permite utilizatorilor să utilizeze mai multe opțiuni de recuperare MS SQL și să aplice o varietate de metode de derulare a bazei de date. Opțiunile de recuperare cele mai frecvent utilizate sunt descrise mai jos:

• Parametru unde: În cazul Bacula Enterprise Edition, acest parametru permite administratorului să restaureze baza de date într-o anumită locație.
• Înlocuire parametru: Folosit pentru a defini modul în care Bacula ar trebui să se comporte cu baza de date curentă atunci când este restaurată. Backup-ul MS SQL de la Bacula vă permite, de asemenea, să utilizați mai multe opțiuni la restaurare, cum ar fi:
• Instanță: Deoarece MS SQL utilizează mai multe instanțe, backupul bazei de date MS SQL de la Bacula vă permite să alegeți ce instanță să restaurați. Acest parametru este opțional, iar dacă nu este specificat, valoarea specificată la crearea copiei de rezervă va fi utilizată la restaurare. În mod implicit, este utilizată o instanță numită „MSSQLSERVER”.
• Bază de date. Această opțiune specifică numele bazei de date de restaurat și folosește valoarea specificată la momentul creării bazei de date. Acest parametru este opțional. În mod implicit, backup-urile bazei de date SQL Server utilizează parametrul Unde pentru a determina numele noii baze de date. Dacă ambilor parametrii Unde și Bază de date li se atribuie un nume valid al bazei de date, atunci va fi utilizat parametrul Bază de date.
• Utilizator. Numele de utilizator utilizat pentru conectarea la instanța bazei de date MS SQL. Acest parametru este opțional, iar dacă nu este specificat, valoarea specificată la crearea copiei de rezervă va fi utilizată la restaurare.
• Parola. Parola folosită pentru a vă conecta la instanța bazei de date MS SQL. Acest parametru este opțional, iar dacă nu este specificat, valoarea specificată la crearea copiei de rezervă va fi utilizată la restaurare.
• Domeniu. Domeniul folosit pentru a se conecta la instanța bazei de date MS SQL. Acest parametru este opțional, iar dacă nu este specificat, valoarea specificată la crearea copiei de rezervă va fi utilizată la restaurare.
• Recuperare. Parametrul vă permite să determinați dacă baza de date va fi revenită la starea anterioară în timpul recuperării sau nu. În mod implicit, la restaurarea unei baze de date, aceasta va reveni la starea anterioară.
• Stop_before_mark. Stare CU STOPBANTEMARK = Folosit pentru a indica faptul că intrarea din jurnalul de tranzacții care precede steag este punctul de restaurare. Punctul de recuperare poate fi o dată și o oră, un LSN sau un flag mark_name.
• Stop_at_mark. Stare CU STOPATMARK = Folosit pentru a indica faptul că tranzacția marcată este un punct de recuperare. STOPATMARK trece înainte la steag și redă tranzacția marcată. Punctul de recuperare poate fi o dată și o oră, un LSN sau un flag mark_name.
• Stop_at= . Stare CU STOPAT = este folosit pentru a indica faptul că punctul de restaurare este data/ora.
• Restrict_user. Clauza WITH RESTRICT_USER este folosită pentru a restricționa accesul la baza de date restaurată. Valoarea implicită este nr.

Restaurarea MS SQL la un moment dat poate fi efectuată direct din pluginul de backup MS SQL. De asemenea, puteți să restaurați fișierele local și să efectuați operațiuni din Consola de management Microsoft SQL Server pentru a obține mai multe funcționalități.

LSN

Numărul LSN al intrării de jurnal la care a avut loc un anumit eveniment de backup și recuperare poate fi vizualizat în unul dintre următoarele moduri:

• Când se afișează o descriere a sarcinilor pentru crearea unei copii de rezervă folosind software-ul Bacula
• În numele fișierului jurnal
• În tabelul msdb.backupset
• În tabelul msdb.backupfile

Când efectuați o sarcină pentru a crea o copie de rezervă a unei baze de date MS SQL, următoarele informații despre numerele LSN vor fi afișate atunci când se afișează descrierea sarcinii:

Număr Primul LSN corespunde ultimului număr LSN al ultimului backup al jurnalului de tranzacții. Un astfel de backup poate fi primul backup complet sau ultimul backup (incremental).

Număr Ultimul LSN se potrivește cu ultima tranzacție înregistrată în jurnal.

În cazul unei copii de rezervă a jurnalului de tranzacții (incremental), numele fișierului asociat cu această bază de date în sarcina de creare a unei copii de siguranță incrementală va arăta astfel:

Numărul din nume, în cazul nostru 42000162001, corespunde ultimului număr LSN al sarcinii anterioare (pentru a crea o copie de rezervă completă sau incrementală).

Figura 2: Primul LSN, Ultimul LSN și LSN-urile în numele fișierelor

După cum se arată în exemplul din Figura 2, dacă administratorul trebuie să restaureze baza de date MS SQL într-o stare corespunzătoare cu numărul LSN 14, se pot efectua următorii pași:

• În meniul de recuperare a bazei de date, utilizați opțiunea 5
• Selectați cel mai recent fișier de backup complet „data.bak” (LSN: 10)
• Selectați backup incremental „log-10.trn”

Sau, dacă cea mai recentă copie de rezervă completă a MS SQL Server nu este disponibilă, dar copia de rezervă completă anterioară este disponibilă, atunci:

• Utilizați opțiunea de restaurare 3, selectați valorile jobids corespunzătoare
• Selectați directorul bazei de date „/@mssql/db29187”
• Selectați fișierul de rezervă complet „data.bak” (LSN: 2)
• Selectați backup-uri incrementale „log-2.trn”, „log-3.trn”, „log-10.trn”
• Setați parametrul stop_at_mark la „lsn:14”
• Rulați sarcina pentru a restabili copia de rezervă

Scripturi de recuperare MS SQL

Descriere	Unde	Bază de date	Exemplu
Recuperați fișierele pe disc	cale		unde=c:/tmp
Restaurați baza de date inițială			unde=/
Restaurați cu un nume nou	Nume		unde=newdb
Restaurați cu un nume nou		Nume	baza de date=newdb
Recuperați cu un nume nou și mutați fișierele		Nume

Tabelul 1: Scenarii de recuperare MS SQL

2.3.1 Restaurarea unei baze de date MS SQL cu numele original

Pentru a restaura baza de date cu numele original, opțiunea Unde nu trebuie specificată (valoare goală), sau trebuie specificată valoarea „/” și parametrul A inlocui trebuie să i se atribuie o valoare Mereu, sau mai întâi trebuie să ștergeți baza de date sursă.

Restaurarea unei copii de rezervă MS SQL cu un nume nou

Pentru a restabili o copie de rezervă a bazei de date MS SQL cu un nume nou, poate fi necesar mai întâi să mutați fișierele bazei de date pe disc. Totul depinde dacă baza de date originală mai există.

Dacă baza de date sursă nu mai este disponibilă, atunci parametrul Unde, sau câmpul „Opțiuni plugin” poate conține numele noii baze de date. MS SQL Backup de la Bacula va crea automat baza de date cu un nume nou.

Dacă baza de date originală este încă necesară, parametrul unde va fi folosit pentru a muta fișierele pe disc și va trebui să denumești noua bază de date folosind meniul Opțiuni de plugin. În arborele de recuperare, trebuie să selectați fișierul layout.dat.

Folosind catalogul meu

Rulați sarcina de recuperare MS SQL:

Folosind Catalogul meu, rulați sarcina de recuperare a bazei de date MS SQL:

Recuperați MS SQL pe discul local

Dacă specificați unde=c:/cale/, fișierele vor fi restaurate pe discul local, iar administratorul bazei de date MS SQL va putea folosi extensia procedurală TSQL pentru Microsoft SQL Server Management Console pentru a restaura baza de date. Comenzile SQL necesare pentru restaurarea bazei de date sunt listate în descriere Rezultatul jobului asa cum se vede in poza de mai jos.