Replacing a Veeam Agent for Windows host while preserving existing local or share backups

Introduction

Imagine you have a server with data source volumes that are backed up to local (or a share) target backup volumes with Veeam Agent for Windows (VAW). You might or might not backup the OS as well. That server is old, has issues or has crashed beyond repair and needs to be replaced. You don’t really care all that much about the server OS potentially but you do care about your data backup history! You don’t want to lose all those restore points. Basically, we try to answer how do you replace the backup server when it’s a local Veeam Agent for Windows 2.1 deployment.

How do you do this? Well, you’re out of luck a bit unless you have been sending the backups to a VBR repository. With local (or share) backup targets you have a challenge when the host changes, as the unique identifier changes. But that challenge can be met successfully. We can access the localdb of VAW as the password is known and stored in the registry. So potentially you can swap over the unique identifier of the backups that associates a repository with the host. But in the case of local backups you need to recuperate the entire local database anyway. And as the host is “This server” and not the server name that might work without even needing to edit the database. At least that’s what I learn from looking around a bit in the localdb.

The only place where host seems to truly identify is in names of backup files and in backup target file shares (host name or IP). So, the question is if we can complete a VAW SQL localdb transport successfully. As it turns out we can. That procedure is explained below. Now I’m not promoting this but I’m sharing is as it is part of my research to know how what to do when a host being backup with VAW to whatever repository (local, share, VBR) needs to be replaced.

WARNING: This is not a supported process by Veeam. It’s just what I have come up with when faced with this challenge for this particular use case. No guarantees are given. The best advise I can give is to test this out in a virtual lab before using it for real.

As stated we are not super interested in the server OS actually as that can be easily replaced as long as you have some information about your existing VAW deployment at hand. If the server is dead that info might be the only info you want out of the OS backup. If you do have the OS backup in VAW backups that’s easily dealt with in this scenario. Normally you’re not interested in the backup history of the OS as you are replacing it with other hardware (or a new virtual machine).

The drive letters of the original LUNs.

The following information from the registry on the old server: in the following key HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Endpoint Backup\DbConfiguration we need the value for the SQL password string.

That’s it. That’s all you need. It would be smart to have this info somewhere in case of a total loss server but you could grab it out of an OS backup if you have one. Otherwise, you can just take a peek at the original server for that info. Which is what we’ll do here as a demo.

Note: with VEB the windows LUN ID/disk order was important as well as the disk IDs in windows of those original LUNs. In VAW it seems less finicky about those, but it’s good to have them just in case. I have tested this procedure with different LUNs and I had no issues even when moving around disks to other controllers, adding different disks etc.

Replacing a Veeam Agent for Windows Server while preserving existing local backups

We’ll walk through this a lab exercise. On the original server, we have some data on the SOURCE volume that we backup to the TARGET volume on our lab server. We’ve configured a volume level backup.

We configure VAW 2.1 to backup volume S: (SOURCE) to volume T: (TARGET). We run the backup 5 times. This creates 1 full and 4 incremental files.

You can look at the backup files on the target and you’ll see the metadata file (vbm), the full backup file (vbk) and the incremental backup files (vbi). Please note that the server host name is used in the file names!

So how do we replace that server with a new one? Just install one and add a brand new VAW installation to it. So now we want to move the source volume and the target volume to a new server. Just like you might want to replace a server with a new one after it has failed or when it needs to be upgrade but the data source and backup target volume are retained. The nature of the storage will determine how that is done (SATA, SAS, iSCSI, FC).

We now shut down the VAW service on both the original and the new server.

Copy the SQL password from the original server under HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Endpoint Backup\DbConfiguration => SqlPassword string. For example: cc0b7b4a-362b-4fdb-a60b-b6d7bf2744cd

Paste it into that value on the new server. That will allow us to open the database of the old server that we will copy to the new server. If the server crashed you can grab the registry hive file from a backup (C:\Windows\System32\config\SOFTWARE) copy it to a windows machine and with a registry file reader (regedit on a working machine will do) and grab the value of SQLPassword.

