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

Log Restore too recent to apply.

kepr00kepr00 Posts: 43 Bronze 2
edited March 7, 2009 3:58AM in SQL Backup Previous Versions
I am currently on SqlBackup
I have implemented a fully automated log ship restore process.

Periodically i receive this error.
SQL Server error
SQL error 3013: RESTORE LOG is terminating abnormally.
SQL error 4305: The log in this backup set begins at LSN 5258000001355000001, which is too recent to apply to the database. An earlier log backup that includes LSN 5258000001062700001 can be restored.

There is no danger of log file being applied out of order.
The procedure that i have implemented takes a log backup every 10 minutes, moves the file to the remote server and immediately restores the file to the backup server.

To correct the problem, I have taken one of two paths.
Path 1:(Works sometimes)
Delete the log file that excepted.
Run another log backup/restore.

Path 2:(Works all the time)
Delete the log file that excepted.
Run a full backup/restore for the DB that excepted.

What does this exception mean?
Steve T


  • Options
    peteypetey Posts: 2,358 New member
    That error means that another trx log backup needs to be applied before the current one can be applied. So in your example, you need to look for a trx log backup that includes LSN 5258000001062700001, and restore that, before restoring the current log (or perhaps there may be other logs that need restoring first).

    Firstly, you should check on the source server, for the trx log that contains LSN 5258000001062700001. You can do this by looking in the msdb..backupmediafamily and msdb..backupset tables. Once you have identified the file, you can probably tell if:

    1. someone has made a manual trx log backup, outside of your log shipping process, or
    2. the backup was created successfully by your log shipping procedures

    If it's 2, you will then need to check on the destination server if the trx log file was restored correctly. You can do this by checking the msdb..restorehistory and msdb..backupmediafamily tables. Possible outcomes:

    1. the file was not restored, in which case you'll need to check the SQL Backup logs to see if any errors occurred during the restore process. By default, the SQL Backup logs are stored in the C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\<instance name> folder.

    2. the file was restored, in which case, someone may have restored an earlier full backup of the database after that, which pushed the restore sequence back.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
Sign In or Register to comment.