A primary database ships transaction log backups to a disaster recovery server every 15 minutes, and each file is copied and restored on the secondary shortly after it is taken. If the primary is suddenly destroyed, how much committed data could be lost?
Select an answer to reveal the explanation.
Short Explanation
With log shipping, whatever happened since the last log backup left the building is your exposure. Ship every 15 minutes and you could lose up to about 15 minutes, a bit more if a file hadn't been copied yet. That 'none' answer is describing synchronous mirroring, not log shipping.
Full Explanation
Log shipping protects only the transactions contained in log backups that have reached the secondary. Changes committed on the primary after the most recent log backup, or in a backup that had not finished copying when the primary was destroyed, exist only on the primary and are lost with it. With a 15-minute backup interval, the potential loss is therefore up to about 15 minutes of transactions, extended by any copy delay. That window is the effective recovery point for this design and must be compared with the business's recovery point objective. Log shipping is asynchronous; the primary does not wait for the secondary before completing a commit, which is the behaviour of synchronous mirroring or replication, so zero loss is not guaranteed. A configured restore delay on the secondary affects how far behind the secondary's applied state runs, which matters for recovery time and for protection against logical errors, but files already copied can still be restored during failover, so it does not define data loss. Log backups restore in sequence after a full backup without requiring a new full backup each time, so the exposure is not everything since the last full. Exam caveat: shorten the interval or use synchronous technology when the RPO is tighter than the interval. Operational check: alert when the newest log backup on the secondary is older than the target interval.