Re: [rdiff-backup-users] (almost) real time rdiff

[Josh Nisly]

Adrian-Bogdan Andreias wrote:
> Hello,
>
> I'm trying to do (almost) real time rdiff-backup by using inotify 
> kernel API. More specific, (a modified version of) lsyncd.
>
> For this I think would need:
>
> - rdiff-backup on single file. Since I have the modified files list, 
> there no point for rdiff to scan directories and do check sums compare 
> and all in order to find out which files have modified. I'm surprised 
> this is not implemented in rdiff. Is there an architecture reason for 
> this? Are there any intentions to implement this?
Not that I know of. rdiff-backup is designed to mirror directories, and 
the code is designed around that.
> - have rdiff as binary executable and not as Python script. Since I 
> intend to run every cycle at every X minutes (or even seconds if 
> server is not loaded), there's no point in having the python 
> interpreter overhead. From what I've read, can you please confirm that 
> it's possible to compile rdiff-backup as machine code.
No, I don't believe that it is possible to compile python as machine 
code. You can make binary executables, but those simply package the 
python interpreter into the binary and run it from there. I really think 
that the python interpreter startup will be a pretty negligible part of 
the whole process.
> - disable compression encryption and any possible overhead on 
> rdiff-backup (will be used on a private link).
When operating over the network, rdiff-backup uses ssh for the transport 
by default, but any transport that can be executed and read/writes 
stdin/stderr would work. Netcat comes to mind, for example.
> What do you think about this process? Is this good idea? :)
With enough effort, you can make rdiff-backup do whatever you want, but 
I'm not sure that rdiff-backup is the best starting place. It has a lot 
of infrastructure you wouldn't need, especially if you want to only 
mirror specific files.
> Thank you
JoshN