ADSM-L

Re: ADSM versus Arcserve and Backup Exec

1998-09-16 03:38:58
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 09:38:58 +0200
Hello,

since using adsm server OS/390 3.1 and clients 3.1 (Netware, NT), we are
very happy with backup and restore performance! Even for large Netware
volumes containing more than 400'000 files. It was catastrophic with V 2.

N.B. Netware backups have always been much slower than NT (300 KB/s for
Netware, 2'000 KB/s for NT), as long we used the IBM 3172 ATM box between
the clients and our mainframe OS/390.

We assumed then that the IP stack in Netware was worse than in NT. This
assumption was wrong:

we changed the 3172 for a CIP card from CISCO (escon <-> atm): Netware
backups reach 2'000 KB/s, comparable to the NT throughput!!

So, the CISCO card accelerated the backups (6 times faster for Netware). The
NT backups are limited by the client hardware probably.

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: Richard Sims [SMTP:rbs AT BU DOT EDU]
> Sent: Tuesday, September 15, 1998 5:45 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: ADSM versus Arcserve and Backup Exec
> 
> >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