Julie,

It is not nice to be caught out like this!  But I don't quite
understand why it would take "more than 20 hours" to restore the 10GB
(450,000) files anyway.  We only use ADSM (no weekly full backups) and
we would recover this amount of data in a few hours.

I would be very interested in your hardware configuration (tape devices
used), your policy settings (how many versions etc), and the
configuration of your storage pools (collocation or filespace
collocation) and how many clients are backing up to each storage pool.
Also have you played with miltiple concurrent restore sessions at all
to use all of your tape devices?

Good luck,
Simon
----------
| From: ADSM-L AT VM.MARIST DOT EDU; jphinney AT HUMANA DOT COM
| From: ADSM-L AT VM.MARIST DOT EDU; jphinney AT HUMANA DOT COM
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: No query restore rep=all -ifn
| Date: Friday, 13 November, 1998 7:08AM
|
| I just got very bad news today from IBM about ADSM and I'm hoping that it's
| wrong and one of you can shed some light on this situation.
| Our "theoretical" disaster recovery plan is to use ArcServe weekly and ADSM
| nightly and when a disaster happens, restore from the weekly backup with
| Arcserve... then do an ADSM restore  -REP=ALL  -IFN     to JUST restore
| anything  that's newer than the weekly backup done by Arcserve.   We'd
| expect a reasonable few hours to scan a 10 GB drive and restore anything
| that's newer.
| Well we had a  Novell machine die a couple weeks ago.  Around 10GB,  and
| 450,000 files.  The mainframe ADSM 3.1.2.0 server is using OS/390 2.5,
| TCPIP 3.4 and a Fast Ethernet 100mbs  OSA2 adaptor.
| We restored using a weekly Arcserve backup.  There should have been few
| changes left to restore using ADSM.    The ADSM Client was 3.1.0.3.
| We started the restore with ADSM  using -REP=ALL  and -IFN   which is a No
| Query Restore - our supposed ace-in-the-hole for fast restore.   We let it
| run for about 20 hours a day, every day, when we had to stop it for some
| reason or another.  It started back in the beginning every day, because
| RESTART RESTORE  doesn't work with the -IFN parameter  (IBM created an APAR
| on that for me).    After 5 days of starting it back from the beginning
| and letting it run for 20 hours and it never finished and not letting the
| users have the machine  back   we finally  GAVE UP.   and gave the machine
| back to the users.
| I noticed the session counts on that 20hour thing  every day   showed  6 or
| more GB  being sent.  And I KNEW  very little should actually be moving,
| and it SHOULD be less and less every day.   And it was mounting many tapes
| every day.   It was as if we weren't using -IFNewer.
|
| So I did a trace for IBM.   I picked a small directory that has 30 files in
| it and no subdirectories.  It needs nothing restored.  I did a RES
| -REP=ALL  -IFN.    It mounted 9 tapes and showed session counts with more
| bytes than the total of what was in the directory.  And NOTHING was
| restored (as nothing should have been).
| And IBM told me that is how a No Query Restore works with -IFN.     EVERY
| tape is mounted, EVERY FILE MOVED to the client    OVER THE NETWORK   where
| it is then compared.   And only replaced if the file is newer.
| They will submit a design change request for me.
|
| So then, is our only choice for Disaster Recovery  to use nightly Arcserve?
| Or nightly ADSM, which has already been ruled out as un-viable for quick
| simultaneous recovery of many large drives.   Can't we make these things
| work together?   How can I get ADSM to do a reasonably quick scan of the
| drive and only move what's newer.  I am astonished that that is how it
| works.   I've been using ADSM for years and can't believe I never noticed
| before that -IFN moves every file first before it compares it.   Goodness,
| it's got to be faster to skip the -IFN and just use  -REP=ALL.
| Somebody please tell me  that my IBM rep is wrong before I have to break
| this news to management.  Or help me come up with a different combination
| of parms to offer as an alternative.
| THANKS!!!
| Julie
|