Programe de backup SQL Server. Configurarea bazei de date regulate de backup MS SQL Server. Restaurați baza de date din backup

Există mai multe modalități de copiere a tabelului în baza de date MS SQL Server. Vă ofer mai multe opțiuni pentru crearea unei copii a tabelelor. Care dintre ele de a alege - depinde de structura mesei, prezența indiciilor în ea, declanșatoare etc., precum și dorința de a face ceva cu mâinile lor.

1. Metoda manuală de copiere a structurii tabelului

În MICRISOFT SQL Management Studio, selectați baza de date, selectați tabelul, faceți clic pe clic dreapta și selectați "Tabelul Script As" -\u003e "Creați la" -\u003e "Noua fereastră de editor de interogare". Fereastra de interogare va deschide codul pentru crearea unei mese. Trebuie să specificați numele bazei în care aveți nevoie pentru a face o copie a tabelului și numele nou dacă baza nu se schimbă. Cum se creează codul pentru crearea structurii tabelului existent este afișat în figura de mai jos.

Cu această metodă, vor fi create indexurile de masă, dar declanșatoarele nu vor fi copiate. Ei trebuie să fie copiate în același mod.

Pentru a copia datele la tabelul deja creat, trebuie să utilizați o astfel de interogare SQL:

Inserați în ..tmp_tbl_deps Selectați * de la ..tbl_deps

2. Copie Tabelul SQL. Anchetă

Faceți o copie a tabelului de structură și a datelor în interiorul unei baze:

Selectați * în TMP_TBL_DEP de la TBL_DEPS

Copiați structura tabelului și datele sale dintr-o bază de date la alta:

Selectați * în ..tmp_tbl_deps de la ..tbl_deps

Minusul unei astfel de soluții nu este copiat indexuri.

Luați în considerare modul de organizare a două sarcini de administrare cele mai frecvent întâlnite SQL Server:

Backup automat de bază de date;
Eliminarea copiilor vechi de rezervă.

Planificarea bazelor de date de backup

Deschideți SQL Management Studio și conectați-vă la baza de date dorită. Asigurați-vă că funcționează agentul SQL Server;
Extindeți gunoiul de gestionare - Întreținere (pentru aceasta ar trebui să aveți rolul de "Sysadmin") - faceți clic dreapta și selectați "Un nou plan de întreținere";
Introduceți numele noului plan de servicii;
Faceți clic pe pictograma Calendar din dreapta în singura linie. În fereastra care se deschide, configurați timpul de execuție a sarcinii. Alegeți un moment în care baza de date este mai puțin încărcată;
Din secțiunea Setul de instrumente, trageți sarcina sarcinii bazei de date de backup către zona principală;
Faceți dublu clic pe sarcina de bază de rezervă - fereastra Setări sarcini se va deschide. copie de rezervă - Setați setările dorite;
Faceți clic pe OK - acum Backup-urile vor fi create în conformitate cu ora programată;

Îndepărtarea copiilor de rezervă veche

Deoarece fișierele de rezervă vor fi create frecvent, apoi în curând veți avea spațiu liber pe hard disk. Prin urmare, va trebui să ștergeți fișierele de rezervă depășite. Continuăm să configuram planul de servicii:

De la panoul de instrumente, trageți în zona principală a sarcinii de curățare a întreținerii;
Faceți dublu clic pe sarcina de curățare a întreținerii pentru a deschide fereastra Proprietăți. În aceasta, trebuie să determinați aspectul de rezervă, expansiunea lor și să determinați vârsta fișierelor care trebuie șterse. Bunele practici este de a stoca backup-uri de până la o lună;
Faceți clic pe OK și salvați planul de service;
Puteți mai aștepta ca următorul plan de serviciu să execute un plan de service sau să-l ruleze manual (faceți clic dreapta pe planul de service din obiectul Explorer).

Administratorii BD sunt împărțiți în cei care fac backup-uri, iar cei care vor face copii de rezervă.

Introducere

Acest articol descrie cea mai comună copie de rezervă a IB 1C utilizând instrumentele MS SQL Server 2008 R2, a explicat de ce ar trebui să se facă exact și nu altfel, mai multe mituri au dispărut. Articolul are o mulțime de referiri la documentația MS SQL, acest articol este mai probabil să revizuiască mecanismele de backup decât un manual cuprinzător. Dar pentru cei care se confruntă cu această sarcină pentru prima dată, simplă și instrucțiuni pas cu pascare sunt aplicabile situațiilor simple. Articolul este proiectat nu pentru guru de administrare, guru și astfel toate astea știu, dar se presupune că cititorul este capabil să instaleze serverul MS SQL și să facă acest miracol de tehnici ostile să creeze o bază de date în adâncurile sale, care, în rândul său, este capabil să facă datele de la 1c.

Consider că comanda de baze de date de backup TSQL (și jurnalul de backup brothup) în esență singurul mijloc de susținere a bazelor de date 1C utilizând MS SQL Server ca DBMS. De ce? Să ne uităm la ceea ce avem calea noastră:

Cum	Bine	rău	TOTAL
Descărcare la dt.	Format foarte compact.	Pentru o lungă perioadă de timp, necesită accesul monopolului, nu salvează o parte din datele nesemnificative (cum ar fi setările utilizatorilor în versiunile anterioare), extinde lungi.	Aceasta nu este atât de mult o modalitate de backup, cât de mult metoda de transfer de date de la un mediu la altul. Ideal pentru canale înguste.
Copierea fișierelor MDF și LDF	Mod foarte clar pentru administratorii începători.	Este nevoie de eliberarea fișierelor bazei de date blocante, iar acest lucru este posibil dacă baza este dezactivată (comanda de deconectare a meniului contextual) este deconectată (detașați) sau pur și simplu opriți serverul. Evident, utilizatorii nu vor funcționa în acest moment.	Această metodă are sens să se aplice dacă și numai dacă accidentul a apărut deja, astfel încât atunci când încercați să restaurați, cel puțin să puteți reveni la opțiunea de la care a început restaurarea.
Backup cu OS sau Hypervisor	Metodă convenabilă pentru medii de dezvoltare și testare.	Nu sunteți întotdeauna prietenos cu integritatea datelor. Metoda de resurse.	Se poate limita la dezvoltarea. În mediul de produs practic nu are nici un sens.
MS SQL Backup.	Nu necesită timp de întrerupere. Vă permite să restaurați o stare holistică într-un moment arbitrar, dacă vă deranjați în avans. Excelent automatizat. Economic în timp și alte resurse.	Nu este un format foarte compact. Nu toată lumea poate folosi acest lucru pentru a fi necesar.	Pentru mediile de produse - instrumentul principal.

Principalele dificultăți atunci când se utilizează backup-uri cu instalații cu MS SQL încorporate din cauza neînțelegerilor elementare a principiilor muncii. Acest lucru se explică în parte a marii leneli, parțial lipsa unei explicații simple și ușor de înțeles la nivelul "retetelor gata făcute" (Hmm, să spunem că nu am găsit) și situația este, de asemenea, agravată de fosforii mei forumurile. Ce să faci cu lenea Nu știu, dar voi încerca să explic bazele de backup.

Ce și de ce salvezi?

