Backup Central

All-

Yesterday I replaced the hardware on our primary NetWorker server. The
server OS also went from RHEL 5.7 to RHEL 6.2. The NetWorker version
stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit
NetWorker install.

As described in the installation guide, that meant going through the
disaster recovery procedure. I'm well-versed in that procedure and it
went fine, as did reconfiguring the jukebox (the control port changed
SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not*
bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their
backups last night because of the change in the server certificate, but
now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated
server cert. Can I simply replace the new certificate (or entire nsrladb)
with the one recovered from backups, or is that just going to cause
problems for other clients?

If I controlled all of the clients that failed, I would just delete their
server peer information and let it be regenerated, but unfortunately many
of the clients are SLA backup customers, so I have no access to the
client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with
a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Hi tim
You need to contact EMC for a rehosting on your Networker server.


Med vennlig hilsen / Best Regards,

Otto V. Gudjonsson
Senior Technical Account Manager
Exello Norge AS - Kronprinsensgate 1 - N.0251 Oslo - NORWAY



+47 24 13 08 00 - http://www.exello.com

Følg oss på Twitter: http://twitter.com/ExelloNorge

(Kopier alltid support < at > exello.no på tekniske henvendelser)


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Tim Mooney
Sent: 1. februar 2012 20:13
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] replacing NSR peer information on a NetWorker server

All-

Yesterday I replaced the hardware on our primary NetWorker server. The server OS also went from RHEL 5.7 to RHEL 6.2. The NetWorker version stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit NetWorker install.

As described in the installation guide, that meant going through the disaster recovery procedure. I'm well-versed in that procedure and it went fine, as did reconfiguring the jukebox (the control port changed SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not* bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their backups last night because of the change in the server certificate, but now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated server cert. Can I simply replace the new certificate (or entire nsrladb) with the one recovered from backups, or is that just going to cause problems for other clients?

If I controlled all of the clients that failed, I would just delete their server peer information and let it be regenerated, but unfortunately many of the clients are SLA backup customers, so I have no access to the client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Tim, I run into peer issue now and then and I do not have access to the servers. There is a way to
Remove them from the master server. Here is how I clear them out.

On Master server with client nts481 having peer issues perform Part 1 and Part 2
Part 1 -> a) nsradmin -s nts481 -p nsrexecd
b) print type: nsr peer information
c) delete
d) y
e) quit

Part 2 -> a) nsradmin -s nts740 -p nsrexecd (where nts740 is the master server name)
b) delete type: nsr peer information; name: nts481.kii.kimball.com
c) quit

Hope this helps.


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Tim Mooney
Sent: Wednesday, February 01, 2012 2:13 PM
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] replacing NSR peer information on a NetWorker server

All-

Yesterday I replaced the hardware on our primary NetWorker server. The
server OS also went from RHEL 5.7 to RHEL 6.2. The NetWorker version
stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit
NetWorker install.

As described in the installation guide, that meant going through the
disaster recovery procedure. I'm well-versed in that procedure and it
went fine, as did reconfiguring the jukebox (the control port changed
SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not*
bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their
backups last night because of the change in the server certificate, but
now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated
server cert. Can I simply replace the new certificate (or entire nsrladb)
with the one recovered from backups, or is that just going to cause
problems for other clients?

If I controlled all of the clients that failed, I would just delete their
server peer information and let it be regenerated, but unfortunately many
of the clients are SLA backup customers, so I have no access to the
client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with
a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

In regard to: RE: [Networker] replacing NSR peer information on a NetWorker...:

Hi tim
You need to contact EMC for a rehosting on your Networker server.

Can you give me a little bit more information on why this would be
necessary?

Although the hardware changed, the hostname and IP address did not.
Because it's a Linux-based NetWorker server, that's means that the results
from hostid also did not change.

When I view Configuration->Registrations on the NetWorker server, all
the licenses I expect to see are showing up, and they all show as
"Authorized - No expiration date".

I'm just trying to understand how going through the rehosting process
with EMC is going to fix what appears to be a peer name issue for some of
my clients.

Thanks,

Tim

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Tim Mooney
Sent: 1. februar 2012 20:13
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] replacing NSR peer information on a NetWorker server

