duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

ken, Mike,

Any comments on the general copy/sync concept outlined below?

..ede

On 17.06.2014 12:00, Kenneth Loafman wrote:
> How about using the wrapper that Mike did for things like par for this?
> 
> As for the write command you mentioned, all backends need to be that way.  We could put a file in the cache that had the current upload state of all files.  We need to think about this some.  I'd like to see more async capabilities, but we seem to have users that run their systems at 99% disk capacity all the time.  Can't async if you don't have the room.
> 
> As for restarting, it's in class Restart in bin/duplicity.  We look at the manifest and go from there.  I'd have to do a deep dive to figure it all out again.
> 
> ...Ken
> 
> 
> 
> On Mon, Jun 16, 2014 at 5:08 PM, <edgar.soldin@xxxxxx <mailto:edgar.soldin@xxxxxx>> wrote:
> 
>     hi Ken,
> 
>     just thinking again about my idea to implement a
>      duplicity copy <srcurl> <trgurl>
>     and eventually a
>      duplicity sync <srcurl> <trgurl>
> 
>     these actions would be useful to horcrux (distribute) backup or even other data between backends.
> 
>     in order to successfully mirror/copy a repository i wonder how to best implement a save write command that ensures that the file landed on the backend. as we do not have a generic remote rename command, uploading a part file and renaming it after successful finish is out of question.
>     a journaled approach, placing a trigger file that signals a file is about to be uploaded, upload it and delete the trigger file afterwards seems a probably solution.
> 
>     here's the question:
>     how does the restarting you implemented know that there is an unfinished chain on the backend and at which volume it does have to resume?
> 
>     thx.. ede
> 
>