As much of a performance hit as you want ! With about every TSM task (straight backups via "resourceutilization" or with tdp/r3 with the number of concurrent sessions, etc...) you can tune how busy TSM will keep your system. We have our production boxes at one site and our disaster recovery center miles away, our TSM server(s) are located at the DR site, we have to compress all client data to send it across the OC12 between the sites. For example, we can crank up TSM activities to suck up 90% of 20 processors (out of 32) on a Sun E10K by using client compression... So an OC12 is 622 Mb/sec or roughly 273 GB/hr, on a nightly basis we see it running somewhere between 175-200 GB/hr so we still have about 1/3 capacity BUT we see 3.8/1 compression of most data base data so we are actually moving somewhere around 760 GB/hr of client filespace and I'd hate to be pay'n for an OC24 (or more) between the sites (if we could even get it) !
One view is that if you beef up the processors to assist in backup, the end results to the user community is increased performance during their production use ;-) It's a (god I hat to say this) "WIN ! WIN ! situation... Just remind management that today they are more than ever likely to have to depend on their DR ! Dwight -----Original Message----- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:35 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance thanks for that insight. i forgot to mention we are running fibre channel and not scsi drives. yes, the data is must have... it is all production data and is being copied for DRM. how much of a performance hit will it take to turn compression on at the client level? -----Original Message----- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:22 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance Is 1.6 TB the amount of "must have/critical" information ? and is that already compressed ? Knowing each tape mount runs about 90 seconds, any way to reduce tape mounts will speed up copies. If you have collocation on, turning it off ~could~ help... and collocation can/is set on both primary pools and copy pools. Now if the data isn't compressed by the client the data is uncompressed at the drive, moved through the processor as ~full size~ data, then recompressed at the destination drive. If your clients have the horsepower, turn on client compression, that way not so much data is moved across the processor's buss. Don't daisy chain any of your 3590's if they are older scsi. You might be able to reduce your data down if you force the application owners to review their required CRITICAL/MUST HAVE data and send it to isolated pools for copies to take offsite. just some thoughts... Dwight -----Original Message----- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
