One client - two servers

2001-12-10 Thread Michel Engels

My client is studying the implementation of a SAN. And on top of that there will
be two SAN's in two different places to be able to create a DR site. What my
client is asking is to study if it is feasable and thinkable to do the backups
on the two different SAN's (with tape robot and necessary TSM Servers)
alternatively ie one day at TSM server 1 the other day to server 2.

In my idea it is the dsm.opt or the dsm.sys which directs the client to the
server. Alternating to the two TSM servers would mean updating these files and
restarting the client every day. Not forgetting the difficulty to figure out to
which TSM server to connect to restore a file of a few days ago not knowing by
which server it has been backed up.

Does anyone see a possible configuration to fullfill my client whishes? Any
comment is appreciated.

Michel Engels
TSM Consultant
Devoteam Belgium



Re: One client - two servers

2001-12-10 Thread Zlatko Krastev/ACIT

Do not overcomplicate this without need. Define two servers in dsm.sys
using two stanzas. Create two dsm.opt files, let's say dsm_odd.opt and
dsm_even.opt pointing to each stanza in dsm.sys and start the client with
different DSM_CONFIG environment variable. Or even start both clients.

Zlatko Krastev
IT Consultant





Michel Engels [EMAIL PROTECTED] on 10.12.2001 16:22:06
Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:

Subject:One client - two servers

My client is studying the implementation of a SAN. And on top of that there
will
be two SAN's in two different places to be able to create a DR site. What
my
client is asking is to study if it is feasable and thinkable to do the
backups
on the two different SAN's (with tape robot and necessary TSM Servers)
alternatively ie one day at TSM server 1 the other day to server 2.

In my idea it is the dsm.opt or the dsm.sys which directs the client to the
server. Alternating to the two TSM servers would mean updating these files
and
restarting the client every day. Not forgetting the difficulty to figure
out to
which TSM server to connect to restore a file of a few days ago not knowing
by
which server it has been backed up.

Does anyone see a possible configuration to fullfill my client whishes? Any
comment is appreciated.

Michel Engels
TSM Consultant
Devoteam Belgium



Re: One client - two servers

2001-12-10 Thread Nicholas Cassimatis

Why not just start the second scheduler service with the server stanza
name, getting rid of the need for the second dsm.opt file:

dsmc sched -server=secondserverstanza

When you launch dsmc, it would load the client pointed to the server as
defined in dsm.opt.  To go to the second server, you'd have to add the
-server ( -se ) parameter.

Nick Cassimatis
[EMAIL PROTECTED]

Today is the tomorrow of yesterday.



Re: One client - two servers

2001-12-10 Thread Bill Mansfield

You could run two client schedulers, using separate dsm.opt files pointing
to the two TSM servers.  You would create a schedule on TSM server EVEN
that did backups on even days, and a schedule on TSM server ODD that did
backups on odd days (or you could do day of week if you prefer).  Each
scheduler would listen to its own TSM server.  One consequence of this
scheme is that each TSM server will back up all the files that have changed
since the last time IT ran, rather than the last time its counterpart ran,
since the necessary information is held in the TSM database, not on the
client.

This scheme is almost unthinkable; you'll have an interesting time with
restores.  I'm curious - what is the business requirement behind this?

_
William Mansfield
Senior Consultant
Solution Technology, Inc




Michel Engels
Michel.Engels@DE   To: [EMAIL PROTECTED]
VOTEAM.BE  cc:
Sent by: ADSM: Subject: One client - two servers
Dist Stor
Manager
[EMAIL PROTECTED]
.EDU


12/10/2001 08:22
AM
Please respond to
ADSM: Dist Stor
Manager






My client is studying the implementation of a SAN. And on top of that there
will
be two SAN's in two different places to be able to create a DR site. What
my
client is asking is to study if it is feasable and thinkable to do the
backups
on the two different SAN's (with tape robot and necessary TSM Servers)
alternatively ie one day at TSM server 1 the other day to server 2.

In my idea it is the dsm.opt or the dsm.sys which directs the client to the
server. Alternating to the two TSM servers would mean updating these files
and
restarting the client every day. Not forgetting the difficulty to figure
out to
which TSM server to connect to restore a file of a few days ago not knowing
by
which server it has been backed up.

Does anyone see a possible configuration to fullfill my client whishes? Any
comment is appreciated.

Michel Engels
TSM Consultant
Devoteam Belgium



Re: One client - two servers

2001-12-10 Thread Seay, Paul

You presume there is some kind of logic in this business requirement.  This
is just someone's spin on DR to get the data in an alternate site not more
than 48 hours old the way I see it.

I do not understand why they would not just create a copy pool on a tape
library in the second SAN and connect the primary TSM server to the DR SAN
and the primary SAN.  Then they can see the tape drives from both.  Just
create a copy pool and perform Database backups twice a day (once to
primary, once to secondary).

This presumes the tape drives are on the SAN and not shared on the other end
unless a DR has occurred.  Otherwise, TSM to TSM server communications will
have to be put in place to share the drives.

-Original Message-
From: Bill Mansfield [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 10, 2001 4:56 PM
To: [EMAIL PROTECTED]
Subject: Re: One client - two servers


You could run two client schedulers, using separate dsm.opt files pointing
to the two TSM servers.  You would create a schedule on TSM server EVEN
that did backups on even days, and a schedule on TSM server ODD that did
backups on odd days (or you could do day of week if you prefer).  Each
scheduler would listen to its own TSM server.  One consequence of this
scheme is that each TSM server will back up all the files that have changed
since the last time IT ran, rather than the last time its counterpart ran,
since the necessary information is held in the TSM database, not on the
client.

This scheme is almost unthinkable; you'll have an interesting time with
restores.  I'm curious - what is the business requirement behind this?

_
William Mansfield
Senior Consultant
Solution Technology, Inc




Michel Engels
Michel.Engels@DE   To: [EMAIL PROTECTED]
VOTEAM.BE  cc:
Sent by: ADSM: Subject: One client - two
servers
Dist Stor
Manager
[EMAIL PROTECTED]
.EDU


12/10/2001 08:22
AM
Please respond to
ADSM: Dist Stor
Manager






My client is studying the implementation of a SAN. And on top of that there
will
be two SAN's in two different places to be able to create a DR site. What
my
client is asking is to study if it is feasable and thinkable to do the
backups
on the two different SAN's (with tape robot and necessary TSM Servers)
alternatively ie one day at TSM server 1 the other day to server 2.

In my idea it is the dsm.opt or the dsm.sys which directs the client to the
server. Alternating to the two TSM servers would mean updating these files
and
restarting the client every day. Not forgetting the difficulty to figure
out to
which TSM server to connect to restore a file of a few days ago not knowing
by
which server it has been backed up.

Does anyone see a possible configuration to fullfill my client whishes? Any
comment is appreciated.

Michel Engels
TSM Consultant
Devoteam Belgium