Mark,
Yep. Retention is 30 days. Device type is "Disk", don't use "File" because you
have to manage the volumes like tape and that takes extra work. i've never had
a problem with fragmentation, i suppose it's possible if you make your disk
volumes very small, my disk volumes are 200Gb each and my backuppool Pct Util
has run in the high 90's with no problems.
Has far as keeping my storage small is where i really have to get creative.
First, all clients compress data (don't turn on "compress always" because
already compressed files will grow), that way files are stored compressed on
the disk pools. Second and most important use global excludes so you don't
backup any thing you don't need. One of the biggest saving was not backing up
indexes for Groupwise Databases, all groupwise admin's know if they restore a
DB they have to reindex, the indexes take up much more space than the DB's
themselves. i also exclude temp files and subdirectories, recycle directories,
and salvage directories on NetWare Servers. If it wasn't for my creative use of
excludes my storage requirements for backups would be much greater. You need to
do a lot of work with users, administrators, and dba's to get backups down to
the bare minium.
Let me know if you have any other questions.
John
Synovus
>>> "Hokanson, Mark" <Mark.Hokanson AT westgroup DOT com> 01/10/03 10:22AM >>>
John,
So all of your backup data is on the disk and none ever goes to tape? What is
your retention? Are you device type file? How do you handle storage pool
fragmentation? With 377 servers at 100gB nightly it seems you would fill your
4TB with about 40 day retention, correct?
Thanks a lot for your help,
Mark
-----Original Message-----
From: John Underdown [mailto:johnunderdown AT sti.synovus DOT com]
Sent: Friday, January 10, 2003 7:50 AM
To: ADSM-L AT VM.MARIST DOT edu
Cc: Mark.Hokanson AT westgroup DOT com
Subject: Re: TSM Disk Pool Management
Mark,
We been using a all disk backuppool for a number of years now. It's grown to
4TB, we just keep adding disk expansion to the server as we need more storage
(We are now looking at the new ATA Raid Expansion Cabinets 3TB for $10,000).
We backup 377 servers (80 to 100 GB total) nightly and growing. The TSM
database is 15GB sitting on raid 10 with 15K rpm drives (very fast) , i also
defrag the DB monthly. This is a dream setup and works very well, restores run
in the blink of a eye. I run the TSM server by myself as a part-time duty. The
only problem you'll have is figuring out what to do with all your free time.
The is a common topic on the list, search the achives at www.adsm.org. Let me
know if you have any questions.
John
Synovus
Synovus Makes FORTUNE '100 Best Companies To Work For' in America For Sixth
Straight Year.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Hokanson, Mark
Sent: Thursday, January 09, 2003 7:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM Disk Pool Management
We are considering creating an extremely large TSM disk storage pool
(IE: 1-10TB). The goal being to eliminate going to tape. Does anyone
have any really BIG disk pools? Are there tools available for managing
large TSM disk pools over time. (IE: Reclamation, Aging Data, etc) The
documentation from Tivoli suggests that we need to set it up as a device
type=FILE. What are the drawbacks using this approach? Is performance
dramatically impacted? etc...
Thanks in advance,
Mark Hokanson
Thomson Legal & Regulatory
NOTICE: This communication is intended only for the person or entity to whom it
is addressed and may contain confidential, proprietary, and/or privileged
material. Unless you are the intended addressee, any review, reliance,
dissemination, distribution, copying or use whatsoever of this communication is
strictly prohibited. If you received this in error, please reply immediately
and delete the material from all computers. Email sent through the Internet is
not secure. Do not use email to send us confidential information such as credit
card numbers, PIN numbers, passwords, Social Security Numbers, Account numbers,
or other important and confidential information.
-----------------------------------------
NOTICE: This communication is intended only for the person or entity to
whom it is addressed and may contain confidential, proprietary, and/or
privileged material. Unless you are the intended addressee, any review,
reliance, dissemination, distribution, copying or use whatsoever of this
communication is strictly prohibited. If you received this in error, please
reply immediately and delete the material from all computers. Email sent
through the Internet is not secure. Do not use email to send us confidential
information such as credit card numbers, PIN numbers, passwords,
Social Security Numbers, Account numbers, or other important and
confidential information.
|
