home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.dec:4483 comp.os.vms:13567
- Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!cmcl2!rlgsc.com!gezelter
- From: gezelter@rlgsc.com
- Newsgroups: comp.sys.dec,comp.os.vms
- Subject: Re: DUPLICATING TA90s ???
- Message-ID: <1992Aug12.063129.197@rlgsc.com>
- Date: 12 Aug 92 06:31:29 EST
- References: <2AUG199222003642@ariel.lerc.nasa.gov> <1992Aug4.124921.435@ultb.isc.rit.edu> <1992Aug7.162256.189@rlgsc.com> <1992Aug11.123646.20532@ultb.isc.rit.edu>
- Organization: Robert Gezelter Software Consultant, Flushing, NY
- Lines: 68
-
- In article <1992Aug11.123646.20532@ultb.isc.rit.edu>, ecldco@ultb.isc.rit.edu (E.C. Loyd) writes:
- > [lots of stuff relating to copying TA90s deleted]
- >
- >>Gentlemen,
- >>
- >>A warning! It is important to note that when you copy tapes,
- >>error blocks may appear/disappear. If you are copying VMS BACKUP
- >>savesets, it is extremely important that you leave on the CRC
- >>checking and redundancy grouping capabilities of VMS BACKUP.
- >>Otherwise, there is a distinct chance that your saveset may get
- >>corrupted.
- >>
- >>While it is often painful, precautions are necessary to ensure
- >>that the savesets you copy (and take off of the site) are usable
- >>in the event of a problem!
- >>
- >>- Bob
- >
- > But what we here at RIT would like to do it copy, bit-for-bit, one tape to
- > another tape. There would be no loss of data in this fashion.
- >
- > -Eric
- >
- > --
- > ECLDCO@RITVAX.bitnet ECL6895@RITVAX.bitnet
- > ECLDCO@ultb.isc.rit.edu ECL6895@ultb.isc.rit.edu
- > Eric Loyd's the name, Data Center Operations is the game.
- > Opinions and irrational outbursts are MY pride and joy. Not my employer's.
- --
- Eric,
-
- My apologies. My original post was not specific enough.
-
- The problem that I am referring to will happen on may hardware
- combinations. While it is possible that this scenario will not
- happen on a TA90, it does happen on other drives (and, in fact,
- it may happen on TA90s anyway, this particular case is one of
- those "its not supposed to happen" situations).
-
- The problem occurs when a tape drive senses an error when writing
- the tape and processes a "recoverable" tape error. When this tape
- is subsequently copied using a different drive (or the same drive
- at a different time) the condition which caused the first error
- may not be detected by the tape copy program, resulting in two
- copies of the tape record involved. If the first record was truly
- in error, and the copy program (or the tape drive) did not handle
- it correctly, then the "duplicate" of the tape will have an
- erroneous block (On the original tape, the hardware error was
- used to mark the problem, since the duplicate tape has no
- hardware error, there is NO PROBLEM DETECTED).
-
- In some environments, this is not a particular problem (Tape
- distributions of software use brand new media, the copy operation
- is large scale, and a replacement for a bad copy can always be
- obtained). For archival backups, where the primary and backup
- copy ARE THE ONLY copies of the data, I would recommend more
- caution.
-
- I hope that this has been clearer.
-
- - Bob
- +--------------------------------------------------------------------------+
- | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com |
- | Robert Gezelter Software Consultant Voice: +1 718 463 1079 |
- | 35-20 167th Street, Suite 215 Fax: (on Request) |
- | Flushing, New York 11358-1731 |
- | United States of America |
- +--------------------------------------------------------------------------+
-