VXA tape flaw

"Paul Rubin" wrote in message
...
(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 wrote elsewhere that BackupExec recognised the name but showed the
tape as blank. The name is in the *header* of the tape, which therefor
*must* be readable.

For Athur, here's how BackupExec roughly stores data on tape.

L = Logical Begin of Tape
E = End Of Data marker
F = Filemark
B = blank, unwritten tape until end of media.
+++ = Header
=== = User data
--- = Dataset Index
x = Belongs to dataset x.

New unused tape:
LB

After label operation:
L+++FFEB
Please note that BE will call this a BLANK tape...

After the first backup set:
L+++F====1=====F--1--FFEB

After an append:
L+++F====1=====F--1--F====2=====F--2--FFEB

BackupExec will always first read the header which contains the name. If the
name is present in BE's index database on disk, it will lookup and present
the content from it's index database. If it isn't then you need to import
the tape. BE will use the Filemarks to quickly space to the supposed
location of the Dataset Index. If for whatever reason spacing through the
format it expects fails, BE will show 'unrecognised media'.

In your case, the computer hung before completing the backup. This may cause
two things:

1. Your tape is inconsistent. It looks like this:
L+++F====1=====F--1--F====2=====EB
The Index of your last backup is missing. That last backup will be
unreachable for BackupExec. All previous backups are just fine.

2. The index database on disk for BackupExec is inconsistent! It knows the
tape and tries to lookup which data sets are supposed to be on that tape.
The database inconsistency causes the lookup to fail, and BE shows your tape
as BLANK.

Your fix should be simple. Either run a diagnostics on the BE database,
remove the tape from the 'known tape' index or re-install BE alltogether.
Then import your tape. You will most likely find that everything is there,
except for the last failed backup.

Rob

In article ,
Arthur Begun wrote:
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.

Two samples out of millions of passes doesn't add up to a significant
problem, even if there were a dozen more that haven't come forward it's
still such an obscure failure mode that I wouldn't worry.

Particularly since reasonable care in backup scheduling would have
prevented it from being a problem in the first place. If this happened
on a regular basis, or you could show how normal tape operations
could cause data loss, then you'd have a good case.

Plus: you haven't suggested a mechanism, described the actual
operations that fail at the tape level, or indicated that you've
investigated the problem in any great detail. Can you replicate it?
Have you tried?

--
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 wrote elsewhere that BackupExec recognised the name but showed the
tape as blank. The name is in the *header* of the tape, which therefor
*must* be readable.

For Athur, here's how BackupExec roughly stores data on tape.

[...]

Thanks for the details on BackupExec's storage format (which is, thankfully,
not some kind of exotic partitioned tape scheme but a conventional labelled
and indexed backup with an on-disk database).

So there's likely no mystery flaw in VXA or in Backup Exec, other than
its apparent difficulty in diagnosing a corrupted database... and even there
no matter how careful the developers there's always a possibility of some
obscure database problem going undetected.

--
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" wrote in message
...
In article ,
Arthur wrote elsewhere that BackupExec recognised the name but showed
the
tape as blank. The name is in the *header* of the tape, which therefor
*must* be readable.

For Athur, here's how BackupExec roughly stores data on tape.

[...]

Thanks for the details on BackupExec's storage format (which is,
thankfully,
not some kind of exotic partitioned tape scheme but a conventional
labelled
and indexed backup with an on-disk database).


On some tape devices that support it, BackupExec makes use of partitions as
well. Nothing exotic about that, they just use an extra tape partition to
have all index data close together. The main data format in partition 0 is
identical to non-partitioned tapes.

Rob

On Tue, 3 Feb 2004 08:27:26 +0100, "Rob Turk"
wrote:

[ Snip ]

L = Logical Begin of Tape
E = End Of Data marker
F = Filemark
B = blank, unwritten tape until end of media.
+++ = Header
=== = User data
--- = Dataset Index
x = Belongs to dataset x.

New unused tape:
LB

After label operation:
L+++FFEB
Please note that BE will call this a BLANK tape...

After the first backup set:
L+++F====1=====F--1--FFEB

After an append:
L+++F====1=====F--1--F====2=====F--2--FFEB

BackupExec will always first read the header which contains the name. If the
name is present in BE's index database on disk, it will lookup and present
the content from it's index database. If it isn't then you need to import
the tape. BE will use the Filemarks to quickly space to the supposed
location of the Dataset Index. If for whatever reason spacing through the
format it expects fails, BE will show 'unrecognised media'.

In your case, the computer hung before completing the backup. This may cause
two things:

1. Your tape is inconsistent. It looks like this:
L+++F====1=====F--1--F====2=====EB
The Index of your last backup is missing. That last backup will be
unreachable for BackupExec. All previous backups are just fine.

2. The index database on disk for BackupExec is inconsistent! It knows the
tape and tries to lookup which data sets are supposed to be on that tape.
The database inconsistency causes the lookup to fail, and BE shows your tape
as BLANK.

There's a third, and this is the one noted in the bug report you
noted:

3. BE rewound to LBOT before closing the device. In this case, the
tape looks like:
L+++FFE====1=====F--1--F====2=====F--2--FFB

