cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to get a complete backup

Rob_Nicholson
Level 4
I'm getting to my wit's end with backups :( We've got Backup Exec 12D and a Quantum SuperLoader 3a with 16 cartridge slots. We've been having on-going variety of failures trying to run this system under Windows 2003 R2 64 bit virtualised on top of ESX Server.

Therefore, I've moved the entire backup onto it's own server and as a test, I'm backup up a remote server with ~3.5TB of data. I've run the job three times so far (takes about 24 hours) and each time, it's failing with a read/write error like this:

Backup- \\server004.company.local\F: Storage device "QUANTUM 1" reported an error on a request to write data to media.
Error reported:
A tape read/write error has occurred.  This is usually caused by dirty read/write heads in the tape drive.  Clean the tape drive, and then try the job again.  If the problem persists, try a different tape.  You may also need to check for problems with cables, termination, or other hardware issues.
V-79-57344-34028 - A tape read/write error has occurred.  This is usually caused by dirty read/write heads in the tape drive.  Clean the tape drive, and then try the job again.  If the problem persists, try a different tape.  You may also need to check for problems with cables, termination, or other hardware issues.
A selection on device server004.company.local was skipped because of previous errors with the job.

Verify- \\server004.company.local\F: DATA2The query for media sequence number 2 of this media family was unsuccessful.
Ensure that all media in the family have been inventoried and cataloged.

Now these are different errors to those we were getting when virtualised but the end result is the same - tape with end marker unreadable. I suspect that when virtualised, the same errors were occuring just not getting passed through the virtualisation of the SCSI layer hence the reason we've moved it to bare metal on it's own server.

The question is, is it unreasonable to expect this to be able to backup 3.5TB of data like this?

The tapes have maybe been used 3 or 4 times before so should be still okay. There is a cleaner tape in there which is does automatically use. How often does one replace cleaner tapes?

The Quantum SuperLoader 3A was replaced a few months ago as a tape got stuck and could not be ejected so the tape drive itself should be okay!

Each time the backup has failed, I've removed the failed tape from the media set and put the rest back into scratch, starting the job again. Something baffling: the tapes that fail the next run actually worked fine the run before and the failure always appears to be towards the end of the 3.5TB backup. If we were getting read-write errors due to bad tapes, statistically one of these tests would have failed somewhere through the run, not always at the end.

I happened to be hanging around the console when the backup finished (it uses 8 tapes) and noticed that an automatic clean operation started at the end of the backup before the verify. How does BE handle cleaning? Does it wait until the end of the job or does it have a go half way through if it's detecting errors (would make sense to me)?

If it only happens at the end, then maybe the tape drive is unable to write 3.5TB of data without requiring a clean?

As I said, at wits end. We have support contracts both with Quantum and Symantec on both products as we've always had problems...

Cheers, Rob.
2 REPLIES 2

Not applicable
Job Engine service crashes when the backup job is targeted to the tape drive.

Exact Error Message
Final error: 0xe00084ec - A tape read/write error has occurred. This is usually caused by dirty read/write heads in the tape drive. Clean the tape drive, and then try the job again. If the problem persists, try a different tape.

 
Details:
This is seen when backup jobs are targeted to a tape drive that has a corrupt device driver in operation. This can also cause the tape drive to go offline. When the job engine service crashes, tapes can be marked with "End Marker Unreadable" which is discussed further in the related document 274858.

The following Event ID can be seen in the Event Viewer.

Event Source: Application Error
Event ID: 1000
Description:
Faulting application bengine.exe, version 12.0.1364.134, faulting module bengine.exe, version 12.0.1364.134, fault address 0x001955ee.

Solution:

To isolate and fix the issue, try the following the steps.

1. Perform a disk-based backup to eliminate the tape device.
2. Clean the tape drive.
3. Run an inventory and quick erase on the tape media.
4. Insert a different tape, preferably a brand new piece of media.
5. Check the properties on the tape drive(s) in Windows Device Manager to ensure that the latest Symantec Tape Device Drivers are installed. Install the latest drivers for the tape drive if available.  For information about downloading and installing the latest Symantec drivers, please see the following link


Got this at Symantec.com
http://seer.entsupport.symantec.com/docs/311519.htm
http://seer.entsupport.symantec.com/docs/192216.htm


Hope this resolve your issue.

Rob_Nicholson
Level 4

>Faulting application bengine.exe, version 12.0.1364.134, faulting module bengine.exe, version 12.0.1364.134, fault address 0x001955ee.

This event isn't being shown, just the dirty read/write head errors.

> Perform a disk-based backup to eliminate the tape device.

Not applicable in this case as we are backing up a backup-to-disk system to tape for off-site backup. Apart from tape, the backup works flawlessly backing up to disk.

>Clean the tape drive.

Tried that, many times.

>Run an inventory and quick erase on the tape media.

Tried that - no difference.

>Insert a different tape, preferably a brand new piece of media.

Tried that over the last few days and same problem.

>Check the properties on the tape drive(s) in Windows Device Manager to ensure that the latest Symantec Tape Device Drivers are installed.

Will check this later but suspect it's a faulty tape drive which, fortunately, is under warranty.

Thanks for your help.

Cheer, Rob.