ADSM-L

Re: ADSM versus Arcserve and Backup Exec

1998-09-16 11:41:54
Subject: Re: ADSM versus Arcserve and Backup Exec
From: "Lambelet,Rene,VEVEY,FC-SIL/INF." <Rene.Lambelet AT NESTLE DOT COM>
Date: Wed, 16 Sep 1998 17:41:54 +0200
Hello Dan,

the 2000 KB/s I gave before are the Network transfer rate and not the
aggregate one!

On Win95, I get the following rates for 700 files (volume of 100 MB):

                 Netw transf rate       Aggregate transf rate
Backup:     2'500 KB/s              500 KB/s    
Restore:     6'000 KB/s              450 KB/s

So, comparing is not an easy thing, so many parameters come into
consideration...

Regards,

René Lambelet - *3543 - *A581 
Nestec SA - 55, Av. Nestlé - CH-1800 Vevey
Tel: ++41/21/924'35'43 / Fax: ++41/21/924'45'89
E-Mail: rene.lambelet AT nestle DOT com



> -----Original Message-----
> From: Dan Kronstadt [SMTP:dkronsta AT YAHOO DOT COM]
> Sent: Wednesday, September 16, 1998 4:28 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: ADSM versus Arcserve and Backup Exec
> 
> 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