I am interested in seeing the response you get to this note, as we have a
similar setup.  We have restored a 5 Gb Exchange IS in as little as 30
minutes, and as much as 38 HOURS.

We finally found a conflict in the network connection to the ADSM server to
be the problem.  I 'm not a network "guy", but it had something to do with
duplexing being set differently on the RISC box than it was on the
network/port definition.  This conflict caused problems when the ADSM server
was sending the data only, not receiving.  We found the problem by FTPing a
file of similar size from the ADSM server to the NT server, eliminating the
ADSM client and server code from the equation.

> -----Original Message-----
> From: Nathan King [SMTP:nathan.king AT USAA DOT COM]
> Sent: Tuesday, April 13, 1999 2:00 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Exchange Connect Agent Restore Performance
>
> We are using the ADSM Connect Agent for MS Exchange Server v1.1.0.0A
> (Fixtest A).
> Our ADSM Server is an Rs/6000 S7A running ADSM 3.1.2.2.0
>
> Our backup performance is great. Going to disk we typically average
> 4.5Mbytes/sec.. going to tape we have seen as high as 9.1Mbytes/sec.
>
> I did our first restore the other day only to get a throughput of
> 2.5Mbytes/sec.
>
> I ran perf monitor on the NT Exchange Server. I suspected that the NT
> Server
> migh have been suffering a disk write penalty i.e. it couldn't keep up
> with
> the data being sent from the ADSM Server. I noticed that 98% of disk time
> was being spent doing disk writes but the average disk queue length was
> only
> 1.1.. I would have expected a disk queue length of 2 or greater if the
> disk
> were a problem.
>
> Anyone any ideas on what I could tune here.. whether it be the Connect
> Agent, the RS/6000 or the NT Server.
>
>
> Nathan
>
> Nathan King
> Open Systems Storage Management
> *  (210) 913-5755
> * Pager: 753-5755
> * E-mail: nathan.king AT usaa DOT com
>
> The opinions herein are mine and almost certainly do not reflect those of
> my
> employer.