Re: Live Fille System Backup
On Sat, 06 May 2017, tomas@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
Reply to: