Options
Log Restore too recent to apply.
kepr00
Posts: 43 Bronze 2
Hello
I am currently on SqlBackup 5.4.0.55
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?
I am currently on SqlBackup 5.4.0.55
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
Comments
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.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8