Link to home
Start Free TrialLog in
Avatar of John Tolmachoff
John TolmachoffFlag for United States of America

asked on

Backup Tapes showing more used capacity than data in Symantec Backup Exec

I have a perplexing problem I am hoping some one can help with.

HP Ultrium 4-SCSI external tape drive
Quantum Ultrium LTO 4 800/1600 tape media
Symantec Backup Exec 2010 R3 SP2
VMWare 4.1 Guest
Window Server 2008 Ent R2

We have a primary set of 10 tapes all purchased at the same time. Within that set, they are broken up into 5 sets of 2 for rotation and each set is used one week then rotated. Within that set of 10, 3 of the tapes are reporting higher soft read and/or write errors than the other tapes. Those tapes that are reporting those higher numbers are also show greater used capacity than data, which is a red flag as that can not be. For example, showing data on tape 23-C Backup Exec shows the data on tape as 233.48 GB but it also shows used capacity as 387.9 of 780.5 which is wrong. This leads to failed jobs as the tape fills up, but the actual data is not that high.

I have tried doing both short and long erases and no change.

The last time this happened, I restarted the ESX host and the guest and then the tapes worked correctly. I did that today but no change.

Any one have any ideas? I mean sure, I could just flag those tapes as bad but I am talking about a total of 4 tapes here which seems more that just a tape problem.
3-26-2012-10-51-24-AM.gif
ASKER CERTIFIED SOLUTION
Avatar of IT-Monkey-Dave
IT-Monkey-Dave
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of John Tolmachoff

ASKER

NO, it is only showing all of them as LTO. Should I manually change the media sub-type from LTO to LTO4?
3-26-2012-4-17-13-PM.gif
3-26-2012-4-16-15-PM.gif
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yes, all the tapes say just LTO. I have set it manually on the one and am doing  a long erase now. I will see what happens in the morning.
I'm not that familiar with Backup Exec (we use ArcServe).  With ArcServe a "quick erase" is usually enough.  A long erase won't hurt though, just takes a lot longer.
Same, not familiar with backup exec, but try getting a full list of what it says is on the tape vs actually performing a read of the tape, from the start, to confirm what's on it.  What I'd be looking for in this case is to see if the tape starts at file 50 or similar, in which case you've probably got a tape drive shared on the SAN which something else is giving a rewind to.

"System health monitoring software" tends to be really bad at this.  It'll see what devices are attached to the system (any devices it can see) and then issue it a basic request to see if it responds.  However, it'll often issue that request to a rewind-on-close device, so BE on one system sees the tape at filemark 50, then the other system checks it's okay and rewinds it, then BE continues writing.... from filemark 0 instead of 50.  You should see some errors in the logs about where it's starting read or similar though.

Confirm that your SAN zoning is in place and locked down correctly, ensure that the drives are set up to use persistent SCSI reserve, and that only root/system/admin/whatever can access the tape drives.
Responding to StuWhitby:

There is no SAN involved in this issue. There is only one server/device connected to and using the tape drive. There is only one tape drive. However, I will as you suggested compare what the backup job log says is on the tape with an actual catalog of the tape.

Responding to IT-Monkey-Dave:

After doing a long erase for good measure and setting the "media" properties in Backup Exec to LTO4, the 2 jobs ran fine this morning and the status of the tape shows as expected, sort of. Backup Exec through a tape alert error on the number of soft read and write errors saying the tape should be replaced, but the job itself completed succesfully.
After running with all tapes now properly configured (why didn't Backup Exec do this) as LTO-4 there have been no further problems.