Client operating systems should not be changed

While researching an issue today I was reminded of a problem I had a few years ago that still remains quite valid.

Client operating systems must not be changed. To be more specific, client platforms must not be changed – at least while keeping the same client name.

The reason for this is that index data is incompatible between client platforms. That is, if you’ve been backing up the machine ‘cerberus’ which is a Linux machine, then the machine is rebuilt as a Windows machine, it must be renamed.

Failing to rename a client in these circumstances can result in index corruption. This may manifest in one of three different ways:

1. Inability to backup at all.
2. Backups may consistently fail at specific points.
3. Backups may succeed but recoveries may fail.

Now, there may be some workarounds, and I’ll profess to having tried some of them out in lab environments, but let me be blunt: this causes so many problems (and is so unrecommended by EMC) that changing a client operating system (platform) should never be done without the client being renamed as well.

This may be done by either:

• Creating a new client name entirely for the rebuilt machine

or

• Using the standard procedure for first renaming the machine in NetWorker before the rebuild, so that when the new operating system is configured in NetWorker with the ‘previous’ name, there is no namespace clash or client ID similarities.

Trust me, if you don’t do one of the above when a client operating system is changed, at some point you will come a cropper.

[2009-05-10]

I thought I’d come back and add output from a backup attempt to show what happens when you do this. Here’s the scenario – I created a client called ‘dopey’*, installed CentOS 5, ran a full + incremental backup, then reinstalled ‘dopey’ as a Windows 2003 machine. Here’s (some of) the output from that backup, using NetWorker 7.5.1 as the server and client in all 3 instances:

[root@nox ~]# savegrp -l full -c dopey idata
40473:savegrp: command ' save -s nox.anywebdb.com -g idata -LL -m dopey -l full -q -W 78 -N "VSS ASR DISK:\" "VSS ASR DISK:\"' for client dopey exited with return code 5.
7336:savegrp: Log file /nsr/tmp/sg/idata/sso.dopey.pSMS7s is empty.
68703:savegrp: savegrp:idata * dopey:VSS ASR DISK: Cannot determine status of backup process.  Use mminfo to determine job status.

7341:savegrp: dopey:VSS ASR DISK: unexpectedly exited.
(snip)40473:savegrp: command ' save -s nox.anywebdb.com -g idata -LL -m dopey -l full -q -W 78 -N "C:\" "C:\"' for client dopey exited with return code 5.
7336:savegrp: Log file /nsr/tmp/sg/idata/sso.dopey.BlOmrS is empty.
68703:savegrp: savegrp:idata * dopey:C: Cannot determine status of backup process.  Use mminfo to determine job status.

7341:savegrp: dopey:C: unexpectedly exited.

As you can see, we’re just not getting a successful backup at all, since NetWorker is unable to merge the index entries from the two incompatible platforms.

—
* Currently running through and naming test machines based on the Seven Dwarves from Snow White, that’s all.