Hi Marco,
I will comment on your situation in a bit but first a few clarifying points as there is a bit of confusion here I see and just want to ensure we're talking on the same level about these elements.
First, a few definitions and explanations:
Synthetic Full => Fully functional and normal full backup produced by combining data from previous existing backups of a machine into a new full. Performed entirely on the repository saving network resources and reducing the impact on production (an incremental backup is still performed on Synthetic Full days). No deduplication/space savings happens with _just_ the Synthetic Full operations
Fast Clone => A special function that file systems may support (such as XFS or ReFS and a few additional storage vendors) which allows for fast copies on the file system by creating a reference to an existing block instead of actually writing the data again. This is where you will see a performance improvement in the synthetic operations (synthetic full creation, merging increments into full backups) as well as the space savings. Fast Clone requires that the data reside on the same volume as noted in the User Guide link, and it only works between individual backup chains for a given machine, it is not global across all files on the repository; remember fast clone is a _copy operation_, it's not a background process like global deduplication.
The main advantages of Fast Clone here are that you get fast backups, fast creation of Full backups, and you save space in the process; while Veeam includes inline deduplication and compression, that's limited to the individual backup session, and Fast Clone allows further space savings by reusing blocks from previous backups in the chain.
Clear so far?
So why would you want it? As opposed to Active Full backups, you've already found the main reason, saving resource consumption and placing the workload on the repository. With Fast Clone, this makes the workload even more efficient on the repository AND saves you additional space, while having actual full backups available.
Why are full backups important? Well, it's largely up to you -- many Veeam users run Primary jobs with just Forever Forward Incremental, so no periodic fulls. I suspect most would have a Backup Copy job or Backup to Tape job to create archival restore points from, but it's not a requirement, just very common. But it's also very common to use GFS to have the archival restore points set aside and such retention handled automatically -- as only full backups are able to be GFS points, this is another reason you would consider.
The placement policy for Scale-out Backup Repositories is outlined here in the User Guide, and given that Locality is selected (required) for Fast Clone to work, that's why it's favoring the existing extent.
A few questions I would have:
1. I would check some of the full backups properties on the ReFS volume itself and ensure that the file size really did reduce; there should be two values when the file has fast clone applied: Size and Size on Disk. Similarly, I would check the most recent job run where a Synthetic Full was supposed to run and see if if really used Fast Clone -- the job statistics window will note on the line about Synthetic Full if fast clone was used or not.
2. Keep in mind that depending on the increment size and the size of the full backup, as well as the unique change rate of the data, the space savings may not be enough to keep up with the data ingest; VeeamOne has a capacity planning report that should help with monitoring the ingest rate for your repositories.
As for easy way to check which files are where, I wrote this powershell function some time ago for a different reason, but you can pass a backup object returned by Get-VBRBackup to it and it will print a list of where the backup files are across SOBR extents (and some other information): post509821.html#p509821
I wrote a lot, so will give you time to review and digest it, but maybe it will help with your concerns here.
I will comment on your situation in a bit but first a few clarifying points as there is a bit of confusion here I see and just want to ensure we're talking on the same level about these elements.
First, a few definitions and explanations:
Synthetic Full => Fully functional and normal full backup produced by combining data from previous existing backups of a machine into a new full. Performed entirely on the repository saving network resources and reducing the impact on production (an incremental backup is still performed on Synthetic Full days). No deduplication/space savings happens with _just_ the Synthetic Full operations
Fast Clone => A special function that file systems may support (such as XFS or ReFS and a few additional storage vendors) which allows for fast copies on the file system by creating a reference to an existing block instead of actually writing the data again. This is where you will see a performance improvement in the synthetic operations (synthetic full creation, merging increments into full backups) as well as the space savings. Fast Clone requires that the data reside on the same volume as noted in the User Guide link, and it only works between individual backup chains for a given machine, it is not global across all files on the repository; remember fast clone is a _copy operation_, it's not a background process like global deduplication.
The main advantages of Fast Clone here are that you get fast backups, fast creation of Full backups, and you save space in the process; while Veeam includes inline deduplication and compression, that's limited to the individual backup session, and Fast Clone allows further space savings by reusing blocks from previous backups in the chain.
Clear so far?
So why would you want it? As opposed to Active Full backups, you've already found the main reason, saving resource consumption and placing the workload on the repository. With Fast Clone, this makes the workload even more efficient on the repository AND saves you additional space, while having actual full backups available.
Why are full backups important? Well, it's largely up to you -- many Veeam users run Primary jobs with just Forever Forward Incremental, so no periodic fulls. I suspect most would have a Backup Copy job or Backup to Tape job to create archival restore points from, but it's not a requirement, just very common. But it's also very common to use GFS to have the archival restore points set aside and such retention handled automatically -- as only full backups are able to be GFS points, this is another reason you would consider.
The placement policy for Scale-out Backup Repositories is outlined here in the User Guide, and given that Locality is selected (required) for Fast Clone to work, that's why it's favoring the existing extent.
A few questions I would have:
1. I would check some of the full backups properties on the ReFS volume itself and ensure that the file size really did reduce; there should be two values when the file has fast clone applied: Size and Size on Disk. Similarly, I would check the most recent job run where a Synthetic Full was supposed to run and see if if really used Fast Clone -- the job statistics window will note on the line about Synthetic Full if fast clone was used or not.
2. Keep in mind that depending on the increment size and the size of the full backup, as well as the unique change rate of the data, the space savings may not be enough to keep up with the data ingest; VeeamOne has a capacity planning report that should help with monitoring the ingest rate for your repositories.
As for easy way to check which files are where, I wrote this powershell function some time ago for a different reason, but you can pass a backup object returned by Get-VBRBackup to it and it will print a list of where the backup files are across SOBR extents (and some other information): post509821.html#p509821
I wrote a lot, so will give you time to review and digest it, but maybe it will help with your concerns here.
Statistics: Posted by david.domask — Jun 19, 2024 1:57 pm