Contraste de hipótesis 4

The copy groups consist of rules used to govern the retention of data. There are two types of copy groups: a backup copy group holds the rules for backup data and an archive copy group holds the rules for archive data.

While these two copy groups serve different purposes, they also share some common ground. They both specify where to store the data sent to them from backup/archive operations. The copy group destination parameter specifies a valid primary storage pool to hold the backup or archive data. The copy group bridges the gap between data files and storage pools as illustrated in Figure 45 on page 65. It 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. It is possible to have just one storage pool which is the destination for all the copy groups.

Policy Domain

Policy Set

Backup Copy Group

Archive Copy Group Management

Class

Backup Copy Group

Archive Copy Group Management

Class

Backup Copy Group

Archive Copy Group Management

Class

Node Node

Data storage policy 65 Figure 45. Data flow through copy groups

Both copy groups also need to know what to do with files that are modified during a backup or archive 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 copy serialization parameter provides four options to deal with this problem:

• Theshrstaticsetting specifies that a file will not be backed up if it is modified during backup, but multiple attempts will be made to back up the file. If the file continues to be modified through each of these attempts, the file will not be backed up. The number of attempts can be controlled using the

changingretries option in the client options file.

• Thestaticsetting specifies that a file will not be backed up if it is modified during backup and no additional attempts will be made.

• Theshrdynamicsetting specifies that a file will be backed up if it is modified during backup but multiple attempts will be made to back it up without modification first. If that cannot be done, then the file will be backed up anyway.

• Thedynamicsetting specifies that a file will be backed up even if it is modified during backup. There is no preliminary attempts to back up the file unmodified;

it is backed up on the first attempt.

Note that the copy serialization works differently when doing an image backup.

For an explanation, see 2.6, “Logical volume backup” on page 48.

3.2.1 Backup copy group

The backup copy group is concerned with two logical objects: the file and the file copy. A file is the actual data on a client node, while a file copy is a point-in-time

Policy Domain

copy of the file stored on the server. Another way to think of it is that the Tivoli Storage Manager server 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 subsequently 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 or version 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 specified in the backup copy group.

Whether the file exists or is deleted, the file copy will always pass through the same states in the same order. A file copy will start out as active since it will be 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 will change to inactive because we have a more recent one. Eventually, the first file copy will be expired 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 two inactive copies. When the number of copies is exceeded, the oldest copies are removed from the database.

The retention periods that we set in our rules will specify the length of time that we will retain inactive file copies. It is important to 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 will affect 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 will be kept for retextra days and then removed. It is important to note that the retention period starts from when the file copy becomes inactive not from its original backup date.

If the file has been deleted, the active file copy will be 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.

• retonly — specifies how long to maintain the last file copy of the data. This is the number of days to keep the last copy only and does not apply to other inactive file copies.

Data storage policy 67 See 2.4.1, “Backup key concepts” on page 37 for examples illustrating these concepts.

3.2.2 Backup mode and frequency

The backup copy group defines two other attributes that control the way that backup data is handled:modeandfrequency. Themodeparameter specifies how files are to be selected for incremental backup. Setting the mode to modified will allow a file to be backed up only if it has changed since the last backup. The absolute setting will allow 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.

Thefrequencyparameter specifies how often to allow a file to be incrementally backed up. This parameter only affects client-selectedincremental backups; it does not apply toselectivebackups, since this backs up data regardless of whether it has changed or not. For a file to be backed up during an incremental operation from a node, it has to satisfy three conditions:

1. Domain and 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. 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.

For example, consider a file called /home/admin/redbook.doc that is eligible for backup in the include-exclude list and that has changed since the last backup at 8 a.m. this morning. The server time is 11 a.m. when an incremental backup is started, so the difference between server time and the file copy time is 3 hours. If the frequency is set to 1 day, then 24 hours must pass between incremental backups before a file is backed up again. Therefore, the file called

/home/admin/redbook.doc will not be backed up, since 3 hours is less than 24 hours. The default setting for this parameter is 0 which means there is no minimum required elapsed time between backups.

3.2.3 Archive copy group

The archive copy group works with entire archives as single unique entities so it has fewer rules. Since there is only ever one copy of a particular archive, we do not have to worry about rules to manage versioning. We still have to specify the retention period for the archive object and that is done with theretver setting. It specifies the number of days to retain the archive copy from the day of the archive operation.

There are three other parameters that the archive copy group uses to handle archive data:mode,frequency andcopyserialization. The mode parameter has been discussed, but the archive copy group only allows the value to be set to absolute. This makes sense, since the archive copy group does not link previous archives to the current archive and therefore cannot determine if anything has been modified. The archive copy group has a frequency parameterbut it can only be set to the value CMD which means the archive can be performed on demand.

Copyserialization operates in the same way as for backup and has already been discussed in 3.2, “Copy groups” on page 64