moving data from extent to new extent with XFS Reflink

[mjr.epicfail]

Hi all,

Im moving backup data from a Windows ReFS repo to a new Linux XFS repo.
Im aware that copying data will inflate the source files and disable any fastclone features on the linux extent untill a new active full has been made.
I was wondering if a CP --reflink=always will also save these files again but with blockcloning enabled. Is this a feasible option?

[Gostev]

Hi, Danny. I suggest you upgrade to V12 and use its Move Backup functionality aka VeeaMover, which is block clone aware. Thanks!

[mjr.epicfail]

hi Gostev,

Wish I could, these are extents in a SOBR for our CloudConnect enviroment. We provider BaaS as a ServiceProvider.

[Gostev]

I was wondering if a CP --reflink=always will also save these files again but with blockcloning enabled. Is this a feasible option?

@tsightler do you know if this works?

[chrislove]

We have done ReFS to ReFS SOBR's by bascially doing this with Cloud Connect....

1) Delete VBR side backup job and remove from cloud repo configuration (not disk).
2) Create temporary extent(s) in target SOBR in maintenance mode.
3) Move data to temporary extents (it will reinflate)
4) Rescan SOBR and evacuate the temporary extents. It will use VeeaMover to do block cloning on the data it is moving. I think we might have actually done a SOBR rebalance as well.
5) VBR side remap the backups to jobs after cloud repo rescan and updating the tennat storage.

Sure it would work ReFS to XFS and we will be trying this soon. But you need to make changes client side so it is not seamless to them.

[Gostev]

Good workaround with the evacuation, thanks for sharing!

[tsightler]

I was wondering if a CP --reflink=always will also save these files again but with blockcloning enabled. Is this a feasible option?

The --reflink=always only works when copying files on the same filesystem so it won't work for moving files between filesystems. If you attempt to use --reflink=always to copy files across filesystems you will get an error similar to the following (not sure of the exact wording, but this is close):

Code: Select all

cp: failed to clone: Invalid cross-device link

You could theoretically copy some files, then use duperemove, but unfortunately this is pretty slow and labor intensive. If you scripted it to copy one chain, then run deperemove only on those files, perhaps while the next set copies, it might be tolerable, but I would test it extensively before hand.

[mjr.epicfail]

We have done ReFS to ReFS SOBR's by bascially doing this with Cloud Connect....

1) Delete VBR side backup job and remove from cloud repo configuration (not disk).
2) Create temporary extent(s) in target SOBR in maintenance mode.
3) Move data to temporary extents (it will reinflate)
4) Rescan SOBR and evacuate the temporary extents. It will use VeeaMover to do block cloning on the data it is moving. I think we might have actually done a SOBR rebalance as well.
5) VBR side remap the backups to jobs after cloud repo rescan and updating the tennat storage.

I think this takes to much time, we are a SP and cant tolerate days of downtime for an extent.

The --reflink=always only works when copying files on the same filesystem so it won't work for moving files between filesystems. If you attempt to use --reflink=always to copy files across filesystems you will get an error similar to the following (not sure of the exact wording, but this is close):

I would first copy the files from extent A to extent B, after that cp the files to a different location in de same filesystem on extent B with --reflink=always.
The main thing im worried about is that Veeam can't use the data after the second copy, our assigned technical engineer had his worries about this.