VXA tape flaw

In article ,
Arthur Begun wrote:
I call it what it is. Backup Exec and other programs give you a
choice between APPEND or OVERWRITE. It was an APPEND. If you don't
like it, complain to them.

If Backup Exec are rewriting the header they are not doing an append operation,
they are combining an append operation with an overwrite operation, and lying
to you about it.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

In article ,
Arthur Begun wrote:
As far as Backup Exec causing the problem, I doubt it. Since it
recognized that an error occurred and displayed an error message, I
doubt it was writing anything further to the tape.

It wouldn't have to. It was writing the header. If a failure occurred at
that point, then you HAVE TO assume that any part of the header it was
rewriting was in an unknown state: valid old, valid new, or invalid.

It is incomprehensible to me that anyone would write archiving software
that rewrote already-archived data or metadata without a way of recovering
from any failure to safely update a copy of the data or metadata it was
rewriting. If Backup Exec doesn't have a recovery mechanism that allows it
to skip damaged sections of tape where that is physically possible and
recover the remaining save sets from chained metadata then that is Backup
Exec's problem.

The backup software I use, AMANDA, never rewrites any data, and precedes
each backup set with a descriptive file that not only describes what the
following file will contain, but provides a plain text description that
lets you know how to restore that backup set so you can recover the tape
without even having the AMANDA software online.

That is what I consider a "good" standard of care in designing archival
and backup software. If your description of what Backup Exec does is
accurate (which I must admit is increasingly doubtful) then it it isn't
even doing a "minimally acceptable" job.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`

(Peter da Silva) writes:
If Backup Exec are rewriting the header they are not doing an append
operation, they are combining an append operation with an overwrite
operation, and lying to you about it.

What I want to know is how is it POSSIBLE for Backup Exec to overwrite
a header? Tape drives normally don't support arbitrary overwrite
operations. Are tape partitions involved?

(Arthur Begun) wrote in
om:
I never thought Backup Exec was the greatest program in the world but
I'm sure that the header is written as a series and if it hung during
writing the last of it all I would have lost was information on the
last backup which I don't really care about. The header information
on the previous backups should have remained. In fact there were
several posts about freeze-ups while updating a header and no mention
of prior data loss as a result.

What you don't seem to grasp is that backup exec was trying to rewrite the
entire tape header and stopped in the middle of it, which left the first
chunk of data on the tape unusable. Since this chunk contains information
about what's on the rest of the tape, the tape is screwed and there is
nothing whatsoever VXA or any other tape device in the world can do about
it. The same thing would happen if you did this on a $100 used DDS drive or
on a $40000 Storagetek 9840 (or whatever they cost now).

It's not a tape device problem.

--
/Jesper Monsted
Storage Administrator
TDC Services, Denmark

The same thing would happen if you did this on a $100 used DDS drive or
on a $40000 Storagetek 9840 (or whatever they cost now).

US$30k for a decent sized library....
http://cgi.ebay.com/ws/eBayISAPI.dll...ategory=37 56

"Rob Turk" wrote in message .nl...
"Arthur Begun" wrote in message
om...

I spent a good part of last night reading thru hundred's of newsgroup
posts at Veritas Backup Exec website. They have a fine newsgroup,
appears to be completely open and uncensored, with help provided by
Veritas and users. And it has great searching abilities. Searched on
"header" and anything else I could think of that might be related to
what happened. The newsgroup goes back about 5 years with thousands
of posts of problems with various versions of Backup Exec. NOT A
SINGLE REPORT OF A TAPE READING ZERO OR BLANK AFTER AN APPENDED
BACKUP. NOT ONE!!! NOT A SINGLE ONE. CLEAR ENUF TO YOU GUYS?????


Interesting... My 3 minutes on the Veritas web site brought me to the
following hit:
http://seer.support.veritas.com/docs/233735.htm

So although you found no hits of anyone discussing a similar issue, Veritas
has discovered such a flaw in their software before. Please note the line
that says "NOTE: These errors are not completely indicative of the problem
and could be displayed during other operations"

Also read: "In rare situations, it is possible for a COM communication link
to be broken prematurely." Your system hung and/or you cut power before the
backup was complete. I think we can all agree that at that point COM
communications was gone too.


Rob

Obviously I found that link in my hours of searching and considered
it. I believe it is evidence that Backup Exec did not do the damage.
In the case of software damage to the header, the result was
(according to the document) that the tape became "Unrecognized Media"
the next time it was loaded into Backup Exec. My media remained
recognized, with name undamaged, but it was blank.

(Peter da Silva) wrote in message ...
In article ,
Arthur Begun wrote:
As far as Backup Exec causing the problem, I doubt it. Since it
recognized that an error occurred and displayed an error message, I
doubt it was writing anything further to the tape.

It wouldn't have to. It was writing the header. If a failure occurred at
that point, then you HAVE TO assume that any part of the header it was
rewriting was in an unknown state: valid old, valid new, or invalid.

It is incomprehensible to me that anyone would write archiving software
that rewrote already-archived data or metadata without a way of recovering
from any failure to safely update a copy of the data or metadata it was
rewriting. If Backup Exec doesn't have a recovery mechanism that allows it
to skip damaged sections of tape where that is physically possible and
recover the remaining save sets from chained metadata then that is Backup
Exec's problem.

Which is why I do not think Backup Exec caused the problem. I have
used it in various forms for many years and never seen anything
similar happen. Searching on the internet I could not find it
happening to anyone else. Yet another VXA user using Retrospect
complained of a similar problem. Different software but same drive
technology gave same problem.

(Peter da Silva) wrote in message ...
In article ,
Arthur Begun wrote:
Just in case anyone is reading this thread, check this guys posts in
Google. Basically he is a troll. And if the VXA format is not
capable of reliable appended backups, that fact should be specified in
documentation.

I have had my differences with him in the past, but that doesn't mean
he's not correct in this case. If Backup Exec rewrites the header of
the tape then it's NOT simply doing an append operation. Rewriting the
header is not something any backup software should do, or at the very
least it should do it in such a way that it can reconstruct the header
from chained snapshots that it makes as it goes along.

It is likely that it does since no one else using Backup Exec has
reported this problem but someone else using Retrospect on a VXA drive
had the same experience. Different software, same drive technology
and same problem.

(Arthur Begun) writes:
It is likely that it does since no one else using Backup Exec has
reported this problem but someone else using Retrospect on a VXA drive
had the same experience. Different software, same drive technology
and same problem.

You are simply repeating yourself without giving a shred of actual
evidence of anything.

"Arthur Begun" wrote in message
om...
"Rob Turk" wrote in message
.nl...
Interesting... My 3 minutes on the Veritas web site brought me to the
following hit:
http://seer.support.veritas.com/docs/233735.htm

So although you found no hits of anyone discussing a similar issue,
Veritas
has discovered such a flaw in their software before. Please note the
line
that says "NOTE: These errors are not completely indicative of the
problem
and could be displayed during other operations"

Also read: "In rare situations, it is possible for a COM communication
link
to be broken prematurely." Your system hung and/or you cut power before
the
backup was complete. I think we can all agree that at that point COM
communications was gone too.


Rob

Obviously I found that link in my hours of searching and considered
it. I believe it is evidence that Backup Exec did not do the damage.
In the case of software damage to the header, the result was
(according to the document) that the tape became "Unrecognized Media"
the next time it was loaded into Backup Exec. My media remained
recognized, with name undamaged, but it was blank.

This very statement invalidates your entire story. The name of your media is
in the very first data blocks of rolling drums the HEADER. If BackupExec
is able to identify the tape by name, then your tape is NOT blank.

Rob