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