As a final post, I also want to mention that using the approach of having scripts control whether the backup runs or not results in errors being thrown every time the backup is blocked from running. I can appreciate the logic to this, the script is blocking the backup from running by throwing an error, and the backup task reports this as an error.
However, an unwelcome side effect in my case is that the error reporting becomes useless. As I move around with my laptop, on some days there are no targets available, and on others only the network targets are present. On average, depending on my travel and workload, I’ll only backup to the fixed disks about once a week, which means I only get a “perfect” error-free backup run sporadically.
As a result this makes it difficult to detect when true errors occur with the backup. Don’t worry, my previous comments about the database errors being resolved by using the scripts still stands.
There is a thread here about giving the option to suppress warnings:
In my case, i would also like to suppress errors, since they are useless and distracting. The more complex implementation would be to allow the script to return at a level equivalent to either warning or error, and then with a suppression on warnings I would get the behaviour I desire. However, on balance, I would think that it’s not worth it so please don’t consider this to be a feature request (wrong place for it anyway, I know) more of a general musing on the topic.