Tab,
Just to throw out a thought - our company is currently looking at a
vendor called Data Domain (I ran into their product during the Storage
Decisions 2003 conference last Oct). They make an ATA based appliance
that is supposed to be able to store in the range of 23TB using only 16
raid10 disks. Their claim to fame is a front-end that does what they
call "Global Compression", meaning that they eliminate redundant chunks
of data - which, in the backup world, represents a lot of our data
stream.
Like I said, we are only starting to look at them (as a potential
disk-based replacement of our primary tape pools), so I cant say if they
can really do what they say, but it might be worth checking out their
website.
If anyone else out there has evaluated the product good or bad, please
share the results.
Steve Schaub
Systems Engineer
Haworth, Inc
616-393-1457 (desk)
616-886-8821 (cell phone)
6168868821 AT messaging.nextel DOT com (text page)
WWJWMTD
-----Original Message-----
From: Tab Trepagnier [mailto:Tab.Trepagnier AT LAITRAM DOT COM]
Sent: Wednesday, January 28, 2004 2:42 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM best practices manual?
Wanda,
Thanks very much for the suggestions. In answer to your questions:
1. I know I have compression operating on the drives because our
average tape capacity is 1.6 X uncompressed capacity on all three media.
2. Most of what we back up is server data; a little bit is OS, etc, but
not much. We're a Notes and Oracle shop and we have a LOT of data from
both systems. We also design and manufacture our own products, and our
engineers routinely generate 100MB+ CAD files. 3. We keep five copies of
user-created data, and two copies of everything else. Design data is
also archived but that isn't relevant to this discussion. 4. True, but I
already have FIVE libraries; I am trying to avoid buying a sixth.
This is what I think I'm going to do. At present we keep everything
except permanent archives online fulltime since we don't really have an
"operator". We have two parallel data paths: "small clients" going to a
3575, and "large clients" going to the 3583. I'm going to recombine
those paths into a single path and make liberal use of the Migration
Delay feature. The idea is for the incoming data to travel: Disk -->
3575 --> 3583 --> MSL DLT --> shelf. The idea is to have data 1-2 days
old on disk (radical!), data 2-10 days old on fast-access 3570, data
10-180 days old on LTO, and data older than 6-12 months on the shelf.
The little MSL retains nothing but is instead just a portal.
As for a "best practices" guide, I've begun browsing the TSM 5.2
Implementation Guide to see if that provides the info I'm looking for.
I'm also browsing my training handout from the ADSM 3.1 Advanced
Implementation course.
Thanks again for the suggestions.
Tab
"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> 01/28/2004
12:44 PM Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: TSM best practices manual?
Tab,
I'm not sure this is an issue of TSM design - if your libraries are out
of capacity in terms of SLOTS, rather than throughput, you just have
"too much" data.
That either means you are
1) not compressing the data as much as you can, or
2) backing up things you don't need to
3) keeping data longer/more copies than you need to
4) really in need of additional library space
For 1), it's a matter of checking to make sure that your drives do have
compression turned on. If you can't compress at the drive level, turn
it on at the client level.
For 2-4, I don't know any magic/automatic way of figuring it out.
Here's what I do:
dsmadmc -id=xxxxx -password=yyyyyyy -commadelimited "select
CURRENT_DATE as DATE,'SPACEAUDIT',node_name as node, backup_mb,
backup_copy_mb,archive_mb, archive_copy_mb from auditocc"`;
Suck that into a spreadsheet and look to see which clients are taking up
the most space on the server side.
Then go look in detail at the management classes and exclude lists
associated with the "hoggish" clients, and see what you can find out
about the copies they are keeping.
- Are you keeping copies of EVERYTHING on the client for a zillion
versions, rather than just the important data files?
- for Windows 2000, are you keeping more copies of the SYSTEM OBJECT
than would likely be used?
- Look at their dsmsched.log files and see what is actually being backed
up.
- Be suspicious of TDP clients not deleteing copies they are supposed
to. (For example, if they are supposedly keeping 10 versions of a 10 GB
data base, but the SELECT shows 500 GB on the server, there's something
wrong.)
- If it's user/group space, are there lots of .mp3 files? (exclude 'em
with a clientoptionset)
- Make sure you aren't backing up TEMP directories
etc..
I run the query monthly and save the data so that I can compare from one
month to the next. That tells me which clients are GROWING the fastest.
Those are the ones to attack.
With luck, you will find some things that you can do that will extend
your library life a while. Maybe not. But at least you will be able to
tell your management WHY you are running out of space.
Hope that helps.
Wanda Prather
Johns Hopkins University Applied Physics Laboratory 443-778-8769
"Intelligence has much less practical application than you'd think" -
Dilbert/Scott Adams
-----Original Message-----
From: Tab Trepagnier [mailto:Tab.Trepagnier AT LAITRAM DOT COM]
Sent: Wednesday, January 28, 2004 10:11 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM best practices manual?
TSM 5.1.7 on AIX 4.3.3
9 TB online, total of 24 TB managed.
Our TSM tape libraries are nearing their capacity. Currently we're
running a fairly simple TSM system, using little of the new
functionality introduced since V 3.1. We backup to onsite tape and make
copies to a copypool whose tapes are vaulted offsite. That's pretty
much the entire system.
Our current tape library fleet consists of a 3583-L72 (LTO-1), two 3575s
(and L12 and an L18), an HP SureStore 4/40 (DLT 8000), and an HPaq
MSL5026 (DLT 8000). Before we spend $60-80K - or more - on another
tape library, I'd like to review the system's architecture to see if
there is another path we can go.
I've been through the TSM Admin Guide and Technical Guide, but what I'm
really looking for is a description of current best practices regarding
TSM system design. Is there another document that would present that
info better?
TIA
Tab Trepagnier
TSM Administrator
Laitram, L.L.C.
|
