I did exactly this about two years ago.
Yes you can do it. HSM is not very good at it (DASD backups) though. You may
want to consider alternatives if you have particularly long-term requirements
for keeping your backup data.
My reasons were that by then only HSM used tape, and we wanted to get rid of
the tape units, to save floor space, power usage, and maintenance costs.
The other, most compelling, reason was DR. Our main disk unit is a DS6800 with
PPRC to a remote site. It has around 25% FC disk and 75% FATA - cheapear
because they're (supposedly) slower, but a blind man would be glad to notice,
even they are much quicker than the RVA we had before). Even in asynchronous
mode, the PPRC replicates in near-real time, with a latency or around 7 to 8
seconds. There's no way I can replicate tape data in step with that. We've now
got our DR cutover - including all network switching, NAT changes etc - down to
around 20 minutes all-up, so we're available for end-users to get on and do
real work in that time.
When we were using tape (even though it was virtual tape) we were hindered by
the possibility that ML2 and backup data may not have been replicated yet (in
which case we'd have to wait, sometimes up to four hours, for that to happen)
or in the event of a real disaster, we might be in the position where the ML2
and/or backup data would not get replicated at all, and we'd have a lot of
repairs to make on the production system. For example, if the outage happened
between the ML1/Backup data being written and before it (completed) being
replicated - you won't have the data, but the HSM CDS's think you have it. All
extra work in a DR when you really really want to keep things as simple as
possible.
The first thing I did was increase the size of the ML1 pool and stop creating
ML2 data, leaving it for the rest of its life on ML1 instead. All of the MLx
data is now replicated to the DR site over the PPRC. But this is the easy bit
really. I wouldn't try putting ML2 on DASD, I can't really think of a good
reason to do that.
To do backups to DASD is a bit more painful. You have to pre-define daily a set
of daily backup volumes - HSM cannot dynamically add them as it will for tape.
You need one volume for each backup task that you want to run, plus a couple
more in the event that one fills. If one fills during the backup run and no
more are available, the backup process issues messasges about the task waiting
for a volume, hangs, and moves on to the next task, (which may or may not do
the same, depending on whether other tasks have finished and freed up a volume
with space on). I've not found a way to recover from this other than shutting
down HSM (cancelling), adding volumes, and restarting. You'll need to keep an
eye on the backup volume usage, as HSM won't do it for you, or do any
housekeeping on them other than EXPIREBV processing. In addition, HSM does not
seem to apply any kind of intelligent selection of volumes from the daily set,
e.g., which ones have the most space.. It just uses the fi!
rst one in the list and goes from there, so the spare capacity you've provided
for contingency could (probably will) sit there most of the time 90 or more %
empty for most of the time, which might waste precious disk space if you don't
have a lot spare. I've also noticed that, for some reason I've not been able to
explain, DASD backup seems to take about twice as long as it did on tape. My
backup window went from around 1.5 hours on tape, to 2.5-3.0 hours on DASD.
I always think there are about three main reasons why you do backups:
- DR, for recovering the entire system;
- 'idiot' backups, for local, small-volume recoveries of corrupted or
accidentally deleted files;
- archives, for long-term, usually out-of-sight-out-of-mind copies.
So in my case the DR requirement is satisfied by PPRC, and the archives by the
combination of PPRC and data management/retention policies in SMS/HSM. The data
corruption/accidental deletion is still an issue however, since these kinds of
actions will get replicated with PPRC. At a dataset level I mitigate for these
with additional backup versions, but at the volume level it's still a problem
for certain volumes, notably the HSM daily backup volumes. So I dump those and
a few selected other ones daily (at the moment, still to tape, although I'm
probably going to change that to DASD too). The difference is, I don't care
about replicating that tape data now, there's no need, as it all gets junked
and re-written each day anyway.
The parameters you've identified are about right, I think. I've got:
SETSYS BACKUP( +
DASD +
INUSE( +
RETRY(Y) +
DELAY(5) +
SERIALIZATION(PREFERRED) +
) +
)
SETSYS DSBACKUP( +
DASD +
TAPE( +
TASKS(0) +
) +
)
SETSYS TAPEMIGRATION( +
NONE +
)
And loads of ADDVOLs for DASD daily backup volumes (I've got eight per day on
one LPAR and 12 per day on another).
I'm now questioning why I'm even burning loads of CPU cycles by moving data
back and forth the ML1 at all, so I'm considering just making very large live
data pools and leaving it online, doing away with ML1 completely, but this idea
would work for us but maybe not for everyone.
I also mentioned that you might want to consider alternatives for doing your
backups. This will of course depend on your ML1 policy and how for how long you
need to keep data. I'm looking at FDR/ABR at the moment, which in my case
anyway looks like a far superior way of doing backups to DASD.
There's probably a lot of other things I did but which have slipped my mind at
the moment, if I think if any I'll post again.
Brian
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
esmie moo
Sent: 19 April 2010 17:53
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM QUESTION - MOVING TO DASD FROM TAPE - ML2
Good Morning Gentle Readers,
Because of incessant problems with tapes (3590-1) we are looking at using DASD
for ML2 migration as well as BACKUP. Besides changing the following commands
is there something else I could have overlooked?
SETSYS ARECOVERUNITNAME(3590-1)
SETSYS ARECOVERML2UNIT(3590-1)
TAPEMIGRATION(ML2TAPE(TAPE(A19840C)) RECONNECT(ALL))
MIGUNITNAME(A19840C)
SETSYS BACKUP(TAPE(A19840C))
RIDF(BACKUP(1)) -
UNITNAME(A19840C) -
SETSYS DSBACKUP (DASDSELECTIONSIZE(0 0) TAPE(TASKS(2)
If anybody has been down this road I would appreciate it if you could warn me
of any potential problems that you have encountered.
Thanks
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
