Table of Contents
Advertisement
7.1 Recommended setup
Figure 7-1 on page 271 shows the key components of our sample policy
configuration. We define two policy domains, SERVER and WORKSTN. Both
domains have
details show that the SERVER domain has more copies and longer retention
periods than the WORKSTN domain. It is not necessary to define multiple
domains, but this demonstrates that the policy is really defined in the copy
groups, and that the rest of the constructs are used primarily for flexibility.
In our environment, we want our data to be treated in the following way:
Nodes registered to the SERVER domain will retain a maximum of three
object copies (VEREXIST), and inactive copies will be stored for a maximum
of 100 days (RETEXTRA) after becoming inactive. If an object is deleted from
a node file system, we will retain only the latest copy (VERDEL) for 100 days
(RETONLY). Primarily, we want to store only consistent backup copies
(SHRSTATIC). Files that are being changed during backup, such as log files,
should be bound to the
such files, but first attempt to back them up consistently (SHRDYNAMIC).
Their retention and versioning rules are the same as for the normal data. We
will archive files for a year (RETVER). Further, we want to store a maximum
of three logical volume backups, and keep the inactive image backups for a
maximum of 120 days once they became inactive.
Nodes registered to the WORKSTN domain will retain a maximum of two
object copies (VEREXIST), while inactive copies will be stored for a maximum
of 30 days (RETEXTRA) after becoming inactive. If an object is removed from
a node file system, we will retain only the latest copy of the object (VERDEL)
for 30 days (RETONLY). Primarily, we want to store only consistent backup
copies (SHRSTATIC). Files that are being changed during backup, such as
log files, should be bound to the
storing such files, but first attempt to back them up consistently
(SHRDYNAMIC). Log files should be bound to a management class whose
rules allow storing changing files eventually (SHRDYNAMIC). Their retention
and versioning rules are the same as for the normal data. We will archive
objects for 30 days (RETVER). Further, we want to store a maximum of two
logical volume backups, and keep the inactive image backups for a maximum
of 30 days once they became inactive (RETEXTRA).
Obviously, your environment will have specific data protection requirements that
may differ from our setup. This is the purpose of the planning process. The
provided values here may give you a reasonable starting point for later
customizations.
270
IBM Tivoli Storage Manager Implementation Guide
similar
policy sets and management classes, but their copy group
special
management class whose rules allow storing
special
management class whose rules allow
Advertisement
Table of Contents
