Backup Central

We have purchased a new, even beefier server then our last one.

To make sure it is configured optimally, we want to test how long an
expire inventory runs. Our biggest server is up to 190G DB and expires
run 40-48hours.

I installed and configured the new server, connecting it to the main, tape
library owning server, which happens to be the one with the big DB.

I have taken the 190G DB and restored it to this new server.

Never having done this, I may be asking stupid question, but want to be
sure I don't do anything irreversible that may effect the production
server.

I want to run an EXPIRE INVENTORY against the restored database, perhaps
numerous times.

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release tapes
and such.

On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release
tapes
and such.

By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events. That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing. Interesting situations may
result.

Richard Sims

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries. This
may be the paranoid approach, but we did not break anything.

Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 9:10 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Expiration on a Test server

We have purchased a new, even beefier server then our last one.

To make sure it is configured optimally, we want to test how long an
expire inventory runs. Our biggest server is up to 190G DB and expires
run 40-48hours.

I installed and configured the new server, connecting it to the main,
tape
library owning server, which happens to be the one with the big DB.

I have taken the 190G DB and restored it to this new server.

Never having done this, I may be asking stupid question, but want to be
sure I don't do anything irreversible that may effect the production
server.

I want to run an EXPIRE INVENTORY against the restored database, perhaps
numerous times.

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release
tapes
and such.


This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.
Thank you.

This is one of the reasons I haven't brought it up after the reload, yet.

The test server isn't going to use/do anything but test things like EXPIRE
INVENTORY. We will be eraseing/reloading it numerous times.

So, how do I avoid these possible complication? Disconnect the ethernet
cable and work from the console? Remove/change the test servers
definition from the production server?




Richard Sims <rbs < at > BU.EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 10:28 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release
tapes
and such.

By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events. That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing. Interesting situations may
result.

Richard Sims

Zoltan -

I wouldn't touch this configuration with someone else's sharp stick.

For one thing, to run expiration in a realistic manner you'll be limited to one run per day unless you change the date on the test server.

I'd break the testing into at least two stages -- one as a stand-alone, running the expire inventory with the production database copy, and the second as a TSM server with it's own database (not sure of the terminology here; we've never set up multiple servers with one library manager).

If you could logically or physically partition the library for a while that would let you test the library interface before swapping servers.

Tom

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 10:10 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Expiration on a Test server

We have purchased a new, even beefier server then our last one.

To make sure it is configured optimally, we want to test how long an
expire inventory runs. Our biggest server is up to 190G DB and expires
run 40-48hours.

I installed and configured the new server, connecting it to the main, tape
library owning server, which happens to be the one with the big DB.

I have taken the 190G DB and restored it to this new server.

Never having done this, I may be asking stupid question, but want to be
sure I don't do anything irreversible that may effect the production
server.

I want to run an EXPIRE INVENTORY against the restored database, perhaps
numerous times.

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release tapes
and such.
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.

This is exactly what I do when testing a new TSM upgrade. I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance). That way
the test system is completely
isolated with no chance of trying to contact a production server.

TEST BY TRYING TO PING the production servers/instances!!!!!
We use AIX. One thing to watch our for is that the default lookup order is
DNS first, hosts file second. (at
that's how our systems were) I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:37:46 AM:

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries. This
may be the paranoid approach, but we did not break anything.



-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback. I am glad I asked.



Richard Rhodes <rrhodes < at > FIRSTENERGYCORP.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade. I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance). That way
the test system is completely
isolated with no chance of trying to contact a production server.

TEST BY TRYING TO PING the production servers/instances!!!!!
We use AIX. One thing to watch our for is that the default lookup order
is
DNS first, hosts file second. (at
that's how our systems were) I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:37:46 AM:

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries. This
may be the paranoid approach, but we did not break anything.



-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Ah - A light dawns.

You have a TSM server, 'A', on host 'A' that has connections to a library, disk, and other such. You are now building a new copy of the TSM server 'A' on host 'B'. If host 'B' does not have physical contact with the library AND your new server 'A' does not have a server definition for the old 'A' you should be OK.

Like I say, we've never done server to server setups. But I do think it would be unusual to define a server to itself, which would be the only way I could see the new copy attaching to the old copy at the server level.

When I run my validation tests here I make sure that the normal TSM config for my test environment continues to point to the production server. Then I use a custom DSM.OPT pointing to a test server stanza in the DSM.SYS to access the test TSM server for both client and administrative command-line tools. I also partition my library (I have a 3584) and set up an absolute minimum library environment -- but only after I've played with expiration.

Does this help, or have I confused the issue?

Tom

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 10:39 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: Expiration on a Test server

This is one of the reasons I haven't brought it up after the reload, yet.

The test server isn't going to use/do anything but test things like EXPIRE
INVENTORY. We will be erasing/reloading it numerous times.

So, how do I avoid these possible complication? Disconnect the ethernet
cable and work from the console? Remove/change the test servers
definition from the production server?




Richard Sims <rbs < at > BU.EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 10:28 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:

Will doing this effect the actual, live data on the production server,
since they see each other? I was concerned it would try to release
tapes
and such.

By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events. That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing. Interesting situations may
result.

Richard Sims
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.

FWIW, we use multiple networks for TSM backups/archives - and we use DNS.

My TSM server is columbia; it also answers to columbia-pri (our 'private' network for SAP only); columbia-adm (administrative); columbia-bu1, columbia-bu2, columbia-bu3, and columbia-bu4 (gigabit dedicated backup networks). In addition we use CNAMES in our DNS that point to the columbia names. All our DSM.SYS entries reference the cnames, so we can move to a new TSM server any time we want just by changing the cname entries in DNS.

The primary network uses the 10.x.y.z address range; all the others are from 192.168.y.z.

Tom

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 11:06 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: Expiration on a Test server

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback. I am glad I asked.



Richard Rhodes <rrhodes < at > FIRSTENERGYCORP.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade. I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance). That way
the test system is completely
isolated with no chance of trying to contact a production server.

