How to Specify How Long Backed-Up Data Is Kept

Use browse and retention policies to specify how long data is available for recovery. You can specify browse and retention policies for each client.

What Are Browse and Retention Policies?

The Backup server maintains one file index for each client machine (regardless of the number of client resources configured for it) and one media database that tracks data from all clients. Each time a backup is completed, Backup creates entries for the backed-up files in the client file indexes. The media database stores one entry for each save set and storage volume during each backup operation.

Each client file index is a browsable structure of data from a single client machine. Users can specify anything from a single file to a complete filesystem and direct Backup to reconstruct the data during a recover session to look exactly as it did at a specific time. The information that the client index contains and coordinates enables Backup to automatically handle situations such as assembling data from backups based on levels, and to accommodate all file or directory renamings or deletions. Backup uses browse policies to manage the life cycle of data and to automatically control the size of the client file index.

The Failed Cross Reference Format determines how long files are maintained in the client's file index on the Backup server. During the period of the browse policy, users can browse backed-up data in the Backup recover program (nwrecover) and select individual files or entire filesystems for recovery. After the browse policy for a file is exceeded, Backup automatically deletes the entry for that file. Backup deletes these entries to manage the size of the client index, which can grow rapidly: one entry for each file backed up during each scheduled backup of the client.

The media database is the structure that tracks the location of save sets on storage volumes. Backup uses a Failed Cross Reference Format to manage the longevity of Backup managed data. Data is recoverable as long as entries exist in the media database; there is nothing to be gained by rushing to delete media database entries. For all these reasons, the media database retention policy does not trigger the automatic removal of media database entries. Instead, the retention policy determines how long an entry for a save set remains protected from being accidentally written over.

The retention policy determines how long save sets are maintained in the Backup server's media database. For at least the period of the retention policy, you can recover a client's backed-up save sets from media. No save set is considered recyclable until, at a minimum, it has exceeded its retention policy. No storage volume can be relabeled and written over until, at a minimum, all save sets on the storage volume have exceeded their retention policies. Theoretically, entries for a save set or a storage volume can remain in the media database forever, long after the retention policy has been exceeded. Entries are removed from the media database only if a storage volume is relabeled or if you manually delete the entries.

How the Browse Policy Works

You can recover a file that has an entry in the client file index through the Backup recover program, which enables users to browse and mark files and initiate data recovery. Client file index entries are not necessarily deleted the same day that the browse policy is exceeded. Backup does not remove the entry for a file until all the save sets that are dependent on the file have also exceeded their browse policies. In general, the entries for a full backup that are older than the browse policy are not removed until an additional length of time equal to one backup cycle passes as well. This extra time ensures that you can reconstruct a file to any point in time included in the browse policy period.

The following figures demonstrate how a browse policy affects data availability in the client file index. For more information about schedules, see "Schedule Configuration ", and for more information about backup levels, see "Backup Levels ".

In Figure 5-1, both the backup cycle and the browse policy are set at one week. A backup cycle is the length of time between full backups. Entries for the first full backup on October 2 remain in the client file index until all the incremental and level 5 backups that depend on it exceed the one-week browse policy. The full backup performed on October 2 is not removed until October 16, when the incrementals and level 5 that depend on the full backup expire.

Figure 5-1 One-Week Browse Policy

To illustrate why the browse policy works this way, suppose that on October 12, you decide that you want to recover information backed up on October 6. The backup performed on the 5th is an incremental backup dependent on the October 5 backup, which is a level 5 backup. The October 5 level 5 backup, in turn, is dependent on the full backup performed on October 2. The entry for the full backup performed on October 2 must remain in the client file index for a period of time equal to the browse policy (one week) plus one complete backup cycle (one additional week)--that is, until the level 5 backup on October 5 and all incremental backups dependent on the full backup pass their browse policy. In the example shown in Figure 5-1, entries from the Week 1 backup cycle are removed from the client file index on October 16.

In Figure 5-2, the browse policy is two weeks, which is twice as long as the backup cycle (1 week). In this example, on October 19 a user can still find browsable entries in the client file index from backups created on October 5. The backup performed on October 6 is an incremental backup dependent on the October 5 backup, which is a level 5 backup. The October 5 level 5 backup, in turn, is dependent on the full backup performed on October 2. The full backup performed on October 2, and the incremental and level backups that depend on it, must remain in the client file index for a period of time equal to the browse policy (two weeks), plus one complete backup cycle (one additional week). In this example, entries for the Week 1 backup cycle are not removed from the client index until October 23.

Figure 5-2 Two-Week Browse Policy

How the Retention Policy Works

The Backup media retention policy specifies a period of time during which backed-up data is protected from accidental overwrite. After the retention period is exceeded, the save set is eligible to change its status from recoverable to recyclable. The save set's status, however, does not change to recyclable until it and all the save sets that depend on it have passed their retention policy. Backup keeps track of save set dependencies regardless of whether the dependent save sets are stored on the same media volume or on different volumes. The expiration of a save set's retention policy does not remove the save set's entries from the media database.

When the retention policy for every save set on a volume expires and the status for every save set on a volume changes from recoverable to recyclable, Backup changes the mode of that storage volume to recyclable. Since a volume can contain save sets from multiple backup sessions, all with different retention policies, the mode of a volume might not change to recyclable for a long time. The term "recyclable" is best understood as "eligible for recycling."All the data on the volume remains available for recovery using either save set recover or the scanner command. All the entries for "recyclable" save sets remain in the media database.

