Questions about rebuilding the catalog

[nicho1as]

We've never had a catalog go bad on us, but the thought scares the hell out of me. We use Retrospect for archiving our client files and typically we keep one catalog for each calendar year. So a catalog rebuild towards the end of the year might mean a really lengthy rebuild. Here's my question: if we keep iterative copies of our catalog, will a rebuild only be necessary to the last good copy of the catalog?

 

For instance, we notice that our catalog has gone whacky in June. But, luckily, we saved off a copy of the catalog the month before. So, we have a good copy of the catalog for January through May. Will rebuilding the catalog require us rebuild the entire (January-June) catalog from scratch. Or, can we simply append the known good catalog (January-May) with a rebuild of June.

 

I also know that there is an "Update catalog" feature. But the manual describes this as something we should do when catalogs are "out of date" or "out of sync". Could we use the Update catalog function in the way I'm describing?

 

Thanks for any insights.

[Lennart_T]

Quote:

---

I also know that there is an "Update catalog" feature. But the manual describes this as something we should do when catalogs are "out of date" or "out of sync". Could we use the Update catalog function in the way I'm describing?

 

---

I think that should work just fine. To be sure:

Create a test backup set of the type you are normally using. Backup some files. Quit Retrospect. Make a copy of the catalog file. Backup some more files. Quit Retrospect. Put the copied catalog file back and "Update catalog".

[smartin]

 

For a while, i was doing a lot of catalogue rebulds. A full rebuild scans in tape 1, then will ask you if there are more, and will keep doing that through the tapes. If you have a lot of tapes, it takes a long time, and a lot of babysitting, since it ignores what's in the autoloader. "update catalogue" is for corruption on theend of the storage set. The system goes to the end of the storageset, and then checks the last tape.

Testing is always a good idea, but this is the general idea: Say you have 20 tapes, and you regularly save storagesets. If the current set dissapears, and you've got a saved copy from, say tape 15, you'd do a 'update catalogue' and it would sniff the end of tape 15 and ask for tape 16. Saves time.

Also, sometimes it will say something like 'chunksum error' and ignore the whole storageset. backed up earlier copies are a good thing. Of course they can't be backed up to that storageset.

I run backup server, and stop it at 3 every morning for a half hour and do a duplicate of the storageset folder.

hope this helps.

-s

[nicho1as]

Well we did do some testing. Update catalog works like you'd expect. It will let you rebuild the catalog from only the latest data with the last known good catalog. Huge time savings. We'll definitely be saving of iterative version of our catalog.