I had exactly the same requirement. Now I cannot remember what I did which is not good for this thread, but what I did learn which is not good.... If you have backed a file up the expiration date _cannot_ be changed if file is already deleted !!! even if you associate with another Policy with different retentions However if its still active not deleted just follow steps Dwight wrote Move Node to another relevant Policy and the next backup will change the objects policy settings.
Dwight Cook wrote:
Here is a thought... Define a management class with unlimited characteristics... define domain UNLIMITED backret=9999 archret=30000 define policy UNLIMITED standard define mgmt UNLIMITED standard UNLIMITED migdest=spacedisk define copy UNLIMITED standard UNLIMITED standard t=b dest=gbdp verex=nolimit verdel=nolimit retex=nolimit reto=nolimit ser=shrstatic define copy UNLIMITED standard UNLIMITED standard t=a dest=gadp retver=nolimit ser=shrdynam assign defmgmtclass UNLIMITED standard UNLIMITED Then: Query sched * * node=<nodename> Rename that node to <nodename>_LTR (LTR for Long Term Retention). Update the node and move it over into the UNLIMITED domain. Export /home /etc and /bin filespaces. Rename that node back to its initial name of <nodename>. Update the node and move it back into its initial domain. Make sure the schedule association is still in place, I believe it gets removed so define the association again. Import the <nodename>_LTR node exported earlier. Now, if you had bound any data to any special management class, that management class won't exist under the UNLIMITED domain and thus it will bind to the "backret" and "archret" grace periods of the domain. Any data bound to the default management class will again bind to the default which has unlimited characteristics. This leaves the initial node untouched and allows it to continue its normal backup cycle. Once they are through with the data... simply delete the ~_TLR node. Dwight -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Cheung, Richard Sent: Sunday, November 02, 2008 10:23 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] How to stop data from expiring Hello I would like to know how to stop data from a specific filespace within a node from being expired based on that node's copygroup membership Eg lets say I have a node called ABC against CopyGroup called 'Nightly' which says keep 7 versions. Within the node ABC it has paths /home /etc /bin So within TSM I can see filespaces for this node with those names. Today is Monday.. I have just been told that I need to keep the backup for /etc from Saturday until further notice due to a business requirement.... What is the best way of doing this? Manually copying the data to my CopyPool or create a new media pool not binded to a copygroup and copy the information there?? How would i go about restoring this information if I need to?? Richard <html> <body> <font face="arial" color=#808080 size="-2"><img alt="Santos Logo" src="http://www.santos.com/library/logo.gif";> <br>Santos Ltd A.B.N. 80 007 550 923<br> Disclaimer: The information contained in this email is intended only for the use of the person(s) to whom it is addressed and may be confidential or contain privileged information. If you are not the intended recipient you are hereby notified that any perusal, use, distribution, copying or disclosure is strictly prohibited. If you have received this email in error please immediately advise us by return email and delete the email without making a copy.</font> <font face="arial" color=#008000 size="-2">Please consider the environment before printing this email</font> </body> </html>
![http://www.santos.com/library/logo.gif"](http://www.santos.com/library/logo.gif"){kind=link}