Question #404018 on Duplicity changed: https://answers.launchpad.net/duplicity/+question/404018
nils posted a new comment: > Hi there, hey Nils, long time no read ;) Nils: Indeed, currently a huge amount of my spare time somehow ends up with duplicity :-) > I'm facing an interesting situation and I'm sure that I'm not alone: > I have a backup set that comprises way more data than what my internet > connection can handle within 24 hours (the set is about 200 GB and that > should take round about a week). > Unfortunately, my ISP disconnects my internet connection every 24 hours and > assigns me a new IP. And the backends that I've tried so far (SSH and > dropbox) cannot handle the closed socket (even though the internet > connectivity is back after a few seconds). > I tried quite a few things but in the end failed. So, I have some questions: > 1) Does it somehow harm the quality of the backup if I would start the backup > process over manually (or via the bash) 20 times? I don't find it a good > solution to resume the backup for so often but currently I see no other > option. I really would appreciate your opinion on that it shouldn't although resuming always contains a minimal risk, that wouldn't be there otherwise. i suggest you do regular verify runs to make sure that yur backups are in good shape. Nils: OK, I guess, I'll consider going this way then. > 2) Are there or will there be any backends that can hanlde such a situation? In principle, it's pretty simple. The backend "only" would have to start over authentication and reconnect completely in case of a permanent error (at least trying this in case of a permanent error would be very useful). not as such. resuming is only done on when duplicity detects a that the conditions are right to resume on a new backup run. however what backends can do is retry and you may finetune the retry behaviour via --num-retries . the delay is currently hardcoded as 30s in http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/duplicity/backend.py#L400 Nils: I already played around with the timeouts and the numbers of retries but that does not help as (with the forced disconnect) the complete socket is gone. The backends would have to go one step further and repeat authentication against the backend server but they don't do that :-( > 3) Is anybody here encountering the same problem and maybe found a different solution that I did not yet think of? probably. the usual workaround that is mentioned on the ml for issues like that is to backup to a local file:// target and rsync or use some other means to sync it to the backend of your choice. this way the backup process does not get interrupted by uplink issues. Nils: Yes, I read that. For me that does not work as it would consume disk space that I don't have :-( -- You received this question notification because your team duplicity-team is an answer contact for Duplicity. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
