[fadden-logo]

Recovering Data From an Old HDD

My wife had a pair of Macintosh Classic computers, one that used to belong to her mother, one that belonged to a friend. Both were used in the 1990s and then tucked away in a closet. She wanted to pull the data off of them, but never quite got around to it.

Fast-forward to 2022. We wanted to extract the data (and clear up some closet space), but it wasn't easy. The Classic has AppleTalk networking, which is a bit hard to use now, and a very good floppy disk drive, which would be slow but usable -- assuming all the moving parts still worked after being idle for two decades. Neither system was functional, so the most reliable way to recover the data was to pull it directly off of the hard drives.

I bought a torx screwdriver with a long shaft and cracked the cases open. Both machines had Quantum 40MB hard drives, connected by a SCSI-2 ribbon cable. I extracted the HDD from each, and we sent them off to a drive recovery place (Secure Data Recovery in Los Angeles, CA) to pull the files.

Secure Data was able to extract the files, for a mere ~US$1000 per drive, but I wasn't happy with the results. The files were made available in the cloud and on a secure thumb drive, which was nice. (The thumb drive is kind of cool: it has a tiny numeric keypad on it, and you have to punch in the correct code to unlock the encrypted data.) The problem is that the early Macintoshes used the HFS filesystem, and the recovery process didn't handle it as well as it could.

My first issue with the recovery process was the handling of resource forks. (Macintosh files on HFS volumes can have a "data" fork and a "resource" fork within a single file.) The recovered files only included the data fork. There's a separate folder with a giant collection of numbered files that might well be the resource forks, but with no way to re-attach the resource fork with the original filename they're not much use.

My second issue was the loss of the creator and file type information. Every file on an HFS volume has a creator and a type, e.g. Microsoft Word documents were MSWD / WDBN. Files didn't have extensions like ".doc" or ".txt", so if you discard the type information, it's hard to know what's in the file. To make matters worse, the secure thumb drive was formatted for a Macintosh, but used "UNIX executable" as the type for every file. So if you tried to double-click on a Word document, the system would try to execute it in the shell.

The Macintosh HFS filesystem was also used on the Apple IIgs, so the CiderPress utility is able to access HFS files. It can either read the drive directly, or open a block-level image (often labeled ".iso") of a drive. We asked Secure Data if they could provide such a file for each drive, and they said they could. We got the data back, but didn't find a file with the drive image. We asked again, and they said they'd look into it. A few weeks went by. We eventually gave up and just asked them to send the drives back.

When the drives eventually returned, I noticed that the warranty stickers were still in place on both drives, which means they didn't have to open them up to access the data. That meant I had an excellent chance of extracting the data myself, with one small issue: none of the computers in the house could interface with a SCSI-2 drive.

Speaking SCSI

The first hurdle you have to overcome if you want to read from a SCSI-2 drive is finding an interface card with a 50-pin internal connector. A quick look around the web suggests that these largely stopped being made in the early 2000s. They generally have a PCI interface, which doesn't fit into a PCI-E slot; most of the cards I found with PCI-E interfaces only had the 68-pin wide SCSI socket internally. You can find PCI-to-PCI-E adapters, but if it isn't a "low-profile" card then it's not going to sit well in the case.

Fortunately, I still have an older PC with a PCI slot handy, so I was able to buy a used Adaptec 29160 card from SCSI4ME for about US$60. (To give you a sense for how old this card is, the manual has a troubleshooting section for Win95/98.)

