Log shipping kopieert transaction log backups van een primary naar een secondary en restoret ze daar. Geen automatic failover, geen leesreplicas in real-time, maar eenvoudig en stabiel. Voor budget-DR-scenario's vaak de juiste keuze.
Wanneer log shipping en wanneer niet
Log shipping past als u geen Software Assurance heeft (Always On vereist Enterprise voor leesreplicas), als u DR over een trage WAN-lijn doet, of als u een second-site-replica wilt zonder automatic failover. Niet als u nul-RPO of automatic failover wilt.
Inrichting: jobs en thresholds
Drie SQL Agent jobs per shipped database: backup, copy, restore. Standaardintervallen 15 minuten. Threshold-alerting bij vertraging vangt netwerkproblemen of disk-issues snel. We zetten ook een DBCC CHECKDB op de secondary in zodat corruptie er vroeg uitkomt.
Read-only secondary tijdens restore
Een log-shipped secondary kan in standby-mode read-only worden gequeried. Bij elke log restore wordt de connectie verbroken. Voor lichte rapportage werkt dit, voor 24/7-leesreplicas niet. Dan is Always On asynchroon de betere keuze.
Failover-procedure documenteren
Log shipping heeft geen automatic failover. Bij DR-event: laatste log shippen, restore WITH RECOVERY op secondary, applicaties ompointen via DNS- of connection-string-wijziging. Een gedocumenteerde failover-runbook van twintig stappen scheelt twee uur paniek.
Monitoring en logfile-management
Log Shipping Monitor toont shipping-status. Aanvullend: alerts op disk space op de share waar logs landen, op tx_log-backup-leeftijd, en op de gap tussen primary en secondary. Logfile management op de primary: niet schrinken, wel goed sized.
Verwant: Interim SQL DBA, Disaster recovery plan.