I thought it was 800-bytes for each entry? We will continue to expand our 3494 library. We can easily add a rack of 12-3592 drives. All it takes is $$$$$$$$$$$$$$$$$$$$$$.
Remco Post <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 04/28/2008 05:51 PM Please respond to "ADSM: Dist Stor Manager" <[email protected]> To [email protected] cc Subject Re: [ADSM-L] TSM server scaling/sizing for lots (>20000) nodes Zoltan Forray/AC/VCU wrote: > Crazy project time........... > > I have been asked to research the > feasability/probability/scaleability/sizing of TSM to possibly handle > backing up thousands (actually close to 20,000 or more) desktops! > > Anybody have experience doing very, very large scale backups of so many > nodes? Don't expect much in storage occupancy since we would exclude > things like MP3, etc. It would just be the ##### of files/database size > (sounds like this would have to wait for V6 since DB2 should scale much > better). > > Does anyone run their TSM servers, open? Trying to > administer/register/monitor this many clients would be a nightmare. > > They are talking about budgeting close to $1M, which would include more > bodies as well as the equipment/software! Well, you are an experienced TSM admin, so I guess you know the drill, about 500 bytes for each version of each file. Get a rough estimate of the number of files. The number of nodes you mention is an issue, even if each stores just a few files (they won't I guess). You'll need lots of TSM instances, and lots of db spindles. Really, there is a use for 15k RPM 72 GB (or even 36 GB) disks in raid1, and you just found one. In my experience, there are a few things to make life easier, Gresham EDT is one of them, with autolabeling and decent library sharing, you really gain over TSM's native library sharing. On the plus-side, you are limited to ACSLS libraries, which you'll probably need anyway for larger amounts of data (how many options are there, really? ;-) ). -- Met vriendelijke groeten, Remco Post
