Time to weigh in here. 1. DB2 backups are API backups. Generate backupset will not work. 2. DB2 backups are different to other backups. the db2adutl program is used to expire them. TSM holds indefinitely until db2adutl explicity deletes. So what is necessary is to examine your DB2 processes and the way that db2adutl is run. If you are scripting it to do the deletions (there is a delete after so many days parameter) then you will need to revisit that for your Friday exceptions.
That said, if you want to keep another copy of your DB2 backup, without taking another backup, then you can retrieve the Db2 backup from TSM to a disk file, again using arguments to db2adutl, and then you can back that up to TSM again by the usual backup or archive mechanism. Now there is a DB2 control file that holds details of backups..... whether you will be able to restore 12 months hence and need to also keep a copy of the control information is a question for your DB2 DBA. Regards Steve Harris AIX and TSM Admin Queensland Health, Brisbane Australia >>> [EMAIL PROTECTED] 31/03/2004 8:18:51 >>> On Monday 29 March 2004 23:21, Crawford, Lindy wrote: > Good Day TSMers, > > Please HELP......we do db2 backups to TSM on a daily basis. What I would > like to do to satify our auditors is make a copy of the backup taken on > Friday nights to a storage pool that I've called weekly. > > I do not want to move the data, but make a copy of that backup set taken as > at the friday night. You are confused. :) If I understand you correctly, you want to retain the Friday night's DB2 backups for a period different from that of the DB2 backups produced on other nights of the week? And, you are already producing "copy pool" tapes to be sent off-site. The retention of client backups (including DB2) is separate from the location of that data on disk/tape, and across storage pools. It is the TSM Policy/Management Classes that control how the data is retained. Even if the data is duplicated to multiple storage pools (Primary/Copy) that data is all retained, and expired, at the same time, as specified by the various Management Classes. You can't simply copy the Friday DB2 backups to a differnt storage pool and retian that media for a different period. TSM doesn't bother about retaining media - it only retains data - and when the database expires the data from the database the index of the data on ALL storage pool media is expired. To retain the Friday night's DB2 backups for a period separate from the retention of the other night's you will probably need to create a new client account on the TSM server, and a new Management Class to retain the data. Then configure the DB2 client to use the special nodename only on a Friday, and bind the Friday's backup to the new Management Class. There is no need to create a special "Weekly" storage pool to contain the data. TSM will happily track the retention of your "normal" DB2 backups, and "Friday" DB2 backups, in the same storage pool, and even on the same tape/s. Your system should look _something_ like the following: Nodename Day of week Mgmt Class StgPool --------------- ------------------ ------------------ ------------- NODE_DB2 SMTWT-S DB2 DB2POOL NODE_DB2_FRI Friday DB2_FRI DB2POOL This is necessary because (if I remember correctly) DB2 saves it's backups as a combination of *consistently named* "Backup" objects for data and "Archive" objects for logs. You can't just change the Management Class used for Friday's backup without effecting the retention of the "backup" objects saved from previous DB2 backups (if they belong to the same client account). You probably also want to ensure the Friday backup is a "full" DB2 backup... Remember, storage pools "contain" data, Management Classes "retain" data. Regards, Steven P. -- Steven Pemberton Senior Enterprise Management Consultant IBK, Senetas Group Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907 Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. ***********************************************************************************
