Why the Backup Exec Catalogs folder uses lots of disk space

Problem

Backup Exec maintains records of what has been backed up in a Catalog. In a default installation, the Catalogs folder is a subfolder of the Backup Exec installation path and is
typically located in C:\Program Files\Symantec\Backup Exec\Catalogs.

Over time the content of this folder can grow and consume large amounts of disk space , this article explains some of the causes for this, along with possible options for reducing the impact.

Cause

Whilst other file types may exist within the Catalogs folder,  the key files that make up the catalogs are . XML and .FH files and whilst  .XML files may be unaccompanied by specific .FH files, if .FH files exist, they will be paired with .XML files with matching names.

The .XML files contain information about the backup sets, such as details of the backup resource, backup date, backup type, backup device and media used. They can also contain statistical information about the set, like number of files, bytes, etc. These .XML files are typically small. However, as there will be one of these files per set, and resources such as C; D:, System State etc are separate sets even though they may be related to a single server, there could be a large number of theses files in the Catalogs folder.

The .FH files ( known as file history files) contain detailed information of what has been protected within the backup set. This includes object names, paths and other attributes of each object being backed up. Objects include individual files, e-mails etc. Any given backup set might contain a very large number of objects (number of files inside a volume, number of e-mails inside a mailbox database etc) and this directly affects the .FH file size and can result in very large .FH files. As a large byte count is not always indicative of a large number of individual objects, this cannot be used as a direct indicator of why a catalog is large.  This is because a backup involving 500 files that average 1GB each will create a larger .FH file than a backup containing 2 files of 250GB each. The existence or size of .FH files is also affected by the methods used to backup different resource types as defined in the selections and job configuration. Especially large NDMP filer backups to a Tape type storage or when large Exchange GRT enabled backup to disk device are duplicated to a Tape type storage, the size of the .FH file for each set can be in GB's.

The related .XML and .FH files are removed if a tape is overwritten or if a disk based set is expired and reclaimed.
Note: The overwrite of a tape will remove the catalog files for all backup sets contained on that tape.

The amount of .XML and .FH files in the catalogs folder is linked to :

• the number of resources that are backed up
• the backup set retention settings for backup to disk or deduplication devices
• when used tapes are overwritten, erased or deleted from Backup Exec (vaulted / offsite tapes cannot be overwritten or erased until brought online)
• when RDX cartridges containing expired sets are online (vaulted / offsite RDX cartridges will not expire their backup sets until brought online)
• if catalog truncation is enabled (default is disabled)
• whether GRT (or instant GRT) is used, where GRT stands for Granular Recovery Technology

Solution

There are a number of options to manage the impact on disk space within backup  environments that create (or could create) large catalog folders, as follows:

• Ensure that the catalogs folder is located on a large enough volume. As a best practice do not leave the catalogs folder on the System Drive of the Operating System or on volumes that will be used for Backup-to-Disk (B2D) or Deduplication Storage. Also consider not using the same volume as that containing the Backup Exec application itself. Note: if a  change to the catalog path is required, it is recommended to use BEUTILITY.EXE as this automates moving existing catalog information and restarting services.
• If vaulting regular tape or RDX cartridge based backups offsite for extended periods of time, consider enabling the option to Truncate Catalogs after a defined time period. This option removes the .FH file linked to the set and can have a significant effect on disk usage. It does also restrict catalog searching and the immediate restore capability of affected sets to a complete set (unless a new catalog job is run). Note: this will affect online sets with extended retention as well, however typically online sets are not retained for extended periods.
• Ensure that vaulted / offline tapes and cartridges that do not have long retention requirements are returned for use when appropriate, so that Backup Exec can automatically remove obsolete catalog files as the media is re-used.
• For tape handling enable the setting to "Overwrite recyclable media that is contained in the destination media set before overwriting scratch media" This should result in tapes containing older backup sets being selected more often and thus reduce the number of older catalog files remaining. Note: a tape in scratch could contain a backup set so the benefit of this may be minor.
• Consider disabling GRT for virtual machine (VM) backup operations where there is no requirement to restore individual content (i.e a front end end-web server may only need a DR capability). This will reduce the number of catalog files and the disk space used when backing up such VMs as only details of the VM disk files (.VHD, .VMDK) are recorded in the catalogs and no references to all the objects held within the VM.
• If GRT is required then consider using B2D and the Instant GRT capability. Instant GRT does not create full .FH records for the GRT components within the backup as the restore selections are browsed by mounting the backup image. Note: the search capability is not available when using Instant GRT
• For disk sets, review the overall retention times against business requirements and consider reducing them.