Comments
1 comment
-
In each backup file that SQL Backup creates, it stores the LSN details of that backup in the SQL Backup header (the first 1024 bytes) of that file. As you rightly pointed out, this information is only critical for the batch SQL Backup transaction log restores.
The LSN details stored in the backup data as generated by SQL Server is always present, thus you can still restore the transaction log. You can verify this by running the SQL Backup RESTORE HEADERONLY command.
As to the source of the error, it's being generated because SQL Backup failed to retrieve the LSN details from the msdb tables. Could you please try querying the backup history tables, to see if you can retrieve the LSN details for the backups that raised error 760? E.g.SELECT a.backup_start_date, a.backup_finish_date, a.first_lsn, a.last_lsn FROM msdb..backupset a INNER JOIN msdb..backupmediafamily b ON a.media_set_id = b.media_set_id WHERE b.physical_device_name = <backup file name>
Thanks.
Add comment
Please sign in to leave a comment.
In the transaction log backup job I run, I have it set up to move the file to another location when it finishes the backup. When I get one of these errors the file is not moved. So since my log shipping job pulls the file from this secondary location it will fail, it attempts to apply the transaction log that occurs after the missing file and then that will fail with Easy fix, I just move the missing file over and kick off my restore job.
But this is where i am a bit confused, this is the file that generated the "760: LSN data from server is blank." error when it was taken. I run "restore sqbheaderonly" and I can see that it is in fact missing the LSN information. But this still restores. I am curious as to why this restores with out errors, and if I should really be doing something different, instead of just applying that transaction log.