Symantec Veritas NetBackup data backup and recovery best practices

Symantec Corp. Veritas NetBackup is an enterprise-level data backup application used in some of the world's largest companies. Unfortunately, with such power comes great complexity. With complexity comes choices, and that usually means that there is a good choice and a bad choice. This is the first in a multipart series about Veritas NetBackup best practices to help you make the right choices for your data backup system.

Before we begin, it might be important to review what a best practice is. I define a best practice as:

A technique or methodology that, through experience and research, has proven to reliably lead to a desired result -- and should be followed except when there is a valid business or technical reason for not doing so.

For more detail on how that definition was developed, see my blog entry about best practices.

NetBackup best practice: Use native capabilities

The first NetBackup best practice that we'll discuss is to use the native capabilities of the software whenever possible. Avoid scripting and customization whenever possible. It's also important to configure things in such a way that someone familiar with NetBackup can browse the administrative interface, examine the policies and schedules, and get a pretty good understanding of how your environment is configured.

More expert data backup advice from W. Curtis Preston SharePoint data backup and recovery best practices Tape backup and recovery technology tutorial Server-free backup FAQ Podcast: Disk-based backup for SMBs

Custom backup scripts and backups scheduled outside of NetBackup may bring additional functionality, but they also bring additional complexity, and mask your true configuration from a new administrator. It's often better to live with a product's limitations than it is to force it to behave in a way than it was designed for.

Most people will not administer the backup system for their entire career. They might start there, but they will eventually move onto something else, and it's at that moment that simplicity and the use of a product's native capabilities becomes extremely important. The more you stray from a product's native capabilities, the more you customize, the harder it will be for a new person to understand how things are configured.

Do not allow multiple retentions per tape

NetBackup automatically segregates backups by retention period. That is, backups that expire at different periods of time are not placed on the same tape. For example, a backup that has a three-week retention period will not be placed on the same tape with a backup that has a three-month retention period. This is not to say that NetBackup will ensure that all backups that go on a given tape will expire at the same time. Since backups are stored on the tape at different times, the newest backups on the tape will expire later than the oldest backups, but the tape cannot be returned to the scratch pool until all backups on it have expired.

Newer users of NetBackup may notice that they have used a lot of tapes in a short period of time due to this feature. They then call support for an explanation at which time retention segregation is explained to them. They immediately think it's a stupid idea, because it's causing them to use too many tapes. NetBackup allows you to disable retention segregation globally on a NetBackup master server, and users often think that by doing so they will use fewer tapes. The reverse is actually true. That's because when you start mixing backups on tape, you end up with tapes that have backups that expire at different times. Do not disable this feature.

Use filesystem and database discovery whenever possible

When you enter ALL_LOCAL_DRIVES in the filelist for a policy, it will automatically discover the names of the local (i.e., non-NAS) filesystems it needs to back up. If you use database-all in a MySQL backup script, the same thing happens. In Exchange, the phrase "Microsoft Information Store:" will back up the database as one stream, and "Microsoft Information Store:*" will create one stream per storage group. Using configurations like this ensures that everything is always backed up.

Some people say that this best practice backs up worthless data, such as the operating system, or some databases. However, the amount of money saved by not backing up this data is significantly outweighed by the risk the alternative method poses to the environment. The alternative method (manually listing filesystems and databases) requires the administrator to continually update policies every time someone adds a database or filesystem. It's only a matter of time before a filesystem or database gets missed. In addition, if there is truly worthless data that shouldn't be backed up, that's what exclude lists are for.

W. Curtis Preston (a.k.a. "Mr. Backup"), executive editor and independent backup expert, has been singularly focused on data backup and recovery for more than 15 years. From starting as a backup admin at a $35 billion dollar credit card company to being one of the most sought-after consultants, writers and speakers in this space, it's hard to find someone more focused on recovering lost data. He is the webmaster of BackupCentral.com, the author of hundreds of articles, and the books "Backup and Recovery" and "Using SANs and NAS."