Adventures in PC-98, Part 02
So continuing on from last time... We now have the fated PC-98 HDD in our possession, and I should probably add a Disclaimer at this point...
So continuing on from last time... We now have the fated PC-98 HDD in our possession, and I should probably add a Disclaimer at this point...
I am not a data recovery expert or specialist. Below is the culmination of of tools and techniques that have worked for me in the past over many years and various devices...so without saying, should you wish to try any of this yourself, you do so at your own risk.
Right with that nonsense out the way, lets get started!
The PC-98 HDD in question is a fairly atypical Seagate IDE ATA133 HDD from the late 90's, nothing special or difficult there to deal with...however this is from an NEC machine, and whilst they are FAT16 based, they have a weird MBR and initial partition layout that is quite different from the IBM-PC norm from what I understand. At this point I know very little about the platform and its idiosyncrasies comparative the the PC standards we are accustomed to over here in the west, so this results in some strange reports from our tools later on.
Last we saw the drive was operating but reporting the normal “Abort/Retry/Fail” routine, so lets just throw it into a Linux session and see if we can dump the contents using “TestDisk”.
TestDisk will ignore the partitions tables on the drive and typically access them direct as long as it understands the file system they are formatted in, again trivial here since we know we are dealing with a FAT16 (or variant of) filesystem.
Oh dear....looks like we cant initialize the drive, also the drive spindle sounds like it cannot maintain a consistent speed, which makes me suspect we are dealing with ether corrosion or mould internally. So at this point we need to change tack before the drive inevitably gives up the ghost entirely...
Since we don't know the exact state of the drive at the moment, I find its usually best to just try and get a quick clone of the entire drive as-is (i.e no special tricks or attempts to move or restore sectors etc...) you can use tools such as DD for this typically, although I prefer to use Miray HDClone which tends to be a bit more verbose and doesn't care about the drives contents or formatting. For speed, we throw a basic 256gb SSD in the machine as a target device, and set it to work.
Thankfully, despite a number of sector errors mostly at the beginning of the drive, we manage to get a functioning clone and booting back into our Linux environment we successfully get a responding device.
Firing up TestDisk we can now access the partition, it does however complain about a number of geometry issues with the partition which we will see again later on, nonetheless we get a directory listing and proceed to dump the filesystem contents to our recovery systems scratch HDD.
Great! Looks like we have files and some can be accessed, so we have some data at least and a good clone to work from later.
At this point we have left the original HDD idling on power but not connected to the bus with the hope that the drive heating up and idling will free up any “stiction” that the drive mechanisms may have been experiencing earlier and causing our odd spindle RPM...
I decide to go for broke and reconnect the drive and attempt to re-boot into our Linux environment. Success! We boot and I can see our drive listed in the device tree, so as before we fire up TestDisk and strangely get the same geometry warnings from before? I had previously just assumed this was a result of a slightly corrupted clone (noting the sector errors) but now I believe this might be another example of the PC-98 drive and partition idiosyncrasies...since TestDisk only really understands MBR and GPT partitions on the IBM PC side of things (it can of course read SUN, HFS, and other table types). Nonetheless as before I can proceed to index the partitions and dump the file system.
So now we have two file-system dumps, lets see if we can try and bypass some of these sector read errors now we have a drive responding to commands
For this I decide to use a tool called DDRescue. This is another imaging tool, based on the DD command set, but with some useful extra features to help extract partial and damaged data where normally it would be bypassed or fail entirely.
One neat trick we can do is to read the drive in multiple passes and build up an image with the cumulative results, useful for sectors that fail on the initial try but then read on the second or third attempt. Also we can also opt to make a drive-pass in reverse, again presumably if we have data on a cylinder boundary or similar, this might allow us to extract a few more bytes of missing data.
Since we now have a co-operating drive for the time being we press on and image followed by dumping the filesystem onto a third folder on our scratch drive.
Great we do indeed get data, and comparing the filesystem dumps we have we do indeed seem to have captured a bit more on these passes...of course they may just be empty files or headers! Since we are feeling brave we repeat the process again but with a higher retry rate on read errors to try and get as complete dump as possible whilst the drive is alive.
Doing a compare of the filesystem contents at this point reveals very little difference so I reach the conclusion we are now at the limit of what we can recover using our tools.
Throughout the process we have been monitoring both the dmesg output and logs from the various tools at play and a consistent error we kept seeing reported from the drive and controller was a failure to re-allocate damaged sectors, which made be think could we possibly run a drive scan and force the controller to relocate some of our damaged sectors elsewhere on the drive from which we could extract the last remains of any missing data. I was skeptical of success but thought it was worthwhile to try at least... so I dug out a copy of SeaTools and fired it up.
Well it recognized the drive at least, and reports back the SMART data. However attempting to run a surface scan quickly fails with DRIVE NOT RESPONDING...Undeterred I fired up GWScan, another old HDD tool to try the same.
Alas, no luck, we successfully manage to start the surface scan but shortly into the process the software hangs, presumably with the same error.
So after all that effort, where are we?
Well after concluding this and some other minor experimentation with other tools that resulted in nothing further than what we achieved above, I packaged up all the data and drive images we collected and shared these with CTRL-ALT-REES, and of course promptly returned his HDD (just in-case he was short of a door-stop in his swanky new studio!).
After which I washed my hands of the whole thing and walked away....
Of course not! – but you'll just have to stay tuned here and on CTRL-ALT-REES YouTube channel to see what happens next!
(Spoiler) – Buyee melts my credit card in shipping costs...