ADSM-L

Re: No query restore rep=all -ifn

1998-11-13 10:57:03
Subject: Re: No query restore rep=all -ifn
From: Julie Phinney <jphinney AT HUMANA DOT COM>
Date: Fri, 13 Nov 1998 09:57:03 -0600
It turns out that's the answer.    Thanks to all who responded.  I just got
off the phone with IBM.   If you use -PITDATE (or I assume -FROMDATE)
ADSM first scans the database, and mounts the tapes that it needs, only.
If you use -REP=ALL -IFN    it essentially does a -REP=ALL, mounting every
tape and moving every file, and at the last second, only replaces it if
newer.   I should have used fromdate (or -pitdate?)  to bring the machine
to current after a weekend tape made by Arcserve.    I would not have had a
No-Query-Restore, but it surely (?) would have been faster.   I'll see if I
can get a test done.
Thanks,
Julie




Doug Thorneycroft <dthorneycroft AT LACSD DOT ORG> on 11/13/98 09:18:11 AM

Please respond to dthorneycroft AT lacsd DOT org

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Julie Phinney/Green Bay/Humana)
Subject:  Re: No query restore rep=all -ifn





Julie have you tried using the -fromdate and -fromtime options to
restore
only fies backed up after the date and time of your ArcServ backup.


Julie Phinney wrote:
>
> 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