Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

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

  • February 14, 2018
  • 22 min read
Cloud and Virtualization Architect. Didier is an IT veteran with over 20 years of expertise in Microsoft technologies, storage, virtualization, and networking. Didier primarily works as an expert advisor and infrastructure architect.
Cloud and Virtualization Architect. Didier is an IT veteran with over 20 years of expertise in Microsoft technologies, storage, virtualization, and networking. Didier primarily works as an expert advisor and infrastructure architect.

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.

replacing the backup server when a local Veeam Agent for Windows 2.1 deployment

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - 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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - configuretion VAW 2.1 to backup volum - running the backup 5 times

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!

replacing a Veeam Agent for Windows Server while preserving existing local backups - backup files

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - shutting down the VAW service

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

replacing a Veeam Agent for Windows Server while preserving existing local backups - SQL password

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - new version copies

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - permissions on the VeeamBackup files

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - leveraging psexec to run commands as system

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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - the new 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.

replacing a Veeam Agent for Windows Server while preserving existing local backups - the backup job name and the file paths of the vbm, vbf, vbi files

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:

replacing a Veeam Agent for Windows Server while preserving existing local backups - Virtual Mashine conection

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

starting Veeam Agent for Microsoft Windows service

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.

starting Veeam Agent for Microsoft Windows service - VAW control panel

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.

starting Veeam Agent for Microsoft Windows service - runing a full back up

The backup finished at 12:59:44 AM.

starting Veeam Agent for Microsoft Windows service - backup finishing

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

starting Veeam Agent for Microsoft Windows service - restoring the older backups

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.

Found Didier’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!