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

[Ben Escoto]

>>>>> "DS" == Dave Steinberg <address@hidden>
>>>>> wrote the following on Tue, 10 Dec 2002 14:33:06 -0500

  DS> Case (1):  I do believe that a 'mv' is atomic to the OS, but
  DS> groups of 'mv's aren't.  If I understand your explanation
  DS> correctly, the temp files are moved into position where the old
  DS> ones lived.  You might want to log their metadata (including
  DS> where they're supposed to go), in the event of failure and then
  DS> checkpoint it when its complete.  That seems reasonable, and not
  DS> so hard, to me.  Individual files would always be consistent,
  DS> and any leftovers can be picked up on the next run.

Yeah, probably a good idea, and it kind of fits in with the other
metadata stuff.

  DS> Case (2) seems moot, as a lack of data would prevent any sort of
  DS> roll-forward that you'd like.  If the files themselves haven't
  DS> been processed, why shouldn't you get half-new and half-old?
  DS> The new ones are guarenteed to be consistent by Case (1), and
  DS> well, the old ones are already consistent!

Although, as I just realized, since rdiff-backup doesn't discard old
information, any changes could be rolled back.  That way we could
avoid half-new half-old states.  Logging + rollback would give us, in
effect, full atomicity at the session level.

    Also I could get rid of the current checkpointing/"resume"
features which, although kind of slick, probably produce more
complexity than they are worth.


-- 
Ben Escoto

pgpdhMPOvxVLn.pgp
Description: PGP signature