Cu mult timp în urmă într-o galaxie îndepărtată a existat un astfel de produs de gândire de inginerie și contabilitate, cum ar fi 1C: Enterprise 7.7. Aparent datorită faptului că primele versiuni ale 1C: întreprinderile au fost dezvoltate pentru a utiliza un format popular dBF FIES.Versiunea sa SQL nu a stocat suficiente informații în baza de date pentru a citi backupul MS SQL MS SQL și chiar și cu fiecare schimbare a structurii, au fost încălcate condițiile de funcționare a modelului de recuperare completă, așa că a trebuit să merg la diferite trucuri la forțați sistemul de rezervă pentru a vă executa funcția principală. Dar, din moment ce versiunea 8, administratorii de baze de date au putut să se relaxeze în cele din urmă. Mijloacele de backup de personal vă permite să creați un sistem de rezervă completă și holistic. Nu sunt incluse în copia de rezervă. Numai jurnalul de înregistrare și unele titluri de tip Tips ale formularelor (în versiunile mai vechi), însă această pierdere a acestor date privind funcționalitatea sistemului nu afectează, deși siguranța din jurnalul de înregistrare fac corect și util.

De ce toți avem nevoie de backup? Hmm. La prima vedere, o întrebare ciudată. Probabil, mai întâi, pentru a putea implementa o copie a sistemului și pentru a restabili în al doilea rând sistemul în timp ce eșuează? În detrimentul primului sunt de acord, dar al doilea scop este primul mit de backup.

Backup este ultima frontieră pentru a asigura siguranța sistemului. Dacă administratorul bazei de date trebuie să restabilească sistemul de produse de la backup, înseamnă că multe greșeli nepoliticoase în organizarea muncii au fost făcute cu o mare probabilitate. Este imposibil să se refere la Backup, ca mod principal de a asigura integritatea datelor, nu, este mai degrabă mai aproape de sistemul de stingere a incendiilor. Sistemul de stingere a incendiilor este necesar. Acesta trebuie să fie configurat, verificat și operațional. Dar dacă a lucrat, în sine este o urgență serioasă, cu o masă de consecințe negative.

Pentru ca copia de rezervă să fie utilizată numai "în scopuri pașnice", utilizați pentru a asigura eficiența și alte mijloace:

Oferiți securitatea fizică a serverelor: incendii, inundații, surse slabe de alimentare, curățători, constructori, meteoriți și animale sălbatice - toate așteaptă doar în colț pentru a distruge serverul.
În mod responsabil aparțin amenințărilor de securitate a informațiilor.
Calificarea face modificări ale sistemului și asigurați-vă că aceste modificări nu vor duce la deteriorare. În plus față de planul de schimbare, este recomandabil să aveți un plan "Ce să faceți dacă totul merge prost".
Utilizați în mod activ tehnologia pentru a spori disponibilitatea și fiabilitatea sistemului în loc de curse a consecințelor accidentelor. Pentru MS SQL, trebuie să plătiți următoarele opțiuni:
- Folosind clustere MS SQL (Deși sincer, cred că este una dintre cele mai scumpe și inutile modalități de a lua administratorul bazei de date pentru sisteme care nu necesită 24x7)
- Oglindirea bazei de date (în sincronă și mod asincron În funcție de cerințele accesibilității, performanței și costurilor)
- Livrarea de jurnale de tranzacții
- Replicarea prin 1c (baze de date distribuite)

În funcție de cerințele privind disponibilitatea sistemului și de la bugetul alocat în aceste scopuri, este posibil să se aleagă soluții care să permită o comandă de 1-2 pentru a reduce timpul de nefuncționare și recuperarea în timpul eșecurilor. Nu este nevoie să vă fie frică de tehnologii de accesibilitate: ele sunt suficient de simple pentru a le studia în câteva zile cu cunoștințe de bază despre MS SQL.

Dar, indiferent de ce, backup-ul este încă necesar. Aceasta este aceeași parașută de rezervă pe care o puteți utiliza atunci când toate celelalte mijloace de mântuire vor refuza. Dar, ca o adevărată parașută de rezervă, pentru aceasta:

acest sistem trebuie să fie în avans drept și calificat configurat,
un specialist acordat de sistem ar trebui să aibă competențe teoretice și practice ale utilizării sale (susținută în mod regulat),
sistemul ar trebui să fie alcătuit din cele mai fiabile și simple componente (aceasta este ultima noastră speranță).

Informații de bază privind stocarea și prelucrarea datelor MS SQL

Datele din MS SQL sunt de obicei stocate în fișierele de date (denumite în continuare PD - fără efect de tăiere, acest articol va avea mai multe abrevieri nu foarte frecvente) cu extensiile MDF sau NDF. În plus față de aceste fișiere, există încă jurnale de tranzacții (ZHT), care sunt stocate în fișiere cu extensia LDF. Adesea, administratorii novice sunt iresponsabili și se referă ușor la o cale ferată, atât în \u200b\u200bceea ce privește productivitatea, cât și în ceea ce privește fiabilitatea stocării. Aceasta este o greșeală foarte dură. De fapt, mai degrabă, dimpotrivă, dacă există un sistem fiabil de backup și o lungă perioadă de timp pentru a restabili sistemul, puteți stoca date pe raid-0 rapidă, dar extrem de nesigure, dar atunci ar trebui să fie stocate pe a Resurse separate și productive separate (deși dacă RAID-1). De ce este asta? Să luăm în considerare mai detaliat. Faceți imediat o rezervare că prezentarea este oarecum simplificată, dar suficientă pentru înțelegerea inițială.

În PD, aceste pagini de 8 kilobite sunt stocate (care sunt combinate în 64 kilobyte, dar acest lucru nu este esențial). MS SQL. nu garanteazăCă imediat după executarea comenzii de schimbare a datelor, aceste modificări vor cădea în PD. Nu, doar o pagină de memorie este marcată ca "necesită salvare". Dacă serverul are suficiente resurse, în curând aceste date vor fi pe disc. Mai mult, serverul funcționează "optimist" și dacă aceste modificări apar în tranzacție, atunci pot cădea pe disc înainte de a fixa tranzacția. Aceasta este, în general, cu activitatea activă a FD, acesta conține bucăți disparate de date afectate și tranzacții nefinalizate pentru care se cunoaște dacă vor fi anulate sau fixate. Există o comandă specială "Punct de control", care indică serverul pe care trebuie să-l "acum" pentru a reseta toate datele nemântuite de pe disc, dar domeniul de aplicare al acestei comenzi este destul de specific. Este suficient să spunem că 1c nu o folosește (nu am întâlnit) și înțeleg că în timpul funcționării, PD nu este, de obicei, într-o stare holistică.

Pentru a face față acestui haos, suntem doar necesari. Următoarele evenimente sunt scrise:

Informații despre începerea tranzacției și identificatorul acestuia.
Informații despre fixarea sau anularea tranzacției.
Informații despre toate datele se schimbă în PD (aproximativ vorbit, care a fost și ce sa întâmplat).
Informații despre schimbarea structurii FD sau a bazei de date (creșterea fișierelor, reducerea fișierelor, evidențierea și lansarea paginilor, crearea și ștergerea tabelelor și indexurilor)

Toate aceste informații sunt scrise cu o indicație a identificatorului de tranzacție în care a avut loc și în volum suficient pentru a înțelege cum de la starea la această operație, mergeți la stat după această operațiune și viceversa (excluderea este un model de recuperare a protocolului incomplet) .

