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
>>> stevep AT IBK.COM DOT AU 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.
***********************************************************************************
|
