We are looking into doing the same thing. So far, the only downside is longer restore times. You will have to perform more tasks in order to get the restore done. We are going to archive off parts of our catalog, then run some restore test to see exactly what needs to be done, and how long it will take.
jaggi,
below mentioned are the steps for catalog archiving
Step 1: Use bpcatlist to determine what image files will be archived.
Before attempting to run bpcatarc or bpcatrm use the bpcatlist command to display what images are available for archiving. Running bpcatlist alone will not modify any catalog images. Only when the bpcatlist output is piped to bpcatarc and bpcatrm will the images be modified and the image .f files removed.
To determine what images are available for catalog archiving, run the following command:
# /usr/openv/netbackup/bin/admincmd/bpcatlist -online
To determine what images have been previously archived run the following command:
# /usr/openv/netbackup/bin/admincmd/bpcatlist -offline
Note: This should return "no entity was found" if catalog archiving has not been previously run. For more information on what the fields in the bpcatlist output indicate, refer TechNote 273999.
To display all images for a specific client prior to January 1st, 2000 run the command:
# bpcatlist -client -before Jan 1 2000
To display the help for the bpcatlist command run the command:
# bpcatlist -help
Once the bpcatlist output correctly lists all the images that are to be archived, then the archive itself can be run.
Step 2: Running the catalog archive.
Before running the catalog archive, create a catarc schedule. This is required in order for the bpcatarc command to successfully process images. Refer to the 5.x System Administrator's Guide or TechNote 274028 for more details on creating a catarc policy. When initiated, the catalog archive will create a Job ID for each time the catalog archiving is run.
To run the catalog archive, run the bpcatlist command with the same options used in step 1 to display images. Then just pipe the output through bpcatarc and bpcatrm.
Eg. # bpcatlist -client all -before Jan 1 2000 | bpcatarc | bpcatrm
A Job ID will appear in the activity monitor. The command will wait until the backup completes before returning the prompt. It will report an error only if the catalog archive fails. Otherwise the commands will simply return to the prompt. The File List: section of the Job Details in the Activity Monitor will show a list of image files that have been processed. When the job completes with a status 0, the bpcatrm will remove the corresponding .f files. If the job fails, then no catalog .f files will be removed.
Step 3: Restoring the Catalog archive
To restore the catalog archive, you must first use the bpcatlist command to list the files that need to be restored. Once bpcatlist displays the proper files to restore, then the bpcatres can be run to restore the actual files.
To restore all the archived files from Step 2 above, run the command:
# bpcatlist -client all -before Jan 1 2000 | bpcatres
This will restore all the catalog archive files prior to Jan 1, 2000.
Some miscellaneous notes about catalog archiving:
In the /usr/openv/netbackup/db/images// directory, a header and files file will be created for the catalog archive job.
The header file will be named: catarc_
1) All in one place, no extra steps required to restore images that have been archived; initial time to implement f/s increase; length of catalog backup will increase.
2) Extra steps for restore of archived images; initial time to go through correct procedure to archive catalog; less time to backup catalog.
Suppose it depends on the likelihood of restores from your archived catalog.
However, there are two things to keep in mind. It is critical to keep a recent catalog backup. Very large catalogs, like 750 GB+ take a very long time to backup and restore. This can be a problem in a DR situation, although there are way to work around the issue depending on what you need to recover.
Secondly, you need to take a hard look at what is driving catalog growth. Are your retentions in line with business drivers and legal requirements. If you really need long retentions which may never get restored, catalog archiving can really solve a problem. On the other hand, you may need to look into a real archiving solution, which is made for the archive use case - Enterprise Vault from Symantec comes to mind.
I agree to Tim - we really need to look at what caused the huge catalog growth.
My experience is many business do have backup solution but NO archive solution, therefore we (business decision, not mine) had to use NetBackup to store long retention (i.e. indefinite expiration date) backups and so the NetBackup Catalog kept getting bigger. It appeared to business that we were saving money by not implementing a real archive solution, but it hurts the daily backup operation as well as DR.
