Is there a way to "promote" a scheduled differential/incremental backup to full/differential if the last backup of that type failed?
To clarify what I mean: Let's say I have monthly full and daily incremental backups scheduled. After one month, I have a full and ~30 incremental backups. Assume now that the next full backup fails for some reason, e.g. the backup target is not accessible. What seems to happen now is that on the following day, an incremental image is appended to the first full backup. What I would like to happen is that a full backup is created instead, since the last full backup failed. Is this doable? (Ideally using the built-in scheduling mechanisms)
The problem is that otherwise any retention policy is potentially dangerous: If in the above scenario I have it set to retain full backups for two months (to always have at least one month of daily backups accessible), I will lose all daily backups after two months, since there is only one (two month old) full backup.

There’s no built-in way to do this. That would require Reflect to use the retention policy not just to determine when backups should be deleted, but also when new backups should be created, such as “If my newest Full or Diff is X days old, make a new one ASAP.”

If your scenario is a concern, you may find it preferable to specify your Full retention policy in terms of number of backups rather than length of time. You’ll need more storage since in your scenario one of your Fulls will accumulate an extra month of Incs, and when that Full ultimately does gets purged you’ll still be losing two months of backups rather than one as is normal, but you’ll at least have a minimum number of Fulls. Although I recently made the opposite switch for essentially the reverse problem. Prior to Reflect 7.3 that introduced Macrium Task Scheduler, I encountered a Windows Task Scheduler bug where my monthly Full would run on the day it was supposed to AND on the day before. This gave me an extra Full, which triggered early purging when my retention policy was based on number of Fulls. Switching to time-based retention at least avoided the undesired purge, although I haven’t had the scheduling problem since switching to Macrium Task Scheduler, so I may go back to quantity-based retention. The only other drawback is that if you want t create an extra backup for whatever reason, then that will affect a quantity-based retention policy when you might not want that, whereas it would not change anything for time-based policies.

As with many things in life, there are trade-offs with each of multiple choices.