ADSM-L

Re: ADSM versus Arcserve and Backup Exec

1998-09-16 02:18:01
Subject: Re: ADSM versus Arcserve and Backup Exec
From: Herwig Evenepoel <Herwig.Evenepoel AT KB DOT BE>
Date: Wed, 16 Sep 1998 08:18:01 +0200
Hi,

I can imagine that ADSM developpers are frustrated about all those complaints.
But at the same time there are a lot of adsm users who are also frustrated
because things are not
working as expected and because the local IBM support is insufficient.

For example :

We are using ADSM server for OS/2 (both IBM products) version 2 because there
is no version 3
We do not know if or when there will be a version 3 for OS/2
We also have the same disaster recovery problem : a lot of small files
Version 3 of the ADSM client still suffers with a problem of the 386hpfs file
system
We backup our Notes servers (IBM product) with the agent on doc level, but if
we have to restore
some databases on doc level, we need a lot of time. For example, to restore
only 1 deleted document
into a mailbox of max. 10 MB, we need one hour ! Thus we are saving time and
space with the doc level
backup, but when we need our backup for restore we are losing a lot of time.

So what, stay tuned with IBM and keep on smiling ?

Herwig Evenepoel
KBC Belgium








rbs AT BU DOT EDU on 15/09/98 18:13:00
To: ADSM-L AT VM.MARIST DOT EDU@Internet
cc:  (bcc: Herwig Evenepoel/U29346/KB/KredAlm)
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