rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ben Escoto
Subject: Re: [rdiff-backup-users] Atomicity of backups?
Date: Tue, 10 Dec 2002 09:23:48 -0800

>>>>> "NS" == Nathaniel Smith <address@hidden>
>>>>> wrote the following on Tue, 10 Dec 2002 01:31:28 -0800

  NS> Conceptually, it seems like you need something like journalled
  NS> commits, where after a crash it's always possible to revert to
  NS> the last-good-version.  Even just making a full copy of the
  NS> mirror directory before modifying it would be a good simple
  NS> solution, albeit somewhat hard on the disk space :-).  What does
  NS> it do now?

Well, there are two possibilies:  1) crash in the middle of modifying
one file, 2) crash in the middle of modifying the directory as a
whole.

    For 1), the strategy is to try to not make this any worse than 2
in general.  So rdiff-backup writes new mirror files and increments to
temp files, and then moves them both into position right after
another.  However, there is a (fairly small) period of
vulnerability---if a hard crash happens right in between, then data for
that one file could be lost.  The temp files would still be there, but
manual recovery might be necessary.

    For 2), the directory is still in a consistent state as far as
rdiff-backup is concerned, but it may not be the state of the source
directory at any particular time (it really isn't anyway though, since
the directory can get modified while rdiff-backup is working).  So if
a session crashes halfway through and you try to restore to that time,
the first half of the restore will have new files, and the second half
will have older files from the last successful session.


But now that you mention it, and I am thinking in those terms, that
journalling stuff sounds like a good idea (especially since, as I
mentioned before, new metadata stuff is going to make this harder).
So I guess the basic idea is I write what I'm going to do to a file,
and then do it, and the next instance reads the file and sees when the
crash happened?  Do I have to keep flush()ing the file then?  In
practice does this make things much slower?  If anyone has any opinion
on whether journalling would be appropriate here, or wants to point me
towards some basic information on the topic, that might be useful.


-- 
Ben Escoto

Attachment: pgp2fDAsQQQ0I.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]