Thanks for the comments . . . .
> We were up to almost 2TB per drive, and after
>recarving it out so that each drive was <700gb, we saw a noticeable
>increase in performance and reliability from the TSM backups.
We just talked with our local IBM TSM person yesterday about this project
to get his ideas. He
made a very interesting comment - that the Windows filesystem only supports
one scan process
per filesystem. Setting resourceutiilization high will cause
concurrent/parallel data sessions sending
files to the tsm server from one filesystem, but it WON'T cause parallel
sessions to scan the filesystem.
I don't understand this, but it's what he said, and it's kind of what you
indicate. What we came away
with is that we need to find a balance between multiple filesystems and
filesystem size such that we get
good backup performance. So the windows folks are going to want one
huge filesystem per server,
and we are going to insist on multiple filesystem each up to some size.
How big and now many we
need to figure out.
Thanks for the war story!
Rick
"Schaub, Steve"
<Steve_Schaub@BCB
ST.COM> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: NAS from a TSM perspective -
looking for good/bad/ugly
03/23/2006 05:51
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
Rick,
We don't use any NAS or HSM here, but having gone through 6 very painful
months of trying to stabalize TSM backups on 3 large (3-4TB each)
Windows fileservers, I can share what we have learned in that area.
1. The fileserving itself hardly every taxes our machines, but TSM can
and will take up every resource available during backup. Assuming the
4-8TB 6-8mil files per machine you describe, I would not want less than
a 4-way 3Ghz with 4gb ram running W2k3 SP1 - and I would like an 8-way
x64 with 8gb ram running W2k3 64bit if I could get it. I would also
recommend a dedicated gigabit link for backup.
2. Use TSM journaling. We went through some pretty complicated dance
steps to get individual journal processes running for each volume, it
may be worth it to you, or you may opt for the standard single journal
instance. It depends on your change rate, and you want to clear the
journals up every so often (monthly reboot or restarting the journal
service will zero out the journal db and cause a non-journal backup the
next run), but it has the potential of cutting a huge chunk of time off
your nightly backup. On 2 of our machines, it cut the time from 7hrs to
<1, but the 3rd had hardly any affect because it houses the .pst files
which are obscenely large and backup every night (800gb worth).
3. The biggest thing that helped us in the end was reducing the size of
each individual volume. We were up to almost 2TB per drive, and after
recarving it out so that each drive was <700gb, we saw a noticeable
increase in performance and reliability from the TSM backups. We were
still sending the same amount of data, so don't ask me why this helped,
but it did.
4. YMMV, but on some of these machines, I use a resourceutilization=25.
Feel free to contact me directly if you have questions or need any
sample scripts etc.
Steve Schaub
Systems Engineer, WNI
BlueCross BlueShield of Tennessee
423-752-6574 (desk)
423-785-7347 (cell)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Wednesday, March 22, 2006 8:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] NAS from a TSM perspective - looking for good/bad/ugly
Oh how the projects just keep coming out of the cracks in the walls . .
.
We are a Netware shop that will be converting to Windows for file and
print serving. Part of this project is consolidation many, many Netware
servers into a handfull of centralized Windows systems. Some remote
sites will be served via WAFS technology while others will have onsite
local servers that replicate back to the centralized servers. The plan
is for all backups to take place from the centralized servers. Right
now the NAS team is talking about 4-6 big windows servers, each with
about 4-8TB of storage comprising 3-6m files.
It is possible that HSM would be used on these servers. These servers
would replicate part or all of their filesystem to a DR site.
We are interested in advice that can help us in designing this system so
that we can effectively backup and recover.
Some of the questions we are thinking about . . . .
1) Would this be better on a NAS system (yea, I know this is a TSM
list)?
2) What's a good NAS system (Netapp, Celerra, other)?
4) If NAS, use NDMP or not?
3) Any good suggestions on setting up big Windows servers for effective
backup and recovery?
- limiting individual filesystem size
- memory/cpu requirements for TSM client to back this up
- raw volume backups and incrementals
4) If you backup BIG windows or NAS systems, could you describe how
they are setup and how TSM is setup to effectively backup and recover
them.
We have a "chance" to do this right . . . .
Thanks!!!!!
Rick
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
Please see the following link for the BlueCross BlueShield of Tennessee
E-mail
disclaimer: http://www.bcbst.com/email_disclaimer.shtm
|
