That's good as long as the 10 versions, or 10-days is within the recovery
requirements for the server or site. If there are Winders servers that have
no recovery requirements for the system, and only for DATA on the server,
then why not add "-SYSTEMOBJECT" to the domain for those nodes and save
yourself an additional 2-300MB times 10 versions for each server?
We have a client that has Windows2000 file/print servers in their remote
locations that only backup "ALL-LOCAL -C: -SYSTEMOBJECT". The recovery is to
restore a Ghost image and let it replicate for the AD recovery, then restore
the data.
You can take a look at the specific recovery requirements of the Windows
server to determine if backing up the SYSTEMOBJECT is really necessary.
Bill boyer
DSS, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Hart, Charles
Sent: Wednesday, January 28, 2004 3:10 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM best practices manual?
One huge space saver for us was to create and apply a specific mgmt class
for Win2000 Sysobjects. Each sys obj is approx 2-300mb that changes daily,
and if you have a couple hundred Win2k servers it adds up.
We created a mgmt class called SYSTEM_OBJECTS, then put a inclexcl on the
server side choosing the option to force the client option.
INCLEXCL 1 Yes INCLUDE.SYSTEMOBJECT ALL SYSTEM_OBJECTS
The SYSTEM_OBJECTS mgmt class only retains 10 active and 10 deleted
versions. Big save on tape and TSM DB size.
Every little bit helps
Charles
-----Original Message-----
From: Coats, Jack [mailto:Jack.Coats AT BANKSTERLING DOT COM]
Sent: Wednesday, January 28, 2004 1:51 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM best practices manual?
Tab,
We have similar problems to being out of space. At this point, we need more
room.
I am looking into using the 'move media' command to allow me to start having
on-site
out of library tape storage. I REALLY DO NOT WANT TO DO THIS, but it is
otherwise
flat running out of space.
Wanda's comments are right on. Don't back up what you don't need.
Determine if some
things you are backing up are not 'mission critical' (my sons mp3's are not
mission
critical at home, but if you run a commercial selling site, they could be!,
but at
home my 'quicken' files are mission critical!)
But making lots of that kind of decision at work is really a committee
decision not an
individual one :(
... Lots of luck Tab. ... Jack
> -----Original Message-----
> From: Prather, Wanda [SMTP:Wanda.Prather AT JHUAPL DOT EDU]
> Sent: Wednesday, January 28, 2004 12:44 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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.
|
