SQL Server Log Shipping: Ghid complet pentru administrator de baze de date [2026]

SQL Server Log shipping este o soluție automată de recuperare în caz de dezastru care menține copii în standby ale bazelor de date de producție. Tehnologia transferă copii de rezervă ale jurnalului de tranzacții dintr-o bază de date principală de pe o instanță a serverului principal către una sau mai multe baze de date secundare de pe instanțe separate ale serverului secundar, asigurând că bazele de date secundare rămân sincronizate cu baza de date principală, oferind protecție împotriva pierderii de date și a erorilor serverului.

1.2 Scopul și beneficiile transportului de jurnale

Log shipping-ul servește mai multor scopuri critice în administrarea bazelor de date:

Rolul său principal este recuperarea în caz de dezastru, oferind o țintă fiabilă de failover atunci când serverul principal devine indisponibil din cauza unei defecțiuni hardware, a coruperii software-ului sau a unor evenimente catastrofale care afectează centrul de date.
De asemenea, este eficient din punct de vedere al costurilor soluție de înaltă disponibilitateSpre deosebire de funcțiile de nivel enterprise care necesită licențiere costisitoare, jurnal shipping funcționează cu SQL Server Ediția Standard, fiind accesibilă și organizațiilor cu constrângeri bugetare.
Bazele de date secundare în modul standby oferă o valoare suplimentară dincolo de recuperarea în caz de dezastru. Administratorii bazelor de date le pot utiliza pentru raportare doar în citire, descărcând sarcini de lucru pentru interogări de pe serverul de producție.
Funcția de restaurare întârziată oferă protecție împotriva modificărilor accidentale ale datelor. Prin configurarea unei întârzieri de restaurare, creați o fereastră de timp pentru a recupera după erorile utilizatorului înainte ca modificările distructive să ajungă la baza de date secundară.

2. SQL Server Componente și flux de lucru pentru expedierea jurnalelor

Transportul jurnalelor constă din următoarele componente:

Serverul principal și baza de date principală: Serverul principal reprezintă producția dvs. SQL Server instanță care rulează baza de date principală.
Partajare de backup: Locația intermediară pentru stocarea și transferul copiilor de rezervă ale jurnalului de tranzacții de pe serverul principal pe serverele secundare.
Servere secundare și baze de date secundare: Serverele secundare găzduiesc copiile în regim de standby cald ale bazei de date primare.
Server de monitorizare (opțional): Acest server urmărește istoricul și starea tuturor operațiunilor de backup, copiere și restaurare pe întreaga topologie de livrare a jurnalelor.
Lucrări de agent: Inclusiv lucrări de backup, copiere, restaurare și alertă, automatizând întregul proces de livrare a jurnalelor.

Fluxul de lucru de automatizare este:

Jobul de copiere de rezervă rulează pe serverul principal și creează copii de rezervă ale jurnalului de tranzacții ale bazei de date principale de pe partajarea de copiere de rezervă.
Lucrarea de copiere rulează pe fiecare server secundar și transferă fișierele de rezervă ale jurnalelor de pe partajarea de rezervă pe serverul(ele) secundar(e).
Jobul de restaurare rulează pe fiecare server secundar și aplică copii de rezervă ale jurnalului de tranzacții în baza de date secundară.
Jobul de alertă rulează pe serverul de monitorizare și verifică dacă operațiunile de backup și restaurare sunt finalizate în intervale de timp acceptabile.

3. Condiții preliminare și cerințe

3.1 SQL Server Cerințe de versiune

Transportul de jurnal este disponibil de la SQL Server 2000 și rămâne acceptat în toate versiunile ulterioare de la SQL Server 2005 până în 2025. Acest sprijin de lungă durată demonstrează stabilitatea tehnologiei și relevanța continuă.

3.2 SQL Server Cerințe de ediție

Transportul jurnalelor funcționează cu edițiile Standard, Workgroup, Enterprise și Developer ale SQL ServerAceastă ediție extinsă face ca transportul de jurnale să fie accesibil organizațiilor fără licențe Enterprise Edition, spre deosebire de funcții precum Grupuri de disponibilitate permanent care necesită edițiile Enterprise sau Evaluation.

Notă: Express Edition nu acceptă transportul jurnalelor.

