In case of a failing scheduled backup, communicate to the user that the backup will be postponed
Summary
For the case a scheduled backup fails, Deja Dup secretly schedules another one for the next day. This makes sure the backup still takes place and is a sign of the robustness of the application. However, this is done secretly and not communicated to the user, which leads the user believe Deja Dup is not going to retry backuping (this led me open #214 (closed), thinking Deja Dup wouldn't postpone backups).
Even with a better check if the backup drive is ready (like proposed in #217 (closed)), a scheduled backup being kicked off and failing has to be expected to happen in the real world. The network might break down not only in between the is_ready
check and the backup being started, but during the whole backup process, or the disk might be full, or something else the user could fix. In all these cases it would be helpful if the user knew that the backup is going to happen again the next day automatically.
Proposals on how to fix this
The implementation of this requires some communication to happen between the monitor service and the deja-dup application. However, these processes need to communicate about when backups happen anyway. If I'm not misstaken, this communication currently happens using the settings key LAST_BACKUP_KEY
(and re-calculating all other backup times from LAST_BACKUP_KEY as a synchronisation point and the settings). I'm not very familiar with inter-process communication, what the alternatives are and what the implications were, but if using settings keys for this kind of communication works so far, the monitor
could also store a boolean whether it scheduled a fall-back backup in the settings - the error window could read this boolean from the settings, and if yes, display the information that Deja Dup is going to retry to backup the next day.