Re: [rdiff-backup-users] feature requests and notes

[David Kempe]

----- Original Message ----- 
From: "Andrew K. Bressen" <address@hidden>

> (1) python errors are wonderfully informative compared to most
> environments these days, but not so easy to automatically parse.
> If rdiff-backup could spit some indicator at the beginning and
> end of each error stack, that would make writing log parsers
> much easier. I usually run at -v6; I don't know if running at
> a lower level would be more easily parseable. I have found this
> to be a useful level for diagnostics/bug reporting.

I may be embarking of enhancing/parsing the output of rdiff-backup with
either a perl script or changing the source.
Its been high on my list of things to do is eliminate the very verbose
errors and just note the [OS error 4] Can't access file, or something
similar. Mostly I am not interested in the python debug output for day to
day use. I know its another switch, but it makes long logs longer :)




> (3) in re space management by number of backup cycles instead of
> by dates, Ben said:
>
>   "Yes, it's a good idea.  How about if a new time specification was
>    allowed, so that '--remove-older-than 4B' would remove everything
>    older than the 4th Backup session?  It could be useful when restoring
>    also, e.g. '--restore-as-of 2B'."
>
> I thought of a new failure scenario that might complicate this syntax.
> If my daily backup scripts do a --remove-older-than 7D and something
> goes wrong with backing up, but not the remove, for 8 days, I could be
> in trouble. Ideally, a way to tell --remove-older-than to retain a
> certain minimum number of copies would be a safety, and I don't think
> the above syntax quite allows for that. Similarly, if one has been
> doing lots of tests and reruns one day, perhaps one would want to make
sure
> to have several days worth of backups around.
>
> Perhaps a --retain-at-least that also took
> <number> smhDWMY and <number> B args?

Thats a good feature request. I am sure Ben will ask for patches, maybe
shortly I will be in a postition offer some.
I am hopefully going to gain a developer for our usage shortly, and plan on
contributing to rdiff-backup.
The other push for us to help with rdiff-backup is we have a client
interested in a Windows GUI for rdiff-backup.
Does anyone else know of similar implementations of rdiff-backup or is
interested in such a port?

thanks

dave