* intrig...@boum.org <intrig...@boum.org> [2009-07-12 16:54-0400]: > Hi, > > martin f krafft wrote (09 Jul 2009 10:49:33 GMT) : > >> Any news on this bug report? With duplicity taking ages to encode > >> (on slow processors), I just came back from a trip to find five > >> instances competing for resources simultaneously. Not good.
I ran an experiment yesterday with duplicity. I have a large dataset to backup, and only had a 1Mbit/sec link to use. My calculations made me think that this backup would take 8 days at this rate. I figured this was a good chance to give this problem a test run, so I setup duplicity to backup the data and then started it off. At 1am, when backupninja was scheduled to run, the original backup was still running, and backupninja woke up: Jul 14 01:00:04 Info: >>>> starting action /etc/backup.d/90.dup (because it is everyday at 01:00) It then ran the cleanup: Jul 14 01:02:06 Info: Duplicity cleanup finished successfully. Jul 14 01:08:04 Warning: Duplicity remove-older-than failed. but it failed (perhaps because the original has not finished, so it cannot find anything to clean-up?) Then five minutes later, presumably after it attempted to run the backup part, it failed: Jul 14 01:13:40 Fatal: Duplicity failed. Jul 14 01:13:41 Fatal: <<<< finished action /etc/backup.d/90.dup: FAILED Jul 14 01:13:41 Info: FINISHED: 1 actions run. 1 fatal. 0 error. 1 warning. Looking at the process table, I see the duplicity processes that I started yesterday still running. So it is interesting to me that I didn't get duplicated duplicity processes running, as you did. Perhaps this is only a result of the fact that this is the original full-backup? If the full-backup finishes, and then incrementals start, and they take more than 24 hours to complete, maybe then I would see this problem? > Would the bug reporter and commenters be satisfied if we simply > replaced the backupninja call in /etc/cron.d/backupninja with > > lckdo /usr/sbin/backupninja > > It would hold a lock on the entire backupninja process, instead of > a single action. On the other hand, it would be implemented as > a simple one-liner unobstrusive patch that I volunteer to write and > commit upstream, rather than a brand new wheel^Wlock implementation > that still needs polishing and testing. I like the simplicity of this solution, but I'm concerned about the side-effects. For example, say the backup actions are a database backup and then the duplicity run. If lckdo is in place, and the duplicity run takes more than 24 hours, then the database backup becomes very stale. Rather than potentially loosing 24 hours worth of data, you could loose 48 hours (assuming that the *next* backup run actually succeeds). micah
signature.asc
Description: Digital signature
