ADSM-L

Re: Retention policy -- quick one!

2004-11-05 13:18:09
Subject: Re: Retention policy -- quick one!
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 5 Nov 2004 11:17:43 -0700
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/
> > --------------------------------------------------------
> >