3.3 Cerințe ale modelului de recuperare a bazei de date

Transferul de jurnal necesită ca baza de date principală să utilizeze modelul de recuperare completă sau modelul de recuperare cu jurnalizare în bloc. Modelul simplu de recuperare nu este acceptat deoarece SQL Server trunchiază automat jurnalele de tranzacții, întrerupând lanțul continuu de jurnalizare necesar pentru livrarea jurnalelor.

Pentru mai multe detalii despre modelele de recuperare, consultați ghid complet despre SQL Server de rezervă.

4. Configurarea transportului de jurnale folosind SSMS

4.1 Creați un folder pentru partajarea copiilor de rezervă

Înainte de a configura livrarea jurnalelor, pregătiți folderul de partajare a copiilor de rezervă unde vor fi stocate și transferate copiile de rezervă ale jurnalului de tranzacții.

Pe serverul principal sau pe un server de fișiere dedicat, creați un folder (de exemplu, C:\Backup)
Faceți clic dreapta pe dosar și selectați Proprietăţi
Apasă pe Partajarea fila
Clic Partajare avansată
Verifica Distribuiți acest fișier
Clic Permisiuni și acordă Control total permisiunea către SQL Server cont de serviciu Serviciu NT\MSSQLSERVER.
Clic OK a aplica.
Documentați calea de rețea (UNC) (de exemplu, \\NUME-SERVER\Copiere de rezervă)

4.2 Activarea și configurarea transportului jurnalelor

Faceți clic dreapta pe baza de date principală și selectați Proprietăţi.
În Proprietățile bazei de date , selectați fișierul Livrare jurnal tranzacții pagină din panoul din stânga.
Verifica Activați aceasta ca bază de date principală într-o configurație de livrare a jurnalelor pentru a activa transportul jurnalelor.
Apoi puteți configura setările de rezervă, serverul secundar și serverul de monitorizare în această pagină de proprietăți. Le vom introduce în subsecțiunile următoare.

4.2.1 Configurarea setărilor de rezervă

Apasă pe Setări de rezervă buton
În Setări de copiere de rezervă a jurnalului de tranzacții dialog, sub Calea de rețea către folderul de rezervă câmp, introduceți calea UNC (de exemplu, \\NUME-SERVER\Copiere de rezervă)
Dacă folderul de rezervă se află pe serverul principal, introduceți calea locală (de exemplu, C:\Backup)
Configurați alte setări, cum ar fi perioada de păstrare a copiei de rezervă, pragul de alertă, jobul de copiere de rezervă și compresia.
Clic OK pentru a confirma setările și a închide caseta de dialog.

4.2.2 Configurarea instanței serverului secundar și a bazei de date

Clic Adăuga în Instanțe de server secundar și baze de date
În Setări bază de date secundară dialog, faceți clic pe Connect pentru a se conecta la instanța serverului secundar.
În Bază de date secundară meniu derulant, selectați o bază de date existentă sau introduceți un nume nou pentru baza de date
În Inițializarea bazei de date secundare , selectați Da, generați o copie de rezervă completă a bazei de date primare și restaurați-o în baza de date secundară (și creați baza de date secundară dacă aceasta nu există)
Apasă pe Copiați fișierele fila
În Folderul de destinație pentru fișierele copiate (Acest folder se află de obicei pe serverul secundar), introduceți calea locală a folderului de destinație de pe serverul secundar.
Asigurați-vă că folderul există și că SQL Server contul de serviciu are permisiuni de scriere
Clic OK pentru a confirma setările și a închide caseta de dialog.

4.2.3 Configurarea serverului Monitor

Verifica Utilizați o instanță de server de monitorizare
Clic Setări cont
Clic Connect pentru a se conecta la instanța serverului de monitorizare
set Ștergeți istoricul după pentru a specifica perioada de păstrare în ore
Clic OK pentru a confirma setările și a închide caseta de dialog.

4.2.4 Revizuirea și finalizarea configurației

Verificați toate setările de pe Livrare jurnal tranzacții pagină
Verificați setările de rezervă, configurațiile serverului secundar și setările de monitorizare
Clic OK pentru a aplica configurația
Expertul creează toate joburile necesare pe serverele principale, secundare și de monitorizare
Clic Închide când configurația este finalizată

5. Avantajele și dezavantajele transportului de jurnal

5.1 Beneficii ale SQL Server Expediere busteni

Soluție rentabilă: Funcționează cu SQL Server Ediția Standard, eliminând cerințele costisitoare de licențiere Enterprise Edition. Acest lucru face ca recuperarea în caz de dezastru să fie accesibilă organizațiilor cu bugete limitate.
Simplu de configurat și întreținut: Expertul de configurare îi ghidează pe administratori prin procesul de configurare, oferind opțiuni clare. Majoritatea bazelor de date pot fi configurate în 15-30 de minute, fără instruire specializată.
Suport pentru mai multe servere secundare: Suportă numeroase servere secundare fără limitări arhitecturale. Implementează un server secundar pentru recuperarea în caz de dezastru local, un altul de la distanță și un al treilea pentru raportare.
Impact minim asupra serverului principal: Funcționează asincron, eliminând supraîncărcarea sincronizării pe serverul principal. Timpii de validare a tranzacțiilor rămân neafectați.
Utilizează copiile de rezervă ale jurnalului de tranzacții existente: Copiile de rezervă pentru jurnalele de tranzacții sunt copii de rezervă standard ale jurnalelor de tranzacții, utilizabile pentru recuperarea la un moment dat, independent de jurnalele de tranzacții.
Opțiune de restaurare întârziată: Funcția de întârziere a restaurării oferă protecție împotriva modificărilor accidentale ale datelor care nu sunt disponibile în soluții de replicare în timp real.
Nu este necesar spațiu de stocare partajat: Folosește stocare independentă pe fiecare server, eliminând cerințele de stocare partajată și costurile asociate.
Asistență pe mai multe platforme: Funcționează identic atât pe Windows, cât și pe Linux SQL Server implementări.
Funcționează în mai multe domenii: Nu necesită relații de încredere în domeniu sau integrare cu Active Directory.

5.2 Dezavantajele și limitările transportului de jurnal

Fără failover automat: Principala limitare este cerința de failover manual. Administratorii trebuie să execute mai mulți pași înainte ca serviciul să fie reluat.
Întârziere la sincronizarea datelor: Bazele de date secundare rămân întotdeauna în urma bazelor de date primare în ceea ce privește frecvența de backup și restaurare.
Numai configurație la nivel de bază de date: Configurează la nivel de bază de date, nu la nivel de instanță. Protejarea a 50 de baze de date necesită 50 de configurații separate.
Modificări manuale ale șirurilor de conexiune: Aplicațiile trebuie să actualizeze șirurile de conexiune pentru a indica serverul secundar după failover.
Întreruperi ale bazei de date secundare: Bazele de date secundare în modul standby deconectează utilizatorii în timpul operațiunilor de restaurare.
Gestionare separată a bazelor de date: Fiecare configurație a bazei de date trebuie gestionată individual, fără capacități de gestionare coordonate.

6. Cele mai bune practici și cazuri de utilizare

6.1 Când se utilizează transportul jurnalelor

Recuperare după dezastru cu buget redus: Excelează ca o soluție rentabilă de recuperare în caz de dezastru pentru organizațiile care nu își pot justifica costurile de licențiere Enterprise Edition.
Cerințe RPO/RTO moderate: Aplicațiile care tolerează 15-30 de minute de pierdere de date și 30-60 de minute de nefuncționare se aliniază perfect cu capacitățile sale.
Server de raportare doar în citire: Creați copii doar pentru citire pentru raportarea sarcinilor de lucru care tolerează deconectări periodice.
Medii Standard Edition: Organizațiile au standardizat pe SQL Server Ediția Standard nu are acces la grupurile de disponibilitate Always On, ceea ce face ca jurnalele să fie cea mai bună opțiune disponibilă.
Proiecte de migrare a serverului: Facilitează migrările serverelor prin menținerea copiilor sincronizate în perioadele de tranziție.
Cerințe privind datele întârziate: Configurați întârzierile de restaurare pentru a menține bazele de date la puncte fixe din trecut, în scopuri de conformitate sau audit.

6.2 Când NU se utilizează transportul de jurnal

Cerințe de nefuncționare aproape zero: Aplicațiile cu cerințe RTO sub 15 minute nu se pot baza pe failover manual.
Necesar failover automat: Neadecvat atunci când cerințele afacerii impun failover automat fără intervenția administratorului.
Sincronizare în timp real necesară: Aplicațiile care necesită date în timp real sau aproape în timp real pe servere secundare nu pot accepta întârzierea inerentă a shipping-ului de jurnal.
Toleranță minimă la pierderea datelor: Organizațiile cu RPO măsurat în secunde sau care necesită zero pierderi de date au nevoie de soluții sincrone.

6.3 cele mai bune practici

Optimizarea frecvenței de backup: Echilibrați frecvența backup-urilor în raport cu cheltuielile generale ale sistemului și obiectivele de recuperare. Începeți cu intervale de 15 minute și ajustați în funcție de cerințele reale.
Considerații privind calea de rețea: Folosește căi UNC în loc de unități mapate pentru locațiile de backup. Plasează partajările de backup pe o infrastructură de rețea fiabilă.
Configurarea monitorizării și alertelor: Configurați alerte pentru erorile lucrărilor de backup, copiere și restaurare imediat după finalizarea configurării shipping-ului jurnalelor.
Programul regulat de testare: Programați teste de failover trimestriale sau semestriale pentru a valida procedurile și a menține disponibilitatea administratorilor.
Întreținerea documentației: Mențineți runbook-uri detaliate care documentează detaliile de configurare, procedurile de failover și pașii de depanare.
Considerații de securitate: Folosește conturi de servicii dedicate cu permisiuni minime necesare. Restricționează permisiunile de partajare în rețea în mod corespunzător.
Gestionarea spațiului pe disc: Monitorizați continuu spațiul pe disc din locațiile de backup. Configurați alerte atunci când spațiul scade sub 20%.
Configurarea politicii de retenție: Setați perioade de păstrare a copiilor de rezervă mai lungi decât întârzierea maximă acceptabilă de sincronizare.
Întârziere de restaurare pentru protecție: Configurați întârzierile de restaurare atunci când protecția împotriva modificărilor accidentale justifică o întârziere crescută a sincronizării.

7. Depanarea problemelor comune

7.1 Eșecuri ale sarcinilor de backup

Spațiu insuficient pe disc: Verificați istoricul lucrărilor pentru erori de spațiu pe disc. Verificați spațiul disponibil și spațiul liber ștergând copiile de rezervă vechi sau activând compresia.
Probleme cu permisiunea: Verificați SQL Server Contul de serviciu are permisiuni de Control total atât asupra folderului local, cât și asupra partajării în rețea.
Baza de date nu este în recuperare completă: Reveniți la modelul de recuperare completă și efectuați o copie de rezervă completă pentru a reporni lanțul jurnalului de tranzacții.

7.2 Eșecuri ale lucrărilor de copiere

Cale de rețea inaccesibilă: Testați conectivitatea de la serverul secundar mapând manual calea de rețea.
Probleme de autentificare: Configurați acreditări explicite pentru accesul la partajarea în rețea dacă serverele se află în domenii diferite.
Probleme de blocare a fișierelor: Excludeți folderul de rezervă din scanarea antivirus în timp real pentru a preveni blocarea fișierelor.

7.3 Erori ale lucrărilor de restaurare

Fișiere de rezervă lipsă: Verificați dacă fișierele există în folderul de destinație și verificați istoricul lucrărilor de copiere.
Eroare la secvența de restaurare: Identificați copiile de rezervă ale jurnalului de tranzacții lipsă și restaurați-le secvențial pentru a repara lanțul de jurnalizare.
Baza de date în stare greșită: Reinițializați livrarea jurnalelor prin restaurarea unei copii de rezervă complete cu NORECOVERY dacă cineva a recuperat baza de date.
Coruperea fișierului bazei de date: Dacă eșecurile de restaurare persistă în ciuda secvenței și configurării corecte, fișierele bazei de date pot fi corupte. În astfel de cazuri, este posibil să fie nevoie să utilizați un specialist instrument de recuperare SQL pentru a extrage date din fișierele .MDF și .NDF deteriorate înainte de a încerca reinițializarea împrăștierii jurnalelor.

7.4 Probleme de întârziere la sincronizare

Limitări ale lățimii de bandă a rețelei: Activați compresia copiilor de rezervă pentru a reduce dimensiunile fișierelor și cerințele de lățime de bandă.
Volum mare de tranzacții: Luați în considerare creșterea frecvenței copiilor de rezervă pentru a crea fișiere de rezervă mai mici și mai ușor de gestionat.
Frecvență de restaurare inadecvată: Măriți frecvența lucrărilor de restaurare pentru a aproxima frecvența de backup și a minimiza întârzierea.

7.5 Monitorizarea problemelor de conectivitate la server (SQL 2025)

Erori ale furnizorului OLE DB: SQL Server Criptarea obligatorie implicită din 2025 intră în conflict cu instanțele mai vechi care nu au o configurație de criptare adecvată.
Nepotrivire a configurației de criptare: Verificați configurația serverului conectat pe serverul monitorizat și verificați setările de criptare.
Soluții alternative: Eliminați și recreați transportul jurnalelor folosind parametrii TLS 1.3 sau actualizați toate instanțele la SQL Server 2025.

7.6 SQL Server Probleme legate de serviciul de agenți

Serviciul nu a fost pornit: Verificați starea serviciului Agent și configurați-l să pornească automat.
Programarea lucrărilor este dezactivată: Verificați starea programării lucrărilor și activați programările dezactivate.
Eșecuri ale etapelor de lucru: Revizuiți istoricul lucrărilor pentru a identifica pașii eșuați și mesajele de eroare specifice.

8. Întrebări frecvente (FAQ)

Î: Pot utiliza transportul de jurnale cu Express Edition?

Un nu, SQL Server Ediția Express nu acceptă transportul de jurnal, deoarece îi lipsește SQL Server Agent.

Î: Cât de des ar trebui să programez copii de rezervă ale jurnalelor?

A: Intervalele implicite de 15 minute oferă un echilibru rezonabil. Ajustați în funcție de obiectivul punctului de recuperare.

Î: Pot fi utilizate baze de date secundare pentru raportare?

R: Da, bazele de date secundare configurate în modul standby permit acces doar pentru citire între operațiunile de restaurare.

Î: Ce se întâmplă dacă serverul principal se defectează?

A: Executați o reluare manuală pentru a aduce online o bază de date secundară. Pierderea de date este egală cu întârzierea sincronizării în momentul erorii.

Î: Pot avea mai multe servere secundare?

R: Da, log shipping-ul acceptă un număr nelimitat de servere secundare cu configurații independente.

Î: Cum calculez întârzierea sincronizării?

A: Comparați ultima marcă temporală a jurnalului de tranzacții restaurată cu ora curentă utilizând tabelele de monitorizare a shipping-ului jurnalelor.

Î: Poate funcționa log shipping-ul pe domenii diferite?

R: Da, funcționează în diferite domenii sau în medii de grup de lucru fără a necesita relații de încredere.

Î: Care este diferența dintre modul Fără recuperare și modul Standby?

A: Fără mod de recuperare, baza de date este inaccesibilă. Modul standby permite interogări doar pentru citire între restaurări.

Î: Pot întrerupe temporar livrarea jurnalelor?

R: Da, dezactivați sarcinile de backup, copiere și restaurare pentru a întrerupe sincronizarea, păstrând în același timp configurația.

Î: Cum pot elimina configurația de livrare a jurnalelor?

A: În Livrare jurnal tranzacții pagina de proprietate:

Debifați Activați aceasta ca bază de date principală într-o configurație de livrare a jurnalelor
Clic OK pentru a elimina configurația și a șterge joburile.

Î: Pot comuta baza de date secundară în modul citire-scriere?

R: Da, executați RESTORE DATABASE WITH RECOVERY, dar acest lucru întrerupe lanțul de livrare a jurnalelor.

Î: Care este întârzierea maximă pe care o pot configura pentru restaurare?

R: Nu există o limită fixă. Configurați întârzierile de la minute la zile, în funcție de cerințele dvs. de protecție.

Î: Cum afectează transportul jurnalelor strategia de backup?

