ML2 datasets are guaranteed an HSM backup ONLY if they are defined with
an SMS management class that requires auto backup. Auto backups may not
be useful in many applications where the timing and synchronization of
backups must correspond to application processing cycles, not the whims
of DFhsm. For that reason we tend to limit auto-backup to mostly
libraries. If the only reason for the auto backup is to recover from
damaged ML2 tapes, you would be much, much better off using HSM
duplexing of ML2 tapes. Recovery from a damaged ML2 tape is then
trivial: fetch the (hopefully offsite) duplex alternate, issue a single
TAPEREPLACE command, and then force a TAPECOPY or RECYCLE of the
alternate-made-primary tape to build a new offsite alternate. Without
duplexing, there is essentially no way to recover from loss of an HSM
backup tape that contains important archival data.
And just to re-iterate comments I've made here before, when making vault
or DR copies of HSM tapes, you really want to do it with HSM duplexing
and write two tapes at the same time, not with HSM TAPECOPY, or any
other product that replicates the behavior or TAPECOPY, by re-reading
the HSM tape after the fact. We can vouch from experience that with
after-the-fact copies you will eventually have a catastrophic tape
failure reading the tape while attempting (unsuccessfully) to produce
the copy. Fortunately we were not yet on 3590's when that occurred.
Almost everything we put on 3590 cartridges is duplexed in some fashion.
The second copy is for DR, which includes the limited disaster of loss
of a single tape cartridge. The criteria for not being duplexed is that
loss of the data is known to be acceptable.
Using techniques that effectively utilize the cartridge capacity, with
faster I/O transfer rates on 3590E, and with 3590E having at least 30
times the capacity of 3490E cartridges, you can generate duplex copies
and still beat the cost of unduplexed 3490E.
R.S. wrote:
Hal Merritt wrote:
Gee. Doesn't 'single point of failure' count for anything any more? What
happens when (not if) one of those tape goes bad or gets destroyed?
That's one heckofa lot of data lost.
I guess that means one might want to have more than one copy. Two would
be better. Gee. This solution is getting expensive.
Just a thought.
Let's assume you have SMALL cart, and small amount of data.
Now the cart went bad/got destroyed. You don't worry too much, because
it's only small amount of data, do you ?
After that you check what data was lost. Single file,
SYS1.MOST.IMPRTNT.DATA. <g>
Problem is not capacity-dependent IMHO.
For ML2's recovery can be capacity-dependent, after thousands ML2s lost
you cannot fix catalog entries/do restores manually - too much trouble.
Some scripted solution seems to be a must. Of course it also would work
with small capacity carts.
BTW: ML2 datasets have backup, otherwise they won't be migrated.
BTW2: You can exploit duplexing or tapecopy to have two copies on two
carts. IMHO it's inexpensive.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
