Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cerebraljoylad

  • Rank
    Occasional Forum Poster
  1. cerebraljoylad

    Re-catalog doesn't work on large Backup sets

    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.
  2. 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.