Video Screencast Help

Catalog Archiving

Created: 04 Jun 2009 • Updated: 22 May 2010 | 8 comments
Jaggi's picture

We are planning to do catalog Archive on Netbackup 6.5 Unix server. Please anyone explain me the downside of Catalog Archiving.

Current catalog size: - 200 GB on 300 GB SAN space.

Compress catalog interval set to 5 days.

Please advice.

Comments 8 CommentsJump to latest comment

Criss R's picture

 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's picture

1. Adding more disk space to the existing catalog file system.

2. Archiving old catalog to Tapes.

Which will be the best option?

Andy Welburn's picture

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.

What's the impact in a DR situation?

Deepak W's picture


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__UBAK
The files file will be named: catarc__UBAK.f

Do not attempt to archive the catarc__UBAK image files. These are not archived by default. Attempting to archive catalog archives will make it nearly impossible to determine what files are needed for restoring catalog entries. The catarc__UBAK image files contain a listing of what catalog images were archived and need to be present and intact on the master in order to do a catalog restore.

The catalog archive images will also appear in the Backup, Archive and Restore GUI. The catarc policy is of type Standard so it will display the catalog archive backups along with the regular filesystem backups. However, this is not the correct method to restore archived files. Catalog archive files should be restored using the bpcatlist | bpcatres commands.

Running bpcatlist | bpcatarc |bpcatrm as listed on page 229 of the NetBackup 5.0 System Administrator's Guide 1 will archive the entire NetBackup catalog. To recover from this, run bpcatlist |bpcatres to restore all archived images. Then work with the bpcatlist command to determine what options are needed to archive only the desired images.

Some recommendations for catalog archiving:
Perform catalog archiving operations when NetBackup is in a quiet state. It is unknown what would happen to an active backup if bpcatlist | bpcatarc | bpcatrm was running during an active backup.

To ensure that catalog backup images are not on the same tapes as user backups, create a separate media pool for catalog archives.

below link is for your information

-- Deepak W (Kindly close the thread if your query is resolved)

Stumpr2's picture

Keep It Simple Stupid

I will never archive when disk space is so cheap.

VERITAS ain't it the truth?

TimBurlowski's picture

I like the idea of keep it simple as well.

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.

Technical Product Manger Symantec

CY's picture

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.

Jaggi's picture

At this movement I have decided to add more disk space to catalog file system. Thanks everyone for valuable suggestions.