Cum să faceți copii de siguranță la baze de date SQL la o partajare de rețea

Este necesar să faceți backup periodic bazelor de date SQL. Am acoperit deja căi prin care puteți să salvaț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.

Backup local și apoi copiați în rețeaua de distribuire

Modul preferat și cel mai direct de a realiza această sarcină este să creați 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: Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackup
SqlCmd -E -Q "Baza de date de rezervă MyDB To Disk ="% LocalFolder% MyDB.bak ""
XCopy "% LocalFolder% MyDB.bak" "\ 192.168.16.55BackupDatabase" / Z / V
DEL "% LocalFolder% MyDB.bak"

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

1. Setează o variabilă la 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 suplimentar pe disc 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ă precum:

SqlCmd -E -Q "Baza 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
DATABASE BACKUP se termină anormal.

Această eroare apare în ciuda faptului că ați executat comanda de backup SQL utilizând Windows Authentication (comutatorul -E) și contul Windows ca fiind capacitatea de a accesa și copia fișierele partajate 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 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 rezervă 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 resursele 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.

Modificați proprietățile serviciului SQL Server și în fila Log on, configurați serviciul să ruleze 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 executați comanda pentru a salva direct o copie de rețea:

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

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

Au fost procesate 152 de pagini pentru baza de date "MyDB", fișierul "MyDB" din fișierul 1.
2 pagini prelucrate 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 partajare 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 cota de rețea fără a fi solicitat pentru acreditări. Contul pe care l-ați configurat serviciul SQL Server pentru a rula ca trebuie să aibă o conexiune de încredere cu partea de rețea unde acreditările respective permit accesul, în caz contrar o eroare ca aceasta poate apărea:

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 la conectare: nume de utilizator necunoscut sau parolă defectă.).
Msg 3013, nivelul 16, starea 1, serverul JF, linia 1
DATABASE BACKUP se termină anormal.

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

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

Implicații în securitate

Așa cum am menționat mai devreme, este preferată utilizarea metodei în care faceți copii 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 local la sistem.

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ă luați în considerare adăugarea unui spațiu suplimentar pe hard disk și apoi să implementați copia de siguranță locală și copiați astfel încât să puteți rula serviciul SQL folosind un cont local.