rsbackup can get "stuck" for days if there are a lot of old backups to prune

[pm215]

My backup strategy involves alternating between a couple of backup disks, which I periodically rotate offsite. This means that when I do a rotation, the "new" backup disk contains no backups from the past month or so, and then a lot of older staler backups from the period when it was last the currently-being-backed-up-to disk.

On the first evening after I swap backup disks, rsbackup will run a nightly backup. It then kicks off a prune-stale-backups process. Due to a combination of "I was a bit less frequent with my rotations than ideal" and "this disk is oddly slow at I/O", the prune-backups job has just taken 25 days to complete, deleting 356 old backups. During all this time no new backups were run, because the prune job had the lock on the backup system. When the pruning finally finished, all 25 nightly cronjobs ran one after another and I got 26 report emails all at once.

Some possibilities that might improve handling of this situation:

• Have a config setting for "don't bother pruning more than N old backups at once"; this would spread the pruning process over multiple nights rather than trying to do it all in one go on day 1
• More complicatedly, allow a backup job to interrupt or cancel an in-progress prune, rather than having to sit to wait for it to finish. Backups should take priority over housekeeping, unless there really isn't enough space on the disk for the backup at all.

(I am using rsbackup 3.1 because I'm still on Debian stretch on this machine.)

[ewxrjk]

You might want to look into a disk without a performance problem l-) But I do think that is a bug; pruning shouldn't block backups indefinitely.

My current thinking is to place a timeout on pruning, allowing a policy of e.g. "never spend more than 1 hour on pruning per invocation". Any outstanding rm subcommands would be killed when the timeout expires, and pruning would get to continue next time the cronjob ran.

[ewxrjk]

This is now implemented on the https://github.com/ewxrjk/rsbackup/tree/issue66 branch. @pm215 if you have time to test it and see if it meets your needs, let me know how you get on.