On Fri, Aug 16, 2019 at 11:38:45 -0600, ghe wrote:
> I have reason to believe that one of my tapes isn't working properly
> (last night's backup died without finishing because of a tape error --
> the retry running right now successfully flushed last night's and wrote
> a new one).
I haven't looked closely at tape drives in a few years, but others on
this list certainly have in-depth experience with them. I think some of
the specific answers do depend on what tape-drive technology/generation
you are using, so it might help for you to post that info.
Also, "because of a tape error" is pretty vague; knowing the exact error
message might make a difference in what advice we can give you....
> Is there an Amanda utility that will validate a tape without destroying
> the Amanda header at the front of the tape? And maybe build a 'bad
> sector table' on the tape?
In my experence (which I guess was an LTO-2 drive), bad spots on the
tape were handled transparently by the drive. As Gene mentioned, tapes
are sequential, so there aren't fixed "blocks" like there are on disk
drives. Instead, the drive just knows that it has some data it needs to
write, and writes out that data onto the bit of tape currently streaming
past the write head, then attempts to re-read that just-written data
with the read head as the tape goes by there. If the read is
successful the drive considers that data to have been successfully
written and moves on to the next chunk of date; if the read fails, the
drive will write that same data again onto the next segment of tape,
repeating the process until the write/read cycle succeeds.
(Put another way, the exact spot on the tape that gigabyte number X is
written onto the tape will vary from run to run, depending on all sorts
of factors happening earlier in the the run. But it doesn't matter,
because the drive never tries to find data based on how many centimeters
of tape have passed from the front of the tape, but instead scans along
the tape bit by bit reading data, or at least looking for file markers,
as it goes.)
So, if you have a tape that is starting to "go bad" overall, usually the
symptom is that Amanda hits the end of the tape after writing less data
than the expected capacity for the tape -- rather than some sort of "bad
block" error.
A related thing to keep in mind is that the writes can fail because
specific spots on a specfic tape are bad... or because e.g. the write
head is dirty, which has nothing to do with the specific tape in use.
So, what I did was watch my Amanda reports to see if a specific tape
consistently gave me an "out of tape" error each type it was used, and
when that happened I figured the tape was getting worn out and removed
it from the cycle. (We ran the cleaning tape on the weekly cycle or
whatever the drive manufacturer recommended, which was not an even
fraction of the number of tapes in rotation, so from use to use a
particular tape would sometimes be used shortly after the heads were
cleaned -- and thus we could be pretty sure that it really was a bad
tape if the error happened consistently over many cycles.)
Regarding utilities to "validate" the tape: as far as I remember only
"amtapetype" is related to checking a tape to see its capacity. So if
you wanted to more directly check that a particular tape had a much
lower than expected capacity you could use amtapetype to see.... but
really all that can do is confirm what Amanda is already seeing (i.e.
the expected dumps no longer fit on that tape). And such a test would
overwrite any dumps currently on the tape, which you probably don't want
to do at least until enough time has passed that those dumps have all
become obsolete by later runs.
(amtapetype does have an "-l" option so you could tell it to re-create
the label that is already in the header file on the tape, but off hand I
am not sure if using that will cause Amanda to properly delete the
previous run found on that tape from the index, etc....)
(Denise mentioned the "amcheckdump" utility. This reads through an
existing Amanda tape and verifies all the dumps found on it can be
successfully read back -- something that is a good idea to do if a tape
seems to be failing just in case it is failing so badly that the drive's
normal rewriting-data-until-the-test-read-succeeds doesn't actually
result in a tape that can be read back later -- but a different task
than attempting to write to the tape to see how much data it can
currently store.)
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
