View Full Version : Spinrite and ZIP disks?

January 18th, 2015, 07:01 PM
A few months ago while I was in the process of backing up a very valueable ZIP disk (it had a backup of my AutoCAD 12 installation, plus some other software I no longer have the complete install media for) either I fell victim to a Click of Death or my PC decided to burp the USB port again while my drive was on and the cartridge became unreadable. Total disaster. :(
I still badly need those files. Aside from confirming it WAS the cartridge by checking on my mac's ZIP drive and a spare USB zip drive (I got spare parallel and SCSI drives handy) I have not touched the cartridge. I simply couldn't access anything.

I've heard rumors that Spinrite 5 could recover the data but before I risk nuking the disk in another accident I need confirmation that it might work and if so, what type of interface was the ZIP drive attached to? I'm too weary of USB now. It's the first time in almost a decade that I've experienced any data loss. Of all goddamn times, DURING THE GODDAMN BACKUP!

January 18th, 2015, 08:32 PM
Spinrite claims to be able to do the repair on disks mounted in IDE and SCSI drives. If you have done the visual inspection of the disk* and ensured that it is not torn, there is little to lose by trying. My recollection is that a few people got lucky and were able to recover at least something from the disk.

* Iomega really recommended sliding the shutter back and rotating the disk around to check for any tears in the material. Wish they had used clear cartridges like SyQuest because that seemed like a great method to get enough dust to kill a working disk. Torn disks will kill your other drives and only specialized recovery services should make the attempt.

January 18th, 2015, 09:33 PM
The big problem with the Zip CoD was that it often mangled the drive as well, which, in turn, could mangle good disks, which in turn, could mange good drives.

In rare cases, a Zip cartridge with disk edge damage could rip off the heads in a Zip drive. The damaged disks could go on to damage the heads of any other drive they were used in. A previously good drive would click as if a mis-written cartridge had been inserted. Replacement drives had a warning about damaged ZIP cartridges on a peel off label and quick visual inspection instructions.

You might do best just reading physical sectors from the drive and saving them and see what you get. I'm not at all sure that SpinRite will fix anything on CoD-ed media. In any case, Linux 'dd" with the "conv=noerror" option might be your best tool.

January 18th, 2015, 10:14 PM
According to https://www.grc.com/tip/codfaq5.htm, the official position was:

"Our findings, and those of many happy users, have shown that just running our freeware "Trouble In Paradise" (TIP) utility with a healthy drive on a troubled cartridge will often completely remove all signs of damage and restore the cartridge's sectors to full health!"

Looking lower on the page is recommendation to use Spinrite to recover more data.

The related GRC pages go through the various failure modes for Zip drives and which can be recovered from and which can not. The odds of success are low but restoration of Zip disk data has happened. Zip disks suffer from click of death because of damage or because the special tracks are unreadable. Damage can't be worked around; special tracks can be ignored to get at the data.

January 19th, 2015, 09:06 AM
I was thinking of Steve Gibson's page also--but it's also a bit dated and I doubt that Iomega will do anything but laugh at someone complaining about COD on a ZIP 100 cartridge.

Understand that no tool is going recover lost data doing anything more than retrying the read a few times. And if your Zip drive is bad itself, you're only going to make the problem worse.

Good luck.

January 19th, 2015, 09:46 AM
A lot of what is on the SpinRite page sounds like snake-oil; his wording could be better or he could fill in some details.

Anything more advanced than a generic floppy diskette or an ancient ST-225 uses servo data written onto the media to help the drive position the heads accurately. The servo data may be on special tracks or embedded with customer data on normal tracks. On drives that use servo data the drive is always trying to read the servo data and using it to figure out precisely where the heads are at the moment. If the heads are slightly off the center of a track or on the wrong track the drive will detect this and then provide inputs to the servo system to move back to the correct place.

A problem with media that uses servo data is that most drives can't write the servo patterns. Which means if the servo pattern is damaged, that part of the drive where the damage is can no longer be used. The real world analogy is using street lights at night to drive and not having head lights; if the street lights go dark you will go off course very quickly because you probably can not stay centered.

The servo patterns can be damaged by head crashes that hit those spots on the disk or by bad data writes that overwrite the servo data. Drive firmware has to be very careful not to write over servo patterns and there are mechanisms in place to turn off the write head quickly if the head is not where it is supposed to be, both to protect your data and the servo patterns. But sometimes this doesn't work perfectly.

In the case of a Zip drive, the clicking sound is the sound of the drive trying to position the heads to retry a read that failed. One cause of a failed read can be a bad spot on the media. If it is in the customer data part of the media a format will take care of it. But if it is in the servo area then the drive can never effectively find the right spot to move the heads to. Which is why some Zip cartridges can be recovered, but others can not.

Physical damage to the media is a whole other problem. A Zip cartridge with a ragged edge can damage the heads when the drive tries to load the heads onto the media.

The servo data is the reason why you do not bulk erase anything except a generic floppy disk if you want to use it again. Once the servo pattern is damaged or gone, most media is useless. Most consumer grade equipment can not write the servo pattern, and this includes most hard drives (including high end SCSI ones). It is a trade-off between capacity and durability; servo systems using dedicated servo data are far more accurate and generally never need the low-level format that the ancient MFM drives needed periodically. But when you format one of them, you are just clearing the customer data portion of the media; the servo pattern does not get rewritten.

January 19th, 2015, 09:55 AM
Pretty much my opinion, Mike.

Spinrite isn't magic--if you have a marginal mis-alignment or "soft" error, but can recover the data via retrying, then rewriting the data will often clear things up--for the time being. But there's no silver bullet in the form of MFM/IDE/SCSI/ESDI software magic.

January 19th, 2015, 04:26 PM
So...use spinrite....but don't use spinrite because it won't work??

January 19th, 2015, 04:30 PM
So...use spinrite....but don't use spinrite because it won't work??

Who are you paraphrasing there?

I'd try it, but I wouldn't hold my breath. ddrescue under Linux is probably a better option.

January 19th, 2015, 05:31 PM
A Bit by Bit Image needs to be created first (by some Linux Distro - on another Drive, or an image file saved in Linux) so there isn't more corruption
to the Source Disk.

mbbrutman is correct about ddrescue. But, it needs to be the GNU version gddrescue, and that is going to really depend on the Linux Distro chosen,
because the naming convention really depends on the Distro's Repositories. In Debian it's named ddrescue, but it's the gddrescue GNU version as
shown below. It could also be just named ddrescue or dd_rescue, but the Version always gives the GNU version, if it's the gddrescue software.

larry@debian:~$ ddrescue -V
GNU ddrescue 1.16
Copyright (C) 2012 Antonio Diaz Diaz.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gddrescue (ddrescue) creates a log file that can be used to make multiple reads, in either direction, as often as required to recover
as much data as possible. Other Linux tools such as testdisk, photorec, and dd can be used on the created Image file.

I'd hold off running Spinrite until you have at least a valid bit by bit image of the source disk.

Is it a 100 or 250 Zip Disk? Was it FAT or FAT32 format partition? I've got a USB Zip 250 Drive available for use with Linux.

I've had similar problems with a USB Flash Drive, when I accessed it on a USB (Ver 1) port and then the Centon USB Flash drive was
trashed. I've since used only USB Ver 2 Ports with USB Devices. Could this have been the same thing that clobbered your Zip Disk?