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/
> > > --------------------------------------------------------
> > >
|
