ADSM-L

Re: A NEWBIES perspective - ADSM and big file-servers - and slow restore times

1999-03-16 21:40:09
Subject: Re: A NEWBIES perspective - ADSM and big file-servers - and slow restore times
From: "Stephen R. Pole" <stephenp AT PRTH.GEOBANK.PGS DOT COM>
Date: Wed, 17 Mar 1999 10:40:09 +0800
HI there, Stephan this is Stephen from Australia,

Thanks for such as great newsgroup

I'm a relative "Newbie" to this so please be patient, We haven't got a system 
admin or an ADSM guru in house. Just tend to leave ADSM to run by itself. When 
it needs upgrading then we call IBM. Most of the time we figure things out 
oursleves .... ususally into the weee small hours of the mornigs over here. We 
are geographically isolated from the Eastern States of Australia.

Anyway, we had a very similar problem recently regarding slow restore times.

Our system is no where near the sizes what some of you guys have I'm sure.

Briefly, it now consists of the following:-

1 x ADSM Server - 1Tb of SSA with +200Gb for ADSM Disk storage pools
1 x 3494 ATL
8 x 3590 drives

This is becoming a bit of a sore point in our organisation fast backup vs a 
slow restore. If that is what you are speaking of....

The conclusion I reached at the time was that it always a questions of 
resources and time, and making the most from whatever resource you have.

Internally we only a have a few clients of various types NT - Solaris - SGI - 
and AIX. It's the big Servers that are the big head aches. Especially over a 
100BT Ethernet. (Think that is bad it was until recently 10BT).

We took the decision early not to collocate data to improve backup times (there 
are other activities we do in our ATL). As we thought quite rightly, at that 
time it would make better use of resources. Small restores of say 10 to 20Gb 
were just fine. We estimated the chances of a 300 Gb restore on one server that 
was fully RAID'ed and mirrored as being (1 zillion to one).. Guess what I won 
the lottery !!!  It crashed RAID, mirrors, the lot .........  So we were forced 
at gun point to improve this.


36 hours later it was restored .... but with so many tape mounts I lost count 
on fingers and toes and started counting the hairs being pulled out of my head. 
Our internal client was unhappy with the time it took to restore. They had been 
doing this manually onto a single 3590 drive ..... (Of course they had not 
considered the labour overheads and waste of resources doing a conventional 
Weekly then daily incremental backup)

So we went for collocation of filesystems, added four more 3590's, added more 
(bigger disk pools).... and are now begging for a real network that offers 
Quality of Service.

Cut a long story short .... We now also use filespace collocation now  and use 
lots of disk storage pools prior to migrating to tape

This is done for this cleint onto 2 Disk Pools of roughly 50 Gb a piece then 
flush to 3590 either after 90% or one week which ever comes first. We still 
have all the little pools for other stuff and assigned to other nodes. But if 
I'm not mistaken it's really is the big nodes that will cause you grief. If you 
don't sit down and educate the client and don't raise their expections to high 
then your asking for trouble.  This was one of the mistakes we made. Showed our 
internal clients (management) just how fast we could "blow away" a filesystem 
of say 2 - 3 Gb and magically make it reappear  !!! .

Many seem to think that a full restore on any system is just a cut a paste 
matter; And done as quickly as dropping something onto you Win95 desktop.....

We have a couple more (internal) cleints coming across to us soon with more 
than 2Tb filesystems attached. With the delta (change), daily,  being about 
half of that... It will make intersting reading some of our experiences when we 
implement these suckers.

It would be great to hear of anyone else's experiences in ADSM especially those 
of you who have to back up 1-3 Tb every night.

Thanks for some really interesting and helpful reading thus far since our 
joining. 

IBM had been keeping us in the dark for so long ....... Sorry Charlotte !! 
hehehe



Stephen

Stephen R Pole
Operations Manager
Petroleum Geo-Services Data Management Australia
Level 4, IBM Centre
1060 Hay Street
West Perth WA 6005
Australia
Phone          +61 8 9320 9080
Direct           +61 8 9320 9081
Fax               +61 8 9320 9090
Mobile           +61 41 239 4435  (041 239 4435)
e-mail            stephenp AT prth.geobank.pgs DOT com

*******************Internet Email Confidentiality Footer*******************
Privileged/Confidential Information may be contained in this message. If
you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver this
message to anyone. In such case, you should destroy this message, and
notify us immediately. If you or your employer does not consent to Internet
email messages of this kind, please advise us immediately. Opinions,
conclusions and other information expressed in this message are not given
or endorsed by my firm or employer unless otherwise indicated by an
authorized representative independent of this message.



<Prev in Thread] Current Thread [Next in Thread>