Next problem: getting the operating system to recognize the card. Driver support for all the parallel SCSI adpaters I looked at ended at Windows 7 or before. (If you're brave, it may be possible to make certain drivers work on Windows 10.) Fortunately, Linux is exceptionally good at interfacing with old hardware. So instead of installing an old version of Windows, I downloaded Ubuntu Linux onto a thumb drive and booted it. The "try Linux" option puts you into a fully-functional Linux system without having to install anything on your hard drive. The Adaptec card uses the AIC7xxx driver module, which is included in the system.

I shut the machine down, and connected one of the drives with a 50-pin ribbon cable and a Molex power cord (fished out of the modular power supply spare cable bin). When I powered it back up, the hard drive spun up, and proceeded to make some slightly unhappy noises. The drive sounded like it was slowing down and speeding up, and made occasional chirps like a sad cricket.

The Adaptec card has BIOS that appear while the machine is booting. If you hit Ctrl+A while it's on screen, you enter their configuration menu. I used that to reset the card to defaults, and then used the disk utility to see what was on the bus. Nothing. Hmm.

After some time passed and I power-cycled the system, the drive decided it was happy again and appeared on the bus. I booted into Linux to recover the data.

Data Recovery

Once on the Linux desktop, I noticed icons for the various connected HDDs and SSDs on the left side. Double-clicking on the HDD opened the drive, showing the Macintosh files in all their glory. Apparently the Linux installer also comes with HFS filesystem support — something neither Windows nor recent versions of Mac OS can handle without installing 3rd-party software.

Using the lsblk command, I found:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0   2.3G  1 loop /rofs
 [...]
loop8    7:8    0   284K  1 loop /snap/snapd-desktop-integration/10
sda      8:0    0   489G  0 disk 
├─sda1   8:1    0   549M  0 part 
├─sda2   8:2    0   488G  0 part 
└─sda3   8:3    0   526M  0 part 
sdb      8:16   0 978.1G  0 disk 
├─sdb1   8:17   0   549M  0 part 
└─sdb2   8:18   0 875.9G  0 part /media/ubuntu/Glob
sdc      8:32   1  29.9G  0 disk 
├─sdc1   8:33   1   3.4G  0 part /cdrom
├─sdc2   8:34   1   4.1M  0 part 
├─sdc3   8:35   1   300K  0 part 
└─sdc4   8:36   1  26.5G  0 part /var/crash
                                 /var/log
sdd      8:48   0  40.1M  0 disk 
├─sdd1   8:49   0  39.1M  0 part /media/ubuntu/MacintoshHD
├─sdd2   8:50   0  31.5K  0 part 
├─sdd3   8:51   0    16K  0 part 
└─sdd4   8:52   0   998K  0 part 
sr0     11:0    1  1024M  0 rom

sda and sdb are the SSDs I use for Windows, and sdd is the SCSI-2 drive.

You'll note that there four items under "sdd". This is because the hard drive actually has four partitions:

Extracting sdd creates a Macintosh-partition-format image with all four partitions. Extracting sdd1 creates an HFS volume with just the files.

I changed to the /media/ubuntu/Glob directory, which is where I stick large files under Windows, and issued the following command:

sudo dd if=/dev/sdd of=image1.iso status=progress

This means "copy all blocks from /dev/sdd to a file called 'image1.iso' in the current directory, and give me status updates while you work". The data was extracted at roughly 1 megabyte per second, so the whole process took less than a minute.

The second drive was even more fussy, but after power-cycling a couple of times it appeared and I was able to extract everything from that as well.

Tip: if you're having trouble getting a SCSI disk to appear, make sure it's visible to the BIOS (e.g. in the boot options or the SCSI adapter card utilities) before proceeding. Once in Linux, you can use lspci to verify that the adapter is visible. Use lsmod to see if the relevant driver module is present.

Viewing the Files

As mentioned earlier, CiderPress can handle HFS volumes, including those in multi-partition images. The program is designed for use with Apple II files, however, and has minimal support for anything Mac-specific. It can view both forks of the various files in limited ways, but doesn't really understand the Mac file formats. (The newer CiderPress II utility has better support for Mac files.)

cp-mac-sample

Both drives had documents in Microsoft Word format, with file dates in the 1990s. It turns out that Microsoft is very good about letting you access old documents from other platforms. I extracted the files with CiderPress by selecting them, using Actions > Extract, and clicking "Configure to preserve Apple II formats". That doesn't make much sense in this context, but really it means "extract the files without screwing with them". I un-checked "add file attribute preservation", which isn't useful here, and checked "strip folder names".

Once the files were extracted to Windows, I renamed them to have a ".doc" extension and double-clicked one. My 2021 version of Word opened it, but complained that it couldn't view the document unless I changed my security settings. I had to do the following steps:

With that done, the file opened, nicely formatted.

Thanks...

I got some helpful advice and pointers from this thread on comp.sys.apple2.

June 2022