Move backups within SOBR

[efd121]

I have two very large SOBR’s (600TB+) that are currently Windows and want to migrate to hardened Linux. I would like to accomplish this without missing too many nightly backups. Each SOBR has three servers with two 100TB volumes that are just over 50% full. Setting the extents into maintenance mode would take too long so I’m looking for a way to move backups to other extents outside the backup window. I’ve used RoboCopy in the past to but I’m wondering if there are better options/tricks anyone has used.

I’ve thought about setting maintenance mode, starting evacuation in the morning then canceling it later in the day, then rinse repeat until I get the extents on one server low enough to complete evacuation.

Dave

[tyler.jurgens]

You can do an active full backup on your jobs. This should force Veeam to examine an extent to target the backups onto - and chances are (but no guarantee) it will land on your new repos. Depending on your job setup, this might be an easy way to target one at a time, leaving the old backups to age out normally.

Alternatively, you can seal one extent - this will force all VMs landing on that extent to do a new active full backup on a different extent - chances are (but no guarantee) it will land on your new repos.

You can also move the backups using Veeam's new options in v12. Here's a quick post on it: https://community.veeam.com/blogs-and-p ... ories-4003

If you use either of the first two options, you can finally put that extent into maintenance mode once the new backups have started elsewhere and then evacuate the remaining backups.

[efd121]

The move backup feature in v12 doesn't allow moving within the same SOBR, it works great to move between SORB's or other repos

An active full would just increase the amount of data to be moved after the first system has been rebuilt unless I wait for each backup chain to expire which would cause this process to drag on for several months. Sealing the extent would do a similar thing, creating additional storage that needs moved later or waiting out the backup chain expiration.

[tyler.jurgens]

Correct, it would incur additional storage. However, those Linux repos are all new storage anyway, so you have that storage to spare. This is a bit easier, IMO, than manually moving files. Yes, it takes longer as well, depending on how many VMs you are backing up and how long your retention policy is, of course. If you don't have enough room to handle the old backups from your Windows Repos, and a new Active Full on your Linux repos, you can't easily put the old repos into maintenance mode and evacuate them afterward, so you'll have to wait for them to age out.

Personally, I prefer this method because you end up with a new active full chain on the XFS filesystem. New Active Full backups on XFS and you will immediately get the benefits of block cloning for spaceless full backups. No messing around with re-hydrating your Windows backups and whether new synthetic fulls will utilize block cloning or not (from my experience, they won't, and you'll eventually have to do active full backups anyway to re-engage it). All concerns over old backups having undiscovered data corruption are gone as well. You start fresh. I've done a similar migration as you are doing, and quite frankly, this was the option for me that caused me the least headaches.

You could of course move the files manually like you first stated. Often this requires re-mapping the backup jobs, but it is a viable solution.

[efd121]

It would be much easier if I was replacing the repo's with new hardware but in this case I'm rebuilding as hardened from Windows on the same hardware.