Tape Capacity Problems.

[ABeale]

Hi,

We recently migrated from a Brightsor installation to Backup Exec 11d.

The Backup Exec revision number is 7170. We have SP2 applied and hotfixes 31,32,33,34,35.

We're using a HP 1/8 Autoloader that contains a LTO Ultrium-2 drive. We're using HP drives for the tape drive (we did try Symantec drivers but the through put dropped to 20MB/Min when backing up the local disks).

Our backup jobs are set to use hardware compression.

The problem we have is that we aren't achieving the native capacity of the tapes when running a backup. A full backup is spanning multiple tapes. Lookig at the properties of a tape that has been filled shows the following:

Available capacity: 523MB; Used Capacity: 195 of 196 GB; Data 173GB; Compression: Nothing is recorded

The first few backups worked fine. We were getting aroun 221GB per tape with a hardware compression ratio of around 1.18:1

Any help would be welcome.

[Greg_Meister]

Good morning,

Backup Exec does not perform any form of hardware compression. As with other tape applications, Backup Exec simply sends the command to the tape hardware to enable or disable hardware compression. This can be verified by running the SGMON.EXE utility in the \backup exec folder. If you capture the ADAMM and Job Engine activity, you will see in the resulting log file that the commands to start and stop compression are sent at the start and end of the tape write operations.

Another place to look is in the System Event log. There may be a problem with the tape hardware or SCSI controller causing the command to fail.

Regards,

Greg Meister

Symantec Support Engineer

[OptiX]

I have the same sort of problem. However, I have LTO2 400GB capacity tapes and BE only views them as 200GB tapes. In the barcode rules there isnt a selection for LTO2 400GB -- only 200GB.

[Greg_Meister]

If you only have a single drive, or multiple drives of the same type, barcode rules are uncessary. Barcode rules are only required to differentiate types of tapes to associate them with their requisite tape drives. They have no bearing on how the media capacity is detected or reported.

Regards,

Greg Meister

Symatec Support Engineer

[OptiX]

Ah ok, is there a way that I can get BE to see the tape's correct capacity? I have 11d SP2.

[ABeale]

Sorry, I was a little unclear in my original post.

The issue isn't that we aren't getting any compression on the backup, the issue for us is that we can get the full native capacity on any of our tapes compression enabled or otherwise.

Backup Exec is reporting the capacity of the media correctly. When a backup is run and a tape is filled we are seeing the following against the tape properties:

Available capacity: 523MB  -  Used Capacity: 195 of 196 GB  -  Data: 173GB

So, on a 200GB native tape we can only get 170GB of data (at best. On some tapes we only get 160GB). We have approx 60 tapes. It's happening on all of them.

Message Edited by ABeale on 02-05-2008 07:04 AM

[Greg_Meister]

If you are not even achieving native capacity on your tapes, the two primary suspects are the tape drivers, or the tape hardware itself. Run the TAPEINST.EXE utility within the \backup ecec folder, and select the option to uninstall out tape drivers. A reboot will be required. Once rebooted, verify in Windows Device Manager that the tape drive shows the driver provider as the manufacturers drivers. Run the same job. If there is no change in the tape capacity, I'd recommend contacting your hardware vendor to further troubleshoot.

Regards,

Greg Meister

Symantec Support Engineer

[ABeale]

Last time I used TAPEINST.EXE to update to the Symantec tape drivers, the result was that the data throughput when backing up a local disk dropped to 20MB/Min.

If I update to these drivers again, is there a way to prevet this?

[Greg_Meister]

Due to the number of possible causes of throughput issues, I cannot definitively answer that one way or another. My primary reason for suggesting this was simply to determine if the driver set itself may be causing the media capacity to be detected or reported incorrectly, or if the problem lies in the tape hardeare itself.

Regards,

Greg Meister

Symantec Support Engineer