Retrospect 7 can't restore from duplicate of backup set

[gvanden]

Retrospect Multi-Server 7.0.265 and Retrospect Update 7.0.3.101

 

We back up to disk backup sets stored on a RAID. When a backup set reaches 279 GB, we duplicate it to a 279 GB FireWire drive, delete the backup set from the RAID, and store the FireWire drive for safekeeping. If we need to do a restore, we attach the FireWire drive and change the catalog properties so that the catalog points to the FireWire drive. This has always worked in Retrospect version 6.5. (We initially did transfers but were constantly running out of memory and crashing.)

 

But now with Retrospect 7, when I try to do this, Retrospect keeps looking on the RAID for the backup set and of course doesn't find it. I tried changing the drive letters and the volume labels, but Retrospect isn't being fooled. The Operations Log has entries like "Can't read to file F:\Retrospect\Macs 050107\1-Macs 050107\AA001199.rdb, error -1101 (file/directory not found)", where F: is the RAID. "Trouble positioning: 'Macs 050107' (70623877), error -102 (trouble communicating)."

 

Is it no longer possible to modify the catalog for a disk backup set so that it looks for its data folder on a different volume from which it was originally?

[natew]

Hi

 

Many changes were made to disk backup sets to accomodate grooming and snapshot transfers. I wonder if this is a by-product of those changes?

 

Will the set work if you do a catalog rebuild?

 

FWIW memory management has been greatly improved in Retrospect 7. Backup set and Snapshot transfers should work well for you now.

 

Thanks

Nate

[gvanden]

Thanks for your reply.

 

I tried updating the catalog instead of rebuilding but that didn't help. (I didn't want to do a rebuild because I was afraid it was going to take too long.) Fortunately, I only needed to restore a few files and the Operations Log told me Retrospect only needed two .rdb files. I duplicated those back to the original volume and did the restore from there.

 

Now I'm transferring the filled backup sets to FireWire drives instead of duplicating them. After I delete the original backup set from the RAID, can I delete the corresponding catalog file, or will I lose all references to that backup set in the Backup Report?

[gvanden]

As a follow up, I had to restore a folder from another disk backup set that had been moved to a FireWire drive via duplicate. I didn't bother changing the properties of the backup set to point to the FireWire drive. I was expecting it to log errors and list the .rdb files it was looking for, which I would then duplicate back to the original RAID, but this time, it displayed a dialog box asking me to locate the "missing" backup set member. I browsed to the FireWire drive and drilled down to the folder where the .rdb files were, but Retrospect never let me select anything. It did give me a "Choices" button. When I clicked that, it gave me the option of choosing whether the member was missing or to browse to the specific .rdb file it wanted. I browsed to the FireWire drive and selected the .rdb file it wanted. In this case, it only needed one, and it was able to complete the restore successfully.

 

So maybe we don't need to do a backup set transfer to get if off the RAID and on to the FireWire drive. We can still just duplicate it, which takes less time and doesn't create another catalog file. Hopefully, the typical restore won't require selecting too many .rdb files.

 

Now in the case of backup set transfers, am I correct in assuming that if I delete the original catalog file afterward, I won't lose any history of those backups from the Backup Report as long as I don't *forget* the backup set from the database?

[natew]

Hi

 

That is correct. As long as Retrospect still thinks the set is there the backup report will contain information about it.

 

Thanks

Nate