1) There is a setting in a Scheduled Task (the MS-default is Yes, but you can change it) to 'Run task as soon as possible after a scheduled start is missed'. You can find it on the Misc tab of SB's Schedule drill-down dialog (or on the Settings tab of
the underlying Windows Scheduled Task). If this setting was in place when you took your 'system backup dated one month ago', then it will of course be reloaded/remain the case when you perform a system Restore, and because it appears from the Task's own History that it last ran a month ago, it will take effect after booting (quite possibly 'immediately/unexpectedly')
You should note that this MS-defined option calculates its decision from Windows Task Scheduler's own Task History, not from any info stored by SB (though your system restore likely replaced any SB historical data anyway). So, SB did
not decide to run your profile,
Windows decided to run SB > your profile (subtle difference)
2) You didn't give details about your profile settings, but I would guess the top section of its Modify > Expert mode > Decisions - Files is set as '
Source overwrites Destination always (backup)''? Given that Source is usually where new/changed-content first manifests itself (because Source is where you do your work and save the results), this normally works 'as expected'. Unless, that is, you just changed the Source content wholesale to 'as of one month ago', and had agreed that your PC would start running SB > that profile as soon as possible/able after your PC thinks a run was missed - in which case in every instance where a file exists on both sides, the (old) Source file will win. Any instances of newer files on your external drive (that did not exist a month ago, so do not now exist on your Source) may - if your profile is set up as a Mirror - also be deleted, as part of the normal housekeeping of a Mirror profile
It's a little late now, but for future reference, simply unplugging the external drive during the first boot and allowing the late-start Scheduled run to Fail (because 'Destination unreachable') would have solved it (provided your very next move is to Restore the latest copy of the data)
Or, you could consider arranging things so you have a system disk and a data disk (or, with slightly less security, a similar concept using partitions), in which case you should find that a system restore doesn't also move your data 'back in time' in the first place...
Statistics: Posted by cliffhanger — Sat Dec 23, 2017 10:29 am
