21ab6a5bdb
* We now check for in-progress backups when asked to perform one, and don't bother firing off another one concurrently (nor do we adjust the scheduling; after all, someone asked to do a backup "now" and we're doing one, so we are in line with expectations). We also defer backup passes while a restore is in flight, and abort attempts to perform a restore during a backup pass. * When a backup attempt fails, we now ask the transport how far in the future we should put our retry. Previously we were simply not bothering to consult with the transport, so we would wind up retrying backup while network connectivity was known to be down, etc. Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90