ADSM-L

Re: TSM best practices manual?

2004-01-28 15:07:48
Subject: Re: TSM best practices manual?
From: Guillaume Gilbert <guillaume.gilbert AT CGI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Jan 2004 15:04:49 -0500
Hi Tab

Instead of buying a sixth, buy one big one to consolidate everything. STK
has the L700E with a capactiy of nearly 1400 tapes with 2 frames and the
L5500 with nearly 5000 tapes. IBM's 3584 can go up to 16 frames now (I
think) with just as much capacity. I'm working with all three of these and
almost no problems. (Hardware is hardware, it breaks...) Put 10 LTO2 drives
in either and you're all set.

Guillaume Gilbert
Backup Administrator
CGI - ITM
(514) 415-3000 x5091
guillaume.gilbert AT cgi DOT com

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf Of Tab Trepagnier
> 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.
>

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