ADSM-L

Re: ADSM versus Arcserve and Backup Exec

1998-09-15 05:11:02
Subject: Re: ADSM versus Arcserve and Backup Exec
From: Christo Heuer <christoh AT ABSA.CO DOT ZA>
Date: Tue, 15 Sep 1998 11:11:02 +0200
Hi,

I can agree with Dan regarding poor performance when it gets to
restoring a great number of small files. It does not matter what platform
you are on, the performance IS an issue!
To give you an idea - We had  a standalone unix server that we backed
up (4M/bit T/ring card, not very powerfull as far as processing etc. goes).
We backed up this box - 15Gig of user data consisting of about 300K files,
between 1Kb and 1.7Meg each.
The backup took about 16Hours - this is WITH other backups etc. running to
the ADSM server. In other words the ADSM server was not dedicated to this
task.
This is acceptable performance taking the above into consideration, BUT,
(Why is there always a BUT?), the restore was a different story.

This unix box was moving to a node on our SP/2 - the data was already
on this node but a bit outdated as to speak.
So the only option we had was to do one of two things:
1) Wipe all the older data on the SP/2 node and restore the standalone
unix box onto the SP/2 node
or
2) Use ADSM's intelligence and restore the box using the -ifn (If newer then
replace).
BIG mistake!
The restore ran for two days non-stop - where we eventually cancelled it and
restored
via the GUI braking the directory structure down a bit more.
This helped in the sense that we had less files in the restore stream and we
could
also make use of parrallel sessions.
At the end it took us about the whole week-end sitting monitoring the
restore process
and starting new processes. (Not a pretty solution).
Now - Where was the bottleneck?
Who knows - Bad design I think (Sorry IBM)
The ADSM server: In this case is a powerfull MVS mainframe - doing a few
I/O's
and using very little CPU cycles during all of the restore process.

The network: Escon attached to SP/2 node

The Adsm client: (Powerfull node - the reason we had to move this
box to the node was because of performance on the old box)

We monitored the network/cpu usage on the SP/2 side etc. but
nowhere could we find any pointers as to what the problem
with the bad performance was.

During the whole restore process the first time - after running for
about 24 hours only 15Meg of user data was physically transferred.
The rest of the time seems to be spent comparing files between
MVS and the SP/2 - not that this should be taking so long?
Has anyone been able to get better performance from a restore
when there is such a number of files in the picture?
Does not matter what platform!

Cheers
Christo Heuer


