ADSM-L

Re: Retention policy -- quick one!

2004-11-05 13:45:08
Subject: Re: Retention policy -- quick one!
From: Timothy Hughes <Timothy.Hughes AT OIT.STATE.NJ DOT US>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 5 Nov 2004 13:44:51 -0500
TSM Policy Settings

POLICY DOMAIN - This is a container for policy and scheduling info
*BACKRETention* is a fallback value for any files which
have been backed up under the specified policy domain,
but for which there is now a lack of an active policy set.
*ARCHRETention* is a fallback value for any files which
have been archived under the specified policy domain,
but for which there is now a lack of an active policy set.

POLICY SET - This is a set of management classes within a POLICY DOMAIN.
Only the active version has any effect. The active version
is created by issuing ACTIVATE POLICYSET <set-name-you-made>.
After activating, you may edit the original set without
affecting the active copy.

MANAGEMENT CLASS - This is a classification for particular sets
of objects. Minimal set to be bound is an entire archive
for archiving (ARCHMC option) or a single file, directory,
filespace or everything for a backup (INCLUDE option).
There can be many management classes per policy set, but
only ones in the active policy set may be referenced.
**The additional parameters for this structure are used
only for HSM migration.

BACKUP COPYGROUP - This is the structure which defines retention
of backup data. These settings are the most confusing
because their operation overlaps and may require some to
be set to "NOLIMIT" to attain the desired effect.

*VERSIONS DATA EXISTS* - This value specifies the maximum
number of versions of a file which may be retained.
If this is exceeded by additional backups or imports,
then the next expiration run on the server will remove
the oldest versions until there are only this many left.
**This may be "NOLIMIT" or a whole number.

*RETAIN EXTRA VERSIONS* - This value specifies the maximum
number of days to retain an inactive copy when there is
an active copy in the database.
**This may be "NOLIMIT" or a whole number.

*RETAIN ONLY VERSION* - This value specifies the maximum
number of days to retain the most recent inactive version of
a file once there are no active versions from the date that
version becomes inactive.
**This may be "NOLIMIT" or a whole number.
**This does not affect active copies which are always
retained.

*VERSIONS DATA DELETED* - This is the maximum number of
inactive versions of a file to retain once the file no
longer has an active version.

*DESTINATION* - This specifies the storage pool to which
newly backed up data will go if it is bound to this
management class during backup.
**Rebound data will not move to a new pool automatically.
**Data may be moved from this pool through migration or
MOVE DATA commands.

ARCHIVE COPYGROUP - This is the structure which defines retention
of archive data.

*RETAIN VERSION* - This is the only retention parameter
for archives, and is the number of days that the entire
archive will be kept.

*DESTINATION* - This specifies the storage pool to which
newly archived data will go if it is bound to this
management class during archive operation.
**Rebound data will not move to a new pool automatically.
**Data may be moved from this pool through migration or
MOVE DATA commands.

Schedule - This is a time/date/frequency setting for when commands may
be automatically run by the tsm server either on the tsm
server (administrative) or on the tsm client (client).

Client Association - a separate entity that binds clients to schedules.

Node - A separate entity which defines a client and allows access.

NOTE: Once an archive is made, it may not be rebound. In other words, a 
different
management class may not be specified for it. It is possible to change the
copy-group retention period for this management class, and then re-activate the
policyset. This will change it's retention; however, be cautious with this, as 
you
will affect ANY data in the same
management class.

NOTE: Management classes with the same name but which are within a different
policy domain will NOT conflict with each other.

NOTE: Changes to a policy set will NOT have ANY effect unless that policy
set is copied into the active policy set with ACTIVATE POLICYSET. Only
the active policyset, and not its source policyset or any other, will have
an effect.

NOTE: Active versions are converted to inactive only by the client, through
client-side expiration. See the particular client manual for details.
This may happen during a backup with an exclude list, or during a backup
with missing files, or through an API call to expire the object.

NOTE: There are other parameters for all of these structures. Please see
the ADSM/TSM Administrator's Reference Guide for details.

