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, <[email protected] > <mailto:[email protected]>> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
