Now beyond my earlier statement on DASD units to keep a copy of the files in
the remote location...

Just treat the TSM db like any other db.  
Say, once a week, take a full db backup, take that to the remote location,
and do a restore there... (with commit=no)
then, say, once daily (or more often) take incremental backups and apply
them to the remote location (with commit=no)
An easy way to deal with the daily incrementals would be to put them to a
disk file, ftp it to the other server and apply it.

We've moved environments by taking the full backup, performing the restore
to the "other" tsm server (commit=no) then when it was time to actually
swing over to the new server, we disabled sessions, ensured all disk data
was migrated to tape, took an incremental db backup (to a disk file), ftp'ed
it to the other server and did a restore db blah commit=yes.
So there would be nothing from keeping someone from doing something similar
over an extended period of time in order to keep a remote site in a recovery
mode... and if you have another atl with all your copy tapes in it... you
could be up and running within 30 minutes.  At least I could make that
guarantee!

This would take very few ksh scripts to automate... (ok, so this is all
based on running in an aix environment or other unix environment)

Dwight



-----Original Message-----
From: Caffey, Jeff L. [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 9:56 AM
To: [EMAIL PROTECTED]
Subject: Re: Wouldn't it be nice if...


Christo,

I would definitely like to have that same capability, but I'd prefer that my
mirrored server be offsite somewhere.  We have a Distribution Center that is
about 20 miles from our Data Center.  I'd really like it to be there.

In my spare time (what's that?), I'm looking into possibilities, but I
haven't gotten very far.  I'd be interested in your findings, and I will
share mine as well.

Thank you,

Jeff Caffey
Enterprise Systems Programmer
(AIX & Storage Administrator)
Pier 1 imports, Inc.  -  Information Services
[EMAIL PROTECTED]
Voice: (817) 252-6222
Fax:   (817) 252-7299

 -----Original Message-----
From:   Christo Heuër [mailto:[EMAIL PROTECTED]] 
Sent:   Monday, June 04, 2001 5:20 AM
To:     [EMAIL PROTECTED]
Subject:        Wouldn't it be nice if...

Hi Everyone,

Does anybody have the requirement to mirror/replicate the Tsm server. I'm
not just talking about on the same machine as in when you create mirrors of
db and log volumes but a server geographically seperate from the production
Tsm server.
Surely development must have thought of the requirement - not just for high
availability but also for doing DR tests on some of the clients from your
replicated TSM db. Quite a few of us are sitting with Tsm databases in
excess of 25Gig. When you have a catastrophic disaster where your TSM server
is dead you need to restore the DB from your off-site tapes. On a 20Gig or
bigger database you are going to have at least 3 hours downtime before being
able to start restoring some of your clients that were located in the same
place as your Tsm server. If you had a replicated Tsm server - all you had
to do is point the dead clients and start restores off the DR Tsm server.
This would at least save 3 hours or more apart from the added bonus of
having a proper TSM DR server ready willing and able to receive restore
requests at a moments notice...

Does this make sense to others on the list or do you think my requirement
are unique?

Cheers
Christo Heuer
ABSA Bank
==================================================

Reply via email to