SQL Server Log Shipping: Guida completa per DBA [2026]

SQL Server Il log shipping è una soluzione automatizzata di disaster recovery che mantiene copie di standby a caldo dei database di produzione. La tecnologia trasferisce i backup del log delle transazioni da un database primario su un'istanza del server primario a uno o più database secondari su istanze separate del server secondario, garantendo la sincronizzazione dei database secondari con il database primario e proteggendo da perdite di dati e guasti del server.

1.2 Scopo e vantaggi del trasporto di tronchi

La spedizione dei log svolge molteplici funzioni critiche nell'amministrazione dei database:

Il suo ruolo principale è il ripristino di emergenza, fornendo un failover affidabile tarquando il server principale non è più disponibile a causa di guasti hardware, danneggiamento del software o eventi catastrofici che interessano il data center.
È anche acost-efficace soluzione ad alta disponibilitàA differenza delle funzionalità di livello aziendale che richiedono licenze costose, la spedizione dei log funziona con SQL Server Edizione Standard, che la rende accessibile anche alle organizzazioni con vincoli di budget.
I database secondari in modalità standby offrono un valore aggiunto che va oltre il disaster recovery. Gli amministratori di database possono utilizzarli per la reportistica in sola lettura, scaricando i carichi di lavoro delle query dal server di produzione.
La funzionalità di ripristino ritardato offre protezione contro modifiche accidentali dei dati. Configurando un ritardo di ripristino, si crea un intervallo di tempo per il ripristino da errori utente prima che modifiche distruttive raggiungano il database secondario.

2. SQL Server Componenti e flusso di lavoro per la spedizione dei registri

Il trasporto dei tronchi è costituito dai seguenti componenti:

Server primario e database primario: il server primario rappresenta la tua produzione SQL Server istanza che esegue il database primario.
Condivisione di backup: posizione intermedia in cui archiviare e trasferire i backup del registro delle transazioni dal server primario ai server secondari.
Server secondari e database secondari: i server secondari host le copie warm standby del database primario.
Server di monitoraggio (facoltativo): questo server tiene traccia della cronologia e dello stato di tutte le operazioni di backup, copia e ripristino nell'intera topologia di log shipping.
Lavori dell'agente: inclusi i lavori di backup, copia, ripristino e avviso, automatizzando l'intero processo di spedizione dei log.

Il flusso di lavoro di automazione è:

Il processo di backup viene eseguito sul server primario e crea backup del registro delle transazioni del database primario sulla condivisione di backup.
Il processo di copia viene eseguito su ciascun server secondario e trasferisce i file di backup del registro dalla condivisione di backup al/ai server secondario/i.
Il processo di ripristino viene eseguito su ciascun server secondario e applica i backup del registro delle transazioni copiati al database secondario.
Il processo di avviso viene eseguito sul server di monitoraggio e verifica se le operazioni di backup e ripristino vengono completate entro tempi accettabili.

3. Prerequisiti e requisiti

3.1 SQL Server Requisiti di versione

Il trasporto dei tronchi è disponibile da SQL Server 2000 e rimane supportato in tutte le versioni successive da SQL Server Dal 2005 al 2025. Questo supporto di lunga data dimostra la stabilità della tecnologia e la sua continua rilevanza.

3.2 SQL Server Requisiti dell'edizione

La spedizione dei log funziona con le edizioni Standard, Workgroup, Enterprise e Developer di SQL ServerQuesto ampio supporto dell'edizione rende la spedizione dei log accessibile alle organizzazioni senza licenze Enterprise Edition, a differenza di funzionalità come Gruppi di disponibilità sempre attivi che richiedono le edizioni Enterprise o Evaluation.

Nota: Express Edition non supporta la spedizione dei log.

3.3 Requisiti del modello di ripristino del database

Il log shipping richiede che il database primario utilizzi un modello di recupero completo o un modello di recupero con registrazione massiva. Il modello di recupero semplice non è supportato perché SQL Server tronca automaticamente i registri delle transazioni, interrompendo la catena di registri continua necessaria per la spedizione dei registri.

