I don't know your application, but IMHO every application design should
include backup considerations. When I hear "24x7 and no time for
backups" I also hear (ashamed whisper) "in fact we do backups, but it
take whole week to finish it. Recovery would be horrible, we didn't
tested it yet". One polish bank was closed for over week just because
backups were not planned correctly.
Application HAVE to allow to do backups. It can rely on flashcopy-like
functions, preferrably online mechanism like DB2 imagecopy, maybe just
backup window.
If you don't like HSM autobackups, then you can use ad hoc backups
(HSEND) - it's still better than IBEGENER/DSS based ones, because HSM
tracks the backups in an inventory. It can be part of job scheduling.
IMHO usually it is feasible to customize ARCMDxx to have autobackups
when needed.
--
Radoslaw Skorupka
Lodz, Poland
Joel C. Ewing wrote:
An interesting difference in philosophy. We use HSM less for backups
and more for space management. The backup capability sounded attractive
initially, but we quickly found that with some application batch running
almost 24x7 there were too many cases where the timing of autobackup
and/or the number of cycles needed made HSM backup a bad fit for us. On
the other hand, being able to move idle data the users are unwilling to
delete to duplexed ML2 has become a significant savings for us for DR.
The data is completely covered for DR and yet rarely needs to be
touched. If the migrated data were still on DASD, it would have to be
repeatedly processed and dumped by daily DR point-in-time backups and
add significantly to the cost of daily DR processing.
If we had the luxury of our own DR hot site and could afford the
required bandwidth, we would look for DR solutions that minimized
dependency on tapes and rethink our current HSM strategies as well.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
