If-Koubou

Cum se fac copii de rezervă ale bazelor de date SQL la o partajare de rețea

Cum se fac copii de rezervă ale bazelor de date SQL la o partajare de rețea (Cum să)

Este necesar să faceți backup periodic bazelor de date SQL. Am acoperit deja modalități de a putea să copiați cu ușurință toate bazele de date ale serverului dvs. SQL pe o unitate hard disk locală, dar acest lucru nu protejează împotriva defectării unității și / sau a sistemului. Ca un strat suplimentar de protecție împotriva acestui tip de dezastru, puteți să copiați sau să creați direct backup-urile pe o partajare de rețea.

Faceți backup local, apoi copiați-o în Share Share

Modul preferat și cel mai direct de a realiza această sarcină este de a crea o copie de rezervă locală a unei baze de date și apoi să copiați fișierul de rezervă respectiv într-o partajare de rețea. Puteți face acest lucru prin crearea unui script batch care arată astfel:

SET LocalFolder = C: Fișiere de programMicrosoft SQL ServerMSSQL.1MSSQLBackup
SqlCmd -E -Q "Baza de date de rezervă MyDB To Disk ="% LocalFolder% MyDB.bak ""
XCopy "% LocalFolder% MyDB.bak" "\ 192.168.16.55BackupDatabases" / Z / V
DEL "% LocalFolder% MyDB.bak"

Acest script are următoarele (rând pe linie):

  1. Setează o variabilă în directorul local de backup SQL.
  2. Creează o copie de siguranță SQL a MyDB (utilizând Windows Authentication) în directorul local de backup SQL.
  3. Copiază fișierul de rezervă local într-o partajare de rețea.
  4. Șterge fișierul de rezervă local.

Din nou, aceasta este metoda preferată deoarece funcționează din cutie, iar probabilitatea unei erori de salvare este minimă, deoarece copia de rezervă este creată pe un disc local. Cu toate acestea, dacă nu aveți suficient spațiu pe disc pentru a stoca copii locale ale fișierelor de rezervă, această acțiune va eșua. În acest caz, va trebui să adăugați un spațiu pe disc suplimentar sau o copie de rezervă directă la o partajare de rețea.

Backup direct la o partajare de rețea

De obicei, când încercați să creați o copie de siguranță direct la o partajare de rețea folosind o comandă, cum ar fi:

SqlCmd -E -Q "Bază de date de rezervă MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

Veți avea probabil o eroare la fel ca în cazul:

Msg 3201, nivelul 16, starea 1, serverul JF, linia 1
Nu se poate deschide dispozitivul de backup "\ 192.168.16.55BackupDatabasesMyDB.bak". Eroare de sistem de operare 5 (accesul este refuzat.).
Msg 3013, nivelul 16, starea 1, serverul JF, linia 1
BACKUP DATABASE se termină anormal.

Această eroare apare în ciuda faptului că ați executat comanda de backup SQL folosind Windows Authentication (comutatorul -E) și contul Windows ca abilitatea de a accesa și copia fișierele la partajare prin Windows Explorer.

Motivul pentru care această acțiune eșuează este că comanda SQL este executată în limitele contului pe care rulează serviciul SQL Server ca. Când vizualizați lista de servicii de pe computer, cel mai probabil veți vedea serviciul SQL Server care rulează ca (coloana Log On As) fie Local System, fie Network Service, care sunt conturi de sistem care nu au acces la rețea.

În sistemul nostru, copierea de siguranță la o comandă de partajare de rețea nu reușește deoarece avem serviciul SQL Server care rulează ca sistem local, care, din nou, nu poate ajunge la nici o resursă de rețea.

Pentru a permite SQL să copieze direct o copie de rețea, trebuie să executați serviciul SQL Server ca un cont local care are acces la resurse de rețea.

Editați proprietățile serviciului SQL Server și pe fila Log on, configurați serviciul ca un cont alternativ care are drepturi de acces la rețea.

Când faceți clic pe OK, veți primi o solicitare ca setările să nu aibă efect până când serviciul nu este repornit.

Reporniți serviciul.

Lista de servicii ar trebui să afișeze acum că serviciul SQL Server rulează ca cont pe care l-ați configurat.

Acum când rulați comanda pentru a salva direct o copie de rețea:

SqlCmd -E -Q "Bază de date de rezervă MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

Ar trebui să vedeți un mesaj de succes:

S-au procesat 152 de pagini pentru baza de date "MyDB", fișierul "MyDB" din fișierul 1.
S-au procesat 2 pagini pentru baza de date "MyDB", fișierul "MyDB_log" din fișierul 1.
BACKUP DATABASE a fost procesată cu succes în 154 de pagini în 0,503 secunde (2,493 MB / sec).

Cu fișierul de rezervă acum în directorul de partajare în rețea:

Considerații privind partajarea rețelei

Este important să rețineți că comanda de copiere de rezervă se așteaptă să se poată conecta direct la partajarea de rețea fără a vi se solicita acreditări. Contul pe care l-ați configurat pentru a rula serviciul SQL Server trebuie să aibă o conexiune de încredere cu partea de rețea în care acreditările respective permit accesul, în caz contrar poate apărea o eroare ca aceasta:

Msg 3201, nivelul 16, starea 1, serverul JF, linia 1
Nu se poate deschide dispozitivul de backup "\ 192.168.16.55BackupDatabasesMyDB.bak". Eroare de sistem de operare 1326 (Eroare de conectare: nume de utilizator necunoscut sau parolă defectă).
Msg 3013, nivelul 16, starea 1, serverul JF, linia 1
BACKUP DATABASE se termină anormal.

Această eroare indică faptul că numele de utilizator și parola contului nu au fost acceptate de partajarea de rețea și comanda a eșuat.

O altă problemă care trebuie păstrată în minte este că copierea de rezervă este efectuată direct la o resursă de rețea, astfel încât orice sughiț în conexiunea de rețea ar putea duce la eșecul copierii de rezervă. Din acest motiv, ar trebui să creați copii de rezervă numai în locații de rețea care sunt stabile (adică, probabil, nu este o rețea VPN).

Implicații în securitate

După cum am menționat mai devreme, este preferată utilizarea metodei în care copiați copiile de rezervă la nivel local și apoi copiați într-o partajare de rețea, deoarece vă permite să executați serviciul SQL ca un cont cu acces la sistem local.

Prin rularea serviciului ca un cont alternativ, deschideți ușa pentru posibile probleme de securitate. De exemplu, un script malware SQL ar putea executa sub contul alternativ și să atace resursele de rețea. În plus, orice modificare a contului respectiv (modificări de parole / expirare sau ștergere / dezactivare a contului) va determina încetarea serviciului SQL Server.

Este important să păstrați aceste puncte în minte dacă executați instanța SQL Server folosind un cont alternativ. În timp ce acestea nu sunt afișate opritoare dacă se iau măsuri de precauție adecvate, trebuie să vă gândiți să adăugați un spațiu pe hard disk suplimentar și apoi să implementați copia de rezervă și copia de rezervă locale pentru a putea rula serviciul SQL folosind un cont local.