Join GitHub today
Entire backup fails when one path is missing #2919
I had c:\gedhtree_280 selected as one of my backup sources, and deleted it. I received the following error in my email home:
Steps to reproduce
I can rerun this with profile logging enabled if that is helpful.
@Pectojin noted that missing files can flow out of all your backup versions if you have some form of retention, which is a good point.
However, I agree that raising PARSEDRESULT to
I would rather have a backup continue to run (with some missing data) than stop running because one path is missing. While it is true that deleted data would eventually disappear from backups, I view it as my job (as backup manager) to keep an eye on logs and errors. If I set 30, 60, 90+ days as backups, then I have plenty of time to go back and recover missing data. But if I edited files today and my computer dies tomorrow morning, then under the current scheme, everything I accomplished today would be lost if I did not set the non-default allow-missing-source field, because the backup would have completely given up.
Erring on the side of caution is the safer bet when it comes to backups. We all maintain multiple days (or weeks, or months) worth of backups. The risk of a situation requiring recovery within one day is much greater than the risk that over some longer period we will fail to notice a big red "error" sign and an email that a path is missing.
The default behavior in my mind should be "back up as much as you can all the time" and "huge error message to admin if something is missing or goes wrong". Stopping the backup should never be part of the plan unless there is literally no retention plan, and then we're talking about snapshots, which are not backups (and should never be treated as such). --allow-missing-source=true should be the default behavior.
I have this error too. I highly agree that the default should be backups continue to run if a source folder gets deleted. If someone only does weekly backups, you could set them back an entire extra week by aborting the job. And everyone else would lose those revision-versions that they'll never be able to get back.
It is a great idea to record that event as a warning so that it is clearly visible in the job log, a popup in the web GUI, and most importantly, it gets emailed immediately to the admin. That lets the admin investigate the issue when convenient while still protecting the company's files. I think an "error" is too serious as it implies that something has malfunctioned in a bad way.
I suggest changing "--allow-missing-source" to "--abort-if-source-missing" as allow is probably the expected behavior.