Veeam ReFS backup file mover tool?

[Mgamerz]

I am not 100% sure on the terminology used by ReFS, so excuse my possibly bad interpretation of it - one of the big benefits I have found is that blocks that are referenced multiple times are only stored once, kind of like deduplication, but not to the same degree or stored in that fashion. Hence how this image's third row makes sense:


However, if I ever have to move these files to a new ReFS repository, I cannot do it with Windows as it says there is not enough free space (Windows Explorer shows only some of drive in use, but if you were to calculate the size of the folder it'd be way larger than the drive itself). I understand this is becuase Windows is not doing the block... cloning? moves. When Veeam Support tells me to move my backups to a different storage, this task with ReFS can literally be impossible due to this.

Is there any chance Veeam could build a tool that could copy files using Block Cloning (or whatever the deduplication-like feature that is going on here) - or does a tool like this exist already? While I have not run into a dire situation like this, I would not want to find myself in a situation where I literally cannot move my backups, especially if the hardware they reside on starts to fail. I do have a copy of them elsewhere but not to the same retention.

[veremin]

Such tool does not exist right now.

We're of this request already, but currently cannot comment on when (if ever) we will release such feature.

Thanks!

[nmdange]

I run the repository inside a Hyper-V VM (on local storage), so it's just a matter of moving the vhdx file to another physical server if the hardware has to be changed.

[veremin]

Are other VMs also running on the same local storage? What happens if this storage fails for some reason, you will loose both production VMs and their backups? Also, having backups stored on production datastore complicates restore process (check this thread for more information regarding that). Thanks!

[nmdange]

The repository VM is sitting on a standalone Hyper-V host with local storage (a Supermicro server+JBOD with 84 6TB disk drives), so it's independent of the production environment. It's basically an all-in-one Veeam backup server, it's just running as a VM instead of bare metal.

[veremin]

It still might make restore a bit more difficult - as you will need to have a VM running to access data stored inside .vhdx, but it's up to you to use whatever scenario that works best for you and your needs. Thanks!

[nmdange]

The VM doesn't depend on anything outside of the standalone physical host that it lives on to start, so there's nothing that would prevent it from running unless the physical host has a problem. But in that case, the repository wouldn't be accessible even if it was stored directly on the physical host.

[veremin]

I was talking more about making repository physical instead of virtual: using physical disks instead of virtual and attaching them to spare physical server. So that if anything happens with Hyper-V host, backups will be still accessible.

Again, if the current approach works for you, there is nothing to worry about.

Thanks!

[Technogod]

That is exactly why I switched from Virtual to Physical. My Physical computer hosting the VM was the one that seemed to always need restoring.

[ian0x0r]

This post by Luca Dell’Oca may be worth a look. Very unsupported but has been documented using Windows Storage replica to replicate ReFS volume to a new target https://www.virtualtothecore.com/window ... s-volumes/.

The ReFS block clone layout is maintained on the target replica.

Ian

[ericn]

When evacuating a SOBR Extent that is formatted with ReFS and has a bunch of embedded block cloning efficiency; will this block cloning be replicated during an extent evacuation, or will the result on the target extent be an expanded set of un-cloned copies?

[HannesK]

Hello,
and welcome to the forums. I merged your question to the existing one.

block cloning benefits well get lost during migration.

To avoid that you can use any tool that does block copy (I used dd in the past) or storage replication.

Best regards,
Hannes

[jayscarff]

Hi All,

Any word on a tool to do this? Ive got to move a 72TB vbk file and some VIBs....its proving to be a big headache!

Thanks

[HannesK]

Hello,
nothing new yet on that topic. Block-based copy of the whole volume is still "the way to go".

Best regards,
Hannes

[Gostev]

One alternative in v10 is to use Seal mode on the decommissioned SOBR extent, and just let those backups expire on it per retention, instead of performing the move.

[jayscarff]

Thanks, eventually we simply pointed the new job to the new repo and waited 6 days!