The change in status to recyclable is a passive reminder that you can overwrite the volume if conditions are right. If you place the volume in an autochanger or mount the volume in a standalone device and enable the auto media management attribute in the Devices resource, the volume is available for relabel and use by Backup. The existing data is nonrecoverable after the volume is relabeled, so the entries for the overwritten save sets are removed from the media database. For more details about this feature of auto media management, see "How Backup Selects a Storage Volume for Relabeling ".

The save set's entries are also removed from the media database when you manually delete a volume from the Backup volume inventory. However, the data on a volume that you delete manually is still available for recovery using the scanner program. The scanner program retrieves the information needed to re-create entries in either the client file index, in the media database, or in both places. If you re-create the entries in the client file index, a user with the proper permissions can recover data through the Backup recover program (nwrecover). If you re-create the save set's entries in the media database, a user with Backup administration privileges can recover data with save set recover. See Appendix B, Command Line Reference Utilities, or refer to the scanner man page for more information on how to use the scanner program.

Figure 5-3 illustrates how a retention policy works. In this example, the backup cycle is set at one week and the retention policy is set at three weeks.

Figure 5-3 One Week Backup Cycle; Three Week Retention Policy

The save set entries for Week 1 have passed their browse policy and retention policy, but they remain available for recovery using the scanner program until you relabel. When all the save set entries on a volume change status to recyclable, the volume mode changes from full or appendable to recyclable, and the volume is ready to be relabeled for reuse. When you relabel the volume, the data on the volume can no longer be recovered by Backup.

For more information about storage volume modes, see Table 4-3.

For more information about schedules, see "Schedule Configuration ", and for more information about backup levels, see "Backup Levels ".

How the Browse and Retention Policies Manage the Data Life Cycle

The browse and retention policies that you associate with a client save set control both the growth of the client file index and the media database, and how long data remains available for recovery. Figure 5-4 traces the data life cycle through the client file index and the media database. In the example, the entries for the September 1 through September 7 backup cycle remain in the client index for one month (the browse policy), plus the length of a full backup cycle (one week), to ensure that all dependent entries pass their browse policies. In this case, the file index entries for the September 1 through September 7 backup cycle are removed on October 13. Since the entries exist in the client file index, you can browse and recover the data through the recover program's GUI (nwrecover). As long as the save set's file entries remain in the client file index, the status of the source save sets is browsable. After the save set status changes from browsable to recoverable, you cannot perform file recovery directly.

The status for each save set backed up during the September 1 through September 7 backup cycle remains recoverable until their retention policies expire, plus however long it takes for all the dependent save sets to pass their retention policies. In this case, the entries from the September 1 through September 7 backup cycle change from recoverable to recyclable on December 8. When all of the save set entries on a volume change status to recyclable, the mode of the volume itself changes from either full or appendable to recyclable.

While the status of a save set is either recoverable or recyclable, you can recover any save set from the storage volume by using either the save set recover operation or the scanner program. Alternatively, you can use the scanner program to re-create a save set's entries in the client file index, which enables file recovery directly from the GUI. For more information about using Save Set Recover and the scanner program, see "Save Set Recover and Scanner".

Figure 5-4 Data Life Cycle in the Client Index and the Media Database

On October 13, all data entries from September 1 to September 7 are removed from the client file index. On December 8, the save set entries from September 1 to September 7 in the media database change status from recoverable to recyclable. After all save sets on a volume change status from recoverable to recyclable, the volume mode changes to recyclable. If auto media management is enabled, the volume may be relabeled automatically by Backup to satisfy a volume mount request. After you relabel the volume, all existing data on the volume is unavailable for recovery.

---

Caution -

When you relabel a volume for reuse within the same pool, the volume identification (the volume name as it appears on the volume label) remains unchanged. Even so, after relabeling, the information that Backup needs to locate and access all existing data on the volume is destroyed and neither the Save Set Recover feature nor the scanner program are options. At this point, the volume is ready for new data. All existing data is inaccessible and is overwritten.

---

Save Set Status Values

Backup assigns to each backed-up save set a status based on the success of the backup or the age of the save set data. The save set status changes in the following situations:

• When the save set exceeds its browse policy. For more information about browse policy, see "How the Browse Policy Works".

• When the save set exceeds its retention policy and all save sets dependent on the save set also exceed their retention policies. For more information about retention policy, see "How the Retention Policy Works ".

• When you manually change the save set status.

Table 5-1 provides a list of all the possible values for save set status.

Table 5-1 Save Set Status Values

Status Value	Meaning	Description
abort	Aborted	You aborted the backup for this save set manually or a crash occurred during the operation. This save set is considered immediately eligible for recycling.
brows	Browsable	The files in this save set retain entries in the client file index. You can restore all the files using an index-based recover.
inpro	In progress	This save set is currently being backed up.
recov	Recoverable	The files in this save set do not have browsable entries in the client file index and have not passed the retention policy.
recyc	Recyclable	The save set and all the save sets that are dependent on this save set for recovery have exceeded their retention policies.
scann	Scanned-in	The client file index entry for this save set was restored with the scanner program. This entry remains in the client file index and media database until you remove it manually.
susp	Suspect	An attempt to recover this save set failed. The recover program could not read all the blocks of the save set, for example, if there was a bad spot in the tape.

How to Customize Policies

Use the Policies resource to create a custom browse policy or retention policy. In the Policies resource, give the policy a unique name and specify a time period. After you define a policy, it is available as a choice in the Browse Policy and Retention Policy attributes in the Clients resource.