I've been having problems for a couple of weeks with my backup drives spontaneously dismounting part way through a backup. Sometimes I can restart the backup and it will complete, sometimes I can't. This may be an OS or connection problem rather than a Qrecall problem, but I'm mentioning it here in case you have any ideas or can tell anything about it from my report.

This has been happening with two different computers and two different backup drives, connected both directly and over wifi. In case both those drives were bad I bought a new drive and it has similar problems. When I tried to backup my MBP into a fresh archive on the new drive it ran for a while and the disk dismounted after backing up 87gb (of about 400 on the drive). I started it again and went to bed, hoping to add to the archive, and it stopped at 89gb. When I got up in the morning the archive showed up as 38gb in the finder, but when I tried to open it in qrecall that all disappeared and archive was empty. I ran it again today, and it quit with an archive that shows in the Finder as 89gb, but internally shows 1 layer containing 75kb incomplete.

As I'm writing this I think I remember you saying something to another user about a problem being caused by qrecall failing after using up all the empty space on a drive with temporary files, and I'm wondering if something like that could be happening here? If so, how can I work around it?

Any thoughts you have on this would be welcome.

Ralph

Ralph,

Sorry to hear you're having drive problems. Hard drive spontaneously, and inappropriately, unmounting can usually be traced to one of five problems:

Software (operating system)

Bus (computer/interface)

Bus (cable)

Hard Drive Controller

Power

Sometimes, very rarely, this can be an operating system or filesystem plugin issue. For example, OS X 10.8, 10.9, and 10.10 all had various problems with external drives using Firewire; it would occasionally eject volumes when the computer went to sleep. But again, these issues are atypical.

Bus problems are the most common. This can usually be traced to a flaky (USB, Firewire, Thunderbolt, eSATA, Ethernet) controller, the cable, or the physical connection. It might be the controller chip itself or the computer's motherboard.

Drive controller problems are also a possibility, although less common.

Finally, power can be the cause. Most external drive use simple transformers (unlike the switched power supply inside your computer) and are much more sensitive to drops in voltage. The likeliness that this is the problem would depend on how "clean" the power in your neighborhood is.

The typical technique for diagnosing these problems is "divide and conquer." In other words, you try to take each of these possible causes and eliminate or substitute them to identify the weak link.

For example, if your drives are connected via Thunderbolt, try switching to USB. Many external drives these days support multiple interfaces, so switching interface can help identify a bus problem. If you find the drive does not unmount when connected via USB, then you can go back to Thunderbolt and try a different cable.

If it's a motherboard issue, or if you don't have an alternative bus to try, the next step is to connect the drive to a different computer system. For example, you might set aside a weekend and relocate the drive from the desktop to the laptop and perform the captures in the other direction, intensively, for a day or overnight.

(If your external drive is unmounting for both local processes and shared computers via Ethernet, then the problem is probably local. Logically, a drive that unmounts locally will be unmounted for the remote user too.)

If it's a physical hard drive or HD controller issue, then swapping it out for another drive is the simplest test, which is sounds like you already did.

Finally, there's power, which can be difficult to diagnose without specialized equipment. If you have a UPS you can borrow, you might try that.

Additional notes:

QRecall does not control volume mounting or unmounting. The most any application (like QRecall) can do is to make mount and unmount requests to the operating system. It's up the operating system to mount and unmount the volume, and it should never unmount a volume that still has open files. So if a volume that's currently in use is getting unmounted, there is a (physical) problem somewhere.

QRecall does write temporary files during capture and those files won't get deleted until the next action or repair. So you may see an archive that has 90GB of data in it, but open it to find almost nothing. The next action (including verify or even just opening the archive) will invoke an auto-repair that will delete/overwrite these temporary files and recover that disk space. (You can open the archive package in the finder and watch this happen.)

But just to be clear, the space used by QRecall during a capture would never be the cause of a volume being unmounted. It would result in a "disk full" error, and the capture stopping gracefully.

As a workaround, you might consider setting up an incremental capture: create a capture action that runs every hour, but stops after 50 minutes. Every hour the capture will start, picking up from where it left off last time, and capture for 50 minutes. If it hasn't finished, it will then wrap up and commit whatever has been successfully captured so far. The next capture starts where the last one left off, but if it is interrupted only the latest capture will be lost when the archive is auto-repaired. You'll probably end up with a lot of unfinished layers (which can later be merged), but at least you'll have successfully captured your files.

The incremental capture was what I needed. I set that up yesterday afternoon on the MBP with the new backup drive, which had been unmounting partway through the backup each time. The first three incremental captures worked fine, then there were several failures with Qrecall reporting problems communicating with helper. Then around 10pm the incremental captures started working again and ran through the night without problems. I'm sending a report from the MBP.

My other backup drive is currently attached to the iMac, and the problems I was having with that earlier this week seem to have disappeared. My next step will be to move this drive over to the iMac and back that up, then go back to my usual routine of backing up the MBP over the network and keeping one of the backup drives off-site.