Fast Clone and ScaleOut with multiple extents

[collinp]

Does Fast Cloning w/ REFS still function properly on a ScaleOut repository when using Data Locality with multiple extents?

It looks like when a weekly synthetic full is performed, it looks at free space (and other factors) and may choose a new extent with more free space. It then keeps the fulls (vbk) and incrementals (vib) together on that new extent. I'm assuming that Fast cloning would still work in this case.

I am assuming that if you choose the "performance" feature where .vib's are kept separate from .vbk's, that this could possibly break Fast cloning?

[Gostev]

Yes, SOBR is aware of our ReFS/XFS/deduplication storage integrations and will always try to put the new synthetic full onto the extent with the previous full backup. This is not reflected anywhere in the user interface because you cannot control this behavior.

[ober72]

Hi Collin,

Keep in mind though that if one of your extents fills up and breaks the policy, thereby putting new vibs on a different extent then the system will switch to "partial fast clone" since obviously it can't use pointers from another volume (if I understand and have termed the REFS functions correctly). By partial fast clone, and Anton can correct me if I am wrong, I believe it does fast clone on the items still on the same volume but not for the vibs on the other extent. The way to solve this is to run an active full or have weekly synthetic clones which will then be places on the volume with more free space. That first synthetic full though will take just as long as they used to when leveraging NTFS.

[collinp]

Does fast clone still work when the backup chooses the new extent when the weekly synthetic happens with REFS/Fast Clone technology? I would think that since it is starting a new full on a new backup extent, that it would not be able to reference the fast clone blocks from the old prior REFS volume. Or is it somehow able to reference fast clone pointers from the old backup that was on the old REFS extent when choosing a new extent?

[Mildur]

If the backup files go to the new extend, fast clone cannot be used.
Fast clone rely on „blocks of previous backups are already on the same target disk“ (Block Cloning API).
A new extend doesn‘t have any blocks of the previous backups.

[foggy]

Correct, currently block cloning is not possible across extents. New active full is created on another extent in this case.

[collinp]

Ok, so a new active full is created on the new extend initially but subsequent backups use fast clone if that new extent is configured with all the fast clone prerequisites?

[foggy]

Correct.