![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(304, 63%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECK%3C/text%3E%3C/svg%3E)
SQL Server Database Engine
Core component of SQL Server for storing, processing, and securing data
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(35.2, 63%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDD%3C/text%3E%3C/svg%3E)
Manual log backup doesn't break the LSN chain. It just left a gap in log shipping's restore sequence on the secondary (the next scheduled .trn fails as "too recent").
Fix: Copy the manual .trn to the secondary's restore folder, restore it WITH NORECOVERY (or STANDBY) in LSN order, then let the restore job resume. Verify with RESTORE HEADERONLY that its FirstLSN/LastLSN slot between the last restored file and the next scheduled one.
If the .trn is lost: reinitialize the secondary from a fresh full backup WITH NORECOVERY.
Prevention: take ad-hoc log backups WITH COPY_ONLY.