---------------
EXAMPLE
---------------

Backup copygroup is set as follows:
VDE = 3
VDD = 1
RETEX = 100
RETO = 1

Explanation:
- Versions 1 through three are kept up to 100 days FROM WHEN THEY
BECAME INACTIVE.
- Any versions past 3 will be expired immediately upon the next
server-side EXPIRE INVENTORY process.
- NOTE: NO MORE THAN THREE VERSIONS WILL BE KEPT AFTER EXPIRE
INVENTORY, REGARDLESS OF THE NUMBER OF DAYS SPECIFIED IN
RETAIN-EXTRA AND RETAIN-ONLY!
- If the active version is made inactive (client side expiration),
then only the most recent copy will be kept, and it will only
be kept for one day FROM WHEN IT BECOMES INACTIVE.

--------------
EXAMPLE
--------------

Backup copygroup is set as follows:
VDE = NOLIMIT
VDD = NOLIMIT
RETEX = 14
RETO = 20

Explaination:
- All versions will be kept for 14 days FROM WHEN THEY BECAME INACTIVE.
- When no active version remains (client-side expiration), the last
inactive version will be kept for 20 days FROM WHEN IT BECOMES INACTIVE.


--------------
EXAMPLE
--------------

Backup copygroup is set as follows:
VDE = 5
VDD = 0
RETEX = NOLIMIT
RETO = NOLIMIT

Explaination:
- 5 versions will be kept while an active copy exists.
- Files will not expire by age.
- When the active version is made inactive, the next EXPIRE INVENTORY
will remove ALL versions of the file.


Sandra wrote:

> Great /andrew.. you cleared all my confusions...
> Unfortunately for me .. i have been immediately given TSM and all at the same
> time .. i m in Lotus,systems, oracle backups... thats why i get to confuse in
> policies that everything requires.
>
> I try my level best to get all thats written, but sometimes i get tooo much
> confused and there is no one around to help .. then i look forward to get help
> from you guys .. and believe me .. i get really very satisfied when you people
> reply ...
>
> Thanks alot ...
> Kind Regards,
> Sandra
>
> Andrew Raibeck wrote:
>
> > Sandra,
> >
> > You really need to read the TSM Admin Guide in order to understand how TSM
> > works. The chapter "Implementing Policies for Client Data" is especially
> > pertinent to this discussion.
> >
> > > That means:
> > > Version exists = nolimit ----------- I m effectively keeping the files
> > that
> > > are on the system for ever. Fine with me !
> >
> > Not quite. This setting works in *tandem* with RETEXTRA. VEREXISTS says
> > how many versions to keep and RETEXTRA says how long to keep inactive
> > versions (active versions are not subject to expiration). Whichever
> > criterion is met *first* will cause the version to expire. For example, if
> > you have RETEXTRA=30 and VEREXISTS=7, then you can have no more than 7
> > backup versions, no matter how old they are; and that the oldest inactive
> > version will be no more than 30 days old. So if you back up a file every
> > night, no active version will ever get older than 7 days old, despite the
> > RETEXTRA setting, because you permit a maximum of 7 versions (and if you
> > back up the file 7 times a day, then no version ever gets older than 1
> > day); if you only back up the file once a week, then you will have no more
> > than 5 versions, regardless of the VEREXISTS setting, because inactive
> > versions older than 30 days will be expired by RETEXTRA.
> >
> > When you set VEREXISTS=NOLIMIT and RETEXTRA=1100, then you are permitting
> > an unlimited number of backup versions within the number of days specified
> > by RETEXTRA.
> >
> > > Version data deleted = NOLIMIT --------- I m keeping the files that have
> > been
> > > deleted from client forever just in case if i want to restore sometime
> > later
> > > . -- my requirement -- fine with me.
> >
> > Not quite. This works just like VEREXISTS, but takes effect when TSM
> > detects that the file on the client machine has been deleted. Depending on
> > whether you want to use less stringent criteria for deleted files, you can
> > either set VERDELETED to something less (doesn't make sense to make it
> > bigger than VEREXISTS) or set it to the same value as VEREXISTS.
> >
> > My point is, you can't look at the VER* and RETEXTRA settings in a vacuum
> > since they work together.
> >
> > > Retain extra version = 1100 --- keeping the inactive versions for 1100
> > days
> > > that is approximately around 3 years -- and I can restore those active
> > > versions after 3 years too  and not beyond.
> >
> > No. Active versions are *always* available, regardless of age, until you
> > delete the file from the client system. When that happens, then the next
> > incremental backup will detect that the file has been deleted, mark the
> > version inactive, and then VERDELETED and RETONLY take effect. RETONLY
> > affects that active version that was just inactivated. RETONLY provides
> > you with an option to allow the final backup version of a deleted file to
> > be kept longer (or shorter) than RETEXTRA affords.
> >
> > > Retain only version = 1100 ---- After the deletion of files from client,
> > the
> > > extra versions will be deleted and the ONLY VERSION LEFT WILL BE DELETED
> > AT
> > > THE SAME TIME THAT IS AFTER 1100 DAYS.
> >
> > No. This affects retention of the most recent backup, which was the active
> > version until TSM detected that the file was deleted and marked it
> > inactive (see what I wrote in the paragraph above).
> >
> > > What is Backup Retention (Grace Period) which is defined in Policy
> > domain?
> >
> > See the chapter in the Admin Guide that I recommended above.
> >
> > Regards,
> >
> > Andy
> >
> > Andy Raibeck
> > IBM Software Group
> > Tivoli Storage Manager Client Development
> > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> > Internet e-mail: storman AT us.ibm DOT com
> >
> > The only dumb question is the one that goes unasked.
> > The command line is your friend.
> > "Good enough" is the enemy of excellence.
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/05/2004
> > 10:59:03:
> >
> > > That means:
> > > Version exists = nolimit ----------- I m effectively keeping the files
> > that
> > > are on the system for ever. Fine with me !
> > >
> > > Version data deleted = NOLIMIT --------- I m keeping the files that have
> > been
> > > deleted from client forever just in case if i want to restore sometime
> > later
> > > . -- my requirement -- fine with me.
> > >
> > > Retain extra version = 1100 --- keeping the inactive versions for 1100
> > days
> > > that is approximately around 3 years -- and I can restore those active
> > > versions after 3 years too  and not beyond.
> > >
> > > Retain only version = 1100 ---- After the deletion of files from client,
> > the
> > > extra versions will be deleted and the ONLY VERSION LEFT WILL BE DELETED
> > AT
> > > THE SAME TIME THAT IS AFTER 1100 DAYS.
> > >
> > > What is Backup Retention (Grace Period) which is defined in Policy
> > domain?
> > >
> > > Kind Regards,
> > > Sandra
> > >
> > > Version
> > >
> > > "Das, Samiran (IDS ECCS)" wrote:
> > >
> > > > Vere,verd,rete,reto
> > > > NOLIMIT,NOLIMIT,1100,1100
> > > >
> > > > Regards, Samiran Das
> > > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > > > Behalf
> > Of
> > > > Sandra
> > > > Sent: Thursday, November 04, 2004 2:43 PM
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Subject: Retention policy -- quick one!
> > > >
> > > > Dear List,
> > > > This is just a quick one.
> > > > What policy setting should i keep in order to keep unlimited number of
> > > > versions of a file for 3 years?
> > > >
> > > > Kind Regards,
> > > > Sandra
> > > > --------------------------------------------------------
> > > >
> > > > If you are not an intended recipient of this e-mail, please notify the
> >
> > > sender, delete it and do not read, act upon, print, disclose, copy,
> > retain or
> > > redistribute it. Click here for important additional terms relating to
> > this
> > > e-mail.     http://www.ml.com/email_terms/
> > > > --------------------------------------------------------
> > > >

<Prev in Thread] Current Thread [Next in Thread>