April 1, 2009 at 2:55 pm
I'm trying to set up mirroring between Server A and Server B. On Server A I take a full backup and a transaction log backup. I copy the 2 files over to Server B then restore with norecovery the full backup, which works fine. Then I try to restore the transaction log backup with norecovery but get the following error:
The log in this backup set begins at LSN 24000000020700001, which is too recent to apply to the database. An earlier log backup that includes LSN 24000000020000001 can be restored.
Again, I did a full backup then a log backup on Server A, less than 1 minute apart. Restored the full but couldn't restore the log backup on Server B. What am I missing?
Thanks,
Tim
April 1, 2009 at 3:07 pm
TimC (4/1/2009)
IThe log in this backup set begins at LSN 24000000020700001, which is too recent to apply to the database. An earlier log backup that includes LSN 24000000020000001 can be restored.
You are missing a log backup which begins with LSN 24000000020000001, I know you have backed up Full and then Tran freshly, but its strange.
Query the backup set table and see what you can find and post it here please?
April 1, 2009 at 3:32 pm
I figured out my problem. I had a prior backup set in the .bak and .trn files and that was apparently confusing it (or more likely me). I did another full backup, this time using the REPLACE option to remove the prior sets and a tail log backup and that fixed the problem. Thanks for your help.
-tim
April 1, 2009 at 3:32 pm
TimC (4/1/2009)
What am I missing?
A transaction log backup.
Do you have scheduled log backups? Could one of them have run between when you took the full backup and when you took the log backup? If so, you need to find that log backup and restore it on the mirror after the full, before the log backup you took.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 1, 2009 at 3:38 pm
GilaMonster (4/1/2009)
TimC (4/1/2009)
What am I missing?A transaction log backup.
Thanks GilaMonster.
Reading previous posts, I had a feeling that you were going to say that. 🙂
April 1, 2009 at 3:42 pm
TimC (4/1/2009)
I figured out my problem. I had a prior backup set in the .bak and .trn files and that was apparently confusing it (or more likely me). I did another full backup, this time using the REPLACE option to remove the prior sets and a tail log backup and that fixed the problem. Thanks for your help.-tim
From Bol:
For a database using the full or bulk-logged recovery model, SQL Server 2005 requires in most cases that you back up the tail of the log before restoring the database. Restoring a database without first backing up the tail of the log results in an error, unless the RESTORE statement contains either the WITH REPLACE or WITH STOPAT clause
:pinch:
April 1, 2009 at 3:59 pm
Krishna Potlakayala (4/1/2009)
From Bol:For a database using the full or bulk-logged recovery model, SQL Server 2005 requires in most cases that you back up the tail of the log before restoring the database. Restoring a database without first backing up the tail of the log results in an error, unless the RESTORE statement contains either the WITH REPLACE or WITH STOPAT clause
:pinch:
That's when you restore a database over the existing database. It does not apply, and is not in any way relevant, when restoring a database on a different server from the one where the backup was taken.
In addition, the error received in the situations where that is the case is completely different from the one Tim reported.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 1, 2009 at 4:02 pm
TimC (4/1/2009)
GilaMonster (4/1/2009)
TimC (4/1/2009)
What am I missing?A transaction log backup.
Thanks GilaMonster.
Reading previous posts, I had a feeling that you were going to say that. 🙂
😀
Glad you appreciate it.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 1, 2009 at 4:08 pm
GilaMonster (4/1/2009)
K
In addition, the error received in the situations where that is the case is completely different from the one Tim reported.
Oh! thanks Gail you clarified it, I was a bit worried to see what's going on with this. actually i posted that by mistake :-P, i was testing it until i saw 'notifications' email popped up in my inbox:-D
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply