Hi Eric
How much disk space do you have? What is the size of the database? You don't
specify the platform either, but I'll assume AIX.
Possibility #1.
Backup as normal. Use db2adutl extract to restore the data to a filesystem.
Archive this data. Watch out for filesystem limits on the size of a file. You
may need to use jfs2
Possibility #2.
Mirror your data.
Run db2 command to stop IO
split mirror from backup (standard AIX 4.3.3 Facility)
Resume IO
Backup the stale copy with standard TSM archive
Restore mirror
This is documented
http://www7b.software.ibm.com/dmdd/library/techarticle/0204quazi/0204quazi.html
Possibility #3
Write some scripts to control the db2adutl delete process and use some sort of
exclusion list to keep the copies that you want indefinitely.
HTH
Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia
>>> ewinters AT AU1.IBM DOT COM 18/02/2003 9:19:57 >>>
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
**********************************************************************
This e-mail, 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 e-mail 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
e-mail in error, you are asked to immediately notify the sender by
telephone or by return e-mail. You should also delete this e-mail
message and destroy any hard copies produced.
**********************************************************************
|
