Okay, I will chime in on this one.
You can use DNS to control you backup NIC's. Any scheme can work.
Consistency will win out. I have some sites that use 10. instead of the
first octet of the IP address. The remainder is the same 3 octets in the
production name. We add a "-b" to the dns name. Works on both Windows and
Unix clients. The master and medias are also in DNS with a -b.
I have another set of sites that use 192.168 domain.
Since they are in DNS and use a different name than the public address in
DNS, using the "REQUIRED_INTERFACE" is not necessary.
About the FQN's, we don't use them. Why type all of those extra characters?
Our DR strategy is to carry our offsite tapes to one of our other sites and
do our recovery. Without using FQN's, we just bring a development box back
up as a lost production box and put it in the domain of the DR site.
We have to use the /etc/hosts file on the master server at the DR site in
order to translate the backup LAN name to a public LAN due to routing issues
of the 10. and the 192. domains.
As far as the comment about the "REQUIRED_INTERFACE" being needed to keep
the client from going out the incorrect NIC during a restore or a user
backup; if you set up DNS correctly, have the CLIENT_NAME as being on the
backup LAN, and have the backup LAN addresses of the Master set as your
primary Master server, your bplist or restores or UBAC's will work just
fine.
When you implement or convert to a backup LAN, you will probably (for the
systems that had backups done as the public name) have to do an altnames
entry in order to get to older data for restores.
DON'T ever use symbolic links to tie the two names together. I inherited a
huge master where that was attempted. It did not work, but was not undone.
What a mess it has been to clean up.
Bobby Williams
2205 Peterson Drive
Chattanooga, Tennessee 37421
423-296-8200
_____
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Carlisle, D
Renee
Sent: Wednesday, September 27, 2006 3:41 PM
To: Hindle, Greg; Hillman, Eric; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Client Hostnames
We do the same thing. Each server, including the master and media servers
have two nics, each with their own name in dns. One caveat, especially with
user directed or database backups, have REQUIRED_INTERFACE set on your
clients and set it to the name of the nic on your backup network. If you
don't, the clients may send information out on the public interface and the
media server will respond on whichever network it received the request. I
would also make sure your nic cards are configured to use a set speed with
full duplex enabled. You could run into performance issues if you use
auto-negotiate. We have always been told the FQDN are best practice, and
that is what we use.
Rene? Carlisle
Jer 29:11-13
_____
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Hindle, Greg
Sent: Wednesday, September 27, 2006 3:02 PM
To: Hillman, Eric; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Client Hostnames
We use fully QDN's here. We add 2 nics to each client one with its public
name and the other with a private name with NBU at the end. This NBU
interface is configured in the same vlan as our netbackup servers. Both
names are in DNS.
Greg
_____
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Hillman,
Eric
Sent: Wednesday, September 27, 2006 2:38 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Client Hostnames
We have public and backup networks. All clients have a public network which
is typically 100Mb and some clients (larger clients) have a backup network
which is typically GbE. This seems to be pretty typical in larger
organizations.
Given the above scenarios, my question is
in Netbackup what do you name
your clients with backup nic's?
Option #1: Add a dns entry of the client name with a "-backup" suffix and
assign it's backup ip. Do the same with the Master/Media server and add
their -backup hostnames as additional servers from within the netbackup
client software
Option #2: Instead of using dns, simply add the -backup hostname client
alias to the local hosts file on the Netbackup Master/Media servers and
assign the backup ip. Do the same with the Master/Media server and add
their -backup hostnames as additional servers from within the netbackup
client software
Option #3: Simply override the actual client's hostname IP with it's backup
ip by adding it to the local hosts file on the Netbackup Master/Media
server. Do the same with the Master/Media server in the client's hosts file
and leave the non -backup hostnames as servers in the netbackup client
software. This alternate method would overwrite the DNS record of the
actual client and Master/Media hostnames with the hosts backup IP.
Also, is it best practice to use FQDN's, or no?
Thanks
-Eric
THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE
PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM
DISCLOSURE. If the reader of this message is not the intended recipient, you
are hereby notified that any dissemination, distribution, copying or use of
this message and any attachment is strictly prohibited. If you have received
this message in error, please notify us immediately by replying to the
message and permanently delete it from your computer and destroy any
printout thereof.
>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for
the addressee. If you are not the intended recipient, do not use the
information in this e-mail in any way, delete this e-mail and notify the
sender. CEG-IP1
_____
The information contained in this message may be privileged,
confidential, and protected from disclosure. If the reader of this
message is not the intended recipient, or any employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately
by replying to the message and deleting it from your computer.
Thank you. Paychex, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060928/d4b87ce3/attachment-0001.html
|
