Re: [Duplicity-talk] Non-integer mtime

[Peter Schuller]

> This may have to be marked as a bug if it becomes important to track.
> 
> I'm not sure how you would miss an update unless:
> 1) the update on that file happened as the file was backed up,
> 2) the update happened within one second, and
> 3) the file was not updated after that.
> 
> Kind of a small, very unlikely, scenario.

While considering writing Yet Another Backup Software I considered
this senario, and ended up concluding that I would keep track of the
fact that a file being backed up had an mtime that is equal to or
greater than the start of the backup.

If this was the case, this fact would be indicated in the archive
format. On a subsequent backup, any such files would be forcibly
checksummed rather than summarily skipped based on meta data (I was
planning a hash based backup method for dupe/diff handling).

I don't like to ignore the problem, and in fact I prefer this method
over the rdiff-backup one (of skipping the file entirely) since it
means you have *SOMETHING* in the event of a disaster even if the file
is consistently always being modified during a backup, while at the
same time you will *NOT* be permanently screwed if you happened to
take a backup the one time in a year when you were actually modifying
that important file (because the next backup would force a checksum
and update the file if actually changed).

The good bit is that duplicity already has checksumming in place for
the purpose of incremental backups, so perhaps it would not be that
much of a chore to make this work. I haven't checked the source for
it.

Thoughts? Other than dont-bother-just-juse-filsystem-snapshots ;)

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

pgpRZ_s7SsoHY.pgp
Description: PGP signature