Note: do not worry about the SQLinstancePipeName value. While you need this to connect to the VeeamBackup database it changes when the VAW service is restarted anyway and has no impact on your ability to backup.

You can find the database files under C:\Windows\System32\config\systemprofile.You’re after VeeamBackup.mdf and VeeamBackup_log.ldf. Only SYSTEM has access to those files by default. You do not have ownership or any rights to those localdb files.

Note: don’t work on the copies under C:\ProgramData\Veeam\EndpointData, those seem to be a copy of the ones under C:\Windows\System32\config\systemprofile. If you rename the copies under C:\ProgramData\Veeam\EndpointData you’ll see after a reboot or service restart, a new version gets copied over there.

You don’t have permissions, not even as administrator, on the VeeamBackup files

You either have to grab ownership and grant yourself the permission’s (and fix it back afterwards). Another option is to use psexec -s -i cmd/exe and run the move/copy commands under a system in that window. I just copy them out of there into a temporary location on the old server and then copy them to the new one. That can be a USB drive or thumb drive, a share, whatever works. If the original server died you need to grab them from the most recent backup.

Leverage psexec to run commands as SYSTEM which helps copy files you normally don’t have access to without having to alter any permissions or ownership.

The host name of the server doesn’t really seem to matter for this operation (identified as “This Server”, remember). Now because the files VAW creates are based on the host name we can (re)name the new server to match the old name. For a domain member server this means the old one will be kicked out of the domain / renamed and the computer AD object will be reset unless that new server is in another domain. For standalone servers this is less complex. While this keeps things consistent, it is actually not needed. The backups will work on a host with a different name, and the new backup files names will start reflecting the new host name as you can see in the picture below! Pretty resilient stuff.

In the database, we’ll see the backup job name changes to the new server name if we don’t recuperate the original host name.

The new backup file name uses the new host name if we don’t recuperate the original host name.

The host name, the backup job name and the file paths of the vbm, vbf, vbi files (screenshot above) are not used as unique identifiers. Only when a volume unique identifier (a guid, the DeviceID) changes you’ll run into issues. You can research this in the VeeamBackup database.

Looking around in the VeeamBackup database is educational. You can use free portable tools for this so don’t need to install anything on the server. Use the named pipe and the login credentials you can read in the registry.

Now if you want the backup job folder name to reflect the new server name the only way I have found to do that is recuperating the old name. There are just too many referrals in the database to the path and of the backup files stored for the tasks, jobs, restores etc. They would all need to be changed if you can identify them all. So, that’s not really an option – I didn’t drive it that far anyway – I achieved my goals, this is cosmetics. If it was a good idea I’m sure Veeam would have built it into the product like they did for picking up the name change. In any case, for replacing a failed server recuperating the old server name is a good way and you get 100% naming consistency.

Finally, you grant ownership back to SYSTEM if you so desire and take away the rights you gave yourself to end up in a permissions situation you had at the start. If you did everything you needed to do via psexec under SYSTEM everything is already as it should be security wise.

The source data volumes and the backup target volumes must be brought offline and unpresented from the old host. We then present both the source data volumes and the backup target volumes to the new server. We bring these volumes online and make sure they get the same drive letter. In our case Source S: and Target T:

Start the Veeam Agent for Microsoft Windows service on the new server.

When that is running open op the VAW control panel. You will see the backup history you had on your old server pop up on your new server.

Now we’ll run a backup to prove that this works. You’ll notice it does run a full back up as the digests have to be calculated again.

The backup finished at 12:59:44 AM.

The next test is to prove we can still restore the older backups we test this with the backup taken at 12:10.

As you can see we are ready to restore historical data on our new server. Do note that restores historical backups for the OS volume are no longer that useful that when you have moved to new hardware. These will expire over time and be gone.

That’s it. You have moved the source and data volume used by Veeam Agent for Windows 2.1 on the old server to the new server. By copying the localdb files over from the old server to the new server and editing the registry you were able to maintain your previous backups and have those available for restores. The first backup you create is a full one as it has to calculate the digests. But that’s the price you pay to keep your backup history.

WARNING: This is not a supported process by Veeam. It’s just what I have come up with when faced with this challenge for this particular use case.