>There are so many pieces involved in tuning for a fast restore.  It would
be
>nice to know how fast each piece could theoretically go.  In this case it
>would be nice if someone (IBM?) supplied a program which could run on many
>platforms that would read an input stream of file names and sizes and then
>allocate the file and write random data of the input size.  This would test
>the speed of the filesystem and be one of the baselines for estimating
>restore time.  When a restore is going badly, it might help point the blame
>finger in the right direction.
>
>A logical source for the input file would be the output of 'dsmc q backup'.
>I think it would help us plan for restores of large servers.
>
>Another Tool for baselining would be to run a restore into  the bitbucket,
>i.e. exercise the server and the network, but not the filesystem.
>
>one more would be to have the server do everything it does for a restore
but
>not send it out over the network.
>
>--
>-----------------------------------------------------------
>Bill Colwell
>C. S. Draper Lab
>Cambridge, Ma.
>bcolwell AT draper DOT com
>-----------------------------------------------------------
>
>In <19980914142949.13666.rocketmail AT send103.yahoomail DOT com>, on 09/14/98
>   at 07:29 AM, Dan Kronstadt <dkronsta AT YAHOO DOT COM> said:
>
>>Dave - I would be interested in getting some more info about your restore
>>tests. We are happy with adsm except for one thing - a restore of a file
>>server with several 100K files takes TOO LONG! I have yet to hear anyone
>>say they can restore more than a gig or 2 an hour, when that is made up of
>>files averaging 50K each. We are still testing, and the bottleneck may be
>>Netware *allocating* that many files - but other vendors (arcserve, for
>>example) claim faster restore times. Do you have any info on this kind of
a
>>restore? Large files get restored fine.
>
>>Thanks.
>>Dan Kronstadt
>>Warner Bros.
>>dan.kronstadt AT warnerbros DOT com
>
>
>
>
>>---Dave Larimer <david.larimer.hnj9 AT STATEFARM DOT COM> wrote:
>>>
>>> An alternative suggestion on the use of ADSM, the issue is that you
>>do not
>>> wish to use ADSM over the network because of restore being too slow.
>> If
>>> this is correct, I would give you an alternative suggestion.  Given
>>that a
>>> disaster situation is hopefully few and far between, backup all data
>>via
>>> ADSM through the network and in the event of an actual disaster,
>>construct
>>> a new box at the central site, restore it there and ship it to the
>>remote
>>> location.  The cost savings eliminating local software, tape library,
>>> hardware and labor would be substantial.   In addition, when I
>>evaluated
>>> Arcserve, Backup Exec, and ADSM, I found the following:
>>> Backup time:  (depending on how much data changes from day to day) I
>>found
>>> that overall ADSM came in first, followed closely            by
>>Arcserve
>>> and then by Backup Exec.
>>> Restore time: (depending on severity of restore and network
>>connectivity)
>>> All three products performed about the same, with            ADSM
>>having a
>>> slight edge, due to it's strength as file restore software.  In
>>ADSM, the
>>> file is ready as soon as it        is restored.  This may not be the
>>case
>>> with the other two products.
>>> Service Support: This is the part that I experienced the most
>>variety, with
>>> ADSM, I found the most support, followed by Arcserve         and then
>>> Backup Exec a distance third.  Backup Exec's support fell off sharply
>>> during off hours.
>>> Cost savings: ADSM clearly came out ahead here in all categories.
>>>
>>> I hope that this helps.
>>>
>>> Dave Larimer
>>> David.Larimer.HNJ9 AT StateFarm DOT com
>>>
>>>
>>>
>>>
>>>
>>> From:
>>O1=INET00/C=US/A=IBMX400/P=STATEFARM/DD.RFC-822=ADSM-L\@VM.MARIST.EDU > on
>>09/11/98 04:21:21 PM
>>> To:   ADSM-L
>>> cc:
>>> Subject:  ADSM versus Arcserve and Backup Exec
>>>
>>> Help!
>>>
>>>      There is a shift going on within our company where many Netware
>>> servers are being consolidated to larger NT servers.  A large number
>>of
>>> these Netware soon to be NT servers are located in remote offices
>>connected
>>> to our statewide ATM backbone via T1 lines.  The new NT servers in the
>>> remote offices will contain approximately 6 - 10 GB of user data.
>>> In most cases we were not planning on backing up the remote NT
>>machines to
>>> a central ADSM server because it would take too long to restore an
>>entire
>>> machine in a disaster recovery scenario.  This means, for the remote
>>> offices, local tape, probably a IBM 3570 library, would be used with
>>the
>>> standalone version of ADSM.  We also thought we might backup the 3570
>>> storage pools to a central server for disaster protection.
>>>
>>>      Our current enviroment is ADSM for MVS v3 backing up 100
>>clients all
>>> within the Datacenter or close by.  Clients are AIX, SUN, HP,
>>Windows NT
>>> (Lotus Notes Servers), and 1 Netware server.   ADSM has been in used
>>to
>>> backup our UNIX servers for nearly 3 years.  Arcserve is currently
>>used to
>>> backup the Netware servers using a DAT tape drive attached to each
>>server.
>>> We standardized, or a least I thought we did, on using ADSM company
>>wide
>>> about a year and a half ago.
>>>
>>>      Ok that's the background on to the problem.. A person from our
>>> distributed computing group informed me today that they have pretty
>>much
>>> decided to go with Arcserve or Seagate Backup Exec to backup the
>>remote
>>> office servers.  This decision was made without my involvement and
>>> shouldn't have been.. But that's a political issue.. The question I
>>have
>>> for you good people is has anyone out there done a side by side
>>comparison
>>> of the ADSM single server version versus Arcserve and/or Seagate
>>Backup
>>> Exec? Any ammo you can give me that shows ADSM is the better choice
>>would
>>> be GREATLY appreciated.  It is their feeling that ADSM is too slow
>>and not
>>> widely used in the industry for backing up Windows NT or Netware.
>>>
>>>
>>> Thanks!
>>> Jeff Connor
>>> Niagara Mohawk Power Corp.
>>> Syracuse NY
>>>
>
>>_________________________________________________________
>>DO YOU YAHOO!?
>>Get your free @yahoo.com address at http://mail.yahoo.com