Il Log Shipping è una soluzione di disaster recovery disponibile in SQL Server, che consente di mantenere una copia sincronizzata del database primario su uno o più server secondari tramite l’utilizzo del backup del log delle transazioni.
Questa funzionalità è ideale per garantire la disponibilità dei dati e la continuità operativa in caso di disastri perché permette di avere un database secondario sempre aggiornato e pronto per essere utilizzato come backup in caso di bisogno.
Il meccanismo del Log Shipping si basa su tre job di SQL Server Agent che permettono la sincronizzazione dei dati tra il server primario e quello secondario: Backup del log, Copia dei file e Restore dei log.

Meccanismo del Log Shipping
- Backup del Log: Questo è il primo job che viene eseguito nel meccanismo di Log Shipping. Sul server primario viene eseguito periodicamente il backup del log delle transazioni del database configurato per questa funzionalità. Il log delle transazioni contiene tutte le modifiche apportate al database dopo l'ultimo backup. La frequenza di esecuzione di questo job è configurabile a seconda del proprio RPO.
- Copia dei File: Il secondo job entra in azione dopo che il backup del log è stato creato. Questo job, eseguito sul server secondario, ha il compito di copiare i file di backup dal server primario al server secondario.
- Restore dei Log: L'ultimo job, presente sul server secondario, esegue il ripristino del backup del log sul server secondario. In questo processo vengono applicati i log copiati al database secondario, mantenendo quest'ultimo sincronizzato con il primario.
Il ripristino può essere eseguito in due modalità:
- NO RECOVERY: rende il database secondario non disponibile;
- Stand-by/Read-Only: permette di accedere al database in modalità di sola lettura.
Benefici del Log Shipping
l Log Shipping offre molti vantaggi per chi cerca una soluzione di disaster recovery:
Alta disponibilità del database secondario: In caso di guasto del server primario, il database secondario è pronto per essere attivato come database principale, minimizzando i tempi di recovery.
Riduzione dell'impatto sulle performance: Il Log Shipping opera in modo asincrono, il che significa che il processo di backup, copia e ripristino dei log delle transazioni non influisce significativamente sulle prestazioni del server primario, a differenza di altre soluzioni come i gruppi di disponibilità (Availability Group) o la Replicazione. Avendo un database secondario aggiornato, le attività di reportistica e di analisi si possono eseguire su questo evitando così di impattare sulle prestazioni del database primario.
Supporto per database multipli: Il Log Shipping permette di configurare più server secondari per un unico server primario fornendo maggiore flessibilità e garanzia della disponibilità del servizio.
Semplicità di implementazione/integrazione: La configurazione di questo meccanismo è semplice e veloce. Se esistono già processi di backup dei log, il server primario è già configurato.
Svantaggi del log shipping
Nonostante i suoi vantaggi, il Log Shipping ha alcuni limiti:
- Assenza di failover automatico: A differenza dei gruppi di disponibilità (Availability Group), il Log Shipping non supporta il failover automatico. In caso di guasto del server primario, l'intervento manuale è necessario per attivare il server secondario.
- Interruzione delle connessioni: Durante il ripristino del log delle transazioni, le connessioni esistenti al database secondario vengono interrotte, il che potrebbe causare problemi di disponibilità temporanea.
- Limitazioni nella flessibilità di utilizzo: Il database secondario, quando in modalità No Recovery, non è accessibile per le letture. Questo limita la sua utilità per scopi di reporting o analisi.
Conclusioni
Il Log Shipping rappresenta una soluzione solida e affidabile per il disaster recovery in SQL Server. È particolarmente utile in ambienti dove è necessaria una soluzione semplice, configurabile e con un impatto minimo sulle performance del server primario. Tuttavia, come tutte le soluzioni di disaster recovery, presenta dei limiti che devono essere considerati in base alle esigenze specifiche dell'ambiente IT. È una soluzione ideale per chi necessita di un metodo efficiente per mantenere un database secondario aggiornato e pronto all'uso in caso di emergenza, pur senza la complessità e i costi associati ad altre tecnologie più avanzate.
di Nabil El Merzouki, pubblicato il 30 gennaio 2025