I thought that with the way ReFS works and the fact that it allows the re-mapping of blocks, it would be the ideal candidate for Reverse Incremental? When the merge parts of the job are happening instead of re-writing all the merged blocks it just re-maps them?
My understanding being that Forward Incremental will use 1 write IO during the backup then 1 read and 1 write after the backup to do the merge. Where RI will use 3 IO during the whole backup process, 1 write of the new block, 1 read of an existing block and another write to put that existing block into the new file. My understanding was that with ReFS the 'existing block' IO is just re-mapped instead of actually read/written. So this improves the speed of the process and takes the actual IO load away from the disk array and does it at a software level instead. I understand that would cause fragmentation of the files, but that would happen anyway with ReFS no?
I thought that Reverse Incremental would give the benefit of the latest backup always being a full, but the IO load issue normally associated with it would be removed due to benefits of ReFS functionality.
Our problem with using Forward Incremental is that we rely on the full chain to go back to last night, if there is an issue with any of the chain the backup is no good. 99% of the time we only want to restore from last night. With Reverse Incremental we always have a full backup being last night.
Any comments on why Reverse Incremental is the worst for IO with ReFS? To me it seems like the ideal candidate to use with ReFS? Why is Forward Incremental so much better with ReFS?