Hi Jon/Eric,

Well we use $hostname_NBI {NetaBackup Interface} for the client with a
dedicated backup interface.

And yes we use the hosts file at both ends.

Jon, why shd we use the DNS service for resolution, what are its advantages
over FLAT file resolution. Say my DNS server is down, would'nt that affect
my backups.

Regards,
PP BIJU KRISHNAN

On 9/28/06, Martin, Jonathan (Contractor) <JMARTI05 at intersil.com> wrote:
>
>  Right now my site uses HOST names, but with our new servers' I'm going
> 100% DNS.  I've tested this in ONE case right now and it has worked 100%.
> It is how I am going to configure all my new backup servers and clients.
> We've got about 120 clients, 40 of so have high-speed "backend" 1GB Nics.
>
> 1 - Add a "connection specific" DNS Suffix to the "Backend" (Backup
> Network) connection.  That is backup.company.com.  Make sure you have PRT
> (reverse DNS) records for these IPS, especially for the Media servers.
>
> 2 - Configure your media servers to query DNS in a specific order STARTING
> with backup.company.com followed by company.com site.company.com etc...
>
> When your media server looks up a client it will query
> client.backup.company.com, and use that IP if returned.  If that query
> DOES NOT return a valid IP it will continue querying company.com etc until
> it finds a valid HOST entry in DNS.  I've tested this in ONE case with our
> current setup and it seems to work GREAT.  It alleviates me adding -backup
> entries to my client configs, adding host file entries to direct traffic and
> generally is the "cleanest" way I can come up with to configure multiple
> backup networks.  You could just implement step number 1 and then use
> client.backup.company.com in your policies, but we're not using FQDNs
> right now so I'm avoiding them like the plague.
>
> The only problem I can see with this method is verifying that the backup
> policy uses the backend connection.  I.E. if the DNS query of
> client.backup.company.com fails then it will continue the DNS queries and
> fine the client.company.com DNS entry and try backing up over the "front
> end."  That's not a huge problem for me right now, because my DNS is rock
> steady and backing up over the backend isn't exactly mission critical, but
> to be extra careful you could add the "required interface" option to your
> clients which is an extra step, but should make this bullet-proof.
>
> -Jonathan
>
>  ------------------------------
> *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.
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060928/51360900/attachment.html