Hi, I would suggest that you take a close look at the snapshots of the netapp boxes. Those coupled with ndmp backups into TSM are a very nice combination. Instant restores and longterm retention in TSM, on paper it looks very very nice.
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Rhodes Sent: donderdag 23 maart 2006 14:32 To: [email protected] Subject: Re: NAS from a TSM perspective - looking for good/bad/ugly 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" <[EMAIL PROTECTED] ST.COM> To Sent by: "ADSM: [email protected] 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:[EMAIL PROTECTED] On Behalf Of Richard Rhodes Sent: Wednesday, March 22, 2006 8:39 AM To: [email protected] 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 ----------------------------------------------------------------- ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -----------------------------------------------------------------
