Análisis Exploratorio de Datos

The backup copy group is concerned with two logical objects: the file, and the file copy. A file is the actual data on a node, while a file copy is a point-in-time copy of the file. Another way to think of it is that Tivoli Storage Manager contains file copies, and nodes contain files.

A file can be in one of two possible states: existing or deleted. When we talk about an existing file on a node, we mean a file that has been previously backed up and still exists on the node. A deleted file is a file that has been previously backed up and has been deleted from the node. This simple concept is important when discussing data storage rules.

A file copy can be in one of three states: active, inactive, or expired. An active file copy is the most current copy of the file, an inactive file copy is a previous copy of the file, and an expired file copy is a copy to be removed from the Tivoli Storage Manager server. A backup file copy is set to the expired state when it no longer conforms to the rules defined in the backup copy group.

Whether the file exists or is deleted, the file copy always passes through the same states in the same order. A file copy starts out as active, since it is the first copy of the file, and therefore the most current. Once the file changes and we take another file copy, the first file copy changes to inactive because we have a more recent one. Eventually, the first file copy expires based on one of two limits placed on it by our rules: number of copies or retention period.

The number of copies that we set in our rules specifies the total number of file copies to maintain in the Tivoli Storage Manager database. It is important to note that the specified number includes the active file copy. Thus, when we set the number of file copies to three, we are keeping one active copy and a maximum of two inactive copies. When the number of copies is exceeded, the oldest copy is removed from the database.

You could consider not recovering the NTFS security information for large restores, especially if you are recovering to a different domain structure, and therefore, new security rules must be applied anyway.

Windows NT Users:

tsm: TSM010> define mgmtclass production production custdata \ cont> description="Custdata management class for ABC Corporation"

ANR1520I Management class CUSTDATA defined in policy domain PRODUCTION, set PRODUCTION.

tsm: TSM010> assign defmgmtclass production production custdata

ANR1538I Default management class set to CUSTDATA for policy domain PRODUCTION, set PRODUCTION.

The retention period that we set in our rules specifies the length of time that we retain inactive file copies. Note that there is no retention period for active file copies; they exist as long as the file exists on the node.

Whether or not the file exists on the node affects which rules are used to expire the file copies. If the file exists, the following two backup copy group parameters are in effect:

• VEREXISTS: Specifies the number of file copies, or versions, to keep. This number includes active and inactive file copies.

• RETEXTRA: Specifies how long to keep inactive file copies. When a file changes from active to inactive, it is kept for these extra days and then removed. It is important to note that the retention period starts from when the file copy changes to inactive, and not from its original backup date. This parameter can also be set to NOLIMIT which means the inactive versions are only expired if superseded by other copies and never from a time limit.

If the file has been deleted, the active file copy is made inactive. At this point, there are only inactive file copies for this data in the Tivoli Storage Manager server, and the following parameters apply:

• VERDELETED: Specifies the number of file copies to keep after the file has been deleted. This must be equal to or less than VEREXISTS.

• RETEXTRA: Specifies how long to keep inactive file copies. This means the same as for existing file with the exception of the very last inactive remaining file copy.

• RETONLY: Specifies how long to maintain the last file copy of the data. This is the number of days to keep the last remaining copy only, and does not apply to other inactive file copies which are still governed by the RETEXTRA

parameter. This parameter can also be set to NOLIMIT which means the last remaining copy is never expired.

The backup copy group defines five other attributes that control the way that backup data is handled:

• TYPE: The TYPE parameter is used to differentiate between the two possible types of copy groups. In the case of a backup copy group, it is set to BACKUP.

• DESTINATION: The backup copy group specifies where to store the data sent to it from backup operations using the DESTINATION parameter. The copy group bridges the gap between data files and storage pools as illustrated in Figure 18. The figure shows different types of data flowing through the copy groups and into the storage pools. Note that there is not necessarily a one-to-one relationship between copy groups and storage pools: many copy groups could share the same storage pool. A copy group can only ever point to one storage pool and each backed up file can only be in one management class.

Figure 18. Data flow through copy groups

• MODE: The MODE parameter specifies how files are to be selected for incremental backup. Setting the mode to MODIFIED allows a file to be backed up only if it has changed since the last backup. The ABSOLUTE setting allows files to be backed up, regardless of whether they have changed or not. The latter value would only be used for special cases; the default value is

