Skip to main content

I thought I posted the following post already. But it seems I missed to do so. I also saw @PValsecchi posted similar content already 

But I think I add some other details here, so I hope it is okay to post my stuff too.

 

 

What is it about

One of the new v12 features will be the possibility to move backups between repositories. It’s not just new that this will be an option in the GUI, also fast cloning information will be moved. This means that synthetic fulls will not need more space on target repository than it uses on source! This feature is very useful when it comes to replacing old repository hardware with new one.

How to move backup job data

In beta there are several ways to move backups from one repository to another. One way is to right-click Job Name beneath Disk and select Move backup.

The following windows will ask about the destination repository.

I could see all repository types of my test environment: ReFS, XFS, object storage and Scale-Out backup repositories. When movement runs, you see progress information. As you can see in the following screenshot, backup job will be disabled during the process.

Note: When moving to a hardened repository, files will not be marked as immutable!

If you try to access backups during this – for example for restore, you will see a error with detailed information. Keep this in mind when planing a migration.

Another way to move whole backups to another repository is in the Edit backup job dialog. Here a new question windows arise when you change the destination backup repository.

You have the option to let VBR move the data to the newly configured destination repository for you. But you can also start a new backup chain at this point. Even this is a nice new feature I was waiting for some time. Before v12 you had to clone the job and set target repository in cloned job.

How to move machine backup data

It will also be possible to move just an object of a job like a VM or physical server. I covered this in my post True per-machine backup files in more of its details.

Already tested this out with VeeaMover as I am writing my book (Chapter 3).  Works great to move things around and love the space savings that stay between XFS & ReFS.  


Already tested this out with VeeaMover as I am writing my book (Chapter 3).  Works great to move things around and love the space savings that stay between XFS & ReFS.  

I am curious about the time movement will take. 


Already tested this out with VeeaMover as I am writing my book (Chapter 3).  Works great to move things around and love the space savings that stay between XFS & ReFS.  

I am curious about the time movement will take. 

Everything I tested was very small backup files, etc. so it took no time.  😂

Once RTM comes out and I upgrade our lab at the office then I will test some larger data sets.  I know someone posted in the Vanguard channel in Slack about converting to new backup chains which took a while.


we ran into an issue with this today. I moved a backup job from one xfs immutable repo to another xfs immutable repo. That backup job also had a backup copy job (immediate) associated to it. That backup copy job goes over the wan to another xfs immutable repo at a DR site. For whatever reason the backup copy job is reseeding from scratch which wasnt our expectation (it really makes the process useless as we can not tolerate a full reseed). I suspect this isnt by design but details are light on this subject. I also dont know if having everything immutable is contributing to the issue.

 


I’ll have to test this on a lighter backup based on that last comment.. reseeding 100’s of TB’s isn’t ideal. such a handy feature though. 


Comment