Do you do client compression? If you have compressible data this may be a good way to reduce the amount of data to be transferred, at the expense backup speed (e.g. I have an several 8 way clients with big pipes but I'm limited to by compression running a single CPU at max whilst the others sit idle. )
It can also improve efficiency of non-tape resources - like diskpools. Steve Harris AIX and TSM Admin Queensland Health, Brisbane Australia >>> [EMAIL PROTECTED] 28/07/2002 1:53:12 >>> This may be a math problem. How much data are you trying to send over the T1 daily. A T1 is 1.454Mbits/sec which after taking your stack overhead off is about 1.1Mbits or about 145KBytes/sec. In 24 hours you can send about 12.5GB. So, just remind your auditors this is the case and they need to write a finding that the data center does not have enough budget to meet the audit requirement. Then management makes the decision as to whether they can stay in business if they do not mirror the data. CTAM looks real good when all said and done. AKA. Chevy Truck Access Method. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: John C Dury [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 1:36 PM To: [EMAIL PROTECTED] Subject: Disaster recovery with copy storage pools. We currently have 2 TSM servers. TSM1 which holds the data backups of all the fileservers in the company. TSM2 which is off-site and is used only as a copy storage pool which is defined on TSM1 and nightly we do a backup of the primary storage pool (3494libpool2 on TSM1) to the copy storage pool (DR_POOL1 on TSM2). Unfortunately this is a rather large amount of data and runs for a very long time and doesn't finish copying in 1 day. My auditors want to make sure that we have 2 copies of all data from our fileservers, one on-site and one off-site. Anyone have any suggestions on how to do this in a better fashion? Initially we were having some problems with the backup not finishing because of a network glitch which caused the whole process which could have been running for 8 hours or so, to fail. I believe the network glitches have been solved but the whole operation still takes a great deal of time, usually 24 hours. Because the data is going from tape to tape, I thought about making another copy storage pool on TSM2 on DISK,instead of TAPE, and making it have a migration threshold such that the data immediately went to TAPE from DISK. The DISK would act like a buffer. I don't know if this is even possible but I'm willing to try anything. Unfortunately adding a faster link between the 2 servers isn't really an option as we are really budget contrained. Right now it's only T1. Anyone have any ideas or suggestions? I'm willing to rearrange the whole backup structure if necessary. This is how it was setup when I adopted TSM. Thanks much, John ********************************************************************** This e-mail, 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 e-mail 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 e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. **********************************************************************