Per maggiori dettagli sui modelli di recupero, vedere il nostro guida completa su SQL Server di riserva.

4. Configurazione della spedizione dei log tramite SSMS

4.1 Creare una cartella per la condivisione di backup

Prima di configurare la spedizione dei log, preparare la cartella di condivisione di backup in cui verranno archiviati e trasferiti i backup dei log delle transazioni.

Sul server primario o su un file server dedicato, creare una cartella (ad esempio, C:\Backup)
Fare clic con il tasto destro sulla cartella e selezionare Proprietà a Confronto
Clicca su Sharing linguetta
Clicchi Condivisione avanzata
Vedi Condividi questa cartella
Clicchi Permessi e concedere controllo completo permesso al SQL Server account di servizio Servizio NT\MSSQLSERVER.
Clicchi OK applicare.
Documentare il percorso di rete (UNC) (ad esempio, \\NOME-SERVER\Backup)

4.2 Abilitare e configurare la spedizione dei log

Fare clic con il pulsante destro del mouse sul database primario e selezionare Proprietà a Confronto.
Nel Proprietà del database finestra di dialogo, selezionare il file Spedizione del registro delle transazioni pagina nel pannello di sinistra.
Vedi Abilitalo come database primario in una configurazione di spedizione dei log per abilitare la spedizione dei log.
In questa pagina delle proprietà è possibile configurare le impostazioni di backup, il server secondario e il server di monitoraggio. Li presenteremo nelle sottosezioni seguenti.

4.2.1 Configurare le impostazioni di backup

Clicca su impostazioni di backup pulsante
Nel Impostazioni di backup del registro delle transazioni dialogo, sotto Percorso di rete alla cartella di backup campo, immettere il percorso UNC (ad esempio, \\NOME-SERVER\Backup)
Se la cartella di backup risiede sul server primario, immettere il percorso locale (ad esempio, C:\Backup)
Configurare altre impostazioni, come il periodo di conservazione del backup, la soglia di avviso, il processo di backup e la compressione.
Clicchi OK per confermare le impostazioni e chiudere la finestra di dialogo.

4.2.2 Configurare l'istanza del server secondario e il database

Clicchi Aggiungi per Istanze e database del server secondario
Nel Impostazioni del database secondario finestra di dialogo, fare clic Connettere per connettersi all'istanza del server secondario.
Nel Banca dati secondaria menu a discesa, seleziona un database esistente o digita un nuovo nome di database
Nel Inizializzazione del database secondario scheda, selezionare Sì, genera un backup completo del database primario e ripristinalo nel database secondario (e crea il database secondario se non esiste)
Clicca su Copia file linguetta
Nel Cartella di destinazione per i file copiati (questa cartella si trova solitamente sul server secondario), immettere il percorso locale della cartella di destinazione sul server secondario.
Assicurarsi che la cartella esista e SQL Server l'account di servizio ha permessi di scrittura
Clicchi OK per confermare le impostazioni e chiudere la finestra di dialogo.

4.2.3 Configurare il server di monitoraggio

Vedi Utilizzare un'istanza del server di monitoraggio
Clicchi Impostazioni profilo
Clicchi Connettere per connettersi all'istanza del server di monitoraggio
Impostato Elimina la cronologia dopo per specificare il periodo di conservazione in ore
Clicchi OK per confermare le impostazioni e chiudere la finestra di dialogo.

4.2.4 Revisione e completamento della configurazione

Rivedere tutte le impostazioni su Spedizione del registro delle transazioni pagina
Verificare le impostazioni di backup, le configurazioni del server secondario e le impostazioni di monitoraggio
Clicchi OK per applicare la configurazione
La procedura guidata crea tutti i lavori necessari sui server primario, secondario e di monitoraggio
Clicchi Chiudi quando la configurazione è completata

5. Vantaggi e svantaggi del trasporto di tronchi

