limit incremental backup to list of changed files

Hi Thomas,

I'm pretty sure that this is not yet possible, but it is a feature that I have been considering for some time. There was some talk about it back in 2010:
https://mail.gnome.org/archives/deja-dup-list/2010-February/msg00004.html

I was similarly looking to provide a list of changed files from inotify or similar. It would make implementing real-time monitoring in programs that use duplicity much easier, too, for instance Bug #781428

It probably should be added as a feature request.

On 28.01.2015 20:51, Thomas Tanner wrote:
> New question #261358 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/261358
>
> Hi,
> I'd like to speed up incremental backups by using a list of created/modified/deleted files generated by fswatch
> http://emcrisostomo.github.io/fswatch/
>
> Is there a simple way to specify this file list?

no, currently not ;(

> AFAIK --include-filelist would delete all unchanged files from the backup in this case.
>

yes, it would.

usually the slow part with duplicity isn't the backup creation, but it's transfer to the backend. did you at some point compare backup times from the same source to either local file and a remote location, to get a feel?

problem is that duplicity is not really multithreading, so it waits for transfers to succeed and resumes scanning thereafter until it has enough diff for the next volume. the asynchronous option does tackle this, but only for one volume scanning, while the previous is still transmitting.

..ede/duply.net

Identifying the modified files might not be the most time consuming part,
but even scanning the whole directory tree of a large filesystem (e.g., find) may take a long time.
Using fswatch would give you the result instantly.