>> $ duplicity full /dir scp://user@host1/dest scp://user@host2/dest
> scp://user@host3/dest
>
> yes this is the best way but it will require changes to duplicity it
> self. which I think will require far greater effort then a just a
> backend implementation.
I know, but it worth for the work.
>> - there should be an utility to check if all backends are in sync and synchronize them if needed.
>>
>> This is not really necessary if you are using the multi:// patch.
>
> But it is because now if the upload to the second backend fails next
> time duplicity start it will see that the file have been uploaded
> because it is available on the firs backend
I see. But this is only for the case of non-full backup. If you do full
backup, it doesn't matter.
---
Anyway, all this is very interesting feature which should be implemented
as soon as possible.
>> $ duplicity full /dir scp://user@ host1/dest scp://user@ host2/dest host3/dest
> scp://user@
>
> yes this is the best way but it will require changes to duplicity it
> self. which I think will require far greater effort then a just a
> backend implementation.
I know, but it worth for the work.
>> - there should be an utility to check if all backends are in sync and synchronize them if needed.
>>
>> This is not really necessary if you are using the multi:// patch.
>
> But it is because now if the upload to the second backend fails next
> time duplicity start it will see that the file have been uploaded
> because it is available on the firs backend
I see. But this is only for the case of non-full backup. If you do full
backup, it doesn't matter.
---
Anyway, all this is very interesting feature which should be implemented
as soon as possible.