5.1 vantaggi di SQL Server Log spedizione

Cost-Soluzione efficace: Funziona con SQL Server Standard Edition, eliminando i costosi requisiti di licenza dell'Enterprise Edition. Questo rende il disaster recovery affidabile accessibile anche alle organizzazioni con budget limitati.
Facile da configurare e gestire: La procedura guidata di configurazione guida gli amministratori attraverso l'installazione con opzioni chiare. Most i database possono essere configurati in 15-30 minuti senza una formazione specializzata.
Supporto per più server secondari: Supporta numerosi server secondari senza limitazioni architetturali. È possibile implementare un server secondario per il disaster recovery locale, un altro in remoto e un terzo per la reportistica.
Impatto minimo sul server primario: Funziona in modo asincrono, eliminando il sovraccarico di sincronizzazione sul server primario. I tempi di commit delle transazioni rimangono invariati.
Utilizza i backup del registro delle transazioni esistenti: I backup del log shipping sono backup standard del log delle transazioni, utilizzabili per il ripristino puntuale indipendentemente dal log shipping.
Opzione di ripristino ritardato: La funzione di ritardo del ripristino fornisce protezione contro modifiche accidentali dei dati non disponibili in soluzioni di replica in tempo reale.
Non è richiesto alcun archivio condiviso: Utilizza un archivio indipendente su ciascun server, eliminando i requisiti di archiviazione condivisa e i relativi costi.osts.
Supporto multipiattaforma: Funziona in modo identico sia su Windows che su Linux SQL Server implementazioni.
Funziona su più domini: Non richiede relazioni di trust di dominio o integrazione con Active Directory.

5.2 Svantaggi e limitazioni del trasporto di tronchi

Nessun failover automatico: La limitazione principale è il requisito del failover manuale. Gli amministratori devono eseguire più passaggi prima che il servizio riprenda.
Ritardo di sincronizzazione dei dati: I database secondari sono sempre in ritardo rispetto ai database primari per quanto riguarda la frequenza di backup e ripristino.
Solo configurazione a livello di database: Configura a livello di database anziché a livello di istanza. La protezione di 50 database richiede 50 configurazioni separate.
Modifiche manuali alla stringa di connessione: Le applicazioni devono aggiornare le stringhe di connessione in modo che puntino al server secondario dopo il failover.
Interruzioni del database secondario: I database secondari in modalità standby disconnettono gli utenti durante le operazioni di ripristino.
Gestione separata del database: Ogni configurazione del database deve essere gestita individualmente senza capacità di gestione coordinate.

6. Migliori pratiche e casi d'uso

6.1 Quando utilizzare la spedizione dei registri

Ripristino di emergenza a basso budget: Eccelle come acost- soluzione efficace per il disaster recovery per le organizzazioni che non sono in grado di giustificare la licenza Enterprise Edition costs.
Requisiti RPO/RTO moderati: Le applicazioni che tollerano 15-30 minuti di perdita di dati e 30-60 minuti di inattività sono perfettamente in linea con le sue capacità.
Server di report di sola lettura: Crea copie di sola lettura per segnalare carichi di lavoro che tollerano disconnessioni periodiche.
Ambienti Standard Edition: Organizzazioni standardizzate su SQL Server La Standard Edition non ha accesso ai gruppi di disponibilità Always On, rendendo la spedizione dei log la migliore opzione disponibile.
Progetti di migrazione del server: Facilita le migrazioni dei server mantenendo copie sincronizzate durante i periodi di transizione.
Requisiti dei dati ritardati: Configurare ritardi di ripristino per mantenere i database in punti fissi nel passato per scopi di conformità o di audit.

6.2 Quando NON utilizzare la spedizione dei registri

