From the comment in the script, I think this was an attempt to ignore an
error about setting GIDs. The only place I saw that particular error
occuring in practice was for loopback-mounted isos on OS builders.
We shouldn't be backing those up in the first place! Exit code
23 is "partial transfer due to error" and so can be due to problems
other than failing to set GIDs

The script runs some SQL which ultimately determines the time at which the last
backup with an exit code of zero was. If there has never been a successful
backup, we ended up reporting a clear dot. Whilst this may lead to a few
transitory red dots immediately after adding a new host, I think this is
preferable to not realising for months that a host isn't being backed up!
See ticket 154527

For offline machines, use the time between last backup and last change of conn dot status to decide on backup status

Split logs for tasks with same target machine but different target filesystems into
different logfiles for easier debugging.

prepare-nondebian script creates a fake excludes file for the machine now if
one doesn't exist, because I keep forgetting to do it myself for Redhat
machines and then the zfs-rsync script fails.

Forcing arcfour causes us not to be able to back up jessie machines.