Este important ca aceste informații să fie scrise imediat pe disc. Până în prezent, informațiile nu sunt înregistrate în calea ferată, echipa nu este considerată executată. Într-o situație normală, atunci când dimensiunea unui volum suficient este suficientă și atunci când nu este foarte fragmentată, înregistrările sunt scrise în mod consecvent cu înregistrări mici (nu neapărat 8 KB). În jurnalul de tranzacții, datele sunt foarte necesare pentru recuperare. În special nu Informații despre care textul interogării a condus la modificări, care este planul de execuție pentru această solicitare, care a lansat și alte informații inutile pentru a restabili informațiile. Unele ideii structurii de date a jurnalului de tranzacții poate solicita solicitarea

Selectați * de la :: fn_dblog (, null)

Datorită faptului că unitățile hard disk funcționează mult mai eficient cu o înregistrare consistentă decât cu un flux haotic de comenzi pentru citire și scriere și datorită faptului că comenzile SQL vor aștepta la sfârșitul înregistrării în WPT, se produce următoarea recomandare :

Dacă există cel puțin cea mai mică posibilitate, atunci în mediul de produs, acesta ar trebui să fie amplasat pe suportul fizic individual (de la restul), de preferință cu un timp de acces minim pentru o înregistrare secvențială și cu o fiabilitate maximă. Pentru sisteme simple, RAID-1 este destul de potrivit.

Dacă tranzacția este anulată, toate modificările introduse deja pe server vor reveni la starea anterioară. De aceea

Anularea unei tranzacții în serverul MS SQL durează, de obicei, comparabilă cu durata totală a tranzacției în sine. Încercați să nu anulați tranzacția sau să luați o decizie privind anularea cât mai curând posibil.

Dacă serverul dintr-un anumit motiv va înceta în mod neașteptat să funcționeze, atunci când începe repetarea, acesta va fi analizat care date din FD nu corespund unei stări complete (tranzacții neaplicate, dar înregistrate și înregistrate, dar au fost anulate) și aceste date vor fi corectate. Prin urmare, dacă, de exemplu, ați lansat reconstruirea indexurilor unei mese mari și a reluat serverul, atunci când reporniți, va dura un timp semnificativ pentru a relua această tranzacție și nu există posibilitatea întreruperii acestui proces.

