kubimike wrote:I create a new backup job set for 99 restore points It creates its first VBK, lets call this file BACKUP1.VBK. Time warp into the future, I now am up to 99 restore points, lets call this file BACKUP99.VBK. Are you saying file BACKUP99.VBK still has references to file BACKUP1.VBK ? If thats true it could never be deleted.
BACKUP1.VBK has blocks A1 B2 C3 D4, for simplicity we can say that BACKUP99.VBK has A2 B3 C4 D4, the only common block between BACKUP1 and BACKUP99 is D4. if Backup1.VBK was deleted due to retention where would BACKUP99.vbk reference block D4 ?
ReFS tracks which specific cloned blocks are referenced down to the cluster size (64K for Veeam current best practice for ReFS). If BACKUP1.vbk and BACKUP99.vbk each have block D4, then block D4 would be referenced by every single backup 1-99. When you delete BACKUP1.vbk, ReFS uses the file metadata to determine what blocks are referenced by that file and only frees (deletes) blocks that have no more references in any other file. If you delete BACKUP1.VBK, only blocks that are totally unique to that file will actually be freed, but ReFS has to update the reference count for every block that is still used by any other backup file.
Perhaps an even simpler example:
BACKUP1 - A1 B1 C1 D1
Now I use a command line tool to block clone that file to a file called BACKUP2, so BACKUP2 is this:
BACKUP2 - A1 B1 C1 D1
In other words both BACKUP1 and BACKUP2 are each referencing the exact same blocks on disk, ReFS simply keeps track that each block is referenced more than once. That's where the space savings for synthetic fulls come from, the files are sharing the same blocks between each other, otherwise ReFS would have no space savings benefits for synthetic fulls over any other filesystem.
But that doesn't keep me from deleting the file BACKUP1. If I delete BACKUP1, it will free up exactly zero disk space, because BACKUP2 is still referencing all of those blocks, so ReFS could not free them. Deleting the file simply removes the file from the directory, and reduces the reference count for each block from 2 to 1 (previously 2 files referenced each block now only 1 file does). If you then also delete BACKUP2, the reference count for those blocks drops to 0, which means no files on the system are referencing them, so ReFS can free that space.
In simple terms, just because I use block clone to share data between backup files, doesn't mean I can't delete any file at any time, but when I do, ReFS has to update the reference count for every single block that is shared with other files. Actually, it's technically at the cluster level, so that 5TB file would require updating potentially 80,000,000 clusters worth of metadata when using 64K clusters.