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

[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





reply via email to

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