ADSM-L

Re[2]: Disaster recovery

1997-04-17 11:27:31
Subject: Re[2]: Disaster recovery
From: Eric LEWIS <Eric.Lewis AT CCMAIL.ADP.WISC DOT EDU>
Date: Thu, 17 Apr 1997 10:27:31 CDT
     One factor not discussed in this response . . . the very unlikely
     requirement to restore both the server machine and a remote ADSM
     client simultaneously.  Disaster recovery plans depend on only one
     disaster wiping out one site, either the safe site or the production
     site.  The same rule applies to the server and the remote client.

     The topology of the client/server network and the server/safe site
     separation is perhaps a more fundamental issue than the brand of the
     software - so long as both brands support the same topology.  This is
     a constantly changing situation but ADSM is very strong in its support
     of the disaster recovery topology issues.  Prior to ADSM, our network
     server backup tapes were kept next to the network servers where they
     were handy for file restores.  enuf said.  erl


______________________________ Reply Separator _________________________________
Subject: Re: Disaster recovery
Author:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> at IPNET
Date:    4/17/97 8:37 AM


> Has anyone addressed this before?  In the event of a real disaster, and
> you lose a whole pile of servers, how does ADSM beat ArcServe?
> Where are our bottlenecks?
> Thanks for any feedback!
> Julie Phinney
> JULPHINN @ EMPHESYS.E-MAIL.COM
>

I'm currently evaluating ADSM and other backup packages.  You ask
what your bottlenecks are, the better question is what isn't a
bottleneck!  EVERY piece of hardware and software is a potential
bottleneck,  Lets start . . . .

1)  What kind of connection does your mainframe have to the network?
If it's one channel, you'll never bet more than 40mbps maximum
throughput.  ESCON, I forget the number.  In others words, how big is
the pipe out of the mainframe - you can't go bigger than that.  If
your gateway is a router, can it handle the traffic.

1.1)  A big pipe out of the mainframe is only as good as what it
feeds into.  If the interconnect is a ethernet, expect no more than
ethernet can provide.  Even if you have a highspeed network, don't
assume you can use all of it.  I have 2 RS/6k connect via a 155mbps
ATM switch - the max I've been able to send between them is about
40-50mbps (memory-to-memory tests).

2)  How many tape transports are available?  In a disaster, just how
many transports are going to be available for lan restores?

3) One
issue I looked at was that we contract with Comdisco for Hot Site
service.  Our connect to the Hotsite is T1 - which is acceptable for
servicing the mainframe application, but NOT lan restores.  If we
move to the HotSite, Lan backups and restores would end.

4)  How many servers would you want to restore concurrently?  Without
colocation there could be high contention for the same tapes.  Can
you estimate the load many concurrent restores would put on processor
utilization and the disk subsystems?  You might hit a wall that you
can only effectivly perform x number of restores concurrently.

5)  In a true emergency, are you going to be given the resources to
do what needs to be done?  Have you prioritized the servers so you
know which would need to be restored first?  last?


As I said, I'm only doing an eval so I shouldn't talk too much - but
from what I can see from adsm so far, the biggest bottle neck would
be ADSM itself.

rick


----------------------------------------------------------------------
Richard L. Rhodes     rhodesr AT ohioedison DOT com
Richard L. Rhodes     rhodesr AT ohioedison DOT com
Ohio Edison Co.       Phone:  330-384-4904
                      Fax:    330-384-2514
<Prev in Thread] Current Thread [Next in Thread>