The procedure for doing this is documented in the Tivoli manuals. The
answer is: run two copies of TSM server, and have them back up their
databases to each other. It would be better if they ran on separate
machines at least 10 miles (16km) apart, but they can run on the same
machine, as long as either one can run without the other being up.

Each backs up its database to the other as a FILE device type, which the
backup-receiving system then handles as ordinary Archives and migrates
and tracks through its storage pools and database in the usual TSM way.
The backup-sending system is an ordinary archive client of the
backup-receiving server. (And then they take turns and switch roles.) As
many are written to a tape as will fit, and you use the usual TSM policy
settings to determine how long they are kept, when tapes are reclaimed,
and so on. You can even establish a copy storage pool for offsite copies
of your DB backups - just like for any other client data.

You design such a system to minimize the risk that you could possibly
lose both databases, by having the two databases as far separated on
different drives, controllers, etc. as your configuration will allow,
even if you cannot separate them by physical distance.

This type configuration is described in the Tivoli Administrators Guide.

Do a test! Turn off one of your two servers and see how hard it is to
restore the database from the remaining working one. If you know you can
restore either database under such a configuration, then your resume
need not be updated.

(IDEA: Wouldn't TDP for TSM Databases be nice?)

OTOH, my systems seem to always have a database that is about 1/2 the
size of whatever tape technology I'm using at that time, so half-full DB
backup tapes versus the default 50% reclamation threshold becomes a
wash, and disaster recovery scenarious are simpler writing the DB
backups directly to tape. Buy more tapes; sleep better at night.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu