Slashdot Mirror
Ask Slashdot: Recovering Data From 20-Year-Old Diskettes?
First time accepted submitter Zilog writes "The end of the 3.5-inch floppy and the disappearance of associated drives showed to me the need to backup the tens of diskettes that accompanied my youth. Carefully preserved, these diskettes have proved readable for the most part — while some are approaching 20 years old. However, some diskettes have shown surface defects in areas with compressed archives (zip). Any ideas on how to recover (as much as possible) these bad sectors?"
Find an old copy of norton disk doctor and use it to do bad sector recovery on those disks. I remember it working pretty well back in the day.
Now, be useful and go back 20 years to give him that advice.
"National Security is the chief cause of national insecurity." - Celine's First Law
If you can find one use a Superdisk to read a floppy. The heads are much more sensitive and narrow and can read ordinary floppies better than a regular floppy drive. I have used this to recover data from floppy disks that were old/worn.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Clean and align the drive first, before you screw up any (more) disks.
To give an analogy that kids now a days can easily understand, its like trying to insert an old fashioned flash drive into a USB port full of peanut butter. It might work, it might even work most of the time, but it'll work better if its clean.
Due to the digital capture effect or whatever, you might only need one dB more signal or one dB less noise to go from a sector having a read error somewhere every time you read it, to having an errorless read.
If you have way more time and/or money than you know what to do with, you break out the oscilloscope and align the drive to that individual disk/track. Yes this takes a lot of time and gear, but if you really gotta do it... Basically you align to best SNR on that individual disk rather than to an alignment disk. If the drive that wrote the disk was technically out of alignment, this will save you. If the drive that originally wrote the disk was in perfect alignment, then this is a waste of time.
At the very least, clean the freaking drive. Using kimwipes and undenatured pure ethanol on the heads. You drink some ethanol as a toast to the computing gods after success or failure, doesn't matter which, either way you're doing a shot or its bad luck and the next disk will shed its oxide for sure. Everclear is supposedly pure enough to clean drive heads, and supposedly its drinkable. All I remember from my only experience with everclear was yelling some lines from a cartoon and throwing up, and there are disks I have not been able to recover, so take my cleaning solvent suggestion with a grain of salt. Kimwipes are hard to explain and may no longer be manufactured, but they used to be like a dustless, lintless fabric q-tip, at least in concept, sorta. I don't mean they were like a q-tip in that they were of a certain dia, length, and color, but more the general idea of a perfect cleaning fabric at the end of a non-conductive stick.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
GNU ddrescue.
Please help metamoderate.
don't
Clever, but ...
1) an error inside a zip file (or any compressed archive format) means that any file inside the archive that is stored on the corrupted part of the disk is corrupted. Compare this to the situation without a zip file -- any file stored on the corrupted part of the disk is corrupted.
The rest of of the files in the zip file, the ones stored on parts of the disk that aren't corrupted, are recoverable.
Now, if the table of contents of the zip file is corrupted but the data itself is OK, then you can still recover the data, but it becomes more difficult -- and you'll lose the names of the files. Compare this to the situation where the directory data for the diskette is corrupted but the rest of the disk is fine -- same thing.
The only important difference between files stored in a zip file that are corrupted and files just on the disk that are corrupted here is that if there's an error in the middle of the compressed data in the zip file, that means the file is corrupt from that point on for a file compressed in a zip archive, but that only those blocks are corrupt in the case of a file just on the disk. Does it make a difference how much of the file is corrupt? Maybe. If it's a text file that can't be recovered, yes. But if it's an executable or some data file that just can't be loaded either way -- not really.
2) the zip archive means that the data probably requires less space on the disk. It may not have even fit on the floppy at all without compression. That alone is a pretty important reason to use compression in archives. If you can cram twice as much data on a single floppy -- you could possibly store it on two floppies instead, giving you a backup in case one floppy fails.
3) being compressed means that the file took less space on the disk -- therefore the odds of one of it's blocks becoming corrupt goes down similarly. (Assuming that just a handful of blocks have become corrupt. If the whole disk goes bad, you're screwed either way. Of course, with compression, losing an entire disk means you've lost even more data. But I'm not sure using 360 KB floppies rather than 1.4 MB floppies is really an appropriate data saving measure either.)
4) compressed archives almost always have checksums of some sort which will tell you if their data is corrupted. Of course, some archive formats that don't involve compression have checksums too -- but many don't.
It's very good to be able to tell quickly and programatically if your data has been corrupted.