Jump to content

Bug - Recreating a catalog file removes the backup set from all scripts


Recommended Posts

Since switching to a disk-disk-tape backup strategy about 8 months ago, every month or two we end up with a corrupted catalog file on a disk backup set. I should know better by now, but I always seem to forget that recreating a catalog file also removes the backup set from all scripts.


I doesn't make any logical sense from a user's perspective that repairing a backup set would remove it from the scripts. The end-result is that by fixing one problem (repairing a corrupted catalog) I inadvertently cause more problems (scripts with a missing source or destination).


At best this is an annoyance, because we have about a ten different scripts that we have to manually fix each time. But it's also a very serious issue because a missing item in a script means data is not being backed up. Even worse, it does not cause any errors to be logged and the problem can go unnoticed for days or more. Last night our main server backup script had no Destination, and failed without any notification, after I "successfully" recreated a catalog file yesterday afternoon.


I strongly suggest this issue be moved near the top of the list as a "bug that causes backups to fail silently".


In the meantime, is there any way to recreate a catalog file without corrupting the scripts?


We're using Multi-Server 7.5.508.

Link to comment
Share on other sites

The wizard asks if I want to "forget" the existing catalog file, not the entire backup set. The catalog file is corrupt, so of course I want to forget it. There is no indication or expectation that performing a routine maintenance/repair operation on a backup set will corrupt my scripts.


I call it a bug because we're talking about backup software and the issue has caused me to miss numerous "scheduled" backups. If you want to call it a feature request, fine, but I really hope the feature that allows me to fix a catalog without breaking the scripts gets implemented before I lose data. (Or better yet, fix whatever issue corrupts the catalogs to begin with.)

Link to comment
Share on other sites


The wizard asks if I want to "forget" the existing catalog file, not the entire backup set.



The existing catalog file is record of the backup set. Of course retrospect is going to recognize that the backup set that used to be, is suddenly non-existent. Even if it is to recreate, it does state that the existent catalog will be forgot.


I do agree however that maybe a pop-up saying, "scripts created using this backup-set as a source will be nonfunctional" or something to that affect might be nice. Though this certainly wouldn't be a bug.

Link to comment
Share on other sites

From the User's Guide page 251:

You can remove a Backup Set from the Backup

Set list by selecting it and clicking the Forget

button. Click OK when prompted to remove the

Backup Set. Forgetting a Backup Set does not

affect the contents of the Backup Set, nor does

it delete its Catalog File. However, it does re-

move the Backup Set from any scripts that use



Page 324 of the User's Guide:

After forgetting a Catalog, you must add the Backup

Set to your scripts again because Retrospect removes them when you forget the Catalog


Now that you know how the program is designed, you will hopefully remember that you must modify your scripts after forgetting the catalog file. Will we change this in the future, hopefully we will.

Link to comment
Share on other sites

Ok. To me it's a bug and to you it's a feature. As a programmer I'm familiar with that argument. I have been using Retrospect for years and know that this behavior is how it has always been.


I decided to finally report it as a bug because I have come to consider it a very serious flaw in the design of the UI. It has burned me multiple times, and when it happens my scheduled backups don't run. I only caught it this last time because I actually remembered to check if that specific backup succeeded the next day. There was no error, no warning, no e-mail, only a single sentence on p. 324 of the User's Guide and one missing entry (among dozens per day) in the history log.


If I hadn't thought to check it that day, it's hard to say how much time might have passed before I noticed the missing entry. There's a good chance I wouldn't have noticed it until someone asked me to restore something.


I agree with JMcIntire that at minimum there should a clear warning pop-up whenever scripts will be automatically altered in any way. Don't assume everyone has read and remembers p. 324.


But even then, having to manually go back and fix numerous scripts every time I recreate a catalog is still a major annoyance. It takes time figure out which scripts were affected and then fix them. It also makes it very easy to miss a script, or to accidently change something else while trying to re-add the deleted backup set.


A much better solution would be to simply ask the user if he'd like the scripts to be automatically modified. The current design is obviously meant to preserve referential integrity between the scripts and the backup sets. In this case, however, I'd argue that it's better to allow the possibility of a broken reference in a script. A broken reference would at least generate an error when the script runs, rather than failing silently as in the current design. When recreating a catalog, the reference should only be broken temporarily, if at all.


I think the central flaw in the UI is that a user doesn't naturally associate repairing a backup set with forgetting a backup set (even though I now realize that's how the repair works internally). The fact that I'm trying to repair it would seem to imply that I do NOT want to forget it.


In summary, I guess it all boils down to two requests:

- Allow the user to repair a backup set without forgetting it.

- Never modify scripts without asking the user. Scripts are sacred. Once they're tested and working, they should never be modified behind the scenes.


Thanks for all your responses.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

here's a workaround that may work for some people:


1. exit retrospect.

2. zip this folder:

C:\Documents and Settings\All Users\Application Data\Retrospect\

3. start retrospect, recreate the catalog from disk, overwrite the catalog file.

4. exit retrospect.

5. unzip the folder from step 2

6. launch retrospect which has the scripts intact.

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.

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.

  • Create New...