Migrating data to new repository using scale-out?

[ClarkWGriswold]

There is a thread here that discusses the supported way to move backups to a new repository (vmware-vsphere-f24/moving-to-new-reposi ... 20-90.html). I can go through that procedure, but I'm wondering if there is a better way.

My current setup is a physical Windows box and two repositories that are iSCSI LUNs on a Synology box (let's call them LUN0 and LUN1). Both LUNs are formatted NTFS and about 28TB in size (14TB used on each). The physical Veeam server is brand new Server 2016 with a fresh 9.5 install of Veeam (migrated our setup from 2012 R2 two weeks ago). We backup to tape, hence the need for a physical box. Because we are now on 2016, we would like to leverage ReFS. That means making new repositories formatted as such. I have another 27TB of space available that I can use to create a new LUN formatted using ReFS (we'll call that LUN2).

My original plan was to create LUN2 and map it as a repository, then move data from one of our current repositories to the new one. Then, we'd reclaim the free space and do the same thing all over again. Essentially, we'd move everything from LUN1 to LUN2, then move everything from LUN0 to LUN1, then reclaim the former LUN0 space. That would involve moving ~28TB of data and having those backups offline for several days while the data moves. After all is said and done, we'd still be stuck with two non-scaleable repositories. I'm wondering if there is a better way that will not only prevent many days of down time, but will allow us to have a single scale-out repository when the work is complete.

Is there any way to do something like the following?

1) Create a scale-out repository and add both LUN0 and LUN1 (We have Enterprise license)
2) Create LUN2 and format using ReFS.
3) Add LUN2 as an extent of the scale-out repo
4) Evacuate backups from LUN1 (data should all move to LUN2), then remove it from the scale-out repo
5) Format LUN1 as ReFS and re-add to the scale-out repo
6) Add LUN1 (which contains ~14TB of data) as an extent of the scale-out repo
7) Evacuate backups from LUN1 (data should all move to LUN2/LUN0), then remove it from the scale-out repo

If the above would work, that would allow me to move all of my current backup data without interrupting backups and would give me a new scale-out repo with the same free space as we currently have, all in ReFS. Another alternative would be to use similar steps to get the data from LUN1 to LUN2, then reclaim the space on the Synology and allocate it to LUN2 (not even sure if I can reallocate space to a LUN like that. It works for volumes, but maybe not for LUNs).

Is this a viable plan? Surely there has to be some way of migrating data from one repo to another without stopping jobs for a week or more and manually moving it all.

[foggy]

You can use the described approach, however, keep in mind that backup jobs for chains that are currently located on the extent that is in maintenance mode (being evacuated) will fail (unless you temporarily disable the jobs). You will be able to continue jobs after the chain is fully evacuated.

[ClarkWGriswold]

If jobs that have chains on the extent that is being evacuated will fail, then it's a moot point. The whole idea was to be able to continue backups uninterrupted while the data on the repository moved.

Is there really no way to move data between repositories without taking all of the jobs offline for the entire duration of the move? Our LUNs use iSCSI over a couple of 1GbE connections and moving ~24TB of data will take several days, best case scenario. I hate to have my backups offline for that entire time.

[foggy]

You can migrate them gradually, one by one. This way while you're migrating a single job, others will run fine and chances are that the migration will even fit into the period between job runs.

[ClarkWGriswold]

I only have two backup jobs, two copy jobs, and two tape jobs running to two repositories. So, I'd have 50% of my backups offline at any given time. Still not an ideal solution, but I guess there's not much choice.

Thanks.

[aceit]

You can use the described approach, however, keep in mind that backup jobs for chains that are currently located on the extent that is in maintenance mode (being evacuated) will fail (unless you temporarily disable the jobs). You will be able to continue jobs after the chain is fully evacuated.

Would be nice if Veeam would consider to add in the next versions the possibility to migrate scale-out extents without interruptions in normal services and jobs (ie. in other context what VMware storage vmotion does with VMFS). The whole B&R functions shouldn't be impaired by the indirection layer provided by scale-out mechanics.
Part of the reasons to go for scale-out repos should be to have flexibility, scalability and serviceability of repos storage without impairing general availability.

I agree with the OP that scale-out management operations should include the possibility to decommission storage repo without impairing the backup processes (ok to delay them waiting for a particular piece of the chain to be moved on a different repo, but stopping them isn't indeed a good solution for a backup solution).