Jump to content

Re-catalog doesn't work on large Backup sets


Recommended Posts

I have been reading some traffic on this forum lately about people having trouble rebuilding backup set catalogs from large backup sets. I ran into this problem last week after trying to do a restore and finding the catalog was corrupt. The set was big by Retrospect standards, 1.8TB . 2 1/2 million files, on 12 tapes, but still well within the system limits in terms of the number of snapshots and sessions.

 

When I went to rebuild the catalog using the | tools | repair catalog | recreate from tape | option the system came back and told me that there was no catalog on the last tape in the set (tape 12). Through trial and error I discovered the last time the system wrote a catalog backup to the beginning of one of the backup tapes was Tape 5. So, Tapes 1 through 5 had a valid catalog backup it could rebuild from, Tape 6 though 12 did not. I could have left Tape 5 in the drive and read it and all the subsequent tapes (6 - 12) sequentially through to recreate the catalog but that would have taken at least 24 hours (3 hours to read each tape). I only have one drive, so while this process is going on for hours on end, I am not doing any backups. That's a problem. So, I choose to bag it and restore the client from a 3 month old backup tape set. We lost some data and it was pain for the desktop client. Had it been something really important, like the e-mail server or one of our customer facing database servers, waiting 24 hours to recover a catalog would have been disastrous.

 

I detected this bug on the most current release of 7.0 Retrospect, but just for grins and giggles I tried rebuilding a catalog from an old set of tapes written with Retrospect 6.5. The same problem existed there also.

 

In the year and half I have been using this product, I have never had an occasion to rebuild a catalog from scratch. I have restored a lot of data in my shop without incident. So, I must say I was quite astonished last week when I could not restore a system in a timely manner.

 

I called Retrospect tech support as soon as I discovered this problem. Yes, they were certainly sympathetic about my problem and yes, they had heard about this issue from one or two other clients, and yes, they said the would pass the matter on to their QA department.

 

Let's hope Dantz programmers get there hands around this bug pronto.

Link to comment
Share on other sites

  • 2 weeks later...

Hi

 

This is by design.

Catalogs can get really big. After a certain point the fast catalog rebuild function stops adding the catalog to each tape because it takes up too much space on tape.

 

How large is your catalog file now?

 

Thanks

Nate

Link to comment
Share on other sites

Our catalogs are about 1.5GB. We use AIT-3 tapes with hardware compression and are getting anywhere from 150GB to 200GB per tape. Personally, I think storing the catalog at the beginning of each tape is a nice insurance policy against catalog corruption. I wouldn't mind the small amount of tape it uses if it meant I could recover the catalog faster.

 

As I mentioned in a previous post, I have already had the misfortune of a unrecoverable catalog error because of this so-called "by design" feature of Retrospect. Recovering the catalog from a large set of tapes read sequentially is not acceptable, especially when I have to recover important data in a hurry. It takes too long, in my case 24 hours or more just to recover the catalog.

 

There has got to be a better way of doing this. Why not store the changes to the catalog since the last backup tape (i.e. delta) at the beginning of each tape. That way you would only have to read a short bit of each tape in the set to recover the whole catalog. In our case it would be a few hundred megabytes on all 12 to 14 tapes in our set. I don't think that is a huge hit on tape capacity.

Link to comment
Share on other sites

Hi,

 

This may not be of any consolation now but here is a good strategy that I would recommend when dealing with large catalog files and multiple tape members:

 

Setup a duplicate script that runs prior to the backup script and copies your catalog file/s to a different location. This way, if the catalog somehow gets corrupted, you can just reference the saved copy of the catalog file and just run an "Update Existing Catalog" and put in the most recent tapes.

Link to comment
Share on other sites

Hello,

 

I run several times into problem of the catalogs' recovery. My catalogs are backed up to a separate set, but I had mixed results with "Update catalog" function. I'm even not sure, how do I re-direct recovery to another copy of the catalog, if original catalog is corrupted.

 

Let's see:

 

1. The original catalog gets corrupted.

2. I'm restoring the catalog file from latest known good backup of separate_set_for_catalogues_only.

3. I'm closing Retrospect, renaming corrupted catalog file, and moving freshly restored catalog file to apropriate location.

4. Opening Retrospect, getting "Out of sync" error, going through "Update from tape".

 

Is it a correct way, or am I missing something?

 

Thanks G-d, right now all my catalogs seem fine - running random restore tests weekly...

Link to comment
Share on other sites

Hi,

 

Backing up your catalog files to a separate set is also an excellent setup.

The steps you listed were correct. If you are getting an "Out of sync" error, that means the data on the tape is not matching the contents of your tape.

This can happen if the catalog you restored is still bad (might want to restore an older catalog and try again).

This can also happen if there is a device communication error ie. bad tape/scsi card/scsi cable, clean the tape drive.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...