I rebooted both my Mac and the Time Capsule, thinking it was one of its intermittent glitches. Nope, backups were still failing, so I connected to the Time Capsule disk from the Finder, and mounted the sparseimage disk image file for this Mac. The contents of that disk that appeared was not what I expected at all. It looked like the contents of the Rasbian boot disk.
I thought Finder must have been acting weird and showing me the contents of my SD card, I unmounted and ejected everything, physically removed the SD card, and reconnected to the Time Capsule disk and mounted the backup disk image again. Sure enough, Rasbian. My stomach churned.
When using the SD card builder app, I double-checked that I had selected the correct disk, so how could this have happened?
As part of the SD card writing process, it needs to be unmounted and repartitioned. I wondered if somehow the drive identifiers might have changed when my Time Machine backup started while SD card was unmounted.
I ran a quick test, where I mounted 2 different disk images using the command line -
hdiutil attach <diskimagefile>.sparsebundle . As you'd expect, the first image gets a disk identifier of
/dev/disk2s2 and the second is
/dev/disk3s2. So far so good, so I unmount them both, and repeat the command with just the second disk image. To my surprise, it got assigned
My best guess as to what happened, is that when the SD Card Builder app unmounted my SD card, Time Machine decided to start backing up and mounted the backup disk over the network, 'stealing' the disk identifier that was originally assigned to the SD card. Even though I had picked the correct drive identifier, it seems like the drives got swapped before the writing started, and when it did, it was done on the backup drive. This also explains why the app couldn't unmount the drive because, presumably, Time Machine was still trying do the backup, even though the partitioning and data had already been re-written.
Even though Finder still shows the file size of that backup sparse bundle as 490GB, which is over 6 months worth of backup history,
hdiutil attach <diskimagefile>.sparsebundle shows the partition type as Linux and cannot be mounted, and there isn't a Apple_HFS partition at all.
I'm assuming that disk image is good as gone and I won't be able recover any of that data since the entire partition map and file system has changed, so I'm deleting it and starting a new backup from scratch. I'm just glad that it wasn't my boot drive that got hosed.
Despite my best efforts in taking precautions, the app I used was not much more than a wrapper around the unix
dd command that writes to disk at a block level, and this is an incredibly powerful and potentially destructive command. The lesson today, boys and girls, is to eject all unnecessary disks, and disable any apps or tasks that might cause a disk to get automatically mounted (such as Time Machine or other backup/cloning apps) while you're working with low level disk utilities (especially those that repartition or reformat disks).