NBU 6.5.4 Catalog maintenance

[ADDODD]

Hi gang,

I'm looking for opinions on NBU catalog maintenance.

Is compressing the catalog (Global Attributes) a good idea?  if so, at what interval?  any gotcha's or issues?

I'm planning to set this to 16 days to compress data that's more than a few weeks old.  When we do restore jobs, it's typically from the most recent or the previous most recent backups.  We rarely need to go back more than that..

Also, how often should the catalog be "Archived" (referring to the "Archiving the catalog" section of the admin guide)?

I'm planning to do it once per year.  can it be done more frequently?    How do you determine how often to do it?  Does it archive the catalog to tape, or move to another disk (or does it depend on the special catarc policy defninition)?  any gotcha's or problems?

thanks!

ADDODD

[Mouse]

Catalog DB tends to grow in time, so time to backup it grows as well and compression is a really good thing.

But archiving is really poor-man solution - leave it as last resort...imho

[Alex_Korovin]

What is the size your catalog and its growth rate?

[dustin_yonak]

Hello ADDODD, here are some options for you for controlling the size of your catalog:

1) Move all or some of the catalog data to a different disk. See technotes http://support.veritas.com/docs/323708 and http://support.veritas.com/docs/323700 and the admin guide for the use of the ALTPATH file.
Pros: Does not affect the abilityto restore or the speed of restores for any data in the catalog. Frees up space on the NBU install disk to avoid disk full/EMM crashing situations.
Cons: No decrease in the total amount of space the catalog is taking up, thus no decrease in catalog backup time..


2) Enable catalog compression. Set the "delay to compress" value in the master servers host properties and then run a "bpimage -compress -allclients".
Pros: Nice, steady reduction in catalog size. Self-managing once you've specified the delay.
Cons: Restores from beyond the delay period will be slower to browse/initiate. Initially uses a lot of system resources as it's compressing a huge chunk of the catalog (from the delay back to the beginning of your NBU backups), this goes away after the first time and it's a small overhead at that point.

3) Configure catalog archiving.
Pros: Ideal for situations where you have backups that you have to hold for a long period of time but do not expect to regularly restore or list the backed up files.
Cons: More management is required; in the event of a restore from a backup that's in the archived portion of the catalog you'll need to perform 2 restores (one for the catalog and one for the desired data)

Here are the recommendations for catalog archiving from the Admin Guide:
■Perform catalog archiving operations when NetBackup is in an inactive state (no jobs are running).
■To ensure that catalog backup images are not on the same tapes as user backups, create a separate media pool for catalog archives.
■You may find it useful to set up, then designate, a special retention level for catalog archive images. To specify retention levels, go to Host Properties > Master Server > Retention Periods or see “Retention Periods properties” on page 462.

Overall I would recommend avoiding Catalog archival unless you're quite certain that you won't be needing to restore from that data. Catalog compression is a better fit for most environments due to the lower amount of administrator oversight needed. If the catalog backup time isn't causing problems and you have the option to move all or some of the catalog to another volume that would be ideal.