Data Recovery Techniques For Dead Zip Disks?

Lkmyst writes "Recently I had a Zip 250 disk die on me after the obvious channels were checked and found to be too expensive for a college student at $200US + I looked to see if there was perhaps another method I could use. A *nix dd looks like it might work but I thought I would ask slashdot to see if anyone out there has had luck with zip disks the drive no longer recognizes."

Comments

Spinrite

[iantri]

If you can read the disk at all, Spinrite may help you. It can recover data from any disk accessable to DOS, which includes Zip Disks (with the Iomega DOS driver), depending on the type of your Zip drive (I'm not so sure about USB drives, though there are some USB drivers for DOS).

Despite the bullshit on the Gibson Research website, it essentially repeatedly reads bad data and uses some statistical analysis to determine whether each bit was more likely 1 or 0, depending on which came back most often.

This page has some more information on Spinrite and Zip Disks.

If you can't read the disk at all, I think you are screwed. Sorry.

Re:Spinrite

[dasunt]

Despite the bullshit on the Gibson Research website, [the software] essentially repeatedly reads bad data and uses some statistical analysis to determine whether each bit was more likely 1 or 0, depending on which came back most often.

You should be able to whip something up with dd to do something similar. Make n number of dd images. Write a quick perl program to read through all the images at the same time, figure out if the bit at i position is more likely to be a one or a zero, and write the more likely bit to a new image file. Then mount the new image file as a loopback device, or copy it and try to run some file checkers on the copy.

Re:Spinrite

[fred fleenblat]

dd just reads sequentially and will probably just return the same garbage each time.

Spinrite tries reading stuff in different order each time so that the head momentum, and thus positioning, is a bit different on each read attempt. It then analyzes the data that it read and tries to figure out the whole thing (incl. parity, likelyhood of real world ascii data, etc) not just averaging the bits.

recoverdm

[flok]

Hi, You might want to give my program recoverdm a try. It is especially aimed at bad CD-roms, but is also usable for disks (harddisks/floppydisks/zipdisks). It repeatingly tries to read the sector and then uses statistics which outcome is supposed to be the most likely.

Re:Use your brain!

[Anonymous Coward]

When recovering from damaged media, it's not a good idea to start trying lots of things on the original. There may be a limited number of reads left. You should do your research first.

In this case, I would get a different, known to be good zip drive, and do a dd to get the whole image, and then try to work with just the image; only go back to the zip for a second read if you have to.

Define "die"

[Zocalo]

A little bit more specific please! Do you mean, the disk is suffering from the so called "Click of Death", or just that you can't get it to mount? If it's the former, then your best bet is to something like dd or SpinRite to try and pull as much data off the disk as possible.

However, if it's the latter then you may just have a scrambled partition table which I found was prone to corruption when moving back and forth between Windows and Linux. For some reason Iomega uses partition table entry #4, which I suspect was the root cause of the problem. There also seemed to be a change in geometry between some disks, maybe caused by a reformat or something, I never did figure that one out. Anyway, I eventually came up with the following commands to restore a 250MB ZIP disk to full functionality (change /dev/hd* to suit):

To recreate a valid partition table (you might want to check these values against a known good disk first):

sfdisk -f -q -uS -C239 -H64 -S96 /dev/hdd << EOF
0 0
0 0
0 0
32 489440 6 *
EOF

To avoid some funky issues on Windows which doesn't seem to accept garbage in the first sector of a drive you will probably need to follow that with:

dd if=/dev/zero of=/dev/hdd4 bs=512 count=1

And finally, you can create a pristine new file system with the command:

mkfs -t msdos /dev/hdd4

Obviously if you run the last one then you are not going to have any filenames or pointers left, but the actual data will still be there. In any case, you would certainly want to make a backup image of the raw disk with dd first if at all possible.

Re:Use your brain!

[mpmansell]

Well, what nice, well informed piece of sarcasm.

Maybe it would be a good idea to at least have some knowledge of the subject you're berating someone for BEFORE opening your mouth. You're less likely to get egg splattered.

The original poster did the right thing in asking first. I used to do data recovery and there are times when a media has a very limited physical life left. While less common than with old floppies, even modern magnetic media can suffer from the magnetic material seperating from the disk. If this is the reason for failure then blindly doing something in the hope that it may work could seriously reduce the chances you have for recovery later.

Perhaps you are aware of how much an ass you are by posting as an AC?