3B1 Floppy backup advice
Dennis Lefebvre
is in daily use running proprietary application software and the other
functions as a spare. Whenever the current machine fails (typically
hard drive) I restore the latest backup to the spare machine, put it
into service, and replace the bad part in the failed machine.
This strategy has served us well for several years, but now the tape
drive is showing signs of failure. It still works correctly if only
one tape is used, but if an additional cartridge is required during
the operation the 3B1 cannot verify that the tape has rewound or if
the door is locked. I imagine this is a switch failure on the drive
because changing the cable and tape adapter board did not help. I have
purchased three tape drives via the internet, but none have worked
reliably and two places which thought they could service the drives
did not succeed.
I decided to make a complete floppy backup to see how unpleasant (120
diskettes) it would be. While formating diskettes on the spare machine
I archived some files to reduce the size of the backup. One file took
a very long time to write (several minutes). Afterwards I was able to
see the file on the diskette, but only once. Thereafter the drive was
unable to recognize ANY diskette. I then placed the same diskette in
the drive of the spare machine and not only was it unable to read it,
but thereafter it was also unable to recognize ANY diskette. The
probabilty of simultaneous failure of two drives seems tiny. My guess
is that the surface of the diskette deteriorated and fouled or damaged
the heads. I discarded that diskette and I have installed replacement
floppy drives.
Questions:
0. Does anyone have a working 3B1 tape drive that they would sell?
1. Is the built-in floppy backup the best system, or is there a
superior command line alternative? In particular I am concerned about
losing an entire backup if one diskette fails. (I am a computer user,
no programming knowledge. As a practical matter the alternative would
need to be something that is part of Unix 3.51m or available as a
downloadable executable.)
2. Any idea what caused the diskette drives to fail and how they might
be repaired? I tried cleaning the head with a Qtip and tape head
cleaning fluid, but no effect.
dennis
do...@72.usenet.us.com
> 1. Is the built-in floppy backup the best system, or is there a
> superior command line alternative? In particular I am concerned about
> losing an entire backup if one diskette fails. (I am a computer user,
> no programming knowledge. As a practical matter the alternative would
> need to be something that is part of Unix 3.51m or available as a
> downloadable executable.)
I would make a minimal bare metal restore set of diskettes, and do backups
via serial cable using Kermit to some other machine.
I used to do that via nightly cron.
--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5
DoN. Nichols
> As mentioned in another thread we have two fully functional 3B1's, one
> is in daily use running proprietary application software and the other
> functions as a spare. Whenever the current machine fails (typically
> hard drive) I restore the latest backup to the spare machine, put it
> into service, and replace the bad part in the failed machine.
Reasonable.
Note that the hard disk drive failure is often really a problem
with the connector between the power supply and the computer's system
board. If you have Cramolin, next time you have the computer apart,
spray it onto both connectors and work them together and apart several
times, then wipe the pins dry and re-spray with Cramolin again prior to
reassembling it.
If you don't have Cramolin, the alternative now made by the same
company is called DeOxit and that works pretty much as well.
Also -- while you have it apart, pull the power supply and check
the underside of the board to see whether any of the solder joints to
the power connector pins have turned to cold solder joints (look for a
frosted appearance instead of a smooth surface). If so, use a solder
sucker to remove the old solder (perhaps helping it to work by adding
some fresh solder to the joint to make it flow better), and then
replacing the solder with new solder. This may keep things working for
longer between rebuilds.
> This strategy has served us well for several years, but now the tape
> drive is showing signs of failure. It still works correctly if only
> one tape is used, but if an additional cartridge is required during
> the operation the 3B1 cannot verify that the tape has rewound or if
> the door is locked. I imagine this is a switch failure on the drive
> because changing the cable and tape adapter board did not help. I have
> purchased three tape drives via the internet, but none have worked
> reliably and two places which thought they could service the drives
> did not succeed.
Were the drives which you purchased of the same model as that
used in the system? There are a lot of drives which will accept the
same tapes but which won't interface properly with the 3B1's controller
card. (After all, it treats the entire tape as a big floppy disk, which
is one reason that it runs so slow -- it rewinds to check each sector
before writing the next. :-)
> I decided to make a complete floppy backup to see how unpleasant (120
> diskettes) it would be. While formating diskettes on the spare machine
> I archived some files to reduce the size of the backup. One file took
> a very long time to write (several minutes). Afterwards I was able to
> see the file on the diskette, but only once. Thereafter the drive was
> unable to recognize ANY diskette. I then placed the same diskette in
> the drive of the spare machine and not only was it unable to read it,
> but thereafter it was also unable to recognize ANY diskette. The
> probabilty of simultaneous failure of two drives seems tiny. My guess
> is that the surface of the diskette deteriorated and fouled or damaged
> the heads. I discarded that diskette and I have installed replacement
> floppy drives.
One failure mode for the floppy drives is the buildup of dust
and lint in the optical sensors which detect the write enable notch and
the index sensor. A blow-out with compressed air will work wonders in
this situation.
For that matter, it might be the problem with the tape drive
too, since they use similar sensors. Try a compressed air blow-out
there too, since you don't have anything to lose. :-)
> Questions:
>
> 0. Does anyone have a working 3B1 tape drive that they would sell?
Have -- yes. Sell -- no -- it is still in my main 3B1 system
used for reference work.
> 1. Is the built-in floppy backup the best system, or is there a
> superior command line alternative? In particular I am concerned about
> losing an entire backup if one diskette fails. (I am a computer user,
> no programming knowledge. As a practical matter the alternative would
> need to be something that is part of Unix 3.51m or available as a
> downloadable executable.)
Two questions;
1) Do you have an ethernet card in the system?
2) Do you have another unix system which is not a 3B1 -- say a linux
or BSD system?
If the answer to both is yes, get a recent version of gnu's tar
and use it to back up across the net. Gnu's tar has an option to write
to a remote system. Note that a remote system with a SCSI tape drive
which accepts the same tapes will put 600 MB on the tape instead of the
27 MB that the floppy tape system does.
> 2. Any idea what caused the diskette drives to fail and how they might
> be repaired? I tried cleaning the head with a Qtip and tape head
> cleaning fluid, but no effect.
As I mentioned above, look into blowing accumulated lint out of
the optical sensors. If you have cats, it builds up more quickly, but
without them it still builds up over time.
Good Luck,
DoN.
--
Email: <dnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
do...@72.usenet.us.com
> same tapes but which won't interface properly with the 3B1's controller
Convergent had different firmware from the rest of the world in the Archive
60MB QIC drives on the other platforms. I don't know if that was true for
3B1 drives or not. The firmware chip could be swapped out.
> For that matter, it might be the problem with the tape drive
> too, since they use similar sensors. Try a compressed air blow-out
> there too, since you don't have anything to lose. :-)
That's what I thought you meant in the paragraph about the floppies ;-)
IIRC, the EOT sensor and the BOT sensor were top and bottom holes, with
"you've gone too far" being top plus bottom holes. One of those dirty or
intermittent would be a bad thing. You might write 60/9 about 6MB (way
less in "floppy" mode), and then die, as the EOT wasn't found, but an
unexpected BOT was found. The tape's write enable was a hard switch, I
think.
> 2) Do you have another unix system which is not a 3B1 -- say a linux
> or BSD system?
Kermit would let that other box be any flavor OS, windows, Linux,
Mainframe, ethernet or serial.
> If the answer to both is yes, get a recent version of gnu's tar
> and use it to back up across the net. Gnu's tar has an option to write
> to a remote system. Note that a remote system with a SCSI tape drive
> which accepts the same tapes will put 600 MB on the tape instead of the
> 27 MB that the floppy tape system does.
I was never a fan of putting more than one backup onto a tape, so the size
doesn't matter much, compared to the little 3B1 drives.
You could easily go to a USB flash drive. The flash drives are cheaper
than QIC tapes. That would be true of remote tar or kermit.
Or a hot backup on the other system's disk, then copied off to CDROM or
something.
Dennis Lefebvre
> I would make a minimal bare metal restore set of diskettes, and do backups
> via serial cable using Kermit to some other machine.
Thank you, this has taken on more urgency because the tape drive has
now failed altogether.
I do use Kermit with a Windows PC for terminal emulation and to
interactively transfer individual text files. I'll need to learn how
to backup entire directory trees, and see how long the process takes.
Do you happen to know if Kermit will preserve Unix file links if
copied to a Windows environment and then restored to a Unix system?
Dennis Lefebvre
> If you don't have Cramolin, the alternative now made by the same
> company is called DeOxit and that works pretty much as well.
>
Thank you, Don, your comments are always helpful. I do now have some
DeOxit and will use it as you described on the machine that is
currently open. I have no experience with soldering, but I do have
spare power supplies and I can inspect the one is use and replace it
if it is deteriorating.
> Were the drives which you purchased of the same model as that
> used in the system?
Yes, all are AT&T branded drives with the same model number.
> 1) Do you have an ethernet card in the system?
No. Each machine is configured with the tape board and two combo
boards. This means we have five serial ports. Four are used (three
terminals, one printer), but one is free.
> 2) Do you have another unix system which is not a 3B1 -- say a linux
> or BSD system?
No, the PCs we use to emulate terminals are Windows 2000
> If you have cats, it builds up more quickly, but without them it still builds up over time.
We do have cats at home, but they don't like coming to the office <g>.
SDF Poster
install sz.c and use a terminal program with auto ZMODEM downloading. You
mentioned you are using Windows Hyperterm. I'm not sure if it can do auto
ZMODEM transfers. But basically, you could tar up groups of files or
transfer individual files with find -exec. That way it would at least be
automatic. Over 9600 you should be able to get everything critical in
a few hours, the entire system would of course take longer.
DoN. Nichols
> DoN. Nichols <dnic...@d-and-d.com> wrote:
>> same tapes but which won't interface properly with the 3B1's controller
>
> Convergent had different firmware from the rest of the world in the Archive
> 60MB QIC drives on the other platforms. I don't know if that was true for
> 3B1 drives or not. The firmware chip could be swapped out.
>
>> For that matter, it might be the problem with the tape drive
>> too, since they use similar sensors. Try a compressed air blow-out
>> there too, since you don't have anything to lose. :-)
>
> That's what I thought you meant in the paragraph about the floppies ;-)
> IIRC, the EOT sensor and the BOT sensor were top and bottom holes, with
> "you've gone too far" being top plus bottom holes. One of those dirty or
> intermittent would be a bad thing. You might write 60/9 about 6MB (way
> less in "floppy" mode), and then die, as the EOT wasn't found, but an
> unexpected BOT was found.
And very likely to have the tape wind past the end if the wrong
sensor is blocked. It *is* possible to re-thread the tapes, but it
requires care and studies of the tape path on a still good tape.
> The tape's write enable was a hard switch, I
> think.
Yes it was. And of course the holes in the tapes were protected
behind clear plastic, with a 45 degree mirror bending the light beams
from vertical (the illuminator) to horizontal (to the hole sensors).
>> 2) Do you have another unix system which is not a 3B1 -- say a linux
>> or BSD system?
>
> Kermit would let that other box be any flavor OS, windows, Linux,
> Mainframe, ethernet or serial.
Yes -- but the directory structure and the filenames might be
illegal on some of the systems. For example -- MS-DOS would not like two
dots in a filename or a filename which started with a dot, or any file
which had more than three characters after the dot. Also it is hard to
represent a 14-character filename on an 8.3 system like MS-DOS.
Linux would be fine, since it can handle the longer filenames which
later unix variants with the BSD FFS (something like 253 characters,
IIRC).
So -- for a non-unix system, it would be better to pipe the tar
or cpio output into a single file on the far end to hide all those
offensive filenames from the system. :-) This could be done through
kermit via serial to just about any system, or through rcp/rsh via
ethernet to another unix system. Not sure what would apply on a
mainframe. :-) Windows can handle the weird filenames, but might object
to how deep the directory tree is stacked.
>> If the answer to both is yes, get a recent version of gnu's tar
>> and use it to back up across the net. Gnu's tar has an option to write
>> to a remote system. Note that a remote system with a SCSI tape drive
>> which accepts the same tapes will put 600 MB on the tape instead of the
>> 27 MB that the floppy tape system does.
>
> I was never a fan of putting more than one backup onto a tape, so the size
> doesn't matter much, compared to the little 3B1 drives.
You never had one of the 191 MB Maxtor drives hung on a 3B1 I
guess. That gives you 160 MB of filesystem, or about six tapes for
backing up one disk (and perhaps only one filesystem).
> You could easily go to a USB flash drive. The flash drives are cheaper
> than QIC tapes. That would be true of remote tar or kermit.
Agreed -- but if you use kermit, pipe tar or cpio through it to
hide the unix filenames from the FAT filesystem. It may save
everything, but not retain the filenames unmodified, which could be
problems on restore. And it certainly would not preserve special device
files without a tar or cpio image.
> Or a hot backup on the other system's disk, then copied off to CDROM or
> something.
Again -- even CD-ROMs are better holding tar or cpio images.
I've had filenames corrupted in deep trees on CD-ROMs. Play with the
expanded version on CD-ROM if you wish once you have the whole image
safely preserved as a tar or cpio file.
Enjoy,
DoN. Nichols
> On Apr 1, 9:26 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>
>> If you don't have Cramolin, the alternative now made by the same
>> company is called DeOxit and that works pretty much as well.
>>
>
> Thank you, Don, your comments are always helpful. I do now have some
> DeOxit and will use it as you described on the machine that is
> currently open. I have no experience with soldering, but I do have
> spare power supplies and I can inspect the one is use and replace it
> if it is deteriorating.
And then find someone who does know soldering to refresh the
joints as I described. That way, you still have a spare drive or two
where you otherwise would have one fewer.
Hmm ... while you are at it -- you might try Cramolin/DeOxit
spray on the pins for the hard disk controller (WD1010), and the floppy
disk controller (WD1791 I think). This requires a bit of static care
while doing this to avoid zapping the chips -- especially in an air
conditioned space -- or a cold winter space.
>> Were the drives which you purchased of the same model as that
>> used in the system?
>
> Yes, all are AT&T branded drives with the same model number.
O.K. That should work, then.
Note that the 37-pin cable actually only uses 34 pins (IIRC).
All of the unused pins are at one end, so if you check conductivity of
the cable, don't worry if you find three pins together which are not
used.
>> 1) Do you have an ethernet card in the system?
>
> No. Each machine is configured with the tape board and two combo
> boards. This means we have five serial ports. Four are used (three
> terminals, one printer), but one is free.
O.K. This means kermit or uucp for transferring an image of the
cpio or tar file of the backup.
>> 2) Do you have another unix system which is not a 3B1 -- say a linux
>> or BSD system?
>
> No, the PCs we use to emulate terminals are Windows 2000
O.K. And you can't make them dual boot to linux so you could
use uucp between the systems?
>> If you have cats, it builds up more quickly, but without them it still builds up over time.
>
> We do have cats at home, but they don't like coming to the office <g>.
Ours will go anywhere they want. One used to climb up on top of
the 6'plus relay rack full of computers -- to enjoy the hot air from all
the computers -- until she knocked over a bunch of things (nothing
seriously damaged, including the cat) in the middle of the night, after
which she stayed off of that area. :-)
Enjoy,
DoN. Nichols
Kermit by itself won't, because the Windows filesystem won't
cleanly handle the unix filesystem -- especially links. But if you make
a cpio or tar image and pipe that through kermit to the windows system
and save it as backup.cpi or backup.tar, then that could be restored by
copying it back via kermit and piping it into cpio or tar. The 3B1 used
cpio for backups, so you could get some idea how they did that from
examining the scripts which did the backups. I would personally prefer
to get gnu's version of tar onto the system and use that to create the
backups.
do...@72.usenet.us.com
> Kermit by itself won't, because the Windows filesystem won't
> cleanly handle the unix filesystem -- especially links. But if you make
Cygwin will create hard links on Windows, and it seems to be acceptable to
Windows. I thought I read that it is an available feature in the FAT and
NTFS, just not exposed normally.
Recollecting a little better ... The backups I did routinely were to a
MiniFrame, both from a 3B1 and from a DOS/Windows PC. In this thread, I
was thinking of a Linux box being cheaper than buying a new 3B1 QIC drive.
You could buy a multi-GB USB external drive, dual boot Linux on it, leaving
your normal PC untouched.
> cpio for backups, so you could get some idea how they did that from
> examining the scripts which did the backups. I would personally prefer
> to get gnu's version of tar onto the system and use that to create the
> backups.
I recall in the 3B1 era that cpio was a friendlier tool than tar. I always
used cpio. Then "pax" came out. I was never successful getting rtar, or
some remote tar to QIC working in a Unixware environment in the mid 90's.
Somewhere in this thread, someone mentioned piping to kermit. That's a
key. You can recursively kermit down a file tree (copy /recursive) or if
you are going to tar, you don't want to build a tar image, you want to send
it to a kermit process in a pipe. tar cvf - . | kermit ---something.
DoN. Nichols
> DoN. Nichols <dnic...@d-and-d.com> wrote:
>> Kermit by itself won't, because the Windows filesystem won't
>> cleanly handle the unix filesystem -- especially links. But if you make
>
> Cygwin will create hard links on Windows, and it seems to be acceptable to
> Windows. I thought I read that it is an available feature in the FAT and
> NTFS, just not exposed normally.
Not exposed normally -- and difficult to get to for general
use, though cygwin will probably help with that. However -- what other
information is preserved and what is lost going from the 3B1 to the
Windows NTFS file system?
The question is more one of what happens when you try to restore
from that to the 3B1. It will lose ownership and permissions
information (especially SUID bits) which may be required for the backed
up software to work on the 3B1 after restoration. It is for this that I
suggest using either cpio or gnu's tar (much more powerful than the tar
which came with the 3B1).
> Recollecting a little better ... The backups I did routinely were to a
> MiniFrame, both from a 3B1 and from a DOS/Windows PC. In this thread, I
> was thinking of a Linux box being cheaper than buying a new 3B1 QIC drive.
> You could buy a multi-GB USB external drive, dual boot Linux on it, leaving
> your normal PC untouched.
Agreed! The linux would preserve the various unix features as
needed.
>> cpio for backups, so you could get some idea how they did that from
>> examining the scripts which did the backups. I would personally prefer
>> to get gnu's version of tar onto the system and use that to create the
>> backups.
>
> I recall in the 3B1 era that cpio was a friendlier tool than tar.
I frequently used tar on the 3B1 -- but by choice, the GNU
version of tar, not the one which came with the OS.
> I always
> used cpio. Then "pax" came out. I was never successful getting rtar, or
> some remote tar to QIC working in a Unixware environment in the mid 90's.
While I used gnu's tar in rtar mode to back up to a QIC-60 drive
on a Tektronix 6130 via the net. One thing to beware of is using too
large a blocking factor. Many systems of that period had a hard limit
of just below 64k per block -- thanks to limitations in the controller's
ability to perform DMA. Select a block size of precisely 64K and you
will get a *very* quick backup -- but there will be nothing to restore.
Exceed that and you will have similar problems.
> Somewhere in this thread, someone mentioned piping to kermit. That's a
> key. You can recursively kermit down a file tree (copy /recursive) or if
> you are going to tar, you don't want to build a tar image, you want to send
> it to a kermit process in a pipe. tar cvf - . | kermit ---something.
>
Exactly -- and at the far end save that as a single file with a
".tar" or a .cpio extension. Remember that cpio does a very good job of
feeding to a pipeline -- but be sure to use the options to use ASCII in
the headers instead of binary so it can be extracted at need on systems
with other endian architectures and other sizes of integers.