Very Computer

Hi,

I need to get a SCSI DAT drive for making backups from a Novell server,
a Novell client (OS/2), a Sequent running Unix and a NeXT running
NeXT OS (BSD).

Can anybody recommend a reliable machine ? Are there different recording
formats or are all DAT backups compatible with each other (assuming the same
backup software is used).

Please respond by e-mail, I will summarize if there is any interest.

Thanks for any info, Ernst.
--

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

One of the most widespread machines for any(?) platform is WangDAT 2Gig DAT. They also have
got another machine with hardware compression, allowing You to store 2-8Gigs on a tape (4-5Gigs
is the most appropriate amount). WangDATs exists as internal as well as external SCSI-units.
    Cheyenne Software has got backup-software for Novell NetWare and they have got 'agents'
for a variety of platforms, including DOS, OS/2, Macintosh, SCO UNIX, Interactive UNIX and
Solaris UNIX. The agents let You take backup on the machine the agent resides on to the
tape on the NetWare-server. You can also take backup on other Novell-servers on the network.

A WangDAT 2 Gig SCSI is about $1500 and Cheyenne ArcServe for a 50+ user NetWare-license is
about the same. The agents are about (slightly varying) $400 each.

As far as I have experienced 4mm DAT is a standard shared by many manufacturers with no
compatibility problems.

Regards,

        I'm  creating a dbase file by using vi. I need to insert a ASC(253) and
asc(252) as the data delimiter for the dbase file. Could somebody please help me on that? Thanx in advance!

Barry

I would discourage from using drives with HW compression.

   1. The HW compression is violating the compatibility to other vendors,
      but the pure DDS format is compatible.

   2. You can still use the LZW compression (gnutar ?).

   3. The multiple Gigs on one DAT cassette sound attractive, but the feature
      can turn into a horror, when the tape would fail to read at all (the
      problems with DAT/DDS tapes happen -if at all- mostly at the beginning
      of the tape). Probably it is better to loose *only* 2 Gigs instead of
      5 or 8 ? :)

   4. The price of the DDS cassettes is low, so the 2 Gig per tape is still
      the great achievement.

Of course, people with several Gigs of HD attached to the system may see it
differently.

Quote:>A WangDAT 2 Gig SCSI is about $1500 ...

It is the question of taste, but I would prefere HP DAT for about $1200 or
drives based on Archive's great mechanism (again about $1200).

Quote:>As far as I have experienced 4mm DAT is a standard shared by many
>manufacturers with no compatibility problems.

ONLY WHEN WITHOUT HW COMPRESSION !!!

        -Z.

Quote:>    I'm  creating a dbase file by using vi. I need to insert a ASC(253) and
>asc(252) as the data delimiter for the dbase file. Could somebody please help me on that? Thanx in advance!

>Barry

I think "vi(1)" on NeXT is not capable to save non-ASCII characters. Some UNIX
systems had extended their version of "vi(1)" (or rather "ex(1)") to work with
8-bit character set (e.g. the HP-UX).

1.
You can put instead some unique characters into the file, and then translate
them into your characters using the "tr(1)" utility.
For example, edit your file and put at appropriate places the ^B and ^C instead
of ASC(253) and ASC(252) (you add the ^B pressing ^V^B while appending, etc.).
Then you type:

        tr '\002\003' '\253\252' < your_file > another_file

and all ^B will be translated into ASC(253), etc.

2.
If the special characters ar at the end of the file, you can append them with
B-Shell echo:

        sh -c 'echo "\0253\0252\c"' >> your_file

The "\c" was added to avoid the newline (if appropriate).

3.
Some people would advice to switch to emacs, but it is a "religious" subject.
I use "vi".

        -Z.

I disagree.  While I don't have a DAT drive that supports compression (they
were not available without a hefty surcharge at the time I bought my DAT
drive), I think it is generally good to have.

Quote:>   1. The HW compression is violating the compatibility to other vendors,
>      but the pure DDS format is compatible.

This was the case at one time.  There is now a common, industry
standard for DDS DAT compression.  The only interchange issue now is
if the "other" drive does compression or not.

Quote:>   2. You can still use the LZW compression (gnutar ?).

Why use your CPU to do the compressions when you can use the one on in
DAT drive and get better throughput?  DDS DAT compression is transparent, and
you can still do random seeks around the tape and be completely ignorant
of the compression that's going on.

Quote:>   3. The multiple Gigs on one DAT cassette sound attractive, but the feature
>      can turn into a horror, when the tape would fail to read at all (the
>      problems with DAT/DDS tapes happen -if at all- mostly at the beginning
>      of the tape). Probably it is better to loose *only* 2 Gigs instead of
>      5 or 8 ? :)

So use software that keeps track of what's on the tape.  You can still*
yourself either way.

Quote:>   4. The price of the DDS cassettes is low, so the 2 Gig per tape is still
>      the great achievement.

Hey, when I buy a 1.2 GB disk to add to my 100MB internal and 600MB
fujitsu external, I'm sure that I'll wish I had compression.  If you
are using tape software that can manage multiple data sets per tape
effectively, you can use that extra capacity.

Quote:>Of course, people with several Gigs of HD attached to the system may see it
>differently.

I hope I have this problem soon..

Quote:>>A WangDAT 2 Gig SCSI is about $1500 ...

>It is the question of taste, but I would prefere HP DAT for about $1200 or
>drives based on Archive's great mechanism (again about $1200).

