Kelly,
What was the client you were restoring? NT? Novell? That's pretty damn fast
if you ask me.
You may recall that I posted a while back concerning small file problems,
especially with Windows NT.
We had an SMS server which we restored which had just over a million as you
call them itsy bitsy files. As I recall it took about 24hrs to restore 20Gb
or thereabouts. Actually all I can recall was all the phone-calls I got
every hour asking "is it done yet?".
The opportunity arose to upgrade the hardware on this particular client and
we revisited this restore but this time with a much beefier client machine.
We rebuilt the server onto a 4-way 400Mhz Xeon 256Mb RAM from the twin
pentium 133Mhz system.
Performance improved quite dramatically. The plan was to move to the new
hardware over the weekend which gave me the oppurtunity to test restoring to
the new hardware a few times just to see what we would expect in terms of
performance.
Since we were FS Collocated I was ambitious and tried to restore two
logical drives both about 20Gb in size using the ADSM BA Command Line.
About half way through the restore the machine ran out of memory and both
restores died. ADSM had used over 250Mb of memory.
I then did the one drive using the command line and got about 20Gb in 11hrs.
The plan was to do the other logical drive once this restore had completed.
Total downtime was planned for 24hrs.
Unfortunately however when the day of the restore came the customer did not
want to go with 24hrs downtime. I therefore brought up to instances of the
GUI and restored both drives simultaneously. I've noticed that the GUI
always uses a lot less memory than the command line but the GUI is supposed
to be a lot slower.
Imagine my amazement when both drives completed in about 7.5hrs??
Ok so the network was more dormant as this was done at the weekend, but for
one thing we have an OC-12 ATM network and besides in this type of restore I
would expect the greater part of the processing to be devoted to db
crunching and file creation as the ADSM Server rattles through it's database
and as the client creates file entries on the client.
There was relatively no load on the ADSM Server throughout both restores.
I guess my questions are "How does the Command line differ from the Gui in
the method in which it handles processing of backup/restore?"
"Why is the Command-line touted as
being faster than the GUI?"
"Why was it not so for me?".
I wish I had more perf data to handover but that's about it. The ADSM Server
is an rs/6000 S7a running Aix 4.3.2, ADSM 3.1.2.20 and the ADSM Client
peforming the restore was 3.1.0.7 on NT4.0 Sp4.
Note that although we use 3.1.0.6 to backup data we typically always use a
network load of 3.1.0.7 to do all our large restores. This is due to the
inherent File permisson problems with 3.1.0.6 which can seriously screw up
your restores.
Nathan
> -----Original Message-----
> From: Kelly J. Lipp [SMTP:lipp AT storsol DOT com]
> Sent: Wednesday, September 01, 1999 12:36 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Panic state.
>
> Angel,
>
> If you think about what's going on during a restore like this, locality of
> reference within the database is going to be very low since files arrive
> for
> a client at varying times. Therefore, the effectiveness of the cache is
> not
> surprising. This is a tough query. Not knowing the exact layout of the
> database we can't guess how tough. I guess I'm not surprised that the
> server works very hard on something like this. What was the outcome? How
> long did it take to restore the file system? How many tape mounts?
> Bottom
> line: did the restore meet your service level agreements?
>
> We did some testing a month or so ago restoring a large file system. Due
> to
> circumstances beyond our control, it never completed, i.e., someone kept
> killing our restore! During the test, though, we were able to move ~14 GB
> consisting of a nearly a million itsy bitsy files in a little over three
> hours. Sun Solaris Server (big honking system, I might add), 3494 with 6
> 3590 drives. I didn't track how many tape mounts, but I'm guessing 10-15.
> We didn't monitor the performance of the system during this, but we were
> doing other stuff on it and it didn't seem bothered by the restore going
> on.
>
> Having never tried a large restore like this, I was pleased. The test
> indicated we would be able to perform this sort of restore within our SLA.
>
> Kelly J. Lipp
> Storage Solutions Specialists, Inc.
> PO Box 51313
> Colorado Springs CO 80949
> 719-531-5926
> www.storsol.com
> lipp AT storsol DOT com
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of
> ANGEL BUGARIN
> Sent: Wednesday, September 01, 1999 11:02 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Panic state.
>
> << File: BDY.RTF >>
|
