This is going to be a great feature for many for sure especially us being an MSP and migrating slowly to XFS repos for VCC.  

Can’t wait for this feature. We are migrating legacy repos to new SOBR’s on new hardware and this will make things far less arduous.

This a really great feature.

I am waiting anxiously for it

Very informative and clear steps! Thanks for sharing

Nice write-up @PValsecchi ! I think several folks are really awaiting for this new v12 feature.

Cheers!

@PValsecchi this is a great discussion of this feature! The VeeaMover has a lot of great use cases!  This is one of my favorite features in V12.

I just finished writing about this feature in chapter 3 of my book too along with use cases.

Looking forward to a copy again. This time, a hard copy :-) 

I’m anxiously waiting as well…I have my first use case already, but nothing urgent for moving.  Need to move a SOBR performance tier from REFS to XFS.  My only hope is that the VeeaMover term sticks.  I still don’t see it in the v12 documentation, but that’s my one wish for Christmas…and world peace.  

This is so handy if you inherit an infrastructure with too many repos, and you don’t want to delete any jobs/data for a while until you can get sorted out.  When I received the current infrastructure the SANS were carved up into multiple repos each and it was difficult to move everything around for a bit while not running out of space.

Works very well for sure as I have it in one of the chapters of my book. 

#shamelessplug

Trying this now on 3 repo’s we had to use old servers for until new SAN came in.  Each repo has 25TB of used space, will see how long it takes for each one.

I see that this article mentions rebalancing SOBR extents or for the evacuation of a SOBR extent as one of the use cases but I did not specifically see how you can leverage this tech to do that. 

Took an entire weekend.  But completed fine and everything is working well. 

Took an entire weekend.  But completed fine and everything is working well.

This aspect of the feature I’ve found makes it quite problematic:

If you need to change the target repository for a Backup Job containing existing backups, a warning message is displayed and the procedure cannot be finalized until the backups have moved to the new repository.

If you’re performing such a change on a backup job of any reasonable size, the move forces the job to be disabled, and the move may take what could be days or weeks to complete.  I ran into this recently with a job that had ~250 VM’s with a 30 day retention, probably about 20 TB of data, and was trying to change the job repo from one HP StoreOnce to another HP StoreOnce.  I let it run for 30 hours and it was at the 5% mark.

With no choice but to cancel it to get my job running again, I ended up with a mess of some backups moved, most not, some pieces of some backups moved which prevented subsequent move jobs from working since the target file seemed to already exist even though it was incomplete, so it turned into a nightmare of trying to sort out what pieces were valid or not valid on the target StoreOnce to delete them to allow a subsequent move job of orphaned backups to work successfully.  If parts of that move job failed, it would seem to have a catastrophic effect and cause the move job to fail until I did more fixing and tried again.

The fact that the job is named the same also breaks a bunch of the Veeam powershell tools which work by job name alone, not GUID.  So, for example, cleaning up missing restore points, nope, gotta do them all by hand in the GUI because with the partially broken move, I’ve got backups associated with the same job name in two places.