[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Getting info about the backups
From: |
taintedham-mailinglists |
Subject: |
Re: [rdiff-backup-users] Getting info about the backups |
Date: |
Fri, 25 Nov 2005 01:12:56 -0800 (PST) |
> Can you use --compare[-at-time] to see how your
> current files differ
> from the backed-up files?
Thanks I'll check into that.
> To get around this attack, the devel version keeps
> sha1 checksums of
> all the regular files, and you can use
> --compare-hash[-at-time] to
> check those. This should be a more secure way to
> expose any attacks.
Ya, at this point... if the attacker was that clever
I'll miss it... but I think the majority of things
will change size ... and most attackers aren't that
smart ;) Thanks for the input though.
> Someone has started one at
> http://rdiffbackupweb.sourceforge.net/ but
> I don't know how usable it is.
Thanks for the link, but this looks a little simple
for my taste. I'm looking to make something a little
more full featured. I'd like to have visual diffs of
files and be able to browse the tree revision by
revision, backup by backup.
> Currently rdiff-backup doesn't use XML. I looked
> into using it for
> the mirror_metadata file but thought it was
> overkill. So far at least
> I'm satisfied with that decision. The
> mirror_metadata format can be
> considered pretty stable---I don't think you need to
> worry too much
> about it changing because I'd have to worry about
> all the existing
> repositories in the legacy format.
Is the mirror_metadata documented? and if so can I
get a link to that documentation? I'm assuming the
mirror_metadata format you are referring to is the
data that is written to the disk by rdiff-backup?
I was thinking that there was an interface in the
rdiff-backup program itself, that would read the
internal (maybe mirror_metadata) and have it stream
out XML for programs to parse the output. But if the
mirror_metadata is already well defined and not going
to change in the future I guess that will work.... if
there is some documentation somewhere on how to read
it. I was just thinking XML would be best because
most languages have ways of parsing it. [course you
can parse anything in any language :)]
But I suppose if we do XML output, we are really
re-developing the whole metadata formats...
Thanks so much for the input Ben... and thanks for a
wonderful tool.
--Dave Horner