What are the challenges you face when working across database platforms? Take the survey

LogShipping LSN Error

RazorWingRazorWing Posts: 2
edited February 4, 2010 10:25AM in SQL Backup Previous Versions

Everyday i keep receiving the following flavoured message regarding logshipping failing to restore. I understand partly why this is happening and how to fix it but i dont understand why it only happens once or twice a day.
02/02/2010 11:04:01: SQL error 3013: SQL error 3013: RESTORE LOG is terminating abnormally.
02/02/2010 11:04:01: SQL error 4305: SQL error 4305: The log in this backup set begins at LSN 106965000007070200001, which is too recent to apply to the database. An earlier log backup that includes LSN 106965000007068900001 can be restored.

I currently have two SQL Backup jobs running which backups the transaction logs:
- Logshipping which takes a backup every 5 minutes
- Transaction Log which takes a backup every hour

Most of the time, both jobs run perfect but on the odd occasion, i get the above message and i have to restore the log from my hourly backup before LogShipping can resume restoring.

I have checked the LSN numbers on the backups taken by the transaction log job and both the first and last LSN numbers are the same on most backups except where it causes the logshipping to fail.

Is there anyway i can run both these jobs together? Can i prevent the hourly transactional job from breaking the logshipping without disabling or removing the job? and why does the LSN on the hourly transaction increase randomly? I was unable to find my answer on the forum here so i am hoping someone might be able to help.



  • Options
    Hi Andrew,

    It seems to me the problem here is that you have a transaction log backup job set up outside of log shipping.

    When a log backup is taken (which is essentially what is happening within log shipping) the log is assigned an LSN. These are then restored in order on the target DB, giving you a replica of the source.

    If you take a log backup out of the log shipping job on the source, the subsequent log restore on the target will fail, as there will be a log missing.

    I would advise you to take full backups / differential backups outside of the log shipping jobs rather than transaction log backups every hour along with the log shipping job.

    Peter Peart
    Red Gate Software Ltd
    +44 (0)870 160 0037 ext. 8569
    1 866 RED GATE ext. 8569
Sign In or Register to comment.