7.6 seems to need to constantly repair catalogs

[eec]

I've just updated a couple of clients to 7.6 and now when they switch their external hard drives, it takes almost an hour for Retrospect to close. I can see the hard drive light flashing like crazy, just as it does when a Repair Catalog is done. I'm guessing this is happening automatically because 7.6 has also requested a Repair Catalog before a backup can be run after a switch.

 

7.5 didn't have this problem. We could simply copy the catalog file to both external hard drives (so one can live off-site) and the scheduler would happily assume the same hard drive was present for every backup.

 

Does anyone know if there is a change made in 7.6 that can be overridden or if there is another more reliable way to switch external hard drives in 7.6?

 

Thanks...I've logged in, written this and still the program hasn't finished repairing a 15 GB backup set! Grrr...

[Mayoff]

If a catalog repair is needed it will show in the log.

 

It is actually impossible for Retrospect to perform a catalog rebuild during the "closing" phase of a backup. Retrospect is probably doing a backup of your registry and other system state items. A 15G backup set is very small. My backup sets are over 2 TB in size and updating the catalog doesn't take very long.

 

[eec]

Thanks for your reply, Robin.

 

I think I have more accurate information now; something that takes 30-45 minutes is going on (I got trapped for 5 hours trying to figure this out, so it is not a quick process, whatever is going on).

 

This is what I do and ask clients to do:

 

once a week, swap external hard drives during the day. Retrospect is scheduled to run at night when all the machines are logged out. 7.5 had no or few issues with this procedure; occasionally a catalog repair was required.

 

Now, as I painfully tested, every time a hard drive is swapped, when Retrospect exits, it checks the backup sets on the hard drive to see if the media is ready. This happens even if no backup has been run during that session of Retrospect. If the media isn't the one last written to (i.e., the newly swapped hard drive), it does something on the external drive for 30-45 minutes. The internal hard drive light is also on a lot, but the external drive's light is constantly flashing, indicating full-on use.

 

Retrospect locks out the drive so it can not be "safely removed" from within Windows XP Pro (which is fully updated) and Retrospect is considered to be "Not responding" by Windows until it completes this unidentified process and prompts whether to check if the media is ready or just exit.

 

Hopefully this clarifies what is going on. I think I can modify my client's routines to accommodate this new behaviour in 7.6, but I would like to know what is going on and why, if possible.

 

If there is a way to be more explicit within Retrospect about the swapping, that would be preferable as well; as it is, the drives are swapped and Retrospect doesn't know about it, since the backup set's file name is the same on both drives.

 

Thanks again for any help or insights that come my way.

 

 

Edited August 9, 2008 by Guest

[MRIS]

Oh dear! It's not retrospect that is misbehaving, it's the user!

 

If you're swapping drives, then each drive should contain a uniquely named backup set. For example:

 

Disk 1 should contain Backup Set A

Disk 2 should contain Backup Set B

Disk 3 should contain Backup Set C

 

If I understand you correctly, you're saying that you have it like this:

Disk 1 contains Backup Set D

Disk 2 contains Backup Set D

Disk 3 contains Backup Set D

 

which is a VERY BAD IDEA!!!

 

 

For one thing, each time you swap disks, retrospect's idea of what is supposed to be in the backup set (its catalog) is immediately inconsistent with the contents of the backup set presented to it. You are confusing the hell out the software and no wonder it is struggling to understand what is going on.

 

 

My advice to you is to re-design the backup scripts so that you have uniquely named backup sets as I explained above, one backup set per disk, and each backup set name only used on one disk.

 

For example, if you have 5 disks, then the following might work:

 

Disk 1 contains backup set Monday

Disk 2 contains backup set Tuesday

Disk 3 contains backup set Wednesday

Disk 4 contains backup set Thursday

Disk 5 contains backup set Weekend

 

Then you simply have 5 scripts, that backup to their backup sets on the appropriate days, eg:

 

Script Monday runs on Mondays and uses set Monday

Script Tuesday runs on Tuesday and uses set Tuesday

Script Wednesday runs on Wednesday and uses set Wednesday

Script Thursday runs on Thursday and uses set Thursday

Script Weekend runs on Sunday and uses set Weekend

 

 

 

 

Edited August 10, 2008 by Guest
gave example setup to use

[eec]

Thanks for your thoughts and suggestions.

 

I think I forgot to mention that whenever a swap is done, the next backup is a Recycle, so your concerns are simply overwritten...or at least used to be before the new behaviour in 7.6.

 

The other thing is that this happens in a non-IT supported environment: the goal is simplicity for non-technical users, rather than technical perfection. Obviously the backup needs to be restorable, and so far it has. The swap happens once per week, which is as complex as most clients can handle (your suggestion is great for an IT person, but complex to the point of not-going-to-happen for a non-IT person).

 

If anyone can let me know what Retrospect is actually doing, that would be very helpful in determining whether to live with this new behaviour or not...