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:othonas AT US.IBM DOT COM]
Sent: Tuesday, January 21, 2003 9:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
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