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.
|
