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
He hooked his own analog-to-digital converter up to the read-head and post-processed the heck out of it to recover the data.
http://chrisfenton.com/cray-1-digital-archeology/
I'm perfect in every way, except for my humility.
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.
If you can find an old (pre-Symantec) copy of Norton Utilities, it's Disk Doctor (NDD) program was very good at recovering floppies.
Competition Good, Monopoly Bad.
Let me quote the part of the sentence that lead me to reply:
Are you too dumb to actually parse what you're reading, or are you too stupid to provide any solution at all while jumping on others simply trying to provide ideas?
Write a copy tool that fills in all possible bit combinations for the bad sectors and spits out 100s of zip files instead of just 1. At a max of 1.44MB/zip file, it still shouldn't be much space in modern terms. Then just try to decompress them all and see what the results are.
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.
Or just a good old oscilloscope?
what you need is an electron microscope and a few bottles of Tequila. In reality you don't need the microscope of-course, Tequila is enough.
You can't handle the truth.
This is a totally non-obvious trick that I came across this past year for mitigating binder failure
on floppies. Spray the surface with white board cleaner before you try to read them.
This should only be used as a last resort if you know that disks of a similar age and condition
shed rapidly, and obviously clean the heads before and after you try this.
"Magnetic media like tapes and floppies use a binder (glue) that becomes corrupted with moisture over time, allowing the metal-oxide particles to flake off."
This isn't actually the hydroscopic failure mode of 1/2" computer tapes. The tape becomes sticky and will glue itself to the head if the tape ever stops moving,
for example if the transport attempts to do a reread.
You need to bake computer tapes with a lot of airflow for the process to be effective. I have recovered thousands of tapes sucessfully this way.
This DOS based utility had the ability to control every little detail of the floppy drive's mechanism, it managed to read "most" of a bad track leaving just one or few sectors out, saved many floppies with that thing back in the day. http://en.wikipedia.org/wiki/HDCopy
-. wherever you go, there you are
I've recovered hundreds of floppies over the years. Here's what I've done to good effect.
(1) Find a machine with a floppy drive. If this machine hasn't had its floppy used in a while, either read/write a bunch of disks, or get it cleaned/aligned. I've opted for the former with good effect, but drives are getting old enough now that the former may be increasingly necessary. For older 5.25" drives, I'd definitely try to clean the heads, but be sure to do research so you don't grind the heads away by using the wrong methods. The reason I use the read/write method of a few disks that are new is that it gives you a chance to see if the drive is working on disks that don't matter. It might also allow you to have a minor cleaning effect from this to remove oxides from accumulated sitting time, but I'm unsure if that's what's going on. I have used different drives when the first tests failed, but never paid to have the broken drives fixed. There's just too many surplus floppy drives around. It might also help to have multiple drives.
(2) I have used both ddrecover and rescuedisk. The former is a gnu thing, the latter is included with FreeBSD. Both will incrementally read the disk and optionally write out data about what's been read. Both programs try to read as much data as possible in large blocks, then switch to smaller size reads for the damaged areas to try to get as much data off as quickly as possible with as few read-head passes. Having said that, often times there's a few stubborn sectors that just need to be tried a lot. For ddrecover, you may need to crank up the retry count to 1000 or more. rescuedisk does this automatically. I've had several disks that people have sworn are totally unreadable that I've been able to recover and placed in my hand to do something with. I've been able to recover most of them by retrying between 100 and 1000 times. When that fails, and it has in maybe 2 or 3 of the hundreds of disks I've done, I've taken the log files about what had been recovered to a different machine with a different drive and tried to read the (usually 1-4) missing sectors there. This hasn't failed me yet for disks that are hard to read merely because they are "old." My experience has been more concentrated on the 3.5" floppies than the older 5.25" floppies too. Different rules may apply there.
I guess I should caveat the above advice with "for disks that are just old". Disks that have been damaged over the years, or have had magnets run over them, etc all bets are off short of "extreme" options that might not even work.
Many of these techniques also work for reading damaged audio CDs, DVDs, etc.
I like to use ddrescue, not to be confused with dd_rescue - which is not as powerful. Note that if you use Debian, they have the names alllllllllll sorts of screwed up - search for gddrescue. Same with Ubuntu.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.