Failed SQL Restores That Actually Succeed

This week's adventure in disaster recovery has been with one of our in-house SQL applications. The application has several databases that need to be restored and we find that the Backup Exec restore job is reported as having failed with the error of "V-79-65323-0 - An error occurred on a query to database ." This error doesn't prevent SQL from using the databases properly and hasn't appeared to affect the application.

Once the job completes Backup Exec also warns that the destination server requires a reboot. We are speculating that Backup Exec is unable to do a validation query to the restored database due to the need for the reboot, so the error is somewhat superfluous.

We are going to experiment a bit to see if turning of the post-restore consistency checks eliminate this error in the future, but for the moment we just opted to note the error in our recovery documentation so we don't spend time worrying about during another test or during a real recovery scenario.

We've also found that for some reason, it's very important to pre-create subfolders under the FTData folder before restoring the databases. If these folders related to the full text index aren't available the job will fail, too. This has required our DBA to write some scripts to have available in the event of the restore to create these directories, as well as drop and recreate the indexes once everything is restored.

While I appreciate learning more about the database backend of some of our applications, I'm so glad I'm not a DBA. :-)