Requisiti di tempi di inattività prossimi allo zero: Le applicazioni con requisiti RTO inferiori a 15 minuti non possono fare affidamento sul failover manuale.
Failover automatico necessario: Non appropriato quando i requisiti aziendali impongono il failover automatico senza l'intervento dell'amministratore.
Sincronizzazione in tempo reale richiesta: Le applicazioni che richiedono dati in tempo reale o quasi reale su server secondari non possono accettare il ritardo intrinseco del log shipping.
Tolleranza minima alla perdita di dati: Le organizzazioni con RPO misurato in secondi o che non richiedono alcuna perdita di dati necessitano di soluzioni sincrone.

6.3 Migliori pratiche

Ottimizzazione della frequenza di backup: Bilanciare la frequenza di backup rispetto al sovraccarico del sistema e agli obiettivi di ripristino. Starcon intervalli di 15 minuti e si adatta in base alle effettive esigenze.
Considerazioni sul percorso di rete: Utilizzare percorsi UNC anziché unità mappate per le posizioni di backup. Collocare le condivisioni di backup su un'infrastruttura di rete affidabile.
Configurazione del monitoraggio e degli avvisi: Configurare avvisi per errori di backup, copia e ripristino subito dopo aver completato la configurazione della spedizione dei registri.
Programma di test regolari: Pianificare test di failover trimestrali o semestrali per convalidare le procedure e mantenere l'amministratore pronto.
Manutenzione della documentazione: Mantenere runbook dettagliati che documentino i dettagli di configurazione, le procedure di failover e i passaggi per la risoluzione dei problemi.
Considerazioni sulla sicurezza: Utilizzare account di servizio dedicati con autorizzazioni minime richieste. Limitare opportunamente le autorizzazioni di condivisione di rete.
Gestione dello spazio su disco: Monitora costantemente lo spazio su disco nelle posizioni di backup. Configura avvisi quando lo spazio scende al di sotto del 20%.
Configurazione dei criteri di conservazione: Imposta periodi di conservazione dei backup più lunghi del ritardo di sincronizzazione massimo accettabile.
Ritardo di ripristino per la protezione: Configurare i ritardi di ripristino quando la protezione contro modifiche accidentali giustifica un maggiore ritardo di sincronizzazione.

7. Risoluzione dei problemi comuni

7.1 Errori nei processi di backup

Spazio su disco insufficiente: Controllare la cronologia dei processi per individuare eventuali errori di spazio su disco. Verificare lo spazio disponibile e lo spazio libero eliminando i vecchi backup o abilitando la compressione.
Problemi di autorizzazione: Verifica il file SQL Server l'account di servizio dispone di autorizzazioni di controllo completo sia sulla cartella locale che sulla condivisione di rete.
Database non in completo ripristino: Torna al modello di ripristino completo ed esegui un backup completo su restarnella catena dei registri delle transazioni.

7.2 Errori nei processi di copia

Percorso di rete inaccessibile: Verificare la connettività dal server secondario mappando manualmente il percorso di rete.
Problemi di autenticazione: Configurare credenziali esplicite per l'accesso alla condivisione di rete se i server si trovano in domini diversi.
Problemi di blocco dei file: Escludere la cartella di backup dalla scansione antivirus in tempo reale per evitare blocchi di file.

7.3 Errori di ripristino del processo

File di backup mancanti: Verificare che i file esistano nella cartella di destinazione e controllare la cronologia dei processi di copia.
Errore di sequenza di ripristino: Identificare i backup mancanti del registro delle transazioni e ripristinarli in sequenza per riparare la catena di registri.
Database in stato errato: Reinizializzare la spedizione dei log ripristinando un backup completo con NORECOVERY se qualcuno ha recuperato il database.
Corruzione del file del database: Se i problemi di ripristino persistono nonostante la sequenza e la configurazione corrette, i file del database potrebbero essere danneggiati. In questi casi, potrebbe essere necessario utilizzare un software specializzato. strumento di recupero SQL per estrarre i dati dai file .MDF e .NDF danneggiati prima di tentare di reinizializzare la spedizione dei log.

7.4 Problemi di ritardo di sincronizzazione

