Jump to content

Differential and Log backups won't run


emulator

Recommended Posts

Hi All...

 

I thought that I'd pass along a little tidbit of info on a problem and solution that we found. Over the past week, we had a problem with a SQL Server 2005 client, and had to completely reset it up. Our DB admin wanted to do this manually, and not with via backup. After he did this, any Log of Differential database backups on Retrospect always defaulted to FULL; the reason given in the log was that no full database backups existed, even though there were several Full backups in the set.

 

After doing some checking in the Restore-->Database, the database in question had TWO entries: one before the resetup of the SQL Server, and one after. They were both named the same, and were on the same Windows Server. Apparently, Retrospect was getting confused as to which database actually contained the Full database. I removed the database entry before the SQL server resetup (via the "forget" function), and the database backups started working correctly.

 

While on this line of thinking, I found several other "stale" entries in the database snapshot display, some showing database snapshots belonging to backup sets that no longer exist on the server. I removed these.

 

Is there a more automated way of pruning these entries? Perhaps when a backup set is forgotten, any database snapshots could be automatically removed.

Link to comment
Share on other sites

Now that I am going through more of our snapshots in our databases, it appears that there are a BUNCH of old, stale snapshots belonging to backup sets that do not even exist on the server any longer. These number into the HUNDREDS. Is there a way to get rid of these other than removing them one by one? I have tried the following:

 

1. created a new backup set with the same name and location as the non-existent backup set shown in the database snapshot screen

2. backed up miscellaneous data to this backup set

3. recycled the backup set

4. forgotten the backup set from retrospect

 

None of these have worked.

 

Is there a reason that these snapshots have built up? The only reason that I can think of is that our Retrospect Server has experienced several crashes since upgrading to version 7.6 (assertion error crashes). Could this have something to do with these stale entries?

Link to comment
Share on other sites

OK...I got tired of removing the stale snapshots one by one. I decided to completely remove the entire SQL server in question from the database backup reports editor. This took several minutes, as expected (there was a LOT in there, some dating back to several months ago). I then did a Disk Backup Set Rebuild on the most recent SQL server backup set. This appears to be re-populating the Database Backup History with the proper snapshots.

 

I have a sneaking suspicion that all these stale entries were confusing Retrospect and possibly forcing the program to crash with the Assertion error (Retro always seemed to crash on the SQL server backups, despite creating new backup sets).

 

Robin, does this sound like I'm on the right track? In any case, I hope that this threat proves useful to others.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...