Troubleshoot and recover a Mac with a failed drive

Hard drives failures can happen to anyone, including Mac 911 columnists. A relatively new hard drive bit the dust, requiring days of work to get back to status quo ante.

My wife has a 2011-era MacBook Pro and was barely keeping space free on its original 512GB hard drive. An upgrade made sense, and for a machine of that vintage, the cost of a 1TB SSD seemed too high. We opted for an affordable hard drive. I used a USB 2.0 enclosure to clone the existing drive via Disk Utility while booted into Recovery, which left us with a backup (the original drive) and the newly cloned drive, which I swapped into the computer. We also updated an existing SuperDuper clone as an additional safety policy. (Disk Utility lets you clone and restore drives, a nifty hidden superpower in Recovery.)

This worked just fine for six weeks, until she started to receive errors while using her mail client, restarted, and had screens of Matrix-like text scrolling down. Very quickly, it appeared the drive was damaged, not just corrupted. How did I diagnose this?

• Zapping the NVRAM didn’t help.
• Starting into single-user mode worked, as did performing the fsck command-line function to make sure a drive was left in the correct state for booting. However, the same symptoms resulted when exiting into a full startup environment.
• The Mac could boot into Recovery, but Disk Utility couldn’t perform a repair on the drive, as it wouldn’t unmount.
• I could launch Terminal in recovery to use the diskutil program to force the drive to unmount, but Disk Utility would always wind up reporting that it was unrepairable.
• I used Target Disk Mode to mount the Mac onto another Mac to see if Disk Utility might be able to perform magic that way, and it also failed.
• Sometimes, even a failing drive can be duplicated, but it was in too bad a shape for that, whether through Recovery mode and Disk Utility or Target Disk Mode.

I purchased and installed TechTools Pro 9.5, which can create a bootable Mac system that includes itself. I installed that onto an SSD I had handy, and after running through basic diagnostics that confirmed the Mac was fine, I used its Surface Scan tool to see if it could identify whether bad blocks (unusable small segments) on the disk. Sure enough, it started reporting piles of bad blocks and then stalled. (That’s not great behavior for utility software that’s supposed to cope with terrible system problems.)

Fortunately, we had the six-week-old clone—and I was kicking myself for not having updated it more recently—and a CrashPlan backup that was up to date as of just moments before the system went bad. Between diagnosing and running tests, it took parts of a full day.

CrashPlan hiccups

Restoring also took about a day due to the unfortunately outdated and somewhat primitive controls still found in Code42’s CrashPlan for Home. While I’ve used CrashPlan for many years, the company has held off on updates to its home product for some time, and it just announced on August 22 that it will no longer develop this version. It will stop working in October 2018. I’ve gradually switched my backups to Backblaze; my wife remained on CrashPlan as we have prepaid service that hadn’t expired yet.

We had set CrashPlan to archive just documents and media, not the entire disk, but the CrashPlan restore operation reported over 500GB to recover, excluding a 100GB music library that hadn’t changed and that we’d offloaded to make recovery faster.

After examining the overage, it seems that CrashPlan doesn’t properly recognize the “hard links” that iPhoto and Photos share. Hard links are a special form of Unix file reference that allows a single file to be represented as existing in multiple places on a hard drive. When you use Photos to upgrade an iPhoto library, rather than copy the entire contents, the app uses hard links to point to files in the iPhoto library. Apple chose this route as it saves enormous space.

However, my wife had only launched Photos, which caused it to create an updated library, but hadn’t actively used it. We could remove it from the drive and the restore process. This eliminated over 100GB of files that needed to be downloaded.

CrashPlan also fails to check whether a file to be restored is identical to one already stored on disk. It can only overwrite a file (whether identical or not) or create another copy of it with a unique name. This seemingly defeats the point of restoring. Even with gigabit Internet, CrashPlan ran its restore from between 10 Mbps to 100 Mbps, slowing things down further. 

Ultimately, we got back to status quo ante after losing a few days of access and many hours to restoration work.

Be better prepared

In the future, we’ve resolved to make two changes:

• More regular creation of clones. SuperDuper lets you set a schedule, and you can just plug in a drive and let it run overnight (even though it might only take an hour or two). I have a drive permanently plugged into my iMac that makes a nightly clone, even as I also back everything up to the cloud.

• Switch to Backblaze, even if you’re currently using CrashPlan, given that its inadequate home software won’t be improved. Check out our review of Arq, a potential local (and remote) network backup, or match Backblaze with local Time Machine backups.

Ask Mac 911

We’ve compiled a list of the questions we get asked most frequently along with answers and links to columns: read our super FAQ to see if your question is covered. If not, we’re always looking for new problems to solve! Email yours to mac911@macworld.com including screen captures as appropriate. Mac 911 can’t reply to—nor publish an answer to—every question, and we don’t provide direct troubleshooting advice.