Backup Central

Good afternoon all...

This is my first post, so go easy on me, OK?

We've recently been told, after more than 10 years of being a TSM-oriented shop, that "thou shalt use EMC Networker". While our migrations have been relatively painless (stand up a new backup server, attach a new library, etc), we have recently run into some problems when changing client names after lifecycling servers. As we're lifecycling certain hardware, we're also converting our backups over to networker.

For instance, let's say we have a client named "production-server1.localdomain" (not a real server name) that we're replacing with a new hardware device named staging-server1.localdomain (also not a real server name).

Here's our current process:

1. Copy all of the data from "production..." to "staging..."
2. Do a full backup of "staging..." to networker
3. Rename "production-server1.localdomain" to "lifecycle-server1.localdomain"
4. Rename "staging..." to "production..."
5. Update IP address on "production..."
4. Power down old "production..." server and send to auction.

During this process, we introduce errors because Networker is expecting the client name to be staging-server1.localdomain. We've tried deleting the client in the GUI and re-creating using the same clientid to no avail. We've tried nsrck -r -y staging-server1.localdomain. We've tried deleting the index folder for staging-server1.localdomain.

As it stands, no scheduled backups are running for this box spitting out the following error:

39077:save: error, `staging-server1.localdomain' is not a registered client

The production-server1.localdomain (the desired end-state name) is registered as a client in the Networker Admin GUI and both DNS and WINS are correct. We've even tried using an alias in the client properties in the gui to no avail.

The weird thing is that we can do directed backups from the Networker client GUI on the new production-server1.localdomain box so there seems to be something in our backup server's index that is hanging things up.

Can ayone shed any light on how to delete all references to the old server name?

At this point we're willing to endure another full backup over a 256k link, but scheduling backups is a must.

Please keep in mind that we have one backup in progress over a terribly slow link (128k at best) that won't complete for a few days so a reboot of the backup server or restart of the networker services is out of the question (unless, of course you have a tip to work around this).

There are certain things that NW has to rely on. One of them is the unique hostname resolution. This is obvious. NW also assigns the internal identifier 'clientid' when a client is configured the first time. It is invisibly assigned and stored inside NW's media index. You can not change it.

But you do not need to cheat NW. The procedure to 'move' data is pretty simple:
- Define both client in NW (you only need a hostname resolution to do that)
- Run the backup on the old server
- Restore the data to the new server (so-called 'directed recovery')
- Decommission the old machine as it is not needed any more

Your message maybe due to 2 problems:
- The new client has not been configured yet. This is easy to solve. See above.
- If you just rename the client, then the clientid may remain the same. Changing it is impossible as it remains invisible.
- You better start all over with new backups.
- And do not forget to prepare your NW client:
- stop the NW client daemon/service
- delete the ..../nsr/res/nsrladb directory
- restart the NW client listener

One of my collegues just had a similar problem when we needed to rename some clients because our standard hostname was misinterpreted by SAP. Fortunately these were new servers. Unfortunately i was on vacation and i did not verify the clientid before and after the renaming.

#######

BTW, running a full backup over a WAN is weird. It will of course work .. as longs as there are no interrupts.

However, may i strongly suggest that you install a local (disk) backup device and temporarily promote the client to a Storage Node. In this case, a local backup will take place and only the metadata needs to be transferred. Bare in mind that the WAN speed is still a limiting factor when you backup a lot of tiny files (too much metadata)!

Then bring the backup media (device) to the NW server's site and migrate/stage it to your desired backup media. If you need additional licenses your sales rep is able to provide temporary ones.

Thanks, bingo!

It turns out that we didn't know anything about deleting the nsrladb directory. It worked wonders for us and has been added to our wiki of potential troubleshooting vectors.

I agree that backing up over a WAN link is not the most elegant solution, but given some security restrictions on the far end, we can't really add any new hardware to do a disc-based backup at the moment. I've proposed that we convert the old server to a storage node with an aftd target so we can do our first full backup to it.

When they ship us back the server, we can clone the data or stage it to tape (as I said, we're new at Networker, so some of our ideas may seem strange until we gain some more experience). After that point, the plan is to do a "consolidate" save set every week so we, in our understanding, never have to do a full over the wire ever again.

Of course you can stage/clone save sets. Although these commands work almost the same, you should know:
- you can only clone to a clone pool
- you can stage to any pool

Using NW consolidation is not a good idea because NW consolidates per save set. He actually APPENDS the level 1 to the last full creating a new but artificial full. This works but you need to know:
- initiating recoveries are simple because you always have a moderately updated full.
- It is obvious that you will need some parts from various save sets. Consequently, you should use it with disks only (due to random access). But here they will need more space than a file level based consolidation.
That's why NW Save Set Consolidation never really became popular but almost forgotten.