Veeam 9.5 + ReFS - compact synthetic fulls?

[graham8]

We're evaluating using Veeam 9.5 + ReFS + Server 2016 and backing up what will grow to be a large fileserver (up to 60TB).

With spaceless weeklies/monthlies thanks to Veeam9.5+ReFS+2016, we don't need to have many hundreds of TBs of disks sitting around wastefully to back this up, but I'm trying to understand what will happen to deleted files in the fileserver (data on this server has a high turnover rate) and I'm having a hard time getting clear answers that I feel confident with. I understand that the "compact full backup file" option is what removes deleted files from full backups in most cases. I'm trying to get clarity on a few points though, but I'm having a really hard time getting clear and succinct information on how deleted items are handled with all the different backup models and options.

Btw - the retention calculator isn't so useful right now because it doesn't seem to take into account 9.5 + ReFS and its spaceless GFS savings.

Scenario: (backup model: incremental + periodic synthetic fulls; compact option: off)

Timeline:
DAY1: 10TB initial VBK
DAY2-6: 5TB of new user data in VIBs
DAY7: Synthetic Full #1
DAY8-12: previous 5TB of data in those VIBs deleted by user + 5TB new data written
DAY13: Synthetic Full #2

Questions:

1.) In the above scenario, is the initial 10TB VBK removed eventually (per retention settings), leaving only the new synthetic fulls + incrementals? Ie, future synthetic fulls eventually take the place of the initial active full VBK, correct?
2.) Will Synthetic Full #3, 4, 5, 6 etc contain the data users deleted in DAY2-6, even though that week will be long out of the retention period? Again, with the compact option off.
3.) If I were to turn the compact option on, will the compact operation take advantage of ReFS+2016 and the Block Clone API? Ie, if a VM's full is 60TB, then it requires 120TB of space temporarily? In spite of the fact that normal synthetic fulls would be spaceless? Or will block clone be leveraged, and no additional space will be needed for the new "compacted" synthetic-full?
4.) In the Backup Copy Job, having "Keep the following..." enabled and values set for Weekly+Monthly produces the message "Maintenance is not required when periodic full backups are enabled" under Advanced, not letting me select the "compact full" option. When enabling Synthetic Fulls in my main backup job, however, it doesn't say that in Advanced. Why is that? My understanding was that the Backup Copy keeps its archived weekly/monthly points in time as fulls. Should the main backup job also have the same message, and this was just an oversight?

[Gostev]

1. If you are thinking about the file itself, then yes - it will be gone from the directory. On a file system level though, it is much more complex: while the initial active full VBK will no longer be present, many of its block will still live due to still belonging to more recent synthetic fulls.

In ReFS, every data block can belong to one or more files, this is tracked by block's reference counter. The block is only marked as unused after reference counter turns zero (meaning, the last file this block is used in gets deleted).

2. No, new synthetic fulls will not include deleted data. However, this is not a ReFS-specific benefit: these savings are delivered by our BitLooker feature by excluding (zeroing out) blocks belonging to deleted files from an image-level backup.

3. Compact operation does not require extra space if VBK being compacted is fast clone compatible (created by 9.5 in backup repository backed by ReFS 3.1 volume).

4. Yes, primary jobs should also have the same message - since just like Compact, synthetic full creates defragmented full backup file that does not include VMs no longer processed by the job. Compact is really only useful for forever-incremental jobs with no (or very rare) periodic fulls (synthetic or active) scheduled.

[graham8]

Thanks Gostev. That's what I was hoping to hear.

[DaveWatkins]

3. Compact operation does not require extra space if VBK being compacted is fast clone compatible (created by 9.5 in backup repository backed by ReFS 3.1 volume).

Is that still the case with reverse incremental? I assume it is, in which case it's fantastic news, just want to confirm

[Gostev]

Yes, backup mode does not matter as Compact is about recreating a full backup file.