TEST BY TRYING TO PING the production servers/instances!!!!!
We use AIX. One thing to watch our for is that the default lookup order
is
DNS first, hosts file second. (at
that's how our systems were) I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:37:46 AM:

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries. This
may be the paranoid approach, but we did not break anything.



-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.

Unzone the library and drives on the test machine, so the OS doesn't see
them (then the TSM Server won't, either). Add the "disable sessions" line
to the DSMSERV.OPT file. Now you're isolated. Fire up TSM, and do a DB
Backup to a file (you're doing to want to do this more than once, right?),
then you can test your expiration. To repeat, restore the DBBackup you
did to disk. Each expiration will expire the same data

Note: Your results won't match the real world. There's no other load on
this server, while a real TSM production server will have other things
going on, even when it's fairly idle. So don't be surprised if things take
10% longer when you have this server as the real one.

Nick Cassimatis


----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 08/15/2008 10:58 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:39:24 AM:

[image removed]

Re: Expiration on a Test server.

Zoltan Forray/AC/VCU

to:

ADSM-L

08/15/2008 10:40 AM

Sent by:

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>

Please respond to "ADSM: Dist Stor Manager".

This is one of the reasons I haven't brought it up after the reload, yet.

The test server isn't going to use/do anything but test things like
EXPIRE
INVENTORY. We will be eraseing/reloading it numerous times.

So, how do I avoid these possible complication? Disconnect the ethernet
cable and work from the console? Remove/change the test servers
definition from the production server?


=

I did not interview much. The install date is in the status tren reoport file.

-----Original Message-----
From: Kauffman, Tom <KauffmanT < at > NIBCO.COM>
Sent: Friday, August 15, 2008 11:34 AM
To: ADSM-L < at > VM.MARIST.EDU <ADSM-L < at > VM.MARIST.EDU>
Subject: Re: [ADSM-L] Expiration on a Test server

FWIW, we use multiple networks for TSM backups/archives - and we use DNS.

My TSM server is columbia; it also answers to columbia-pri (our 'private' network for SAP only); columbia-adm (administrative); columbia-bu1, columbia-bu2, columbia-bu3, and columbia-bu4 (gigabit dedicated backup networks). In addition we use CNAMES in our DNS that point to the columbia names. All our DSM.SYS entries reference the cnames, so we can move to a new TSM server any time we want just by changing the cname entries in DNS.

The primary network uses the 10.x.y.z address range; all the others are from 192.168.y.z.

Tom

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 11:06 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: Expiration on a Test server

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback. I am glad I asked.



Richard Rhodes <rrhodes < at > FIRSTENERGYCORP.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade. I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance). That way
the test system is completely
isolated with no chance of trying to contact a production server.

TEST BY TRYING TO PING the production servers/instances!!!!!
We use AIX. One thing to watch our for is that the default lookup order
is
DNS first, hosts file second. (at
that's how our systems were) I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:37:46 AM:

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries. This
may be the paranoid approach, but we did not break anything.



-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.

Thanks for the suggestions.

I realize the test wont be that accurate. However, these servers are
dedicated to TSM so there shouldn't be anything else running.

I would settle for a 50% difference.



Nicholas Cassimatis <nickpc < at > US.IBM.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/15/2008 11:41 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.EDU
cc

Subject
[ADSM-L] Fw: Expiration on a Test server






Unzone the library and drives on the test machine, so the OS doesn't see
them (then the TSM Server won't, either). Add the "disable sessions" line
to the DSMSERV.OPT file. Now you're isolated. Fire up TSM, and do a DB
Backup to a file (you're doing to want to do this more than once, right?),
then you can test your expiration. To repeat, restore the DBBackup you
did to disk. Each expiration will expire the same data

Note: Your results won't match the real world. There's no other load on
this server, while a real TSM production server will have other things
going on, even when it's fairly idle. So don't be surprised if things
take
10% longer when you have this server as the real one.

Nick Cassimatis


----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 08/15/2008 10:58 AM
-----

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU> wrote on 08/15/2008
10:39:24 AM:

[image removed]

Re: Expiration on a Test server.

Zoltan Forray/AC/VCU

to:

ADSM-L

08/15/2008 10:40 AM

Sent by:

"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>

Please respond to "ADSM: Dist Stor Manager".

This is one of the reasons I haven't brought it up after the reload,
yet.

The test server isn't going to use/do anything but test things like
EXPIRE
INVENTORY. We will be eraseing/reloading it numerous times.

So, how do I avoid these possible complication? Disconnect the ethernet
cable and work from the console? Remove/change the test servers
definition from the production server?