You can get an Exabyte (yes!) 4mm DAT with compression for $1139.  We
beat on one for 3 days during NWE and it held up great.  I personally
own an Archive Python drive.  They are getting cheaper.

Quote:>>As far as I have experienced 4mm DAT is a standard shared by many
>>manufacturers with no compatibility problems.

>ONLY WHEN WITHOUT HW COMPRESSION !!!

Again, not any more.  There is a standard for DDS DAT compression.
Make sure you get it, and not the proprietary compression that was (I
believe) used in the WangDAT DAT drives that had compression.  The
newer WangDAT drives now use the standard DDS DAT compression format
and should be interchangable.

Louis Mamakos

No, this is not a question of a contents on the tape. Resonex (where I work)
is using DATs more than 2 years now and there are problems from time to time
with damaged DAT cassettes (I mean: after certain period of successful appends
and reads, suddenly you get media error at the beginning of the tape, and you
cannot read any file anymore). We (and our customers) use anly the graded
DDS cassettes, but still the problems show up from time to time.
And therefore I repeat myself: be careful with putting on one tape a huge data.
This is the reason, why I hesitate to use the drives with compression.
While the drives are standardized now (I have got a few letters from people
confirming the compression standards on DDS), one has a temptation to use
one tape for more backups, increasing the probability of crash.

Of course, having more than 1.2 Gig to save, one has no choice.
[..]

Quote:>>>A WangDAT 2 Gig SCSI is about $1500 ...

>>It is the question of taste, but I would prefere HP DAT for about $1200 or
>>drives based on Archive's great mechanism (again about $1200).

>You can get an Exabyte (yes!) 4mm DAT with compression for $1139.  We
>beat on one for 3 days during NWE and it held up great.  I personally
>own an Archive Python drive.  They are getting cheaper.

Exabyte has included a San Jose company R-byte some time ago, so the DAT drives
from Exabyte have not much in common with the original EXABYTE storage.

Quote:>[...]
>Louis Mamakos

        -Z.

This sounds more like a software problem--when you append, it writes a
new header at the beginning of the tape. If the write isn't done properly,
you get garbage, and suddenly everything is gone.

I have never trusted appending to a tape for this reason; if I have a
short dump, it still goes on an individual tape. Easier to track, easier
to handle, less probability of data corruption, and much less data at
stake--if one tape fails, you don't lose everything.

Append: Just Say No.

:-)

--

The Chairman of the Board and the CFO speak for SCI. I'm neither.
Hestons' First Law: I qualify virtually everything I say.

No, it is not about the user software problem. We are tempted to believe,
that rewinding the tape too many times, loading the tape anew many times,
causes too much stress to the tape. The appends go only after the logical
end of the tape, still - maybe - the firmware writes something at the beginning
of the tape regularly ?.
And when I say "too many times" it still means working with one tape during
only 3-4 weeks, say.

This is more or less what I wanted to raise prolonging this discussion:
DAT-technology is great, even improving, but eventual errors with handling
could cause lost of huge data.

        -Z.

Are you by any chance leaving the tape in the drive (and rewound) for long
periods of time? Both DATs and 8mm tape drives are helical scan, which means
that the heads as well as the tape are both moving. It have heard (and
beleive) that leaving a DAT or 8mm tape loaded in a drive (rewound) will cause
wear on the beginning of the tape. You would probably be better asking this
question in one of comp.scsi  (? I have that feeling there is something in
the middle of that ...), or comp.arch.storage. In either or both groups
you are likely to find people that make the drives and who could therefore
provide a better answer.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada

   >>>[...]
   >>>>>   3. The multiple Gigs on one DAT cassette sound attractive, but the feature
   >>>>>      can turn into a horror, when the tape would fail to read at all (the
   >>          [ ... ]
   >>>>So use software that keeps track of what's on the tape.  You can still*
   >>>>yourself either way.
   >>
   >>>No, this is not a question of a contents on the tape. Resonex (where I work)
   >>>is using DATs more than 2 years now and there are problems from time to time
   >>>with damaged DAT cassettes (I mean: after certain period of successful appends
   >>>and reads, suddenly you get media error at the beginning of the tape, and you
   >>>cannot read any file anymore).
   >>
   >>This sounds more like a software problem--when you append, it writes a
   >>new header at the beginning of the tape. If the write isn't done properly,
   >>you get garbage, and suddenly everything is gone.

   >No, it is not about the user software problem. We are tempted to believe,
   >that rewinding the tape too many times, loading the tape anew many times,
   >causes too much stress to the tape. The appends go only after the logical
   >end of the tape, still - maybe - the firmware writes something at the beginning
   >of the tape regularly ?.
   >And when I say "too many times" it still means working with one tape during
   >only 3-4 weeks, say.

   Are you by any chance leaving the tape in the drive (and rewound) for long
   periods of time? Both DATs and 8mm tape drives are helical scan, which means
   that the heads as well as the tape are both moving. It have heard (and
   beleive) that leaving a DAT or 8mm tape loaded in a drive (rewound) will cause
   wear on the beginning of the tape. You would probably be better asking this
   question in one of comp.scsi  (? I have that feeling there is something in
   the middle of that ...), or comp.arch.storage. In either or both groups
   you are likely to find people that make the drives and who could therefore
   provide a better answer.

Questions on DDS tapes might profitably be directed to
comp.periphs.scsi or comp.sys.hp. Kevin Jones of HP Bristol often
answers such questions at length.

   Peter Van Epp / Operations and Technical Support
   Simon Fraser University, Burnaby, B.C. Canada

Nils-Eivind Naas, ISAF, Oslo