All-

Yesterday I replaced the hardware on our primary NetWorker server. The server OS also went from RHEL 5.7 to RHEL 6.2. The NetWorker version stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit NetWorker install.

As described in the installation guide, that meant going through the disaster recovery procedure. I'm well-versed in that procedure and it went fine, as did reconfiguring the jukebox (the control port changed SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not* bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their backups last night because of the change in the server certificate, but now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated server cert. Can I simply replace the new certificate (or entire nsrladb) with the one recovered from backups, or is that just going to cause problems for other clients?

If I controlled all of the clients that failed, I would just delete their server peer information and let it be regenerated, but unfortunately many of the clients are SLA backup customers, so I have no access to the client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim


--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

In regard to: RE: [Networker] replacing NSR peer information on a NetWorker...:

Tim, I run into peer issue now and then and I do not have access to the servers. There is a way to
Remove them from the master server. Here is how I clear them out.

On Master server with client nts481 having peer issues perform Part 1 and Part 2
Part 1 -> a) nsradmin -s nts481 -p nsrexecd
b) print type: nsr peer information
c) delete
d) y
e) quit

Part 2 -> a) nsradmin -s nts740 -p nsrexecd (where nts740 is the master server name)
b) delete type: nsr peer information; name: nts481.kii.kimball.com
c) quit

Tim-

I was under the mistaken impression that the backup server couldn't do
this kind of thing any more -- there was a security issue in the 7.2.x
timeframe and I thought part of plugging it had disabled this. It appears
not, as I was able to purge the old nsr peer information on each of the
clients.

Unfortunately, this still hasn't fixed the issue.

I've also now tried replacing the nsrladb with the recovered copy, and
that also hasn't fixed the issue.

I'm going to be in touch with a couple of the clients to get a look at
the daemon.raw and see if there are any clues in there, but at this
point it looks like I'm going to be opening a ticket with EMC.

Thanks for your help,

Tim

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Tim Mooney
Sent: Wednesday, February 01, 2012 2:13 PM
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] replacing NSR peer information on a NetWorker server

All-

Yesterday I replaced the hardware on our primary NetWorker server. The
server OS also went from RHEL 5.7 to RHEL 6.2. The NetWorker version
stayed the same (7.6.2.5), but I did convert from 32 bit to 64 bit
NetWorker install.

As described in the installation guide, that meant going through the
disaster recovery procedure. I'm well-versed in that procedure and it
went fine, as did reconfiguring the jukebox (the control port changed
SCSI address) and recovering the client file indexes.

Much to my surprise, though, the disaster recover procedure does *not*
bring back the previous "nsrladb" when it recovers the other resources.
This means that the server certificate used as part of the "peer"
authentication changed.

Surprisingly, only about two dozen of our 125+ clients failed their
backups last night because of the change in the server certificate, but
now I'm in a quandary.

I've now been through one (incremental) cycle with the new/regenerated
server cert. Can I simply replace the new certificate (or entire nsrladb)
with the one recovered from backups, or is that just going to cause
problems for other clients?

If I controlled all of the clients that failed, I would just delete their
server peer information and let it be regenerated, but unfortunately many
of the clients are SLA backup customers, so I have no access to the
client systems.

Any thoughts on whether replacing the nsrladb on a NetWorker server with
a recovered copy is a good idea, or if that's just asking for trouble?

Thanks,

Tim


--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On Thu, 2 Feb 2012 14:37:49 -0600, Tim Mooney <Tim.Mooney < at > NDSU.EDU> wrote:

Unfortunately, this still hasn't fixed the issue.

I've also now tried replacing the nsrladb with the recovered copy, and
that also hasn't fixed the issue.

Actually, it did fix the issue, but there was a second issue that was
masking that.

What I didn't recognize right away is that all of the clients that were
still failing, after replacing the nsrladb with a recovery copy, were
clients that were outside of our datacenter subnets.

It turns out my puppet rules for the new backup server activated our
default server firewall. I just needed to poke an additional hole in
the firewall and all is now right with the world.

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER