Veeam Backup & Replication: Migrate existing repository volumes of a lost server to a new one

1. Introduction

This article is based on Veeam KB1905 and written for advanced administrators of Veeam Backup & Replication who have a basic knowledge of Veeam PowerShell commands.

We’ll dive into a disaster scenario in which a Veeam repository server cannot be recovered, but the block storage, used for storing the backups, is still intact and consistent. As an example, a classic situation would be a physical server with hardware that is defective, but the disc shelves or fibre-channel sub-storage system is not affected by the hardware failure.

By the end of this article, you should have successfully added the repository disk storage to a new Windows or Linux server and be able to continue running backups and recovery tasks without any larger impact.

Before doing any critical changes or migration in your production environment, always have a backup copy ready. Please see this article about the 3-2-1 Rule, a concept for optimizing data protection.

2. Requirements

2.1. Windows to Windows migration

Compared to the failed source server, the new server should have the same or a newer version of Windows installed. It is advised to install all available updates on the new server. Please see the system requirements for Repository Server in the Veeam Help Center.

The new server needs to have a different name then the original server.

2.2. Linux to Linux migration

Compared to the failed source server, the new server should have the same or a newer version of the Linux distribution installed. It is advised to install all available updates on the new server. Please see the system requirements for Repository Server in the Veeam Help Center.

The new server needs to have a different name then the original server.

2.3. Status of the failed source server

The original failed server must be powered off and the repository must be permanently disconnected, even if it is powered on in the future. If both servers can access the storage at the same time, you might experience heavy data corruption or loss.

2.4. Status of the new target server

The new server needs to be set up and running. This includes:

3. Preparation

The first thing to do is disable all the scheduled backup jobs targeting the failed repository server.

The easiest way would be to sort the job list by Target, mark all the dependent jobs and select “Disable”:

The second step is to create a Veeam Backup & Replication Config Backup and a backup of the SQL Database. This can be done from the general menu by selecting “Configuration Backup.”

Depending on migrating either a Linux or Windows server, continue with one of the next two sections.

4. Linux Server

Notice 1:  The new target server should not be added as a Managed Server in Veeam Backup & Replication since the old server object will be renamed in a later step!

Notice 2: Depending on your environment, the path and devices will most likely be different to this example. Please fit the steps to your needs.

4.1. Mount the volume

Note the old mount path of the repository in the Veeam Backup & Replication Console. This path will be needed to mount the volume on the new server in the correct path. In this example, it is /repository/repo01: 

If not already done, attach the existing disk with the repository data to the new Linux server. Here we are using Ubuntu 21.10 and you can use

sudo fdisk -l

to list all present disks and devices. The device we are searching for is /dev/sdb1.

Make sure the mount directory exists or create it with mkdir /repository.

Mount the device to the same path as on the old server with 

sudo mount -t auto -v /dev/sdb1 /repository

and check that the files and folders are visible in the repositories subfolder:

Since you might want to have the mount being available after a reboot, check the device UUID with

sudo blkid /dev/sdb1

and add this to the /etc/fstab file:

Depending on your storage solution, you might need additional mount attributes in the fstab file. For example, the attribute “nofail” can be necessary to correctly mount iSCSI devices during boot when the network is not ready.

Now you have added the source volume with the existing repository data to the new target server.

4.2. Additional steps for Hardened Linux Repositories

If you used the original server as a Veeam Hardened Linux Repository, please perform these additional steps on the new server. In this example, the volume mount point is /vbrrepo and the repository is found in /vbrrepo/hardened.

Create a user account with the same ID as it was on the old server. In this example, the ID is 1001:

4.3. Additional information on immutable flags

The VBM files in a repository store metadata information about the restore points, how they are linked to each other and some more data that needs to be updated on each job run. This is the reason the VBM files cannot have the immutable flag.

Check the immutable flags with

sudo lsattr -R /vbrrepo/hardened :

For management purpose, the time until backup files are locked for immutability is stored in .veeam.*.lock files in each repository folder.

This information might help to get a better understanding when restore points can be deleted.

If you discover any inconsistency between the files flagged for immutability and the ones listed in the .veeam.*.lock file, please open up a Veeam support case for this to be corrected.

Continue with renaming the Manged Server as described later in this article.

5. Windows Server

Note 1:
The new target server should not be added as a Managed Server in Veeam Backup & Replication since the old server object will be renamed in a later step!
Note 2:
Depending on your environment, the path and devices will most likely be different to this example. Please fit the steps to your needs.

Note the old mount path and drive letter of the repository in the Veeam Backup & Replication Console. This path will be needed to mount the volume on the new server with the correct drive letter. In this example, it is E:\Repo01:

If not already done, attach the existing disk with the repository data to the new Windows Server and open the Disk Management console to see the offline disk:

Set the disk online:

It should come online with the mount letter from the old server:

If the drive letter is not assigned automatically, you can do this by using the “Change Drive Letter and Paths…” option:

Do not run any “Format…” option on the volume!

Check that all the backup files are visible:

Now you can continue with the next steps in the Veeam Backup & Replication console.

6. Migration within Veeam Backup & Replication

If the repository server is ready from the operating system and volume perspective, you need to perform migration steps within Veeam Backup & Replication.

6.1. Rename the Managed Server

The old repository server was an object in the Managed Servers in Veeam Backup & Replication. To keep all the references and information about its repository information intact, we need to rename this new Managed Server object through PowerShell. Open the Veeam Backup & Replication PowerShell Console:

Save the old server into an object with

$Servers = Get-VBRServer -name “old-name”

where “old-name” need to be the exact name as shown in the Veeam Backup & Replication Console:

Now rename this Managed Server object to the new server’s name with

$Servers.SetName(“new-name”)

where “new-name” needs to be the IP, Hostname, or FQDN of the new server:

In the Veeam Backup & Replication console, you should now see the Manged Server being renamed:

6.2. Edit Linux Server

To install the Veeam services on this new server, simply open the properties and change the credentials if necessary.

For Hardened Linux Repository, you should use single-use credentials as described in the Help Center.

The Veeam Transport service is not yet installed, it will be installed when applying, even if no changes have been made in the properties:

6.3. Edit Windows Server

To install the Veeam services on this new server, simply open the properties and change the credentials if necessary.

The Veeam Transport service is not yet installed, it will be installed when applying even if no changes have been made in the properties:

6.4. Update the Repository

The last step is to open the properties of the Repository, change the name if desired and check that the repository server name has successfully been changed:

Run an incremental backup job targeting this repository and check that it completes successfully.

7. Conclusion

The described steps help in migrating an existing repository storage from a failed server to a new server by leveraging the advantage to:

The listed advantages can save a dramatic amount of time and administration effort. Even if the occurrence of a failed server should be rare, it is especially important, in such situations, to have a quick and easy recovery option, to get back into a productive stage. The continuous need for data protection can be satisfied and there is little or even no impact on backup related SLAs that must be met.

If you have any doubts or need further assistance, feel free to contact the Veeam support.

Exit mobile version