R: Creează copii de rezervă ale jurnalelor de tranzacții, utilizabile atât pentru livrarea jurnalelor, cât și pentru recuperarea la un moment dat.

Î: Pot utiliza transferul de jurnal pentru migrarea serverului?

R: Da, configurați livrarea jurnalelor către noul server, sincronizați, apoi efectuați failover-ul planificat al vechiului server în timpul întreținerii.

Î: Ce instrumente de monitorizare funcționează cu transportul jurnalelor?

A: SQL Server Management Studio include rapoarte încorporate. Instrumente terțe precum SQL Monitor și SolarWinds oferă monitorizare îmbunătățită.

9. Concluzii și recomandări

9.1 Rezumatul punctelor cheie

SQL Server Transferul de jurnal oferă o recuperare în caz de dezastru fiabilă și eficientă din punct de vedere al costurilor prin operațiuni automate de backup și restaurare a jurnalelor de tranzacții. Tehnologia funcționează cu Standard Edition, necesită o infrastructură minimă și acceptă mai multe servere secundare.

Log shipping-ul este excelent pentru obiective de recuperare moderate în care failover-ul manual este acceptabil. Printre limitările cheie se numără cerința de failover manual, întârzierea sincronizării și domeniul de configurare la nivel de bază de date.

Tehnologia se integrează bine cu strategiile de backup existente, acceptă raportarea doar pentru citire prin modul standby și oferă protecție la restaurare întârziată împotriva modificărilor accidentale.

9.2 Alegerea potrivită pentru mediul dumneavoastră

Evaluați transferul de jurnal în funcție de cerințele specifice înainte de implementare. Luați în considerare obiectivele punctului de recuperare, obiectivele timpului de recuperare, constrângerile bugetare și toleranța la complexitatea operațională.

Organizațiile care utilizează SQL Server Ediția Standard cu cerințe moderate de recuperare ar trebui să ia în considerare cu seriozitate livrarea jurnalelor. Întreprinderile cu un RTO strict sub 15 minute ar trebui să evalueze Grupurile de disponibilitate Always On.

Luați în considerare abordări hibride care combină transportul de jurnale cu alte tehnologii pentru optimizarea costurilor, îndeplinind în același timp diverse cerințe.

9.3 Pașii următori și resurse suplimentare

Începeți cu implementări pilot la scară mică pentru a câștiga experiență. Dezvoltați o documentație cuprinzătoare, inclusiv detalii de configurare, proceduri de failover și ghiduri de depanare.

Programați teste regulate de failover pentru a valida procedurile și a menține disponibilitatea administratorului. Rămâneți la curent cu SQL Server actualizări și îmbunătățiri.

Referinte

Document oficial Microsoft: Despre livrarea jurnalelor (SQL Server)
Document oficial Microsoft: Configurați livrarea jurnalelor (SQL Server)

Despre autor

Yuan Sheng este un administrator senior de baze de date (DBA) cu peste 10 ani de experiență în SQL Server medii de lucru și managementul bazelor de date la nivel de întreprindere. A rezolvat cu succes sute de scenarii de recuperare a bazelor de date în cadrul unor organizații din domeniul serviciilor financiare, al sănătății și al producției.

Yuan este specializat în SQL Server recuperarea bazelor de date, soluții de înaltă disponibilitate și optimizarea performanței. Experiența sa practică vastă include gestionarea bazelor de date de mai mulți terabyți, implementarea grupurilor de disponibilitate Always On și dezvoltarea de strategii automate de backup și recuperare pentru sistemele critice ale afacerii.

Prin expertiza sa tehnică și abordarea practică, Yuan se concentrează pe crearea de ghiduri complete care ajută administratorii de baze de date și profesioniștii IT să rezolve probleme complexe. SQL Server provocări eficiente. El se menține la curent cu cele mai recente SQL Server versiunilor de software și tehnologiilor de baze de date în continuă evoluție ale Microsoft, testând periodic scenarii de recuperare pentru a se asigura că recomandările sale reflectă cele mai bune practici din lumea reală.

Ai întrebări despre SQL Server recuperare sau aveți nevoie de îndrumări suplimentare pentru depanarea bazei de date? Yuan vă urează bun venit pentru a vă ajuta. feedback și sugestii pentru îmbunătățirea acestor resurse tehnice.