Many thanks for the release of restic 0.11.0, support for VSS sounds promising!
Here I have a question about Enh #2969 (Optimize check for unchanged files during backup)
Formerly the strategy was:
“The archiver module performs an extra fopen check to increase the probability that the file information has not changed from the previous stat.”
I unserstand, now this fopen check is skipped.
What are the implications of this enhancement (beyond improving speed)? To me it sounds like there are scenarios where the additional fopen gives more accurate backup results. What are those scenarios? (the former fopen check was implemented for)
Just changes that happen during the current backup run?
Or does(did) using fopen also improve the accuracy of detecting changes that happened since the creation of a former snapshot? (before the current backup was started)
If the data to backup does not change during the backup run then there shouldn’t be any difference. (Except that restic won’t trigger changes to the last accessed timestamp of files).
If there are changes to files while the backup is running, then there’s a microscopic change in timing. Before the PR there was a sub-millisecond timing window between the initial lstat and the fstat after the fdopen during which restic would also detect file modifications which happen during that time window. But concurrent file modifications while restic tries to read a specific file are racy anyways. So the effective change is that we’ve simply exchanged one race condition for a slightly different one, but its still a race condition.
So unless you hijack the open syscall to modify a file when restic is about to backup it, you won’t notice a difference.