ADSM-L

Re: ADSM versus Arcserve and Backup Exec

1998-09-16 10:27:58
Subject: Re: ADSM versus Arcserve and Backup Exec
From: Dan Kronstadt <dkronsta AT YAHOO DOT COM>
Date: Wed, 16 Sep 1998 07:27:58 -0700
Sorry, Richard - that answer is too forgiving. Your example of helping
someone might even have been referring to me. But:

a) it should not be that HARD to get adequate performance. How many
messages have you seen debating "small file aggregation?" Thats not an
option - its a result of careful tweaking thats poorly documented. And
its not clear it can fix files already backed up - which represents
MILLIONS of files at my shop alone.

b) I have still heard very few people state adequate restore times.
Everyone talks about backups. The first decent stated times I have
seen here are 2000kb/s from a gentleman at Nestle's - thats 7 gig per
hour - if he means restores as well as backups. That at least gives me
some hope that it will work if I invest the money. Of course, we get
double that on restores of large Oracle databases thru the SP2 switch
...

c) we have been on the phone with IBM *many* times, and mostly get
people who read the manual with us. Or people who know the server but
not the client code.Or who know Unix but not Netware or MVS.


---Richard Sims <rbs AT BU DOT EDU> wrote:
>
>
> >What is most interesting about this topic is that there has yet to
be a
> >reply from an IBM representative.
> >This is a common problem to which IBM has yet to offer a satisfactory
> >resolution.
>
> >ADSM restores are extremely slow when recovering a large number of
small
> >files. This problem is particularly bad with Novell clients but is
also true
> >for NT and UNIX. As this problem usually becomes apparent under the
most
> >difficult circumstances; a disaster recovery, it is particularly
worrying.
>
> Well, IBM is hearing the complaints, but they would be able to better
> appreciate the problems some customers are having if specifics were
provided
> as to just what the topology is, what PTF levels are involved, and
what
> options are being used.  That is, just saying that restorals are
slow is not
> all that helpful.
>
> For example... I recently helped a site which popped up on another
list,
> complaining similarly about slow restoral times.  They had an MVS
server and
> Novell clients, both running ADSM V.3 code.  They had reasonably
expected that
> by default that options like Small File Aggregation were active.
But not.
> And they had not tried No Query Restore, which is particularly
beneficial in
> the presence of large numbers of files.  They tried these and
reported that
> restoral times were "dramatically improved".
>
> File system topology and client system speed also play large roles
in the
> restoral rates you will see, plus network configuration, buffer
sizes, etc.
> Obviously, you have to take many factors into consideration, based
upon the
> particulars of your site, and then try controlled experiments as you
change
> variables.  It's all worth doing, and at a minimum will give you
both a sense
> of control and a basis for measuring the effect of new options and
hardware as
> they become available.  Appreciate how much it frustrates IBM
developers when
> customers complain that ADSM is slow, but it turns out that
customers have not
> taken advantage of features which the developers went to great pains
to
> introduce to improve performance.
>
>      Richard Sims, Boston University OIT
>

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com