On Tuesday 20 May 2003 19:51, Ochs, Duane wrote:
> In short... There is no way of doing this without significant data transfer
> between the sites.
Not true.

> My question is why would would you want to do this ? The TSM server in
> California would be connected to the data in CA and the TSM server in WA
> would be connected the data in WA.
Not needed.

> If either site was physically down you would not be able to recover data
> from that site, because the data would not be reachable.
Yes you can.

My ideal solution :
You have a TSM server at CA and one at WA.  Both servers are using the same
tape media like LTO or so.   The TSM server at CA creates daily offsite copy
storate pool tapes for vaulting.  These tapes are taken offsite each day.
The changes in the database are also committed to the TSM server in WA.  But
not the data.  So the server in WA knows what's on the tapes of the server in
CA.
In case of a disaster in CA, you can take the offsite tapes from the TSM
server in CA out of the vault and place them in the library of the server in
WA.  The needed database information is there so you can access the data on
the tapes.  Voila, clients can restore from the copy storate pool volumes.

This setup only requires to commit the database changes from the server in CA
to the server in WA.  This can be scheduled each hour (asynchronous) , or can
be done synchronous.  And you have to check for conflicts like client names,
tape labels and so on.

Stef

PS.  We do this all the time on oracle databases.

--

stef.coene AT docum DOT org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net