Another option that we are considering. Create a Copy Pool for each of the cycles that are important to you. Do a copy of the primary pool to each of those copy pools on the schedule that you want. Yes, you have all the data in each of these copy pools at that interval of time. And, it will take a number of tapes. But it may be more understandable to the customer.
>> Previous Option We have been facing the same issues and I came up with a neat way to handle this. Lets presume that the requirement is to be able to recovery any data that is 6 years old or younger and these are file system files not database backups. To accommodate achieving this from a real point of view you would define a management class with verexist and verdelete of nolimit and retention dates of 7 years. You would run the backup daily. Now the question becomes how many cycle days do you want to have offsite of tapes. If you were rotating daily, theoretically you would need to have 2 offsite and the one going offsite. So, to reduce the amount of pool rebuild which I will describe below you should probably go with a 20 day cycle. It makes no difference because the same amount of data would be offsite. Now, you write a script command to select the volumes from the DRMEDIA table that are going to return that are over say 18 days ago created/updated and are in a VAULT status, use that as input to MOVE Data commands to the same offsite pool and the primary pool tapes will rebuild those few tapes that go offsite daily by adding to the new tapes created in the copypool. So, you can avoid open storage with this scenario, and you have all versions of files offsite that are in the 7 year data picture. Just mark the box of tapes to return 21 days later. To determine if this is a cost effective approach talk to your customer and sell the benefits. The windows where files could be lost are eliminated. There is no guessing or gambling. The reality is he will be able to see the data and recover it. The side benefit of this is you never have to perform reclamation of the copy pool. The move data commands handle it for you. Watch, there is going to be a new requirement for copypools submitted at Share in Nashville for tape rebuild expiration days so that this is automated as an extension to reclamation. The cost benefit is enormous to customers that use offsite tape rotations. There is no tape handling by the courier anymore. It is a box of tapes at a time. No matter what the primary pool will have to have the copies in it onsite unless you used something like backupsets. The other option is to dynamically create and delete of copypools to meet the customer requirements for the data and come up with an elaborate mechanism which can be done. -----Original Message----- From: Thomas Denier [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 11:36 AM To: [EMAIL PROTECTED] Subject: Re: Different retentions for same file > I am planning a TSM implementation ata customer who has another backup > solution already in place. They want to slowly make TSM take over all backups, > but they don4t want to suddenly change the work done by the production people, > who take care of all tape movements. The present backup solution works using > different retention times for the backed up files: the daily backups are kept > for 20 days; the saturday ("weekly") files are kept for 40 days; the monthly > backup is kept for 100 days, and there is a "year" backup that is kept for 5 > years. > > The question is: I could make this using backups for the daily processes, > and to use archives for the other ones. But there are TDP4s involved > (SQLServer, Exchange and DB2) who always do backups, and if I use something > like different management classes, I would get a lot of rebinding problems. > > Would backupsets be the answer? Any ideas would be greatly appreciated. Lots of TSM sites attempt to emulate the kind of selective tape retention described above. However, the goal is usually to emulate the old system's hit or miss ability to retrieve very old files, not to emulate the old system's tape handling. Historically, sites trying to emulate selective tape retention have done TSM incremental backups every day and run occasional TSM archives as substitutes for tapes kept for longer than usual periods. More recently, some sites have experimented with TSM incremental backups every day and occasional generation of backup sets. If you use TSM incremental backups at all there are going to be changes in tape handling. I would suggest that your customer either give up on TSM or give up on preserving the current tape handling practices.