Backup Central

A few new features this version. Next on my list is cleaning up some
rdiff-backup stdout/stderr (especially stack traces), which a few
people have requested, and making sure Mac OS X works (I think we're
getting close now).


From the CHANGELOG:

New in v1.1.1 (2005/11/05)
--------------------------

rdiff-backup now writes SHA1 sums into its mirror_metadata file for
all regular files, and checks them when restoring.

The above greatly increases the size of the mirror_metadata files, so
diff them for space efficiency, as suggested by Dean Gaudet.

Added two new comparison modes: full file (using the --compare-full or
--compare-full-at-time) or by hash (--compare-hash and
--compare-hash-at-time).

Applied Alec Berryman's patch to update the no-compression regexp.

Alec Berryman's fs_abilities patch is supposed to help with AFS.

Fixed filename-too-long crash when quoting.

Patched carbonfile support, re-enabled it by default.


--
Ben Escoto

Ben Escoto wrote:
rdiff-backup now writes SHA1 sums into its mirror_metadata file for
all regular files, and checks them when restoring.

I haven't had a chance to test it yet, but I bet that pounds CPU bound
boxes. I have quite a few of these and would love a way to turn this
feature off - is that going to happen? Happy to have it default - most
aren't CPU bound.

dave

David Kempe <dave < at > solutionsfirst.com.au>
wrote the following on Sun, 06 Nov 2005 20:11:17 +1100

I haven't had a chance to test it yet, but I bet that pounds CPU
bound boxes. I have quite a few of these and would love a way to
turn this feature off - is that going to happen? Happy to have it
default - most aren't CPU bound.

It would be possible to add the option, but I'd like to see some
numbers before deciding if the extra complexity were worth it.
rdiff-backup consumes a lot of CPU when dealing with small files, or
searching through files that haven't changed, and I would guess that
this new feature uses up the most CPU in the opposite circumstance,
when rdiff-backup is processing large files with lots of data to hash,
and so usually isn't CPU bound.

For testing, I think you may just be able to comment out the

self.sha1.update(buf)

line in hash.py. No file data will be processed by the hash
algorithm, so all your files will show up with the same hash of a
0-byte file.


--
Ben Escoto

Firstly, the GPG signature on your mail failed. Is the mail authentic?

Ben Escoto wrote:

From the CHANGELOG:

New in v1.1.1 (2005/11/05)
--------------------------

rdiff-backup now writes SHA1 sums into its mirror_metadata file for
all regular files, and checks them when restoring.

The above greatly increases the size of the mirror_metadata files, so
diff them for space efficiency, as suggested by Dean Gaudet.


Does the user have control over diffing the metafiles, with a new
feature? I thought you had decided against that, because it would make
the archive more prone to errors.

Wiebe Cazemier <halfgaar < at > gmail.com>
wrote the following on Sun, 06 Nov 2005 18:45:08 +0100

Firstly, the GPG signature on your mail failed. Is the mail
authentic?

Yes, although my mailer also thinks the signature is bad. That's
weird, I'm not sure what happened.

Does the user have control over diffing the metafiles, with a new
feature? I thought you had decided against that, because it would
make the archive more prone to errors.

No, in this version it's a mandatory feature. As for errors, I took a
compromise position. Firstly, rdiff-backup won't extend the string of
diffs longer than 9. So if you do a lot of backups your
mirror_metadatas will look like:

<snapshot>
<diff 1>
...
<diff 9>
<snapshot>
<diff 1>
...
<diff 9>
<snapshot>
...etc

avoiding the need for a string of diffs 100+ files long to be intact.
Since the diffs will probably be much smaller than the snapshot
(especially with the uncompressable sha1 info added), the snapshot +
diffs probably aren't much bigger than the snapshot. If the chance of
corruption is roughly proportional to the total size, then there isn't
much increase in total corruption risk.

Also diffs aren't written when the files are being incremented.
rdiff-backup will write the snapshot first, sync it, then as a final
step reread the snapshot, write a diff, and delete the snapshot. If
rdiff-backup gets interrupted, the regress step knows that if there is
both a diff and a snapshot, then the snapshot must be fully written
but the diff may have been interrupted.


--
Ben Escoto