On Sat, 06 May 2017, to...@tuxteam.de wrote: > > 2. one or more components of a set of several files change *during* > > backup (files may be internally consistent, but the set of files > > itself isn't). > > Only the application can know that. But this is a realm where snapshots > won't help either, without the application's help. > > > In some cases, (1) and (2) can manifest as files missing from the > > backup, or being zero-sized. > > If I understood you correctly (2) won't produce empty or missing files, > just inconsistent application state.
If the application does delete-then-create, it is a race, you can hit it after the unlink but before create (file will be missing from the backup), after the create before any writing (file in backup will be zero-sized), or during writes (file will be incomplete). This is valid for (1) and (2). If the application does write-in-place (typical for mmap()), you get an internally inconsistent file, possibly incorrectly sized. If it does truncate-and-write, "possibly incorrectly sized" also includes the possibility of an empty file. Applications doing atomic replacement change this: you will get either the old or the new file or directory (application places the entire file set on its own directory). No race, there. And, finally, as you pointed out, rsync will usually[1] be able to notice when an inode changes behind its feet (i.e. while it is copying its contents). [1] I am not sure it can detect changes that are not reflected in the inode for whatever reason (e.g. because the writer reset all relevant inode metadata after writing). -- Henrique Holschuh