Limitazioni della larghezza di banda della rete: Abilita la compressione del backup per ridurre le dimensioni dei file e i requisiti di larghezza di banda.
Elevato volume di transazioni: Valutare la possibilità di aumentare la frequenza dei backup per creare file di backup più piccoli e gestibili.
Frequenza di ripristino inadeguata: Aumentare la frequenza dei processi di ripristino per avvicinarsi alla frequenza dei backup e ridurre al minimo il ritardo.

7.5 Monitorare i problemi di connettività del server (SQL 2025)

Errori del provider OLE DB: SQL Server La crittografia obbligatoria predefinita del 2025 è in conflitto con le istanze più vecchie prive di una configurazione di crittografia adeguata.
Mancata corrispondenza della configurazione della crittografia: Verificare la configurazione del server collegato sul server monitor e controllare le impostazioni di crittografia.
Soluzioni alternative: Eliminare e ricreare la spedizione dei log utilizzando i parametri TLS 1.3 o aggiornare tutte le istanze a SQL Server 2025

7.6 SQL Server Problemi con il servizio agente

Servizio non Started: Controllare lo stato del servizio Agent e configurarlo su start automaticamente.
Pianificazione lavoro disabilitata: Verificare lo stato della pianificazione dei lavori e abilitare le pianificazioni disabilitate.
Errori nei passaggi di lavoro: Esaminare la cronologia dei lavori per identificare i passaggi non riusciti e i messaggi di errore specifici.

8. Domande frequenti (FAQ)

D: Posso utilizzare il log shipping con Express Edition?

R: No, SQL Server Express Edition non supporta la spedizione dei log in quanto manca SQL Server Agente.

D: Con quale frequenza dovrei pianificare i backup del registro?

R: Gli intervalli predefiniti di 15 minuti forniscono un equilibrio ragionevole. Regolali in base al tuo obiettivo di punto di ripristino.

D: È possibile utilizzare database secondari per la reportistica?

R: Sì, i database secondari configurati in modalità standby consentono l'accesso in sola lettura tra le operazioni di ripristino.

D: Cosa succede se il server primario non funziona?

A: Eseguire il failover manuale per portare online un database secondario. La perdita di dati equivale al ritardo di sincronizzazione al momento dell'errore.

D: Posso avere più server secondari?

R: Sì, il log shipping supporta un numero illimitato di server secondari con configurazioni indipendenti.

D: Come calcolo il ritardo di sincronizzazione?

A: Confronta l'ultimo timestamp del registro delle transazioni ripristinato con l'ora corrente utilizzando le tabelle di monitoraggio della spedizione dei log.

D: Il log shipping può funzionare su domini diversi?

R: Sì, funziona in diversi domini o in ambienti di gruppo di lavoro senza richiedere relazioni di fiducia.

D: Qual è la differenza tra la modalità No Recovery e la modalità Standby?

R: Nessuna modalità di ripristino mantiene il database inaccessibile. La modalità standby consente query di sola lettura tra un ripristino e l'altro.

D: Posso mettere in pausa il ritmo di spedizione dei registrirarily?

R: Sì, disabilita i processi di backup, copia e ripristino per mettere in pausa la sincronizzazione preservando la configurazione.

D: Come posso rimuovere la configurazione di spedizione dei log?

A: Nel Spedizione del registro delle transazioni pagina delle proprietà:

Deseleziona Abilitalo come database primario in una configurazione di spedizione dei log
Clicchi OK per rimuovere la configurazione ed eliminare i lavori.

D: Posso impostare il database secondario in modalità lettura-scrittura?

R: Sì, esegui RESTORE DATABASE WITH RECOVERY, ma questo interrompe la catena di spedizione dei log.

D: Qual è il ritardo massimo che posso configurare per il ripristino?

R: Non esiste un limite massimo. Configura i ritardi da minuti a giorni in base alle tue esigenze di protezione.

D: In che modo la spedizione dei log influisce sulla strategia di backup?

R: Crea backup dei registri delle transazioni utilizzabili sia per la spedizione dei registri che per il ripristino puntuale.

