Implementing Backup and Recovery: The Readiness Guide for the Enterprise

After determining why the data needs to be backed up and the recovery requirements, you are ready to look at how your particular business requirements come into play. You need to determine how often each type of data or each system needs to be backed up, what the restore requirements are, what the data retention policy needs to be, any security requirements, off-site storage requirements, and unique business unit requirements. All of these items must be addressed.

Developing a Backup Strategy

To start this phase of architecting your backup and recovery strategy, you need to look at the frequency of backups and the required retention of the data. This is usually controlled by the business, legal, and recovery requirements. The business requirements that generally affect the backup strategy are those that define how long specific types of data must be kept available either locally or in a storage facility. These requirements could also specify the number of copies of the data that must be retained. In some cases, there are specific business requirements regarding how often specific data is backed up. Legal requirements must also be considered, although they are usually the basis of the specific business requirements. When you are dealing with data that might fall under control of any of the many governmental regulatory agencies, you must make sure your strategy complies with all their requirements.

Business Requirements

The specific business requirements that you need to consider include the following (see Figure 2.1):

• Service-level agreements to business units. What backup and recovery guarantees do you have?

• Unique requirements for specific data. For example, all original circuit design must be kept for seven years.

• Recovery time objectives. How fast will specific systems/applications be recovered?

• Recovery point objectives. How far back in time are you willing to go to recover?

Legal Requirements

The legal requirements you need to consider are generally those imposed by governmental regulatory agencies. These typically involve specific data retention requirements for specific kinds of data. What makes this even more challenging is that these requirements can change because of changes in administrations or new laws. These can also dictate how many copies of the data must be kept and where it must be kept.

Figure 2.1: Recovery point and recovery time.

Recovery Requirements

As you build your strategy, you should make a special note of systems or applications that have special recovery requirements. These are usually covered by the business requirements but are worth mentioning again. We have found it much better to always look first at the recovery requirements when building a backup strategy, since that is probably the reason you are doing backups.

With these absolutes in mind, the next step is to take the information gathered in the first chapter and start your backup matrix. As you put this together, you should also consider the type of backup you need. Following are the different backup options:

• Full backup. This backup copies all the files and directories that are below a specified directory or filesystem to a storage unit.

• Cumulative incremental backup. Scheduled by the administrator on the master server, this option backs up files that have changed since the last successful full backup. All files are backed up if no prior backup has been done. This is very similar to a differential incremental backup, which is covered later, with one very major difference. In the event of a full system recovery, a cumulative incremental backup would require only two images: the last full backup and the most recent cumulative incremental. While this speeds the recovery process, this type of backup does require more tapes than the differential incremental and may potentially take more time, because you are backing up all the files that have changed since the last full backup.

• Differential incremental backup. Scheduled by the administrator on the master server, this option backs up files that have changed since the last successful incremental or full backup. All files are backed up if no prior backup has been done. This is what most people traditionally refer to by incremental backup. During a full recovery, using this type of backup could require more tapes. However, do not base your architecture decisions just on these two definitions, but rather on the information gathered during your initial discovery phase.

• True image restore. This type of backup restores the contents of a directory to what it was at the time of any scheduled full or incremental backup. Previously deleted files are ignored. You can also select Move Detection, which specifies that true image incremental backups include files that were moved, renamed, or newly installed.

The example in Figure 2.2 shows the data that is included in a series of backups between January 1 and January 4. The January 1 full backup includes all files and directories in the policy file list. Each of the cumulative incremental backups include the data changed since the last full backup. If the disk fails sometime on January 4 (after the backup), the full and the last cumulative incremental are required for the recovery.

For this example: Recovery = Jan 1 (full) + Jan 4 (incr)

Figure 2.2: Cumulative incremental backup.

The example in Figure 2.3 shows the data that is included in a series of backups between January 1 and January 4. The January 1 backup is a full backup and includes all files and directories in the policy file list. The subsequent backups are differential incrementals and include only the data that changed since the last full or differential incremental backup. If the disk fails sometime on January 4 (after the backup), the full and all three of the incrementals are required for the recovery.

For this example:

Recovery = Jan 1 (full) + Jan 2 (incr) + Jan 3 (incr) + Jan 4 (incr)

Figure 2.3: Differential incremental.

The following are examples where using move detection backs up files that otherwise would not be backed up:

• A file named /home/pub/doc is moved to /home/spec/doc. Here, the modification time is unchanged, but /home/spec/doc is new in the /home/spec/ directory and is backed up.

• A directory named /etc/security/dev is renamed as/etc/security/devices. Here, the modification time is unchanged, but/etc/security/devices is a new directory and is backed up.

• A file named /home/pub/doc is installed by extracting it from a UNIX TAR file. Here, the modification time is before the time of the last backup, but the doc is new in the /home/pub/ directory and is backed up.

• A file named docA is removed and then a file named docB is renamed as docA. Here, the new docA has the same name, but its inode number changed, so it is backed up.

NetBackup starts collecting information required for move detection beginning with the next full or incremental backup for the policy. This first backup after setting the attribute always backs up all files, even if it is an incremental.

Move detection takes space on the client and can fail if there is not enough disk space available.

The following table shows the files backed up in the /home/abc/doc/ directory during a series of backups between 12/01/2001 and 12/04/2001. Assume that True Image Restore Information was selected for the policy that did the backups.

FILES BACKED UP IN THE HOME/ABC/DOC/ DIRECTORY^[*]

Also, assume that you are going to restore the 12/04/2001 version of the /home/abc/doc/ directory.

• If you do a regular restore, the restored directory has all files and directories that ever existed in /home/abc/doc/ from 12/01/2001 (last full backup) through 12/04/2001:

  file1

  file2

  dirA/fileA

  dirB/fileB

  file3

  dirC/fileC

  file4

• If you do a true image restore of the 12/04/2001 backup, the restored directory has only the files and directories that existed at the time of the incremental backup on 12/04/2001:

  file1

  file2

  file4

NetBackup does not restore any of the files deleted prior to the 12/04/2001 incremental backup.

The restored directory does not include the dirA and dirC subdirectories, even though they were backed up on 12/04/2001 with a user backup. NetBackup did not restore these directories because they did not exist at the time of the incremental backup, which was the reference for the true image restore.

^[*]From the NetBackup 4.5 DataCenter System Administrator's Guide, VERITAS