Veeam v12: move or copy backups with VeeaMover

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.

Very informative and clear steps! Thanks for sharing

@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.

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

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.

#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.

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.