This is why I run and incremental and a dbsnapshot every day. And two TSM database backups for every offsite run. And a primary, onsite copy, and offsite copy (DR) for filesystem backups. And, applicaton database and application log file offsite copies to roll forward a bad application backup tape. And, we are considering an additional offsite copy for filesystem recoveries.
The bottom line is tape is tape. It is a mechnical device that has lots of parts that can break and create bad tapes and planning recovery from failed disaster recovery is important. We have at least 1 tape with write errors a week. We immediately movedata that data to another volume to be sure we can read it and recover if we cannot. We have at least 1 drive that goes wacko every 6 months and 50% of the time eats the tape. Ours are 3590-E1A drives. Our drives run nearly 7x24 that are online right now, with about twice the number coming online soon. This will relieve the pressure and provide us with a really nice solution. Thanks to our previous backup solution that took more than twice the hardware (16 Magstar drives online to TSM now, 38 total soon) and still could not get the backups done with half the storage we have now. The beauty of TSM is you can actually design a nearly bullet proof environment. It costs a little more. In our case, it takes about half the hardware to do this kind of TSM implementation than it did with our previous completely single point failure full/incremental solution. The only place we feel that there is a short fall is TSM does not support multiple simultaneous copies of database backups for performance and time saving and in the case of incremental database backups a single point of failure issue that can be helped by running dbsnapshots more often or sending the incremental backups to disk on a different disk subsystem (maybe a case for one of these cheap ATA arrays). Ultimately, a well planned setup is far better than a proprietary one up solution from some fly by night vendor that will "save the world". I know of some, but will not recommend any because you will not be happy. The solution you are asking for will require you to manage a bunch of manual stuff outside of TSM with TSM having no visibility to where the second copy is. Yes, we have a lot of hardware to save our environment. I suggest you document your failure losses well, do a total cost of ownership to prevent a future failing, and procure a solution that is affordable, and hits a recovery comfort target that your financial and executive management can be satisfied with. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: Othonas Xixis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 9:29 AM To: [EMAIL PROTECTED] Subject: Dublicate TSM's DB or Data Tapes (3590, LTO) ... not within TSM Importance: High Hello TSM'ers, Does anyone know of a way or a company where the TSM DB or Data Tapes can be duplicated (in a hardware level) ? I do understand the duplication methods within TSM and I am not interested at this time because I can't use them. We are in a real disaster recovery situation, not where we lost the TSM server, but where we lost portions of the data on the tapes, and now we have legal requirements that we need to fulfill. Thanks in advance for yr assistance. Brgds, Othonas Xixis
