Re: [rdiff-backup-users] Atomicity of backups?

[dean gaudet]

ben you might want to study qmail's maildir and/or /var/qmail/queue
formats... which use directories/renames/etc. and need certain atomicity
guarantees.  (look for the maildir.5 manpage, and at the INTERNALS
file in the qmail source tarball.)

one thing which is different between linux and other unixes is the
behaviour of fsync() on the directory containing a file.  in most unix the
sequence:

        fd = open("/dir/foo")
        write(fd)
        fsync(fd)
        close(fd)

is sufficient to guarantee that the metadata for "foo" is written to
"/dir"  (in addition to ensuring that the data written to foo itself is
on disk.)  i.e. that you'll be able to find "foo" in the directory
even if a crash happens now.

that's not the case on linux... on linux you need also do this:

        fdir = open("/dir", O_RDONLY)
        fsync(fdir)
        close(fdir)

there's a huge amount of flamewar material surrounding this topic on
lists such as djb-qmail and linux-kernel :)

at any rate, this is just something to keep in mind -- your modifications
to filenames within a directory may not make it to disk until fsync()
of the directory itself.

i'm not sure what degree of atomicity i'd want to see in rdiff-backup...
'cause it sounds kind of complex.

this all seems so much easier for duplicity, doesn't it?  :)

perhaps the easiest answer of all is to say that if folks need automicity
on mirror updates then they should mirror onto filesystems which are
mounted on snapshot-capable volume managers.  take a volume snapshot
at the start -- perform the mirror update, and then delete the volume
snapshot.  if fatal problems occur then revert to the snapshot state and
the entire backup attempt will be discarded.  (hey this sounds pretty
cool!  yet another thing for my TODO!)

-dean