1. The hypothetical benefits only come from a full proper setup in my experience, so you must be using Block Cloning, you must be using Forward Incremental, and you must use periodic Synthetic Full Backups. I can confirm the speed benefit, mainly as a result of not needing to perform file "merges" every time the backup runs. I can't say I noticed any big difference in storage used. For either of "faster" or "smaller" though, I still would say it's harder to calculate or predict anything without actually doing it. I can believe there was a Veeam user with 3x faster speed and 3x smaller storage used, but I would not expect to see that number across the board. It will vary depending on the specific data you have and your device processing speed, network transfer speed, disk I/O speed, etc...
4. Periodic synthetic fulls works well when you're using block cloning and forward incremental jobs.
2. "Block Cloning" is a feature used in XFS or ReFS filesystems, also available on many dedicated storage appliances such as Dell's DataDomain or HPE's StoreOnce, which enables you to "copy" blocks without processing them in the software, the filesystem or storage appliance will copy them instead, so data doesn't need to be transferred. When Veeam uses Block Cloning to create a synthetic full, it generates a new "full" backup using assorted blocks of data from previous incremental and full backup files, so the new full backup is created without transferring any data. This allows those older incremental and full backup files to be deleted while retaining the recoverability for the restore point in the Synthetic Full Backup file, and that file is also used as a base file for future incremental files to be built on to.
On the disk, don't think of a "file" as a container with a lot of data in it, think of it as a list of blocks. "Blocks" represent a container for data on the disk, a small amount of data, usually many blocks are required to make up a file. For some familiarity, you may have defragmented your disks before, which takes the many blocks for a file and moves them physically to sit next to eachother on a disk. In a filesystem that supports Block Cloning, when you "copy" a file, what happens is the filesystem stores a new "file" which is just a list of blocks, so you now have two "files" that reference the same "blocks" on the disk and thus use the same physical space.
When Veeam uses Block Cloning to create a Synthetic Full Backup, it creates a new VBK file (a list of blocks) by using blocks that are already used in previous VIB or VBK files, so your new Synthetic Full Backup doesn't actually need to write new data to the disk and it doesn't actually take up more space, because the data is already there.
Similarly when you use an object storage repository, such as Wasabi, AWS S3, or Azure Blob Storage, Veeam will store all data as a collection of objects (functionally equivalent to blocks), and there are no VIB or VBK files at all. In that scenario Veeam stores the list of "objects" that contain the data for a restore point. So when you upload a new increment, new data is written, but data from the source that didn't change is already there in the existing objects, and so does not need to be reuploaded.
4. Periodic synthetic fulls works well when you're using block cloning and forward incremental jobs.
2. "Block Cloning" is a feature used in XFS or ReFS filesystems, also available on many dedicated storage appliances such as Dell's DataDomain or HPE's StoreOnce, which enables you to "copy" blocks without processing them in the software, the filesystem or storage appliance will copy them instead, so data doesn't need to be transferred. When Veeam uses Block Cloning to create a synthetic full, it generates a new "full" backup using assorted blocks of data from previous incremental and full backup files, so the new full backup is created without transferring any data. This allows those older incremental and full backup files to be deleted while retaining the recoverability for the restore point in the Synthetic Full Backup file, and that file is also used as a base file for future incremental files to be built on to.
On the disk, don't think of a "file" as a container with a lot of data in it, think of it as a list of blocks. "Blocks" represent a container for data on the disk, a small amount of data, usually many blocks are required to make up a file. For some familiarity, you may have defragmented your disks before, which takes the many blocks for a file and moves them physically to sit next to eachother on a disk. In a filesystem that supports Block Cloning, when you "copy" a file, what happens is the filesystem stores a new "file" which is just a list of blocks, so you now have two "files" that reference the same "blocks" on the disk and thus use the same physical space.
When Veeam uses Block Cloning to create a Synthetic Full Backup, it creates a new VBK file (a list of blocks) by using blocks that are already used in previous VIB or VBK files, so your new Synthetic Full Backup doesn't actually need to write new data to the disk and it doesn't actually take up more space, because the data is already there.
Similarly when you use an object storage repository, such as Wasabi, AWS S3, or Azure Blob Storage, Veeam will store all data as a collection of objects (functionally equivalent to blocks), and there are no VIB or VBK files at all. In that scenario Veeam stores the list of "objects" that contain the data for a restore point. So when you upload a new increment, new data is written, but data from the source that didn't change is already there in the existing objects, and so does not need to be reuploaded.
Statistics: Posted by BackupBytesTim — Apr 22, 2025 1:46 pm