John,
I believe that's it. Our documentation had references to the vmglob
command, but gave to reason why. That technote explains it.
As far as Sandor goes, what can you say about somebody who airs their
dirty laundry in a public forum? ;-)
Thanks John!
John Nardello <john.nardello AT jpmchase DOT com>
10/02/2009 02:34 PM
To
"scott.george AT parker DOT com" <scott.george AT parker DOT com>,
"veritas-bu AT mailman.eng.auburn DOT edu" <veritas-bu AT mailman.eng.auburn
DOT edu>
cc
Subject
RE: [Veritas-bu] Possible Disaster Recovery Exercise Problem introduced in
6.5.3.1
Have you tried this to disable EMM communication with them ?
http://seer.entsupport.symantec.com/docs/303842.htm
- John Nardello
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
scott.george AT parker DOT com
Sent: Friday, October 02, 2009 11:24 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Possible Disaster Recovery Exercise Problem
introduced in 6.5.3.1
Our last full blown DR exercise was done with 6.0 MP5, and our next one
will be done with 6.5.3.1. My master is on AIX 5.3 TL9.
I replicate my NBU server's operating system to another disk subsystem and
boot the copy on somewhat similar hardware in a remote location.
Everything works fine in this respect. Naturally, I must remove old
definitions for network adapters and tape drives and re-detect them, but
that always works as advertised.
One of the first things that I do is remove any entries to SERVER and
MEDIA_SERVER for my media servers in the bp.conf and DEVICE_HOST and KNOWN
in the vm.conf, so that the master server isn't trying to contact them for
anything. Media servers are not brought back in the DR exercise. They
simply exist "back home" for speed using the SSO option. They all contain
a considerable amount of data, and trying to push that data over the
network while everything else is backing up doesn't make sense. For DR,
everything is a restore, so pushing that data back over the network is
fine, since it is a one-time-good-deal.
We did a mini-test in August where I restored one Windows server, but
noticed that with 6.5.3.1, everything was slow, but I wrote it off to the
fact that the servers that are media servers at home, and are not media
servers in DR, didn't exist during the mini-test, and the master server
was still trying to communicate with them, because they still existed in
the EMM database. But now I am looking at it a little more suspiciously,
thinking it may be a 6.5 thing, instead of a "lack of hosts altogether"
thing. My quick answer in August was "It was trying to communicate with
servers that weren't there and just timing out, but in January (when the
big test happens) it will get "connection refused" because the same hosts
will exist but not be media servers.
Is my logic flawed, or should I be looking to decommission the media
servers in January as part of the test? If I have to decommission the
media servers, it is looking like an additional 2 hours due to the media
movement I have to do in the database to actually remove the media
servers. It takes about 3 seconds a tape to move media, and I have a
bunch of tapes to move logically, even though those tapes won't be touched
at DR (I restore from duplicated copies).
Thoughts?
I apologize for the long-winded e-mail, but do appreciate your input.
Thanks!
Scott
PLEASE NOTE: The preceding information may be confidential or
privileged. It only should be used or disseminated for the purpose
of conducting business with Parker. If you are not an intended
recipient, please notify the sender by replying to this message and
then delete the information from your system. Thank you for your
cooperation.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
