Tried a couple of things further after going thru some posts and solved the problem with unchecking "put HD to sleep when possible" in the Energy preferences.
I never have this selected on my systems but it must have been checked by default after the sysem reinstall that triggered this problem.
However, it is curious that Apple allows this problem to occur. Since the OS know that TM is backing up to the external HDs (it's destination is selected in System Pref), and the Energy Pref is to put HD to sleep "when possible" - why is the OS allowing the TM backup HD to go to sleep when it is not possible to do so, since going to sleep obviously triggers this error of stopping the TM backup to allow the destination disk to be unmounted???
Seems a stupid oversight by Apple...
Michael Cucka wrote:
Since the OS know that TM is backing up to the external HDs (it's destination is selected in System Pref), and the Energy Pref is to put HD to sleep "when possible" - why is the OS allowing the TM backup HD to go to sleep when it is not possible to do so, since going to sleep obviously triggers this error of stopping the TM backup to allow the destination disk to be unmounted???
Time Machine backups do not require unmounting the drive, nor does putting the HD to sleep. I regularly use the energy saver option to sleep the HD's when possible & it has no effect on my Time Machine backups.
Your problem apparently is with the Drobo HD. See this article for more info, especially this:
"After upgrading to OS X Mountain Lion, Time Machine backups to Drobo FS/B800fs may encounter an error. We are investigating this issue, but restarting the backup may resolve issue."
Thanks, R C-R -
However, I've been running the Drobo with ML/TM since the OS release and never had problems until this past week with the OS reinstall - highly unlikely to be a Drobo problem now. The article you site lists a very specific Drobo model (FS/B800fs) and does not pertain to all Drobos (incl the model I have) - mostly lists Drobo Dashboard problems with ML.
I don't think I said TM requires unmounting the drive or putting the HD to sleep, as you mention. In fact, what was most likely happening in my case is the drives were being put to sleep, casuing the Console message that the backup was being stopped - then cancelling after the time out.
In my case, since the initial backup after the OS reinstall was over 600GB, the long period of time such a sizable backup takes probably got to the time period the OS put my HD to sleep. Certainly, smaller incremental backups would not take that long and so most users wouldn't have the problem I saw, as you certainly don't with routine automatic TM backups.
There were some occasional messages in the Console when TM was going thru the process, counting off GB copied, only to be interrupted by the "unmount" message. But, I only saw this once or twice in a dozen or so runs of TM while it was not performing so I never put the two together.
Regardless, by TM is working again after changing the Energy setting, so Drobo and TM work fine in ML in my setup once again.
Michael Cucka wrote:
In my case, since the initial backup after the OS reinstall was over 600GB, the long period of time such a sizable backup takes probably got to the time period the OS put my HD to sleep.
THe OS will not put the TM backup drive to sleep during a backup (or put any other drive to sleep during an access of its contents). In fact, since my TM drives are often in sleep mode at backup time, TM wakes them to do the backup.
That's what the "when possible" part means: drives are sent a sleep signal after a period of inactivity (& some do that anyway after a built-in period of inactivity, regardless of the OS setting) but they should wake up automatically anytime a data access signal appears on their port (USB, Firewire, Thunderbolt, whatever).
Appreciate that, R C-R
It seems, in my case, the fix only occurred with disabling the HD sleep option. And, I got that suggestion by doing a search of the Console message I previously noted and came across other postings about TM problems and that message that others were having and were fixed by the same method. So, not isolated to my setup.
Bottom line: my TM failure was corrected with disabling HD sleep - when nothing else worked over a span of days. Since I disabled that option in Energy, TM has worked without incident.
Your description certainly is how I would expect TM and the OS to work. But obviously that's not always the case.