"Arthur Begun" wrote in message
om...

In case it is not clear to you, the incident happened this past Friday
(1/23/04), not in 2001. When it happened on Friday I talked with
Marty at Exabyte and sent in a log. On Monday I got a call and was
told if the header is gone, tough luck. I was actually using 4.21 of
Backup Exec (not Retrospect) but when the tape that was previously
full of differential backups suddenly turned empty after a backup
froze while writing the header I called Exabyte and also searched
using Google to see if I could find anything else about retrieving the
lost data. I found the 2001 post of someone having a similar problem
using a VXA drive and Retrospect. On the one hand you guys claim that
your drives are more reliable than other formats but as it turns out a
simple software freeze while writing the header blows the header away
and effectively erases the contents of a backup tape unless it is
restored by a data recovery company at the cost of thousands of
dollars.

So to make it absolutely clear, the incident happened afew days ago.
I have a tape on my desk full of data that is inaccessible because
somehow the header was destroyed because software froze while
appending a backup. I consider it a major flaw. I've been doing
backups on tape for almost 2 decades and have never seen a header
destroyed by an appended backup.

It was indeed not clear to me that this happened recently, as all you
referred to was something you found on Google from back in 2001. I called
the engineer you talked to on friday, he forwarded all information. It
describes that you had a failed harddisk, moved the tape drive to a
different system on which you had a bad SCSI connector or cable. The
computer froze while the backup software was rewriting it's header
information on a tape that contained the only backup of the failed disk, to
which you decided to append to when you should have write protected that
tape and used a fresh tape.

I'm not sure how I can explain this any clearer. What you experienced,
regardless of the backup package you used, is that a backup failed in a way
that left an incomplete backup set or incomplete index information on tape.
To the tape drive, all data blocks it was told to write are actually there.
All blocks that were there before from previous backups are also on that
tape. However, when BackupExec tries to examine that tape, it *expects* a
certain sequence to be present on the tape. The sequence consists of a
number of filemarks and data blocks of predetermined size, all in a closely
defined order. If, for whatever reason, that *exact* sequence is not found
on the tape, BackupExec (and most other backup software) will assume this is
either an empty tape, or a foreign tape written in some other format and
refuse to process it.

There are two levels of 'header' in play. One header is under control of the
drive, and is invisible to the user. It lives in the first section of tape
even before where data ever gets written. The drive uses it to to
'bookkeeping'. That's the header I referred to when I mentioned
auto-recovery in my previous post.

The second header is the high-level format as it's defined by your backup
software. To the tapedrive these are just data blocks. To your backup
application it's a crucial section on tape. If power is cut, or the system
freezes or reboots while that header is being written, your backup
application will no longer recognise the tape or what's on it. This is NOT
the tape drive's issue. The tape drive doesn't know about the format, it
just writes the blocks it receives from the host. If the host stops sending
blocks, the drive stops writing them. If that means you have half an index
file, that's too bad, but nothing the tape drive can do anything about.

Compare it to harddisk technology. If you write a file, and you lose power
before the FAT/NTFS directory is written, you may lose that file and perhaps
more if bad luck strikes. That's not the fault of Maxtor, Seagate, Hitachi
or WD, and no-one will blame the harddisk manufacturer for this. In the same
sense, while your backup software is updating it's header, if you lose
power, you may lose normal access to the data as well. There's nothing VXA,
DDS, DLT, LTO, Magstar, OnStream, AIT, SLR on any other tape technology on
this planet can change about that.

So let me re-iterate this one last time:
- Are your previous backups still on the tape? YES
- Can your standard backup software reach it? NO
- Can a data recovery company get to the data? PERHAPS.
- Is this VXA's fault in any way? NO.

The engineer you talked to on friday gave you the right advice. Your data
can most likely be rescued, get in touch with a data recovery company.
Meanwhile, VXA is not to blame for this in any way.

Rob