Doesn't sound like a netbackup issue
Sounds like a host configuration issue - maybe dns
Are you returning 127.0.0.1 even when you have any entry in your local hosts?
The system could be configured not to look at hosts
Can you resolve forward and reverse lookup when using nslookup?
Regards,
Tal
That's what we thought also, but why then would it work just fine before
the catalog recovery?
I do have a hosts file entry for the system.
Currently it is off the network so nslookup is not working, but even
when it was on the network and name resolution was working fine the
issue was
It is a standard system build. I did the build and did not change
anything to do with DNS
Firewall is also turned off. I tried with the firewall service disabled
and after a reboot and the error still exists.
Joe Infantino
MCP, MCSA, Security+, ITILv3
Senior Systems Analyst
It could just be down to the way your host is configured to lookup names
Is this a standard windows build or a bespoke build created by your sys admins?
They could have changed the way the build resolves hostnames as a security
feature?
Regards,
Tal Shekel
CSA
FUJITSU
From: Infantino, Joe
That's odd
If you have any entry in the host file bpclntcmd should pick it up
Still sounds like host config though
Although this is probably not the issue check if there are any entries under
veritas\netbackup\remote_versions - that should affect name resolution but may
be worth cleaning out
What seems to stick out, is the target OS is 64bit (vs the original 32bit OS)
and the problem only shows up after a good catalog restore
/Steve
---
From: veritas-bu-requ...@mailman.eng.auburn.edu
Subject: Veritas-bu Digest, Vol 71, Issue 11
To: veritas-bu@mailman.eng.auburn.edu
Did you try run bpclntcmd prior to the upgrade?
I also noticed the 64 bit and 32 bit change but wouldn't have thought it would
make a difference
Regards,
Tal Shekel
CSA
FUJITSU
From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of
The old system is still up as that was our fallback option.
We don't have a spare drive in our lab to use for a hot catalog backup
test, at least not yet. That was our next option, but we would need
downtime again to do the catalog backup/restore.
Joe Infantino
MCP, MCSA, Security+,
From what I remember, the recommended catalog backup was the hot backup
when it first appeared (in 6.0?). I have had to use it a couple of times
with success every time.
Even if it could be dumped to disk and transferred/mapped to the new
system, it would be worth a try.
From: Justin
Hi,
Does the D/R site have the same master, media servers as the source site?
Does the master at the D/R site have network connectivity to the media
servers and clients?
If it has the same hostname as the other server, how will the client know
which master server it is talking to?
Or is the
Just so I didn't leave this hanging out there, I had 201 tapes with volume
expirations that had expired. It was a good lesson in the difference
between data expiration and volume expiration.
Thank you for all of the input!
From: David McMullin david.mcmul...@cbc-companies.com
To:
client = master. We first saw the issue when we replaced the master
server and had it on the production network.
We reverted to the old server to keep things going while I brought the
new hardware back to a lab and rebuilt the OS. I installed NBU and was
able to configure it up and get
Just to clarify, this is our second Windows 2003 x86 to Windows 2008 x64
NBU 6.5.6 upgrade via cold catalog backup. We preformed our first last
December in the same manner with much success. There is a possibility
that the cold backup was bad, and we'd like to test a hot catalog backup
as well.
13 matches
Mail list logo
