Archive for Feb 5, 2007

Monday, Feb 5, 2007 [Tweets] [Favorites]

MacBook Pro Woes

I was excited to get a MacBook Pro in December. The new Core 2 Duo machines are very fast (having four cores wouldn’t matter much for what I do), have a reasonable RAM ceiling, have good external display support, and a 200 GB drive can, as Rentzsch says, hold me. (I apparently have more data than he does, but I don’t need access to different OS versions on the go, so I have those partitions on an external drive.) I thought the MacBook Pro would make a good main Mac, and I would no longer need to synchronize with a notebook, a process that had become more difficult now that my desktop and notebook had different processor architectures.

So far, the switch has been a mixed bag. I liked using the MacBook Pro, but after the first full day of use it wouldn’t turn on, even in target disk mode. The hard drive isn’t removable, but through my extremely good luck it died in the middle of a backup, after all of the changed files in my home folder had been copied. Apple replaced the logic board, and all was well.

About five days later, I started seeing various crashes and freezes while backing up. Sometimes even the Finder froze. After running various repair programs, everything checked out. I zeroed the drive, did a clean install, and that seemed to fix everything.

In mid-January, the freezes returned. DiskWarrior reported a disk malfunction. Drive Genius reported bad blocks. I did a 7-pass zero with Disk Utility, and everything started working again.

A few days later, I started seeing problems with LightScribe. It kept stopping in the middle of burning a label. Everything else remained fine, though.

At the end of January, I started seeing freezes again, but Drive Genius said the drive was fine, and DiskWarrior found only minor problems.

Yesterday, DropDMG reported an error while backing up a particular file, and I found that the Mac would freeze whenever it tried to read that file. I also found that numerous system fonts were no longer working.

Today I ran Drive Genius, and it found some more bad blocks. I decided to send the MacBook Pro to Apple. The guy on the phone was very nice and didn’t ask me to perform any additional tests. In retrospect, I probably should have given up on this drive sooner. He promised that Apple would replace the drive, rather than try to repair it. I’ve written down the drive serial number from System Profiler to make sure. It’s annoying that every time I call Apple they ask if I want to extend my AppleCare beyond the first year.

These problems have cost me time, but I don’t think I’ve lost any data. I’ve been careful to have both clones of my hard disk (made with SuperDuper) and archives of individual folders (made with DropDMG and cataloged with CDFinder). The former are essential so that I don’t waste too much time getting up and running again, and the latter are essential so that if I later find out that a file was damaged, I can go back and find an older version of it that’s not. My really important data is stored in either EagleFiler or Subversion, both of which can verify that the files have not changed since their last known good states. However, while this backup strategy has worked, I did learn some things and recognized the importance of others that I had been less sure about:

  1. You must have a recent clone of your whole drive. I didn’t always insist on this, but it’s such a time-saver. Even if you have backups of all your folders, it takes too long to copy everything back into place. And these days I depend on a lot of Unix stuff for development that’s scattered and thus not easy to backup or restore.
  2. You need SuperDuper and its Smart Update. I like to make complete clones—and for this you don’t need Smart Update or SuperDuper—because (a) I don’t want to depend on the integrity of files that weren’t recently copied, and (b) doing a complete clone is a good way to check that all of your data is readable. It helps spot problems sooner. But, you also need to clone regularly—more than once a day—and SuperDuper can complete a Smart Update while I’m having lunch. rsync is a possible alternative, but it’s still buggy.
  3. You must have a backup Mac that can boot from the clone. Even if your main Mac ends up not needing repairs, you need to be able to continue as normal while you’re checking it. Storage use has increased so much faster than storage speed that it’s easy to waste a whole day running a few disk utilities, re-formatting, and restoring from a clone—if you don’t have a backup Mac.
  4. You need at least two reasonably up-to-date clones. Clone A is newer, and that’s what you’ll switch to as soon as you discover a problem. However, you can’t restore from Clone A while you’re using it, since it’s not a good idea to copy files that are in use. And restoring can take up to four hours, even for a comparatively small notebook drive. So you need a Clone B that you can restore from while you’re using Clone A. Later, you can Smart Update the original drive from Clone A, and that will only take 20 minutes or so now that it’s been primed with Clone B.
  5. The other reason to have two clones is so that you can continue to have two clones. If you’re now using Clone A as your main system, then you only have one clone backup. In order to return to the state of having two clones, you need Clone B so that you can create Clone C while using Clone A.
  6. Software like Drive Genius is good for telling you when there is definitely a problem, but if it reports a clean bill of health, take that with grain of salt. Keep notes of any strange behavior so you can see if it recurs.
  7. Archiving DVDs off-site is a good idea, but you should also keep copies of the recent archive DVDs locally on a hard drive, so that you can access the data more easily.
  8. Notebook drives are slow. Really slow. It’s hard to really appreciate this until you use the same Mac with a different drive.
  9. No matter how silly I’ve felt making more backups than I would probably need, there always seems to come a time when I’m glad that I have them.