Bored with receiving unecessary failure email messages, especially when out of office (i.e. when not in a position to remedy)?

To avoid unnecessary failure email messages when the target external hard drive is not plugged in, and to avoid potentially backing up onto the wrong device, could Reflect be updated to offer some alternative options, such as:
 
(A) instead of emailing a fail notice, email a “Please plug in the relevant external hard drive” message, or maybe allow a custom message? and
(B) not fail, but automatically try again tomorrow; or:
(C) not fail, but offer to defer by X hours (offering say a range of 15 minutes to 72 hours)

For (A), if the destination hard drive wasn't connected at the time the backup was scheduled, I absolutely want to receive an email notification about that immediately so that I have the option to fix it immediately.  That might make the difference between the problem being fixed before somebody leaves the building or not, for example. Additionally, if somebody IS there who can connect the drive, the job can always be re-run manually on the spot, so I don't see a benefit to having the original job sitting there waiting for a hard drive without telling anybody there's a problem.

For (B), the job will automatically try again at the next scheduled time anyway, but once again, why would you NOT want a notification that the previous attempt failed?  It DID fail, since nothing was backed up.  If I decide I don't want to do anything about that and instead just wait until tomorrow, then that's on me, but it would absolutely NOT be appropriate for Reflect to fail silently. After all, what if the system dies before the next scheduled backup and you only THEN find out that the most recently scheduled job didn't complete and Reflect didn't tell you about it, whereas if it HAD told you, then you might have run the job manually before the failure?  And how many times would you want Reflect to let the job fail silently before finally saying, "Hey, I'm just now telling you this, but your system hasn't been backed up for a while. Might want to look into that. Also, I bet you're relieved your system didn't fail in this window where no backups were running and I wasn't telling you about it, because that would've been awful, right!?"

For (C), if you're logged on when a scheduled backup begins, Reflect already throws up a prompt that allows you to defer it. That's true of V7 anyway, not sure about V6.

For your specific case, if you have remote access to your system, you can temporarily disable the scheduled task by going to the Scheduled Backups tab and right-clicking the task in question, which will suppress your notifications -- but obviously remember to turn it back on later.  Otherwise, just create a rule on your email to delete failure notifications while you're away, although once again obviously remember to undo that later.

I forgot to address the concern about Reflect backing up to the wrong device in my post above.  There are various ways to handle that.  The simplest solution if you only use one destination device (rather than a disk rotation strategy) would be to just manually change the drive letter on your destination to a letter far down in the alphabet. Your system will then remember to assign that letter to that drive each time it's connected, and the letter being far down in the alphabet means that no other device will be assigned that letter automatically. That can be done using the Disk Management tool in Windows, then just edit your definition file to use the new drive letter. This does NOT work for a disk rotation strategy because if you manually assign Disk 1 to "Z", then disconnect it, connect Disk 2, and assign that to "Z" as well, then disconnect it, Windows will NOT remember to assign "Z" to Disk 1 when you next connect it, even though Disks 1 and 2 are never being connected at the same time.

If you ARE using a disk rotation strategy, you can already configure Reflect to find destinations by their unique volume ID rather than their drive letter, so that the drive letter is now irrelevant for Reflect's purposes -- see screenshot below.  This would however require you to manually update your definition file if you ever switched to a new destination disk (or formatted your existing one) so that Reflect would start looking for that new volume ID.  Alternatively, you could use some other utility like USB Drive Letter Manager, which would allow you to ensure that the same letter is always assigned to any of your backup drives (as long as only one is ever connected at any given time), and once again if you select a letter far enough down in the alphabet, no other device should ever be assigned that latter automatically. That particular utility offers MANY ways for backup disks to be identified so that it can act on the appropriate devices.

I am grateful for your thoughts and observations, and appreciate where you are coming from.

I was prompted to raise this wish becuase I have previously had several backups scheduled to run with slightly different specifications on a Monday afternoon (or whenever), and so would often receive a sheaf of fail emails while I am out !

I have opted to designate external hard drives as S, L or whatever, so drive letters should never be a problem.

If there is no xhd connected, then there is probably no point in Reflect attempting the next scheduled backup(s) on the same day, because the result is bound to be the same!

Sometimes (perhaps a micro business or a single person at home), there may be no other person available to connect the xhd.

When I have subsequently run the backup manually, one has to manually start each one, rather than being able to restart the whole set.

It is a pity that it does not automatically try again when the pc is next turned on, rather than the next scheduled time. A fail notice and reminder message after log in would be helpful e.g. "A back up failure has occurred, becasue your external drive was not plugged in. Plug it in now, and try again?". If it could re-run the first failed backup, and then go on to complete the others due to follow on, that would be brilliant.

I did not know about being able to Disable scheduled backups; that is a most helpful tip that would be relevant when one knows one is going to be e.g. away on holiday.

Many thanks.

A few more thoughts based on your reply:

You're right that if a given backup fails because the target isn't available, then other backups are also likely to fail, unless somebody happens to connect the disk in the meantime.  But I'm not sure what you'd want Reflect to do differently here.  It's still worth Reflect trying to run the job in case someone DID connect the disk between those two jobs on the same day, and for the reasons I stated above, I believe it's appropriate for Reflect to communicate the failure of each individual job.  The only inconvenience that seems to result from your scenario is a few extra unwanted emails, but that seems a FAR lower potential impact than backups failing silently -- and again, it's easy to create a mailbox rule that filters those out.  If this is a fairly common occurrence in your use case, you could even SAVE that rule and simply disable and re-enable it as needed in order to spare yourself the "spam".

You can start multiple backups at the same time and Reflect will simply queue them for execution immediately after the active job completes.  To do this, go to the Scheduled Backups tab, right-click each job's schedule entry, and click Run Now.

The idea for a failed backup to retry the next time the PC is turned on rather than waiting for the next schedule window is an interesting idea, but that would be tricky to implement for a few reasons.  One is that Reflect relies on Windows Task Scheduler, which does not offer a feature like this.  It allows you to run a missed task immediately at logon, but not reattempt a failed task -- so for this to work, Reflect upon seeing a failed backup would have to create a temporary additional one-time task to re-run the job at next logon.  This feature would also raise other questions, such as:
- After the extra post-logon attempt, should Reflect ALSO run at the NEXT scheduled time, even if that might be only a few minutes after the extra attempt ran, or should it skip the next scheduled entry?
- What if the next scheduled occurrence arrives before the PC is restarted (and therefore before this temporary task will run) because the PC is kept running 24/7?  Now Reflect would have to remember to delete that now-unnecessary temporary additional task if the next occurrence succeeds, or keep it around if that next scheduled occurrence also fails.

And then of course this behavior couldn't be non-configurable, because there are others who specifically do NOT want their backups running at just any time of day.  Hopefully you can see that this adds a fair amount of additional complexity and potential for user confusion and implementation bugs, and the benefit seems slim at best. If you're already getting email notifications of failed jobs, you don't really NEED Reflect popping you a notification that your backups haven't completed in a while. You already know that, so you could just re-run the job manually yourself.