Retrospect 7.7 Can't Groom or Recreate Catalogs for Backups Made by 7.6

[glam]

I have been using Retrospect to backup to a ReadyNAS NV+ for several years. I have used Retrospect 7.5 and 7.6 without problem.

 

I recently paid to upgrade to 7.7 (currently using 7.7.341), and I backed up a few times with it. Last night was my first backup with 7.7 that did grooming. (I had groomed using 7.6 in the past with no problem.)

 

Grooming failed with the following error:

 

"Grooming Backup Set Backup Set A failed, error -2241 ( Catalog File invalid/damaged)

"You must recreate the Backup Set's Catalog File.

"See the Retrospect User's Guide or online help for details on recreating Catalog Files."

 

When I tried to recreate the catalog file, I was told that some files were missing and that I could view them. When I tried to view them, Retrospect died with an error:

 

'Error info: Assertion failure at "db.cpp-174"'

 

There is a dump in assert_log.utx.

 

Then I just went ahead and recreated the catalog file (without viewing the missing files), it ran for a while but the log reported hundreds of missing files (as was reported above). [i wonder if the attempt to view the files died because there were more missing files than the software could handle.]

 

My log also ended with these two lines:

 

"After a Catalog rebuild, only the most recent backups for each source are stored in the Catalog.

"Older backups can be added by going to the Backup Sets' view Backups tab and clicking Retrieve."

 

Does anyone know where this "view Backups tab" lives and how I can do this Retrieve?

 

I also looked at operations_log.utx in C:\Documents and Settings\All Users\Application Data\Retrospect.

 

In it, I saw many pairs of lines of the following form:

 

"VLoc::vlocRDiskDoGetFInfo: 'AA016876.rdb': fileinfo.datapos=51,595,043, old max=64,096,177

"VLoc::vlocRDiskDoGetFInfo: >>>>>>>>>>>>>>>>Warning!!!! datapos is lower, file is neglected."

 

It seems that Retrospect 7.7 can't use many of the files in the backup set because it believes they're corrupted in some way.

 

I wonder if there is some problem with 7.7 using files that were created by earlier versions.

 

(Of course that shouldn't happen - none of this should be happening!)

 

I would be tempted to fall back to 7.6, but I know that a backup set used with 7.7 can no longer be used with 7.6. (I tried.)

[glam]

I tried using 7.7 to recatalog the same media on a disk attached directly to my PC (via USB).

 

I experienced exactly the same problems.

 

It appears that the problem is due to some issue with Retrospect 7.7 and the backup media.

 

The network and the NAS do not seem to be involved.

 

Has anyone been able to use Retrospect 7.7 to recatalog backup media that were created originally with earlier versions of Retrospect?

[dthede]

Yes. Here is something similar trying to rebuild a catalog from a disk-resident backup. "[ ]" contains my input.

Tools > Repair Catalog > Recreate from disks [OK]

All Disks > [My Computer] > [DiskXYZ (N:)] > Select a Backup Set to recatalog [users_Backup_Set][OK]

 

Several Notes about the preceding line: (1) that "Users_Backup_Set" is a defunct backup set that hasn't been used in 10 years (?), has no scripts using it, etc., has been "forgotten" AND, (2) that the actual backup whose catalog I'm trying to rebuild, has a name totally different name; AND (3) no other name besides "Users_Backup_Set" appears anywhere in the various dialog boxes from Retrospect. Apparently I am forced to use that name, no matter what. Continuing with procedure, then:

 

Are there any more disks in this Backup Set? [NO]

Backup Set Users_Backup_Set appears to be encrypted. Please enter the password: [Password]

Saving Backup Set Catalog File

Retrospect Catalog Files (No items match your search.)

File name: Users_Backup_Set.rbs (autofilled by Retrospect)

[click SAVE]

 

Message:

 

"The Backup Set data file name is invalid, cannot recatalog the set using these files."

 

Note also, the surprising History entry:

 

History Tab > Rebuild Operations Log

+ Executing Rebuild at 6/18/2012 11:34 AM

To Backup Set Users_Backup_Set

6/18/2012 11:34:14 AM: Execution completed successfully

 

I'd like some help on this, too.

[bobbodavis]

I see this problem repeatedly in my environment (also upgraded from 7.6 and currently using the latest version of 7.7) I even go through the process of repairing the catalog and am met with the "successfully completed message." In most case though, as soon as I try to view the backup set with the "repaired" catalog file, I am met, once again, by another message that the catalog file is still corrupt. How can it be corrupt if the new catalog file is created with only the data that it just built itself with after scanning the data sets? This happens propably 2-4 times a month in my environment. It's a vicious cycle because the catalog files get corrupt when retrospect crashes, but retrospect crashes trying to groom a backup set that has a corrupted catalog file and there always seems to be a corrupt catalog file somewhere down the line.

 

I've given up. Basically, I end up just having to build a whole new backup set and hope that I don't have to recover from the old one. I keep the old one as per our retention policy (just in case, but it's really pointless) and as soon as possible, delete the old backup set to free up space on the SAN.

 

Because catalog files are not reliable anymore, I've stopped grouping multiple systems into a single catalog file. It's not ideal to have a separate catalog file and backup set for each system, but at least when I run into this problem (which is frequent) I only lose the backup data for that one system, and not a bunch at one time. We're seriously considering a new backup solution such as CrashPlan, Acronis, or Backup Exec for clients. They are much more expensive, but sometimes, you get what you pay for.

[x509]

I see this problem repeatedly in my environment (also upgraded from 7.6 and currently using the latest version of 7.7) I even go through the process of repairing the catalog and am met with the "successfully completed message." In most case though, as soon as I try to view the backup set with the "repaired" catalog file, I am met, once again, by another message that the catalog file is still corrupt. How can it be corrupt if the new catalog file is created with only the data that it just built itself with after scanning the data sets? This happens propably 2-4 times a month in my environment. It's a vicious cycle because the catalog files get corrupt when retrospect crashes, but retrospect crashes trying to groom a backup set that has a corrupted catalog file and there always seems to be a corrupt catalog file somewhere down the line.

 

I've given up. Basically, I end up just having to build a whole new backup set and hope that I don't have to recover from the old one. I keep the old one as per our retention policy (just in case, but it's really pointless) and as soon as possible, delete the old backup set to free up space on the SAN.

 

Because catalog files are not reliable anymore, I've stopped grouping multiple systems into a single catalog file. It's not ideal to have a separate catalog file and backup set for each system, but at least when I run into this problem (which is frequent) I only lose the backup data for that one system, and not a bunch at one time. We're seriously considering a new backup solution such as CrashPlan, Acronis, or Backup Exec for clients. They are much more expensive, but sometimes, you get what you pay for.

I found this thread which seems to address the same grooming issue I have.  I've started a new thread.