MODIFIED in accordance with the progressive incremental backup paradigm of Tivoli Storage Manager.

• FREQUENCY: The FREQUENCY parameter specifies how often to allow a file to be incrementally backed up. A client selective backup, which backs up data regardless of whether it has changed or not, is not affected by this parameter.

To incrementally back up a file from a node, three conditions must be satisfied:

1. Include-exclude statements allow the file to be considered for backup.

2. The file satisfies the MODE setting. That is, if the MODE is set to

MODIFIED, the file must have changed to qualify for backup. If the MODE is set to ABSOLUTE, then the file is automatically allowed to be backed up.

3. The difference between the server time and the active file copy timestamp must be greater than FREQUENCY setting. The frequency is converted to hours to compare to the timestamp difference.

The default value for FREQUENCY is 0 which means there is no minimum elapsed time specified between backups.

For example, take a file called/home/admin/redbook.docthat is eligible for backup in the include-exclude list, and that has changed since the last backup at 8 AM

Policy Domain

this morning. The server time is 11 AM when an incremental backup is started, so the difference between the server time and the file copy time is three hours. If the frequency is set to one day, then 24 hours must pass between incremental backups before a file is backed up again. Therefore, the/home/admin/redbook.doc file is not backed up, since three hours is less than 24 hours.

• SERIALIZATION: The SERIALIZATION parameter specifies what to do with files that are modified during a backup operation. When we say that a file is modified during backup, we mean that it is modified after Tivoli Storage Manager examined it for its details, but before it was completely backed up to the server. This sort of backup is referred to as a "dirty backup" because the file is in an inconsistent state and may not restore properly. The

SERIALIZATION parameter provides four options to deal with this issue:

1. The SHRSTATIC setting specifies that a file is not backed up if it is

modified during backup, but multiple attempts are made to back up the file.

If the file is being modified through all of these attempts, the file is not backed up. The number of attempts can be controlled using the

CHANGINGRETRIES option in the client options file. So, the file is backed up only if a clean backup can be obtained within the defined number of backup attempts.

2. The STATIC setting specifies that a file is not backed up if it is modified during the first attempt at backup and no additional attempts are made. So, the file is backed up only if a clean backup can be obtained on the first attempt.

3. The SHRDYNAMIC setting specifies that a file is backed up if it is modified during backup, but multiple attempts are made to back it up without

modification first. If that cannot be done, then the file is backed up anyway.

4. The DYNAMIC setting specifies that a file is backed up even if it is modified during backup. So, the file is backed up on the first attempt, regardless of whether it changes or not.

You should set these options carefully in your copygroups, driven by whether it will be possible to correctly restore a file which is possibly dirty during the backup. There are two additional points to note here. The first is that if an application locks a file exclusively then Tivoli Storage Manager will not be able to back it up, regardless of the SERIALIZATION setting, since it is not available to it or to any other application. The second is that many files which change or are locked by the application are part of a database (for example, Oracle, Informix, SAP R/3 or Microsoft SQL Server) or other application (such as Lotus Notes or Microsoft Exchange). If this is the case for your environment, we strongly

recommend that you use an add-on product which will interface the backup of the database or application to Tivoli Storage Manager. This will ensure that open, updated or locked files are intelligently handled for both backup and restore.

These products are available both from Tivoli and other vendors. The redbook Tivoli Storage Management Concepts, SG24-4877, has more information.

Thedefine copygroupcommand creates a new copy group within the

management class. Note that the command does not require a name for the backup copy group; it is always called STANDARD and cannot be changed. In any case, there is no reason to change this parameter, since it only has relevance within the Tivoli Storage Manager server itself and there can only ever be one copy group per type (backup or archive) in any management class.

The following command shows how to create a backup copy group for the management class CUSTDATA in the policy set PRODUCTION of the policy domain PRODUCTION. When using this copy group, the client checks for files that have been modified since the last backup process and tries to back them up to the DISKDATA primary storage pool. After a few retries, the process gives up on files that are being modified during backup. The client data is governed by the following rules:

• If the file exists on the client, then three versions of it are kept. The extra inactive versions will expire after 100 days.

• If the file no longer exists on the client, then the last copy is kept for 365 days.