D: Posso utilizzare il log shipping per la migrazione del server?

R: Sì, configura la spedizione dei log sul nuovo server, sincronizza, quindi esegui il failover pianificato del vecchio server durante la manutenzione.

D: Quali strumenti di monitoraggio funzionano con il log shipping?

A: SQL Server Management Studio include report integrati. Strumenti di terze parti come SQL Monitor e SolarWinds offrono un monitoraggio avanzato.

9. Conclusione e raccomandazioni

9.1 Riepilogo dei punti chiave

SQL Server il trasporto dei registri fornisce affidabilità, cost- disaster recovery efficace tramite operazioni automatizzate di backup e ripristino del registro delle transazioni. La tecnologia funziona con la Standard Edition, richiede un'infrastruttura minima e supporta più server secondari.

Il log shipping è ideale per obiettivi di ripristino moderati, in cui il failover manuale è accettabile. Le principali limitazioni includono il requisito del failover manuale, il ritardo di sincronizzazione e l'ambito di configurazione a livello di database.

La tecnologia si integra bene con le strategie di backup esistenti, supporta la creazione di report in sola lettura tramite la modalità standby e fornisce protezione con ripristino ritardato contro modifiche accidentali.

9.2 Fare la scelta giusta per il tuo ambiente

Valutare il log shipping in base ai propri requisiti specifici prima dell'implementazione. Considerare gli obiettivi di punto di ripristino (RPO), gli obiettivi di tempo di ripristino (RPO), i vincoli di budget e la tolleranza alla complessità operativa.

Organizzazioni che utilizzano SQL Server Le aziende con requisiti di ripristino moderati dovrebbero prendere in seria considerazione il log shipping. Le aziende con un RTO rigoroso inferiore a 15 minuti dovrebbero valutare i gruppi di disponibilità Always On.

Considerare approcci ibridi che combinano la spedizione dei log con altre tecnologie per cost ottimizzazione soddisfacendo al contempo diverse esigenze.

9.3 Passaggi successivi e risorse aggiuntive

Iniziare con implementazioni pilota su piccola scala per acquisire esperienza. Sviluppare una documentazione completa, inclusi dettagli di configurazione, procedure di failover e guide per la risoluzione dei problemi.

Pianificare test di failover regolari per convalidare le procedure e mantenere la preparazione dell'amministratore. Rimani aggiornato con SQL Server aggiornamenti e miglioramenti.

Referenze

Documento ufficiale Microsoft: Informazioni sulla spedizione dei tronchi (SQL Server)
Documento ufficiale Microsoft: Configurare la spedizione dei log (SQL Server)

L'autore

Yuan Sheng è un amministratore di database senior (DBA) con oltre 10 anni di esperienza in SQL Server ambienti e gestione di database aziendali. Ha risolto con successo centinaia di scenari di ripristino di database in aziende di servizi finanziari, sanitari e manifatturiere.

Yuan è specializzato in SQL Server Ripristino di database, soluzioni ad alta disponibilità e ottimizzazione delle prestazioni. La sua vasta esperienza pratica include la gestione di database multi-terabyte, l'implementazione di gruppi di disponibilità Always On e lo sviluppo di strategie di backup e ripristino automatizzate per sistemi aziendali mission-critical.

Grazie alla sua competenza tecnica e al suo approccio pratico, Yuan si concentra sulla creazione di guide complete che aiutano gli amministratori di database e i professionisti IT a risolvere problemi complessi SQL Server sfide in modo efficiente. Si mantiene aggiornato con le ultime SQL Server versioni e le tecnologie di database in continua evoluzione di Microsoft, testando regolarmente gli scenari di ripristino per garantire che le sue raccomandazioni riflettano le migliori pratiche del mondo reale.

Hai domande su SQL Server recupero o hai bisogno di ulteriore assistenza per la risoluzione dei problemi del database? Yuan accoglie feedback e suggerimenti per migliorare queste risorse tecniche.