How can I move backups to new repositories within SOBR?

[sarnold]

We're using Veeam B&R 12.2 and have an existing SOBR (we'll call it SOBR1) with 2x ReFS formatted volumes, and the SOBR is set to use Per-VM backups. I'm switching these to Linux servers with local storage, and they've been configured with XFS.

I'm aware that by right clicking a backup job and selecting Move Backup, I can move backups between repositories and maintain spaceless fulls and block cloning (even between ReFS and XFS), but I don't seem to be able to move backups between extents within the same SOBR. I also seem to need to move the entire backup job files to the new repository, I can't just right click a VM or server within the job and move it to a different extent.

Seeing as my original plan of adding the Linux repositories to the existing ReFS SOBR, moving the individual VM's backups within each job at a time to either one of the 2 new Linux extents, and never having to change the backup repository destination doesn't seem to be possible, here's what I'm thinking. Can someone please check my logic?

Option 1: Build a new SOBR and move backups, decommission old SOBR, then rename the new SOBR

•Create a new SOBR with the two Linux extents, which I'll call SOBR2. Enable Per-VM backups on this SOBR as well.
•Using the Move Backup option for each job, move a job at a time from SOBR1 to SOBR2. This will disable the job, if I'm understanding correctly, and move the data to SOBR2. Because I've also enabled Per-VM backups on this SOBR, the VM backup chains should be split between servers, with a full chain for each VM being on one of the two Linux servers for locality and space savings.
•Once ALL jobs have moved, decommission SOBR1, and decommission the repositories that were in it
•Rename SOBR2 to SOBR1

Option 2: Add Linux servers as extents to existing SOBR, evacuate backups, then decommission old repositories

This is possible too and I believe would achieve the same results, but I'm wondering if it might take more backup downtime since I'd imagine while the move is occurring, no backups can take place. This would take a few days. I'm also thinking that to ensure I'm evacuating both the ReFS extents and don't accidentally evacuate one of them onto the other ReFS extent for some of the backups, I'd have to seal both extents, and then evacuate, to ensure all the backups arrived on the Linux extents.

Are one of these ways preferred? Am I missing anything or a better way to do this?

[david.domask]

Hi sarnold,

Your logic is solid, and while I can't tell you what would be best for you, to minimize downtime, I think Option 1 is going to be best and give you more control over the move process. Evacuate can be stopped and continued, but given that this is going to be a few days of transfer it sounds like, probably you will want to be able to do other operations like restores, so I would say focus on 1, but both of your options are valid.

[tyler.jurgens]

Another option you may want to consider is adding a new extent, sealing the old extent and running an active full backup on the VMs you want to move. You can seal and unseal the extent in question to slowly move backups over time. Eg: Seal the extent, run an active full backup on VM1 (or VM1->35), etc, then unseal the extent. Rinse/repeat for all VMs you need to move. As long as the active full has *started* on the VM you can unseal the old extent to allow it to keep ingesting backups from other VMs. Keep in mind your SOBR must be set to "Perform full backup when the required extent is offline" in the properties -> advanced settings of the performance tier.

Obviously this comes with downsides such as the active full taking much longer and needing the required space to perform that new active full backup. However, this may give you enough granularity in the process to achieve what you set out to accomplish.

If you choose to go this route you are left with the choice of what to do with the remaining backups. Can you let them age out? (Probably possible with a 1 month retention policy, not so feasible with a 7 year retention policy). Do you have enough space to move them to the new extent by evacuating the old extent?

[sarnold]

Thanks to both of you for your suggestions. I've ended up going the route of creating a second SOBR and using the Move Backups functionality to move the VMs to the second SOBR.

One thing I'm noticing is that the Move Backups functionality seems to completely ignore the concurrent tasks setting for the repositories. The repositories are currently set to their default of 4 concurrent tasks, and yet, the move process is attempting to move all 30+ VM chains in the backup job at the same time. Some are moving at a decent speed of 30MB/s, but others are 2MB/s or even 150KB/s, just due to the disks only being able to handle so much.

Is there any way to tell the move process "just move a VM at a time" or at least limit the number of VMs moved at once?