Because there is a Logical End of Data written, the data following it
is irretrievable without specialist tools.

That leads to the question "why did the thing rewind?"... and the
issue becomes "What was the error reported?"

[ Snip ]

Rob

Malc.

"Rob Turk" wrote in message l.nl...
"Paul Rubin" wrote in message
...
(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 wrote elsewhere that BackupExec recognised the name but showed the
tape as blank. The name is in the *header* of the tape, which therefor
*must* be readable.

For Athur, here's how BackupExec roughly stores data on tape.

L = Logical Begin of Tape
E = End Of Data marker
F = Filemark
B = blank, unwritten tape until end of media.
+++ = Header
=== = User data
--- = Dataset Index
x = Belongs to dataset x.

New unused tape:
LB

After label operation:
L+++FFEB
Please note that BE will call this a BLANK tape...

After the first backup set:
L+++F====1=====F--1--FFEB

After an append:
L+++F====1=====F--1--F====2=====F--2--FFEB

BackupExec will always first read the header which contains the name. If the
name is present in BE's index database on disk, it will lookup and present
the content from it's index database. If it isn't then you need to import
the tape. BE will use the Filemarks to quickly space to the supposed
location of the Dataset Index. If for whatever reason spacing through the
format it expects fails, BE will show 'unrecognised media'.

In your case, the computer hung before completing the backup. This may cause
two things:

1. Your tape is inconsistent. It looks like this:
L+++F====1=====F--1--F====2=====EB
The Index of your last backup is missing. That last backup will be
unreachable for BackupExec. All previous backups are just fine.

2. The index database on disk for BackupExec is inconsistent! It knows the
tape and tries to lookup which data sets are supposed to be on that tape.
The database inconsistency causes the lookup to fail, and BE shows your tape
as BLANK.

Your fix should be simple. Either run a diagnostics on the BE database,
remove the tape from the 'known tape' index or re-install BE alltogether.
Then import your tape. You will most likely find that everything is there,
except for the last failed backup.

Rob


I wish you were correct but you are not. I've tried accessing the
tape with and without the disk based catalog, BE still believes tape
is blank. The import process gets info from the tape and puts it in
the catalog on disk if it isn't already there. If the BE thinks the
tape is blank it will not search further.

By the way, many, many years ago when BE first came out, it took
forever and did not put a catalog on the disk. I had a problem and
called them up for tech support and also complained how slow things
were. They said it was from writing the header on the tape. I said,
why not put it on the disk? There was a pause. I don't know if that
led to the change but....... the rest is history.

"Rob Turk" wrote in message .nl...
"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

Gosh... I thought it was clear by now.... the tape is not blank but
something happened that makes Backup Exec think there is nothing on it
except the tape's name and it reports it as having "0" on it. Got it?
Same thing happened to a guy using Retrospect. Both of us using VXA
drives.

"Arthur Begun" wrote in message
om...


Gosh... I thought it was clear by now.... the tape is not blank but
something happened that makes Backup Exec think there is nothing on it
except the tape's name and it reports it as having "0" on it. Got it?
Same thing happened to a guy using Retrospect. Both of us using VXA
drives.

Both of you having SCSI cables and terminators that may not have been
attached properly. Both of you using software that isn't infallable. Both of
you using electric power which may have dipped. Both of you being a user
that may have clicked the wrong button at the wrong time. Both of you not
understanding how tape devices *really* work.

You are so determined to blame it on VXA that there's no point in continuing
this thread. You clearly do not understand how backup and tape devices work
in-depth but you insist making claims about it.

Sell your VXA on eBay and live on believing VXA is dangerous. The rest here
knows better.

Rob

On 3 Feb 2004 20:55:09 -0800, (Arthur Begun)
wrote:

[ Snip ]

By the way, many, many years ago when BE first came out, it took
forever and did not put a catalog on the disk. I had a problem and
called them up for tech support and also complained how slow things
were. They said it was from writing the header on the tape. I said,
why not put it on the disk? There was a pause. I don't know if that
led to the change but....... the rest is history.

Don't flatter yourself.

Backup packages have been writing indices to disk since inception.

Malc.

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


Gosh... I thought it was clear by now.... the tape is not blank but
something happened that makes Backup Exec think there is nothing on it
except the tape's name and it reports it as having "0" on it. Got it?
Same thing happened to a guy using Retrospect. Both of us using VXA
drives.

Both of you having SCSI cables and terminators that may not have been
attached properly. Both of you using software that isn't infallable. Both of
you using electric power which may have dipped. Both of you being a user
that may have clicked the wrong button at the wrong time. Both of you not
understanding how tape devices *really* work.

You are so determined to blame it on VXA that there's no point in continuing
this thread. You clearly do not understand how backup and tape devices work
in-depth but you insist making claims about it.

Sell your VXA on eBay and live on believing VXA is dangerous. The rest here
knows better.

Rob

My machine was on a UPS. Cables have been connected the same way for
years. Read an article that predicts 27 gig capacity DVD's by 2006
will put tape out of business. (Hitachi or Sony just got a bunch of
patents on new laser technique that will allow increased capacity.)
Guess I'll keep the VXA till then.