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/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] On Behalf > Of > > > Sandra > > > Sent: Thursday, November 04, 2004 2:43 PM > > > To: [EMAIL PROTECTED] > > > 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/ > > > -------------------------------------------------------- > > >
