These numbers are from STK 9840B drives. I am not talking about a backup and then a restore. I am talking about a daily backup for 8 months and then a restore. File fragemenation dramatically effects your througput over time. Sure we can spin 9840 drives to 100 GB/hr for large files. I have even backed up a file server to 38 GB/hr (throgh 1 GB NIC's) with millions of small files. But over time the speed is effected. It's being unfair it is what it is.
For that restore test was it right after a the backup was done? What is the change rate of the data. If it was after 8 months and you still got 40 GB/hr throughput then good deal. I haven't seen that. Daniel Sparrman <[EMAIL PROTECTED]> wrote: Hi Comparing these types of numbers are abit unfair. We have customers running 9840 and LTO-2. They have alot higher throughput than 8-12GB/hour over a GB nic. For example, we have a customer running Netware. The TSM server is an AIX server(pSeries 615) connected to a 3584-L32 library with 3 LTO-2 drives. The Netware server has about 200GB of data. The AIX server has three 100Mbs nic, bundled togheter in an Etherchannel interface(theoretic speed is 300Mbs or 30MB/s). The netware server is connected through 100Mbs ethernet(single adapter). The server have a restore time of about 5= hours which means we have an hourly throughput of almost 40GB/hour. Average networkspeed is 11MB/s. The Netware server utilizes multi-session restore, which means it can mount multiple volumes at once for restores. We have another customer running a pSeries 650 clustrer. The cluster is attached to a 3584-L32 library with 9 LTO-2 drives. The pSeries server is equipped with an Etherchannel interface which consists of 2 GB nics. During testing of a restore scenario on one of their Lotus Domino servers(300GB of data), they reached about 50MB/s restoring directly from tape. In this case, we didnt utilize multi-session restore, which meant that the single LTO-2 drive could deliver 180GB/hour. Today, the new tape technologies can easily outrun disks. To match LTO-2 drives against disks, you'll ned large, fiber-attached disk subsystems, with no other load than the TSM server load. Internal SCSI-disks can never outrun fiber-attached LTO-2 drives. The LTO-2 drive has a native speed of 35MB/s, compressed around 50-70MB/s depending on the type of data. They also have dynamic speed, which means you dont get the back-hitch as long as you keep writing data with at least 15MB/s. We've seen theese drives push up to 90MB/s on database backups and restores. During the testing phase of the implementation, we had up to 380MB/s from the disks(two mirrored FAStT900 connected through 4 FC HBA:s with 34 15K 36.4GB fiber disks per FAStT system) and almost 650MB/s from the drives(9 LTO-2 drives connected through 4 FC HBA:s). The speed of the drives is all about design. If you attach a large number of drives to a single FC HBA, you'll easily get back-hitch. With the LTO-2 drives, a fair number of drives/adapter is around 3-4 / adapter. Designing disk to match the tape drives is all about cost. S-ATA drives can never outrun LTO-2 drives, at least not when it comes to large files or database backups and restores. Designing FC disks to match the drives will mean the cost is 10 times the cost of the tape drives. This is all my opinion, and I'm sure that there are others out there that dont agree. Best Regards Daniel Sparrman ----------------------------------- Daniel Sparrman Exist i Stockholm AB Propellervdgen 6B 183 62 TDBY Vdxel: 08 - 754 98 00 Mobil: 070 - 399 27 51 TSM_User Sent by: "ADSM: Dist Stor Manager" 2004-09-22 04:27 Please respond to "ADSM: Dist Stor Manager" To [EMAIL PROTECTED] cc Subject Re: D2D on AIX Good questions. Our real world example:We went from around 8 - 12 GB/hr restore off of tape to over 40 GB/hr from the file device classes. Our test was a file server with a little over 300 GB of data. The File server and the TSM server both had 1 GB NIC's. Resource utilization was set to 10 in both cases. The data was fragemented on tape for a little over a year for the first test. The data was fragmented over disk for nearly 8 months. Steve Harris wrote: How does TSM access the data on file volumes? Does it keep an offset of the start of every file or aggregate? If it does, then yes we could skip to the start of each file or aggregate. If it does not, then we need to read through the volume to find the file we are going to restore. Where we have a large number of concurrent restores happening, this could cause performance issues on the array. Now TSM has some smarts on later technology tape drives that have block addressability and on-cartridge memory and can find a spot on the tape quickly, but does this translate to file volumes? Regards Steve. >>> [EMAIL PROTECTED] 22/09/2004 4:49:55 >>> True. Seek time is tiny compared to tape mounts. I am just concerned that the TSM db has to keep track of thousands of volume. How much will it increase the size of the db. Ours is already 90G at 70% utilized. Eliza > > ==> In article <[EMAIL PROTECTED]>, Eliza Lau writes: > > > What is the recommended volume size. I have seen someone mentioned 5G, but > > then the number of volumes will explode from about 800 (current # of 3590 > > primary tapes) to thousands. > > Consider, this doesn't really cost you much. Seek time in a directory of > thousands of files is still tiny compared to tape behavior. > > I probably wouldn't go as low as 5G, but 10G (much less than the average size > of my 3590 vols) seems pretty reasonable to me. 20G is getting big, from my > perspective. > > > > > How about keeping the staging space so clients backup to staging then > > migrate to FILE volumes. Then every volume will be filled up. > > > I like this, too. > > > - Allen S. Rout > *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com