Ce se întâmplă când a ajuns la sfârșitul fișierului? Totul este simplu - dacă există un loc eliberat la început, el va începe să scrie într-un loc liber la începutul dosarului într-un loc aglomerat. Ca o bandă magnetică de fulgi. Dacă nu există niciun loc la început, serverul va încerca de obicei să extindă fișierul jurnal de tranzacții, în timp ce piesa nouă selectată este un nou fișier jurnal de tranzacții virtuale, care poate fi foarte mult în fișierul de tranzacții fizice, dar acest lucru nu este suficient la Backup. Dacă serverul nu reușește să extindă fișierul (locația este pe disc sau este interzisă de setări pentru ao extinde, atunci tranzacția curentă va anula eroarea 9002.

Oops. Și ce ar trebui făcut în locul în Zht, a fost întotdeauna? Aici am ajuns la sistemul de backup și la modelele de recuperare. Pentru a anula tranzacțiile și pentru a restabili starea corectă a serverului, în cazul unei opriri bruște, este necesar să se păstreze într-o înregistrare Zht, începând de la începutul celor mai vechi tranzacții deschise. Acest minim este scris și stocat în Zht inainte de. Indiferent de vreme, setările serverului și dorința administratorului. Serverul nu poate permite ca aceste informații să fie. Prin urmare, dacă deschideți o tranzacție într-o singură sesiune, iar în altele pentru a efectua acțiuni diferite, jurnalul de tranzacții se poate încheia în mod neașteptat. Cea mai veche tranzacție poate fi dezvăluită de comanda DBCC OpenRAN. Dar este doar minimul necesar de informații. Depinde în continuare modele de recuperare. În serverul SQL trei dintre ele:

Simplu (simplu) - Este stocat numai pentru restul șinei curelelor.
Plin (plin) - Este stocat totul din momentul ultimului backup magazine de tranzacții. Notă, nu de la backupul complet!
Vrac înregistrat (cu înregistrare incompletă) - Operațiile (foarte mici, de obicei, parțial) sunt scrise într-un format foarte compact (de fapt, numai înregistrarea este că pagina fișierului de date este modificată). Altfel, plin este identic.

Mai multe mituri sunt asociate cu modele de recuperare.

Simplu vă permite să reduceți sarcina pe subsistemul disc. Nu este adevarat. Este scris exact la fel de mult ca și în cazul înregistrat în vrac, este considerat doar gratuit mult mai devreme.
Înregistrarea în vrac vă permite să reduceți sarcina pe subsistemul disc. Pentru 1c, este aproape greșit. În esență, una dintre puținele operațiuni care pot fi supuse înregistrării minime fără dansuri suplimentare - încărcarea datelor de la descărcarea în format DT și tabele de restructurare.
Când utilizați modelul înregistrat în vrac, unele operații nu se încadrează într-o copie de rezervă a jurnalului de tranzacții și nu vă permite să restaurați statul în momentul acestui lucru backup. . Acest lucru nu este așa. Dacă operația se referă la logo-ul minim, atunci backupul va include pagini curente cu date și va fi posibilă "pierde" jurnalul tranzacțiilor tranzacțiilor până la sfârșit (deși este imposibil pentru un moment arbitrar în timp dacă există minim Operațiuni de logo).

Modelul înregistrat în vrac pentru baza 1c este aproape lipsit de sens, așa că nu îl considerăm mai departe. Dar alegerea între plină și simplă va lua în considerare mai detaliat în partea următoare.

Tranzacție de formare a jurnalului
- Modele de recuperare și gestionarea revistei de tranzacții
- Managementul jurnalului de tranzacții
Utilizați copii de rezervă ale jurnalelor de tranzacții

Funcționarea principală a rețelei în modele simple și complete de recuperare

După tipul de formare, copiile de backup sunt trei specii:

DEPLIN (Deplin)
Diferenţial (Diferența, diferență)
Buturuga. (Backup de jurnale de tranzacții, dat, cât de des se utilizează acest termen, vom tăia la RCCT)

Este necesar să nu vă confundați aici: modelul de recuperare completă și backupul complet este în esență lucruri diferite. Pentru a nu le confunda, mai jos voi folosi termenii englezi pentru modelul de recuperare și vorbind rus pentru tipurile de backup.

Lucrarea completă și diferențială a copiilor este la fel de simplă și plină. O copie de rezervă a jurnalelor de tranzacții este complet absentă în simplă.

Backup complet

Vă permite să restaurați starea bazei de date la un moment dat (la cea în care a început formarea de rezervă). Se compune dintr-o copie de pagină a datelor utilizate o parte a fișierelor de date și o bucată de tranzacție activă în timpul formării backup-ului.

Diferite backup

Stochează paginile de date care s-au schimbat de la ultima copie de rezervă completă. La restabilirea, trebuie să restabiliți mai întâi backupul complet (în modul Norecovery, exemplele vor fi afișate mai jos), apoi puteți aplica oricare dintre diferențele ulterioare copiilor la "billetul" rezultat, dar, desigur, numai acelea care sunt făcute înainte de următoarea copie de rezervă completă. Datorită acestui fapt, este posibil să se reducă semnificativ volumul spațiului pe disc pentru depozitarea copierii de rezervă.

Momente importante:

Fără copia de rezervă completă, diferența este inutilă. Prin urmare, este de dorit să le stocați undeva unul lângă celălalt.
Fiecare copie de diferență ulterioară va stoca toate paginile incluse în diferența de backup anterior, realizată după completa anterioară (deși, poate cu un alt conținut). Prin urmare, fiecare copie de diferență următoare este mai mult decât cele anterioare, în timp ce nu este o copie completă (dacă este ruptă, numai din cauza algoritmilor de compresie)
Pentru restaurare la un moment dat suficient cele mai recente Backup complet în acest moment și cele mai recente Diferența de copie în acest moment. Copiile intermediare pentru recuperare nu sunt necesare (deși pot fi necesare pentru a selecta cuplul de recuperare)

Rkjt.

Conține o copie a acesteia pentru o anumită perioadă. De obicei din momentul ultimului RCCT până la formarea RCCT curent. RCCT permite copiilor restaurate în modul NoreCovery în orice moment primind în timpul perioadei de recuperare, restabiliți statul la orice punct ulterior în momentul intrării în intervalul copiei recuperabile de rezervă. Când formați o copie de rezervă cu parametri standard, locația din fișierul jurnal de tranzacții este lansată (până la ultima tranzacție deschisă).

Evident, RCHT nu are sens în modelul simplu (atunci FP conține numai informații de la ultima tranzacție deblocată).

Când se utilizează RCCT, apare un concept important - lanțul continuu al RCUT.. Acest lanț poate întrerupe fie pierderea unor copii de rezervă ale acestui lanț, fie transferați baza de date în simplă și înapoi.

Atenție: Un set de RCCT este în esență inutil dacă nu este un lanț continuu, iar momentul de început al ultimului backup plin sau diferență ar trebui să fie interiorperioada acestui lanț.

Concepții greșite și mituri frecvente:

"RCCT conține date privind jurnalul de tranzacții din momentul rezervării precedente complete sau diferențe". Nu Nu este. RCCT conține la prima vedere, date inutile între RCCT anterior și copierea completă ulterioară.
"Backup complet sau diferență trebuie să conducă la eliberarea spațiului în jurnalul de tranzacții".Nu Nu este. Backup complet și diferențe Nu atingeți lanțul RCCT.
Zht trebuie să fie efectuat manual pericol, reduce, se micșorează.Nu, nu este necesar, și chiar dimpotrivă, este nedorită. Dacă îl eliberați între RKJT, atunci lanțul RCCT este afectat, ceea ce este necesar pentru recuperare. Iar reducerea / extinderea constantă a fișierului va duce la fragmentarea fizică și logică.

Cum funcționează în mod simplu

Să existe o bază de date cu 1000 GB. În fiecare zi, baza crește la 2 GB și se schimbă 10 GB de date vechi. A făcut următoarele backup-uri

Copie completă F1 de la 0:00 pe 1 februarie (volum de 1000 GB, nu luați în considerare compresia pentru simplitate)
- Diferența Copie D1.1 de la 0:00 2 februarie (12 GB)
- Diferența copie D1.2 de la 0:00 pe 3 februarie (volum 19 GB)
- Diferența copie D1.3 de la 0:00 4 februarie (volum de 25 GB)
- Diferența copie D1.4 de la 0:00 pe 5 februarie (volumul 31 GB)
- Diferența copie D1.5 de la 0:00 6 februarie (volumul 36 GB)
- Diferența copie D1.6 de la 0:00 pe 7 februarie (volum de 40 GB)
Copie completă F2 de la 0:00 pe 8 februarie (volumul 1014 GB)
- O diferență de copie a D2.1 de la 0:00 pe 9 februarie (volum de 12 GB)
- O diferență de copie a D2.2 de la 0:00 10 februarie (volum 19 GB)
- O diferență de copie a D2.3 de la 0:00 11 februarie (volum de 25 GB)
- O diferență de copie a D2.4 de la 0:00 12 februarie (volumul 31 GB)
- Digal Copie D2.5 de la 0:00 pe 13 februarie (Volumul 36 GB)
- O diferență de copie a D2.6 de la 0:00 14 februarie (volum de 40 GB)

Cu acest set, putem restabili datele la ora 0:00 din orice zi de la 1 la 14 februarie. Pentru a face acest lucru, trebuie să luăm o copie completă a F1 pentru o săptămână de 1-7 februarie sau o copie completă a F2 pentru 8-14 februarie, restaurează-l în modul Norecovery și apoi aplicați o diferență de copie a zilei potrivite.

Cum funcționează în întregime

Să avem același set de backup-uri complete de rezervă și diferență, ca în exemplul anterior. În plus față de aceasta sunt următoarele RCCT:

RKJT 1 pentru perioada 12:00 la 31 ianuarie - 12:00 pe 2 februarie (aproximativ 30 GB)
RKJT 2 pentru perioada 12:00 2 februarie la 12:00 pe 4 februarie (aproximativ 30 GB)
RKJT 3 pentru perioada 12:00 la 4 februarie la 12:00 6 februarie (aproximativ 30 GB)
RKJT 4 pentru perioada 12:00 6 februarie la 12:00 pe 7 februarie (aproximativ 30 GB)
RKJT 5 pentru perioada 12:00 la 8 și 12:00 10 februarie 10 (aproximativ 30 GB)
RKJT 6 pentru perioada 12:00 10 februarie la 12:00 12 februarie (aproximativ 30 GB)
RKJT 7 pentru perioada 12:00 12 februarie la 12:00 14 februarie (aproximativ 30 GB)
RKJT 8 pentru perioada 12:00 14 februarie la 12:00 16 februarie (aproximativ 30 GB)

Notă:

Dimensiunea RCCT va fi aproximativ constantă.
Copii de rezervă Putem face mai rar decât diferență sau completă și pot și mai des, atunci vor fi mai puțin în dimensiune.
Acum putem restabili statutul de sistem în orice moment de la 0:00 pe 1 februarie, când avem cea mai veche copie completă a 12:00 pe 16 februarie.

În cel mai simplu caz, trebuie să restaurăm:

Ultima copie completă până la restaurare
Ultima diferență copie înainte de recuperare
Toate RCCT, din ultima diferență de copiere înainte de restaurare

Copie completă F2 de la 0:00 8 februarie
O diferență de copie a D2.2 de la 0:00 10 februarie
RKJT 6 pentru perioada 12:00 pe 10 ianuarie - 12:00 12 februarie 12

În primul rând, F2 va fi restaurat, apoi D2.2, atunci rkt 6 până în momentul 13:13:13 10 februarie. Dar avantajul esențial al modelului complet este că avem o alegere - folosiți cea mai recentă copie completă sau diferență sau nu ultima. De exemplu, dacă sa constatat că o copie a D2.2 a fost răsfățată și trebuie să ne recuperăm la ora 13:13:13 10 februarie, apoi pentru modelul simplu ar însemna că putem restabili datele numai la Timpul D2.1. Cu plin - "Don" T Panic ", avem următoarele caracteristici:

Restaurați F2, apoi mai târziu D2.1, atunci rkjt 5, apoi atunci rcs 6 până la momentul 13:13:13 10 februarie.
Restabiliți F2, apoi RCCT 4, apoi RKJT 5, apoi mai târziu RKLC 6 până la 13:13 februarie 10.
Sau chiar restabiliți F1 și conduceți toate RCCT la RCCT 6 până la 13:13:13 10 februarie.

După cum puteți vedea, modelul complet ne oferă o alegere mai mare.

Și acum imaginați că suntem foarte vicleni. Și câteva zile înainte de eșec (13:13:13 10 februarie) Știm că eșecul va fi. Reducem baza de date de la backupul complet pe serverul următor, lăsând ocazia de a aplica statele ulterioare prin diferențe de copii sau RCCT, adică stânga în modul NoreCovery. Și de fiecare dată imediat după formarea RCCT, îl folosim în această bază de date de backup, plecând în modul NoreCovery. Wow! De ce, pe recuperarea bazei de date, acum vom ieși doar 10-15 minute, în loc de a restabili o bază imensă! Felicitări, am consolidat mecanismul de livrare a jurnalului, una dintre modalitățile de a reduce timpul de nefuncționare. Dacă este posibilă transmiterea datelor mai mult decât o dată în perioada, dar în mod constant, va fi deja oglindire și dacă sursa de bază așteaptă oglinda de bază, atunci aceasta este oglindire sincrone, dacă nu așteptați, apoi asincronă.

Mai multe informații despre disponibilitatea ridicată pot fi citite în ajutor:

Disponibilitate ridicată (componenta motorului bazei de date)
- Informații generale despre soluții cu disponibilitate ridicată
- Valabilitate ridicată. Interacțiune și colaborare

Alte aspecte de backup

Această secțiune poate fi omisă în condiții de siguranță dacă teoria și mâinile sunt plictisite de dvs. pentru a testa setările de rezervă.

Grupuri de fișiere

1c: Compania este în mod esențial capabilă să lucreze cu grupuri de fișiere. Există un singur grup de fișiere și asta este. De fapt, programatierul sau administratorul bazei de date MS SQL este capabil de câteva mese, indexuri sau chiar bucăți de tabele și indexuri pentru a pune în grupuri de fișiere separate (în cea mai simplă versiune - în separați fișierele). Este necesar fie pentru a accelera accesul la unele date (punerea pe medii foarte rapide), fie invers, sacrificând viteza care trebuie plasată pe medii mai ieftine (de exemplu, date cu conținut scăzut, dar voluminoase). Când lucrați cu grupuri de fișiere, există o oportunitate de a-și face rezervele separat, este, de asemenea, posibil să îl restabiliți separat, dar trebuie să vă gândiți că toate grupurile de fișiere vor trebui să "recupereze" într-un moment la RCCT RCCT.

Fișiere de date.

Dacă o persoană controlează datele către date în diferite grupuri de fișiere, atunci când există mai multe fișiere în cadrul grupului de fișiere, atunci datele de pe ele se scufundă independent MS SQL Server (cu o linie egală de fișiere - va încerca uniform). Din punct de vedere aplicat, acesta este utilizat pentru paralele cu acțiunile I / O. Și din punct de vedere de rezervă există un alt moment. Pentru bazele de date foarte mari în epocă "la SQL 2008" a fost problema tipică Selectați o fereastră continuă pentru o copie de rezervă completă, iar discul receptorului pentru această copie de rezervă ar putea pur și simplu să nu îl găzduiască. Cel mai. calea usoara În acest caz, a fost copia de rezervă a fiecărui fișier (sau grup de fișiere) la fereastra dvs. Acum, cu distribuția activă a compresiei de rezervă, această problemă a devenit mai mică, dar totuși această tehnică poate fi suportată.

Compresie de rezervă

MS SQL Server 2008 are o caracteristică super mega-ultra. De acum înainte, copiile de backup pot fi comprimate atunci când se formează în zbor. Acest lucru reduce dimensiunea backup-ului BD 1C de 5-10 ori. Și având în vedere că, de obicei, performanța subsistemului de disc este o blocare a DBMS, nu numai o scădere a costului de stocare, ci și o accelerație puternică de backup (deși crește sarcina pe procesoare, dar de obicei puterea procesorului este destul de suficientă pe serverul DBMS).

Dacă în versiunea 2008 această caracteristică a fost doar pentru Enterprise Edition (care este foarte scumpă), apoi în 2008 R2 Această caracteristică este dată versiunii standard, care este foarte mulțumită.

Mai jos, la analiza exemplelor, setările de compresie nu sunt luate în considerare, dar vă recomandăm cu tărie utilizarea copiilor de backup dacă nu există motive speciale pentru ao dezactiva.

Un fișier de rezervă - multe stagii

De fapt, backupul nu este doar un fișier, este un recipient destul de complicat în care pot fi stocate multe copii de rezervă. Această abordare are o poveste foarte veche (am observat personal de la versiunea 6.5), dar în momentul de date a administratorilor de baze de date "obișnuite", în special baze de date 1C, nu există motive serioase pentru utilizarea "One Backup - un fișier". Pentru dezvoltarea generală, este util să explorați capacitatea de a pune mai multe copii de rezervă într-un singur fișier, dar este cel mai probabil să nu îl utilizați (sau dacă trebuie să utilizați, apoi dezasamblați loviturile de administrator de ecartament, pe care această caracteristică a fost necalificat).

Mai multe copii oglindă

Serverul SQL are o altă ocazie minunată. Puteți forma o copie de rezervă pentru a forma paralel cu mai multe receptoare. Cum cel mai simplu exemplu, puteți arunca o copie pe disc local Și, în același timp, se îndreaptă spre o resursă de rețea. Copia locală este convenabilă, deoarece recuperarea de la acesta este semnificativ mai rapidă, o copie de la distanță este mult mai bună pentru a amâna distrugerea fizică a serverului principal de bază de date.

Exemple de sisteme de backup

Destul de teorie. Este timpul ca practicarea de a dovedi că toate aceste lucrări de bucătărie funcționează.

Configurarea copiilor de rezervă tipică a serverului prin planurile de service (întreținerePlan)

Această secțiune este construită ca rețete gata făcute cu explicații. Această secțiune este foarte plictisitoare și lungă din cauza imaginilor, astfel încât să puteți săriți.

Folosim serviciul planului de creație de masterat

Configurarea serverului Backups TsQL Scripts, Exemple de anumite caracteristici

Imediat apare întrebarea și de ce încă? Se pare că este doar configurat și totul funcționează ca un ceas? De ce să începeți cu tot felul de scripturi? Planurile de servicii nu permit:

Utilizați rezervarea oglindă
Utilizați setările de compresie, altele decât setările serverului
Nu permite să răspundă în mod flexibil la situațiile emergente (fără oportunități de manipulare a erorilor)
Nu permite utilizarea flexibilă a utilizării de securitate
Planurile de servicii sunt foarte incomode (și mențin același lucru) cantitati mari Servere (chiar poate deja pe 3-4)

Mai jos sunt comenzile tipice de backup.

Backup complet

O copie de rezervă completă, cu o consolidare a unui fișier existent (dacă există) și verificarea verificării paginilor înainte de înregistrare. Când formați o copie de rezervă, fiecare procent de progres este programat

Backup Baza de date la disc \u003d n "C: \\ backup \\ mydb.bak" cu init, format, statistici \u003d 1, controlul de verificare

Diferite backup

În mod similar - o copie de diferență

Backup Baza de date la disc \u003d n "C: \\ backup \\ mydb.diff" cu Diferenţial, Init, format, statistici \u003d 1, suma de control

Rkjt.

Backup de jurnal de tranzacții

Jurnal de backup la disk \u003d n "C: \\ backup \\ mydb.trn" cu init, format

Rezervare în oglindă

Este adesea convenabil să faceți o copie de rezervă non-una imediat, dar două. De exemplu, se poate afla la nivel local pe server (pentru a fi la îndemână), iar al doilea se formează imediat la telecomandă fizică și protejată împotriva stocării adverse de stocare:

Backup Baza de date la disc \u003d n "C: \\ backup \\ mydb.bak", Oglindă. Disk \u003d N "\\\\ Safe-server \\ backup \\ mydb.bak" cu init, format

Un punct important care este adesea trecut cu vederea: utilizatorul, în numele căruia începe procesul Server MSSQL ar trebui să fie acces la resursa "\\\\ Safe Server \\ Backup, altfel copierea se va încheia cu o eroare. Dacă serverul MSSQL rulează în numele sistemului, atunci accesul trebuie să fie administrat Domeniului User_name Group, dar este mai bine să configurați corect lansarea MS SQL în numele unui utilizator special creat.

Dacă nu specificați oglinda, nu va fi 2 copii de oglindă, ci o copie, ruptă în 2 fișiere, în conformitate cu principiul alternanței. Și fiecare dintre ele este inutil individual.

Serverele de bază de date sunt unele dintre cheile oricărei organizații. Aceștia stochează informații și oferă emiterea la cerere și este extrem de importantă menținerea bazei de date în orice situație. Livrarea de bază include, de obicei, utilitățile necesare, dar administratorul, care nu se confruntă cu baza de date, va trebui să se ocupe de ceva timp cu caracteristicile de lucru pentru a oferi automatizarea.

Tipuri de backup-uri de baze de date

Pentru a începe cu, ne vom ocupa de modul în care există copii de siguranță. Serverul de baze de date nu este o aplicație obișnuită desktop și să se asigure că toate proprietățile acide sunt executate (atomic, consistență, izolate, durabile), se utilizează o serie de tehnologii și, prin urmare, crearea și recuperarea BD din arhivă are caracteristicile proprii. Există trei abordări diferite pentru datele de backup, fiecare dintre acestea având avantajele și contra.

Cu un logic sau SQL, Backup (Pg_dump, Mysqldump, SQLCMD), o imagine instantanee a conținutului de conținut este creată pe baza integrității tranzacționale și este salvată ca fișier cu comenzi SQL (puteți selecta întreaga bază sau tabele individuale), Cu care puteți recrea baza de date pe un alt server. Acest lucru necesită timp (în special pentru bazele de date mari) pentru a salva și restabili, deci este foarte des posibilă efectuarea acestei operații și se efectuează în timpul încărcării minime (de exemplu, pe timp de noapte). La recuperarea administratorului, va trebui să executați mai multe comenzi pentru a pregăti tot ce aveți nevoie (creați o bază de date goală, conturi etc).

Backup fizic (nivel sistemul de fișiere) - Copierea fișierelor pe care DBMS le folosește pentru stocarea datelor în baza de date. Dar, la copierea simplă, blocările și tranzacțiile sunt ignorate, care sunt susceptibile de a fi salvate și încălcate incorect. Când încercați să atașați acest fișier, acesta va fi într-o stare inconsecventă și va duce la erori. Pentru a obține backup-ul curent, trebuie să opriți baza de date (puteți reduce timpul inactiv folosind de două ori RSYNC - mai întâi pe unul de lucru, apoi pe oprit). Dezavantajul acestei metode este evident - este imposibil să restabilim anumite date, doar întreaga bază de date. Când porniți baza de date restaurată din arhiva sistemului de fișiere, va trebui să verificați integritatea. Există diferite tehnologii auxiliare. De exemplu, în postgreSQL, WAL (scrieți jurnalele înainte) jurnale proactive și funcție specială (Punct de recuperare a timpului - PITR), care vă permite să reveniți la o anumită stare a bazei de date. Cu ajutorul lor, al treilea scenariu este implementat cu ușurință atunci când backupul nivelului de sistem de fișiere este combinat cu o copie de rezervă a fișierelor WAL. În primul rând, restaurați fișierele de rezervă ale sistemului de fișiere și apoi cu WAL, baza este furnizată starea curentă. Aceasta este o abordare de administrare ușor mai complexă, dar nu există probleme cu integritatea bazei de date și de restabilirea bazelor până la un anumit timp.

Backupul logic este utilizat în cazurile în care este necesar să faceți o copie completă a bazei de date sau în utilizarea de zi cu zi pentru a crea o copie, nu veți avea nevoie de mult timp sau loc. Când descărcarea de bază durează mult timp, trebuie acordată atenție arhivării fizice.

Barman.

Licență: GNU GPL.

DBMS acceptate: Postgresql.

PostgreSQL sprijină posibilitățile unei backup fizice și logice, adăugând un alt nivel Wal (vezi Insert), care poate fi numit copiere continuă. Dar pentru a gestiona cu ajutorul instrumentelor standard, mai multe servere nu sunt foarte convenabile chiar și adminul cu experiența, iar în caz de eșec, proiectul de lege merge timp de câteva secunde.

Barman (manager de backup și recuperare) - Dezvoltarea internă a companiei 2ndquadrant furnizează servicii pentru baza de date postgresql.. Proiectat pentru backupul fizic postgreSQL (logic nu acceptă), arhivarea și recuperarea rapidă după eșecuri. Backup de rezervă și restaurarea mai multor servere sunt acceptate, caracteristici de recuperare în timp (PITR), control WAL. Pentru a copia și trimite comenzi la un nod la distanță, ssh, sincronizare și backup utilizând RSYNC vă permite să reduceți traficul. Barman este, de asemenea, integrat cu standardul BZIP2, GZIP, GAR și similare. În principiu, puteți utiliza orice program de compresie și arhivare, integrarea nu durează prea mult timp. Sunt implementate diferite funcții de service și diagnosticare care vă permit să monitorizați starea serviciului și să ajustați lățimea de bandă. Scripturile pre / post sunt acceptate.

Barman este scris în Python, managementul politicii de backup se realizează utilizând un fișier clar Barman.Conf InI care poate fi în / etc sau directorul de acasă al unui utilizator. În livrare vine template gata Cu comentarii detaliate în interior. Funcționează numai pe * nix-sisteme. Pentru a instala în Rell, Centos și Științific Linux, Conectați EPEL - depozitul în care este conținut. pachete suplimentare. Utilizatorii debian / ubuntu au un depozit oficial:

$ sudo apt-get instalare barman

În depozit nu este întotdeauna ultima versiunePentru instalarea sa va trebui să se adreseze textelor sursă. Dependențele sunt un pic și înțeleg procesul este ușor.

Sypex Dumper.

Licență: BSD.

DBMS acceptate: Mysql.

MySqldump, utilitățile MySqlhotCopy sunt furnizate împreună cu MySQL, permițându-vă să creați cu ușurință o dumpă de bază de date, ele sunt bine documentate, iar pe Internet puteți găsi un număr mare de exemple și frontare gata făcute. Acesta din urmă permite un novice să înceapă rapid munca. Sypex Dumper este un script PHP care vă permite să creați și să restabiliți cu ușurință o copie a bazei de date MySQL. A fost creată pentru a lucra cu baze de date mari, funcționează foarte repede, clar și convenabil de utilizat. Abilitatea de a lucra cu obiecte MySQL - prezentări, proceduri, funcții, declanșatoare și evenimente.

Un alt plus, spre deosebire de alte instrumente, atunci când exportați transcodarea producătoare la UTF-8, în autobasculantă, exporturile sunt efectuate în codificarea nativă. Fișierul rezultat ia mai puțin spațiu, iar procesul în sine se întâmplă mai repede. Într-o deplasare, pot exista obiecte cu codificări diferite. Mai mult decât atât, este ușor de importat / exportat pentru a produce în mai multe etape, oprirea procesului în timpul încărcării. Când este reînnoită, procedura va începe din locația opririi. La recuperare, sunt acceptate patru opțiuni:

Creați + Insert - modul de recuperare standard;
Trunchate + insert - mai puțin timp pentru a crea tabele;
Înlocuiți - restabilim datele vechi în baza de date de lucru, fără a influența noi;
Introduceți Ignore - adăugați date șterse sau noi în baza de date, fără a atinge cele existente.

O compresie de copiere este menținută (GZIP sau BZIP2), se menține data de automobile a copiilor de rezervă, conținutul fișierului de depozit este implementat, restabiliți numai structura tabelelor. Există, de asemenea, funcții de gestionare a bazelor de date (crearea, ștergerea, verificarea, restaurarea bazei de date, optimizarea, tabelele de curățare, lucrul cu indexuri și alte), precum și un manager de fișiere care vă permite să copiați fișiere pe server.

Gestionarea este efectuată utilizând un browser web, o interfață cu utilizarea AJAX este localizată din cutie și creează impresia de a lucra cu o aplicație desktop. De asemenea, este posibil să se desfășoare sarcini din consola și pe program (prin Cron).

Basculantă va avea nevoie de un server clasic L | WAMP, setând uzualul pentru toate aplicațiile scrise în PHP (copiați fișiere și drepturi de instalare) și nu va fi dificil chiar și pentru începători. Proiectul oferă documentații detaliate și tutoriale video care demonstrează că lucrează cu autobasculante Sypex.

Există două ediții: Sypex Dumper (gratuit) și pro (10 dolari). Al doilea are mai multe oportunități, toate diferențele sunt afișate pe site.

SQL Backup și FTP

Licență:

DBMS acceptate: MS SQL Server.

MS SQL Server este una dintre soluțiile populare și, prin urmare, se găsește adesea. Sarcina de backup este creată utilizând mediul SQL Server Management Studio, Transact-SQL și cmdletele modulului SQL PowerShell (Backup-SQLDATABASE). Pe site-ul MS puteți găsi doar o cantitate mare documentație care vă permite să vă ocupați de proces. Documentația, deși completă, dar foarte specifică, iar informațiile de pe Internet se contrazic reciproc. Newcomerul într-adevăr va trebui să fie accesat ", prins o mână", deci, chiar în ciuda tuturor celor de mai sus, dezvoltatorii terților Există unde să se întoarcă. în plus versiune gratuită. SQL Server Express nu are unelte de backup încorporate. Pentru versiunile anterioare ale doamnei SQL (până în 2008), puteți găsi utilități gratuite, cum ar fi SQL Server Backup, dar în majoritatea acestor proiecte au fost deja comercializate, deși oferă toate funcționalitățile adesea pentru suma simbolică.

De exemplu, dezvoltarea de backup SQL și FTP și un dispozitiv de restaurare SQL cu un singur clic corespunde principiului "Configurat și uitat". Posedând o interfață foarte simplă și ușor de înțeles, vă permit să creați copii ale bazelor de date MS SQL Server (inclusiv Express) și Azure, salvați criptate și fișiere comprimate. pe ftp i. servicii cloud (Dropbox, caseta, Google Drive., MS SkyDrive sau Amazon S3), rezultatul poate fi vizualizat imediat. Este posibil să începeți procesul atât manual, cât și la program, trimiterea unui mesaj despre rezultatul unui loc de muncă prin e-mail, lansând scripturi de utilizator.

Toate variantele de backup sunt acceptate: jurnal complet, diferențial, tranzacții, copierea dosarelor de fișiere și dimineața. Backup-urile vechi sunt îndepărtate automat. Pentru a conecta K. nod virtual. SQL Management Studio este utilizat, deși pot exista nuanțe aici și nu va funcționa în toate aceste configurații. Pentru descărcare, sunt oferite cinci versiuni - de la GRATUIT GRATUIT la viața profesională tăiată (la momentul scrierii acestor rânduri costă doar 149 USD). Funcția liberă este destul de suficient pentru rețelele mici în care sunt instalate unul sau două servere SQL, toate funcțiile majore sunt active. Numărul de baze de date de backup este limitat, capacitatea de a trimite fișiere către Google Drive și SkyDrive și de criptare a fișierelor. Interfața este, deși nu este localizată, dar chiar și noul venit este înțeles foarte simplu. Trebuie doar să vă conectați la serverul SQL, după care va fi afișată o listă de baze de date, trebuie să vizitați accesul dorit, configurați accesul la resursele la distanță și să specificați timpul de execuție a sarcinii. Și toate astea într-o singură fereastră.

Dar există unul "dar". Programul în sine nu este destinat restabilirii arhivelor. Aceasta oferă un utilitar separat cu un singur clic SQL Restore, înțelegând formatul creat de comanda bazei de date Backup. Admin Este necesar doar să specificați arhiva și serverul pentru a restabili datele și apăsați un singur buton. Dar, în scenarii mai complexe, va trebui să folosească restabilirea.

Caracteristicile de backup MS SQL Server

Crearea unei backup și recuperarea DBMS are diferențele care trebuie luate în considerare, în special în multe ori atunci când transferă arhiva la un alt server. De exemplu, vom analiza unele nuanțe ale serverului MS SQL. Pentru a arhiva utilizând TRANSACT-SQL, utilizați comanda bazei de backup (există o valoare diferențiere de diferență) și jurnalul de tranzacții de backup.

Dacă backupul este extins pe un alt server, trebuie să vă asigurați că există aceleași discuri logice. Ca o opțiune - puteți înregistra manual căile corecte pentru fișierele bazei de date utilizând comanda de bază de date cu opțiunea Move.

Situația simplă - Backup și transfer de baze de date către alte versiuni 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ă. Și există o limitare: mai nou nu mai mult de două versiuni. După recuperarea bazei de date va fi în modul de compatibilitate cu versiunea cu care a fost efectuată tranziția, adică noile caracteristici vor fi indisponibile. Este ușor de rezolvat prin schimbarea compatibilității_level. Puteți face acest lucru folosind un GUI sau SQL.

Alter Baza de date MyDB set compatibilitate_level \u003d 110;

Pentru a determina ce versiune a fost creată o copie, puteți vizualiza antetul fișierului de arhivă. Să nu experimentezi la trecerea la versiune noua SQL Server Ar trebui să conduceți un utilitar gratuit Microsoft Upgrade Advisor.

Iperius.

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

DBMS acceptate: Oracle 9-11, Xe, MySQL, Mariadb, Postgreql și MS SQL Server

Când trebuie să gestionați mai multe tipuri de DBMS, nici o combinație nu face. Alegerea este mare. De exemplu, IPerius este un program ușor, foarte ușor de utilizat și simultan puternic pentru copierea de rezervă a fișierelor având o funcție de baze de date de rezervă fierbinte fără a întrerupe funcționarea sau blocarea. Oferă completă sau bacupul incremental.. Poate crea imagini complete pe disc pentru a reinstala automat întregul sistem. Suportă Backup la NAS, Dispozitive USB, Streamer, FTP / FTPS, Google Drive, Dropbox și SkyDrive. Suporta compresia ZIP fără limitare în dimensiunea fișierelor și criptarea AES256, lansând scripturi și programe externe. Include un programator de sarcini foarte funcționale, eventual executarea paralelă sau secvențială a mai multor sarcini, rezultatul este trimis la e-mail. Sunt acceptate numeroase filtre, variabile pentru personalizarea căilor și a setărilor.

Abilitatea de a descărca pe FTP facilitează actualizarea informațiilor despre mai multe site-uri web. Deschideți fișiere Rezervat utilizând tehnologia VSS (copierea în umbră a volumelor), care permite copierea fierbinte a nu numai fișierele DBMS, ci și alte aplicații. Oracle implică, de asemenea, organizația RMAN de backup și recuperare (manager de recuperare). Pentru a nu supraîncărca canalul, este posibilă ajustarea lățimii de bandă. Rezervarea și gestionarea recuperării se efectuează utilizând consola locală și web. Toate funcțiile în vedere, prin urmare, pentru a configura sarcina, veți avea nevoie doar de o înțelegere a procesului, documentația nu trebuie să analizeze documentația. Urmați instrucțiunile expertului. De asemenea, puteți nota managerul de cont, care este foarte convenabil cu un număr mare de sisteme.

Funcțiile de bază sunt disponibile gratuit, dar abilitatea de a rezerva baza de date este pusă numai în versiuni de DB avansate și complete. Suportă instalarea de la XP la Windows Server 2012.

Handy Backup.

Licență:comercial

DBMS acceptate:Oracle, MySQL, IBM DB2 (7-9.5) și MS SQL Server

Unul dintre cele mai puternice sisteme de management relațional - IBM DB2, având funcții unice de scalare și suportând 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. BACUP este foarte simplu:

DB2 eșantion DB DB

Sau instantanee utilizând servicii avansate de copiere (ACS):

DB2 Backup DB Exemple de utilizare Snapshot

Dar trebuie să vă amintiți că, în cazul instantaneelor, nu putem restabili mesele individuale (DB2 Recover DB). Există oportunități de backup automat și multe altele. Produsele sunt bine documentate, deși conducerea în internetul de limbă rusă este rareori găsită. De asemenea, de la toate soluțiile speciale pot fi găsite suport pentru DB2.

De exemplu, Backup Handy vă permite să efectuați o copie de rezervă a mai multor tipuri de servere de bază de date și să salvați fișiere aproape la orice suport media ( hDD., CD / DVD, Stocare înnorat și Network, FTP / S, WebDAV și altele). Posibile baze de date de backup prin ODBC (numai tabel). Aceasta este una dintre puținele soluții care acceptă DB2 și are, de asemenea, logo-ul "Gata pentru IBM DB2 Server Software". Întreaga procedură se efectuează utilizând un expert obișnuit, în care trebuie doar să selectați elementul dorit și să formați o sarcină. Procesul de configurare în sine este atât de simplu încât noul venit va fi capabil să înțeleagă. Puteți crea mai multe locuri de muncă care vor începe în program. Rezultatul este fixat în jurnal și trimis prin e-mail. În timpul sarcinii, opritorul de serviciu nu este necesar. Arhiva este comprimată și criptată automat, ceea ce garantează siguranța acestuia.

DB2 acceptă două versiuni ale rețelei de backup-office Handy (locale) și servere (rețea). Lucrări pe computerele care rulează Win8 / 7 / Vista / XP sau 2012/2008/2003. Procesul de implementare în sine nu este eliberat pentru niciun admin.

sqlcmd -s declserver \\ sqlgtd -e -q "Declara @s Varchar (255) Set @ S \u003d 'E: \\ backup \\ gtd_' + convertire (Varchar (1), Datepart (DW, GetDate ())) +". Backup Backup GTD la disc \u003d @s cu init, NOFORMAT, SKIP, Nounload »

sqlcmd. Vă permite să introduceți instrucțiuni tranzacționate, proceduri de sistem și fișiere de script linie de comanda În editorul de interogare din modul SQLCMD,

-S. - Specifică numele serverului, server [\\ instance_name];
Declinver \\ sqlgtd. - numele serverului / numele instanței pe care se rotește baza;
-E. - Utilizări pentru conectarea la SQL Server în loc de un nume de utilizator și o parolă de încredere;
-Q "cmdlinequery" - Când începeți programul sqlcmd. Solicitări, dar ieșirea din program după finalizarea executării acestuia nu este efectuată. Pot fi executate mai multe cereri, separate printr-un punct de virgulă. Citate de contact După cum se arată mai sus;
declara. - Declarăm variabila S, numele variabilei începe întotdeauna cu @, prin urmare @s.. În cazul nostru @s. - acesta este un dosar (disc) de stocare de backup;
varchar (n) - Specifică tipul de variabilă @s. ca șir cu un șir lung n, în exemplul de 255 de caractere;
a STABILIT. - stabilește valoarea variabilei @s., În exemplul, acesta este folderul de backup de pe discul E ( E: \\ Backup \\), atunci numele fișierului de rezervă este setat, unde setul de caracteristici conversia (Varchar (1), Datepart (DW, GETDATE ())) Returnează formatul de text cu o lungime de 1 simbol Ziua curentă a săptămânii (luni - 1 , Marți - 2 etc.) și se adaugă extensia bak.. La ieșire primim un fișier numit Gtd_donnedi.bak.;
backup. - Creează o copie de rezervă;
bază de date - indică crearea unei backup a întregii baze;
GTD. - în exemplul nostru, numele bazei de pe serverul SQL;
la disc. - indică tipul de dispozitiv depozitare, dosar. hard diskși variabila este indicată @s.care i se atribuie calea și numele fișierului creat;
cu init, noformat, skip, încărcat - Indică faptul că este necesar să rescrieți datele într-un cerc cu anteturi de suprascriere, ceea ce ne va permite să avem 7 fișiere de backup pentru fiecare zi a săptămânii, rescris într-un cerc.

Dacă este necesar, puteți utiliza alte funcții, cum ar fi comprimarea, consultați Ajutor pentru solicitări și funcții tranzacționate-SQL.

Pasul 2. Schimbați extensia fișierului text prin. Cmd

Ca rezultat, primim fișierul backupgtd.cmd.. Rulați fișierul de comandă creat este necesar de la acea mașină unde este instalată baza de date MS SQL.

Pasul 3. Automatează acest proces

Considera acest pas Folosind exemplul MS Windows Server 2008: Server Manager -\u003e Configurare -\u003e Scheduler de sarcini -\u003e Biblioteca de planificare a activității.