Tivoli Header
Administrator's Guide
Start out simply to plan your policy. You may be able to use the
default policy that comes with the server. Ask the questions:
- How many backup versions do clients need?
- How long do clients need the backup versions?
Examine the default policy to see if it meets your needs:
- Up to two backup versions of a file on the client's system are
retained in server storage.
- The most recent backup version is retained for as long as the original
file is on the client file system. All other versions are retained for
up to 30 days after they become inactive.
- One backup version of a file that has been deleted from the client's
system is retained in server storage for 60 days.
- An archive copy is kept for up to 365 days.
See The Standard Policy for more details about the standard policy.
The server manages files based on whether the files are active or
inactive. The most current backup or archived copy of a file is the
active version. All other versions are called inactive versions.
An active version of a file becomes inactive when:
- A new backup is made
- A user deletes that file on the client node and then runs an incremental
backup
Policy determines how many inactive versions of files the server keeps,
and for how long. When files exceed the criteria, the files
expire. Expiration processing can then remove the files from the server
database. See File Expiration and Expiration Processing and Running Expiration Processing to Delete Expired Files for details.
The standard policy consists of a standard policy domain, policy set,
management class, backup copy group, and archive copy group. Each of
these parts is named STANDARD. See The Parts of a Policy for details. The attributes of the default policy are
as follows:
Table 23. Summary of Default Policy
Policy
| Object where the policy is set
|
Backup Policies
|
Files are backed up to the default disk storage pool, BACKUPPOOL.
| STANDARD backup copy group, DESTINATION parameter
|
An incremental backup is performed only if the file has changed since the
last backup.
| STANDARD backup copy group, MODE parameter
|
Files cannot be backed up while they are being modified.
| STANDARD backup copy group, SERIALIZATION parameter
|
Up to two backup versions of a file on the client's system are
retained in server storage. The most recent backup version is retained
for as long as the original file is on the client file system. All
other versions are retained for up to 30 days after they become
inactive.
| STANDARD backup copy group, the following parameters:
VEREXISTS
RETEXTRA
RETONLY
|
One backup version of a file that has been deleted from the client's
system is retained in server storage for 60 days.
| STANDARD backup copy group, VERDELETED parameter
|
When a backed up file is no longer associated with a backup copy group,
it remains in server storage for 30 days (backup retention grace
period).
| STANDARD policy domain, BACKRETENTION parameter
|
Archive Policies
|
Files are archived in the default disk storage pool, ARCHIVEPOOL.
| STANDARD archive copy group, DESTINATION parameter
|
Files cannot be archived while they are being modified.
| STANDARD archive copy group, SERIALIZATION parameter
|
An archive copy is kept for up to 365 days.
| STANDARD archive copy group, RETVER parameter
|
When an archived file is no longer associated with an archive copy group,
it remains in server storage for 365 days (archive retention grace
period).
| STANDARD policy domain, ARCHRETENTION parameter
|
General
|
The default management class is STANDARD.
| STANDARD policy set (ACTIVE), ASSIGN DEFMGMTCLASS command
|
Space Management (HSM) Policy
|
Client files are not space-managed (there are no HSM clients).
| STANDARD management class, SPACEMGTECHNIQUE parameter
|
When you register a client node, the default is to assign the node to the
STANDARD policy domain. If users register their own workstations during
open registration, they are also assigned to the STANDARD policy
domain.
To help users take advantage of Tivoli Storage Manager, you can further
tune the policy environment by doing the following:
Some types of clients and situations require policy changes. For
example, if you need to direct client data to storage pools different from the
default storage pools, you need to change policy. Other situations may
also require policy changes. See Configuring Policy for Specific Cases for details.
To change policy that you have established in a policy domain, you must
replace the ACTIVE policy set. You replace the ACTIVE policy set by
activating another policy set. Do the following:
- Create or modify a policy set so that it contains the policy that you want
to implement.
- Create a new policy set either by defining a new policy set or by copying
a policy set.
- Modify an existing policy set (it cannot be the ACTIVE policy set).
- Note:
- You cannot directly modify the ACTIVE policy set. If you want to make
a small change to the ACTIVE policy set, copy the policy to modify it and
follow the steps here.
- Make any changes that you need to make to the management classes, backup
copy groups, and archive copy groups in the new policy set. For
details, see Defining and Updating a Management Class, Defining and Updating a Backup Copy Group, and Defining and Updating an Archive Copy Group.
- Validate the policy set. See Validating a Policy Set for details.
- Activate the policy set. The contents of your new policy set
becomes the ACTIVE policy set. See Activating a Policy Set for details.
An expired file is a file that the server no longer needs to keep,
according to policy. Files expire under the following conditions:
- Users delete file spaces from client nodes
- Users expire files by using the EXPIRE command on the client (client
software at Version 4.2 and later)
- A file that is a backup version exceeds the criteria in the backup copy
group (how long a file is kept and how many inactive versions of a file are
kept)
- An archived file exceeds the time criteria in the archive copy group (how
long archived copies are kept)
- A backup set exceeds the retention time that is specified for it
- Note:
- A base file is not eligible for expiration until all of its dependent
subfiles have been expired. For details, see Expiration Processing of Base Files and Subfiles.
The server deletes expired files from the server database only during
expiration processing. After expired files are deleted from the
database, the server can reuse the space in the storage pools that was
occupied by expired files. You should ensure that expiration processing
runs periodically to allow the server to reuse space. See Reclaiming Space in Sequential Access Storage Pools and Running Expiration Processing to Delete Expired Files for more information.
Expiration processing also removes from the database any restartable restore
sessions that exceed the time limit set for such sessions by the
RESTOREINTERVAL server option. See Managing Client Restartable Restore Sessions for information about restartable restore sessions.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]