Why Backup Exec CASO catalog replication is not a redundant solution

I started with a Backup Exec 2012 project for a larger company some months ago. One of their demands was to build a high-available solution with enough scalability for the next two years. The first thing that pops-up in my mind was an implementation of a Backup Exec Central Administration Server Option (CASO) with catalog replication. That should do the trick!

What are catalogs? The catalog and the database are required to perform restores of the data that has been written to tape. When losing the catalog, you are unable to select data to be restored. Compare it with a book without an index. You know it’s somewhere in the book, but can’t tell if it’s in chapter 1 or in chapter 25.. Ofcourse you have the ability to rebuild your catalog by performing a “catalog media” job. Needless to say this is a time-consuming job!

During the implementation, it came to my attention that this was not a redundant setup. I started a search with the best consultant on the world = Google and I was quiet disappointed with the results. Apparently nobody posed this question before or has written something about it. I saw this as an opportunity and wanted to clear this one out.

First of all, there are three ways catalogs can be stored. These are described in the Backup Exec 2012 Administrator’s Guide.

Distributed:

When the catalog is distributed, the view of the restore selections on the central administration server displays only the backup set at the volume level. Backup set details are not displayed if the managed Backup Exec server that created this backup set is not available, but the whole volume can be restored from the central administration server.

A distributed catalog provides increased performance, default centralized restore capability, and decreased network traffic. If a managed Backup Exec server does not have a persistent connection to the central administration server, then whenever the managed Backup Exec server does connect, the image files in the catalog are automatically distributed to the central administration server. The temporary increase in network traffic caused by the catalog distribution is not significant.

Centralized:

All catalog files and information for the managed Backup Exec server are kept on the central administration server.

Replicated:

All catalog files are replicated from the managed Backup Exec server to the central administration server. Both the managed Backup Exec server and the central administration server store the catalogs that are produced by the managed Backup Exec server.

Deletions of catalog files are replicated between the managed Backup Exec server and the central administration server only when the catalog files are deleted by Backup Exec according to the catalog settings. If catalog files on the managed Backup Exec server are deleted as a result of a backup job or a manual deletion, the deletions are replicated the next time that the catalogs are synchronized.

Based on the information described above “both the managed Backup Exec server and the central administration server store the catalogs…” you could interprete that there is no dependency between the two servers and that’s where you are wrong.

In a Backup Exec CASO setup there are three types of systems:

  • Backup clients;
  • Central Administration Server (CAS);
  • Managed Media Server (MMS).

It’s important to note the catalog replication works uni-directional (from MMS to CAS and not the other way around). This means you have the ability to restore data from the MMS and the CAS. But backups created on the CAS server, can only be restored from the CAS server itself (single-point-of-failure = conclusion 1).

As a second test, we staged a disaster whereby we lost our CAS server. Normally you should be able to restore data from on tape by using the Managed Media Servers. (conclusion 2)

caso-replication-issue

In my situation BCK06 is the Central Administration Server, whereby BCK07 is the Managed Media Server. This image illustrates the dependency between both systems. Losing the CASO server will have a significant impact on the environment.

Alternatives:

  • Clustering (High-Availability) provides the means to survive a hardware crash and startup the environment on another node. This is an active/passive setup.
  • A dedicated CASO holds the configuration – and historical data. This server will not be used for executing backup jobs on the local server. It’s possible to install this within a virtual machine (Extended-Availability). As usual do not locate the virtual machine on a hardware platform you would like to protect, but use a seperate cluster if available.
  • Or another software solution.

These findings are based on Backup Exec software revision: Backup Exec 2012 (14.0).

Leave a Reply