With 200M files and only 7TB you must have many small files. To guess at how many objects will be in your DB you could use the file count from an incremental backup. Just multiply by your retention and add the base count.
For comparison purposes I have 149M objects in a 71% used 94GB DB. The source data is about 40TB, of which TSM has 72TB stored. TSM backs up about 1.2TB per night. To keep LTO3's fed, be sure you have adequate system busses to handle the simultaneous reads and writes from disk, tape, network, DB and Logs. Andy Huebner -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dave Mussulman Sent: Friday, May 19, 2006 3:13 PM To: [email protected] Subject: [ADSM-L] multiple instance recommendations Hello, I have questions about server sizing and scaling. I'm planning to transition from Networker to TSM a client pool of around 300 clients, with the last full backup being about 7TB and almost 200M files. The TSM server platform will be RHEL Linux. I realize putting all of that into one TSM database is going to make it large and unwieldy. I'm just not sure how best to partition it in my environment and use the resources available to me. (Or what resources to ask for if the addition of X will make a much easier TSM configuration.) For database and storage pools, I will have a multiple TB SAN allocation I can divide between instances. I have one 60 slot HP MSL6060 library (SCSI), with two LTO-3 SCSI drives. There is also an external SCSI LTO-3 drive. My understanding of a shared SCSI library indicates that the library is SCSI-attached to a server, but drive allocation is done via SAN connections or via SCSI drives that are directly attached to the different instances. (Meaning the directly attached SCSI drives are not sharable.) Is that true, at least as far as shared libraries go? The data doesn't actually go through the library master to a directly connected drive, does it? If not, and I still wanted to use sharing, I could give each instance a dedicated drive - but since two drives seems like the minimum for TSM tape operations, I don't really think it's wise to split them. (However, if the 'best' solution would be to add two more drives to max out the library, I can look into doing that.) If the drives need to be defined just on one server, it looks like server-to-server device classes and virtual volumes are the only solution. I don't really like the complexity of one instance storing anothers' copy pools inside of an archive pool just to use tape, but it looks like things are heading that way. Other than the obvious hardware cost savings, I don't really see the advantage of multiple instances on the same hardware. (I haven't decided yet if we would use one beefy server or two medium servers.) If you load up multiple instances on the same server, do you give them different IP interfaces to make distinguishing between them in client configs and administration tools easier? Tape access-wise, is there a hardware advantage putting multiple instances on the same system? Any recommendations on any of this? Your help is appreciated. Dave This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
