Unsolved
This post is more than 5 years old
96 Posts
0
1000
November 26th, 2010 22:00
Cannot restore SQL DB from full Backup
Good Day All,
I have just come accross one of the worst experiences ever with SQL restores.
We regularly do resores from full DB backups and it always works fine, with no errors.
However we werent so lucky this time...
We running a windows 2008 platform client and NetWorker server.
we running 7.5.2 on Server and clients.
I tried restoring a copy of a full DB backup from our prod server into the QA server.
I selected to restore the full backup and checked which media the backup was on and it displayed the correct tape.
However when the restore is started it mounts a tape from a different pool and tries to restore from an incremental backup.
the tape is loaded on which the incr backup is on and tries to recover the incr file.
the restore then fails reporting the following - The log or differential backup cannot be restored because no files are ready to rollforward.
This doesnt make sense to me because I select the full backup and it shows me the tape the full backup is on, but still tries to restore the incr.
I have opened a SR with support team and they have been helping me but still no luck.
I have even tried running the restore from the command line and this took the production DB offline - OMG.
Has anyone come accross anything like this ??
any input would be appreciated...
Thanks
Umraan
96 Posts
0
November 27th, 2010 07:00
Found the solution.
SQL server grants each backup (incr or full) a sequential number which was not in the correct order. So, the incremental finished first, SQL gives it a 'n' sequence number, then the full ends, getting a 'n+1' sequence number. The correct sequence is that the full gets 'n' and the incr gets 'n+1'.This caused the restore to fail.
SO what we done was change the DB mode to simple mode and disabled the log backups as well and then started the full backup.
After the full backup completed, I started the restore and the correct tape was mounted which had the full backup on it.
It was no longer looking to recover the log backup because the full DB backup gave it a new sequence number.