Dear All,

Can anyone advise on a workable strategy for taking DB2 backups which would
be treated effectively as 'archives' ie kept for the long term.
The requirement is to take an occasional DB2 backup (online if possible)
and to keep this backup offsite for the long term. The DB2 backup would
also be sent offsite with a backup set and TSM database backup, thereby
permitting total system recovery in the future. (Assuming same version of
TSM is available).

The requirements are not mine - they are the ones I have to work with. How
can TSM and DB2 best meet a requirement for long term storage WITHOUT
interfering with the current backup cycle?
Not being a DB2 administrator I'm wondering what the DB2 implications are
of sending a single backup offsite and subsequently keeping it. This
'archive' should not be considered to be available for the short term ie if
it becomes necessary to restore the DB in the very short term then the
recovery procedure should not use this 'archive'.

>From the point of view of managing and deleting old DB backups would it
perhaps make sense to use a different nodename? A different dsm.opt would
be necessary anyway to direct the data to a different storage pool.

I'm considering the following approaches and would appreciate feedback.

1) Shutdown DB2 and just archive filesystems. Almost certainly not going to
be acceptable to lose DB2 service however. But very simple to implement.

2) Perform online DB2 backup to the routine node name but use different
inclexcl file to direct backups (and logs created during the backup)  to a
different storage pool which is sent offsite. But can a db administrator
avoid deleting this backup (ie is it possible to keep a backup from 60 days
ago AND delete backups from 59-31 days ago?). I'm assuming that an online
backup plus associated logs provides the ability to fully recover.

3) As above but offline. Only difference I suppose is that there will be no
logs to backup too. I'm doubtful we can get the window though.

4) As for 2 and 3, but with a new node name.

Thank you for any suggestions.


Regards,

Eric Winters
Sydney, Australia