VXA2 tape and 9.2 G Capacity

[Siriusonsite]

I haven't seen this anywhere else so I'll start a new topic. One of my clients has a Exabyte 1U Firewire Autoloader attached to a newer Intel Xserve running 10.5.5.

 

We're using Retrospect 6.1.230. I've recently updated the firmware of the tape drive and the autoloader. All of the tapes are new in the last few months. The goal is to back up about 400GB of data with two rotating backup sets.

 

If one starts a recycle backup, the first three tapes usually back up a reasonable capacity for VXA2: between 80 and 160 GB. The 4th tape and beyond somehow identify themselves as tapes with 9.2 G capacity. If there are erased tapes available, Retrospect appears to write 9.2 GB to all of them until it runs out of tapes.

 

This happened occasionally when they used Retrospect the old G4 server as well. Now that they have more drive capacity, they regularly have more than 3 tapes worth of data to back up.

 

I've run the vxaTool test many times and the drive seems to be working normally. We've swapped tapes out, erased and mixed them around to no avail. Do anyone else have any insight into this? By client's backup is not working and I'm about to download a demo of NetVault to see if that works better.

 

D

[rhwalker]

perhaps some odd header has been written to the tapes indicating that they are some odd format, not VXA-2.

 

I've never seen this happen, but we have the SCSI version, not the firewire version, and we are on MacOS 10.4.x Server, not Leopard.

 

Have you tried using vxatool to force the drive to put down a VXA-2 header and turn on compression?

 

./vxatool Tape1 -e 2 -P C -C 1

 

Russ

[Siriusonsite]

Thanks Russ,

 

I did a full tape test today (./vxaTool Tape1 -t F) of the tape drive and it appears to be working. Strangely the tape filled up at 68242 MB. I would have thought it would hold 80GB as advertised. I would like to try another tape and see what happens but it takes literally all day.

 

I think instead I'm going to erase all of the tapes with vxaTool, forced into VXA2 format as you suggest, and run a new backup. This might take awhile. I'll let you know what happens. Thanks for your help!

 

D

[rhwalker]

Strangely the tape filled up at 68242 MB. I would have thought it would hold 80GB as advertised.

Well, tape capacity depends on the compressibility of the data and also the inter-block spacing, which depends on how fast the driver can pump the data out, which, in turn, depends on the CPU horsepower, I/O bandwidth, etc.

 

With our Xserve G5 and SCSI interface to our Exabyte VXA-2 1x10 1u Autoloader (SCSI), we see about 110 to 120 GB on an X23 VXA-2 tape (rated 80/160 GB uncompressed/compressed). The VXA-2 drive will also adjust the inter-block spacing to ensure that it doesn't get starved by data. When the drive starves for data, it has to backhitch when it passes the needed start of the next block without data so that it can get a running start again, which wears out the tape (and greatly increases backup time).

 

You will only get maximum storage on the tape with optimal data and a dedicated driver (such as vxatool) pumping data to the tape.

 

Russ

[fchanMSI]

I have VXA2 Autoloader 1U also but I'm using Arkeia as the backup server. My guess you are using firewire model to connect to your Xserve system and please correct me I'm wrong. I have SCSI-320 for mine connect to a Linux server. Vxatool should able to write the full 80GB to the VXA2 X23 tape, but it does take a long time even on my Linux system with SCSI-320 running at full tilt. Make you have a clean the heads of the tape drive before you do this test and depending on you usage clean the tape drive head regularly.

On my Linux system my command line is:

 

vxatool -m 80000 -t W /dev/st0

 

-m 80000 is to write 80GB of information to the tape.

-t W is to test write only should take a few hours to do. You can use 'F" instead of 'W" for full test and this will a very long time since it will write 80GB and then read that 80GB.

 

If you run into more problem you can contact Tandberg, which bought Exabyte, for assistance:

http://tandbergdatana.mv.treehousei.com/Surveys/32/818AD3CAEC099D2D/

 

I hope this helps.

[Siriusonsite]

Hi fcahn, thanks for the input.

 

Yes, we are using firewire. The above mentioned command (./vxaTool Tape1 -t F) does about the same as the command you mention for the SCSI device on Linux. It resulted in the 80GB tape filling up at about 66GB. If the tape head was dirty or malfunctioning, would it skip parts of the tape resulting in the lower capacity? The test results did not indicate an error, just that the test ran until the tape was full at a certain capacity. I'll run some extra cleaning.

 

However, i have made an error. The capacity of the 4th tape that Retrospect asks for is 9.1 G, and not 9.2. My fault.

Here's a link to a screen shot:

http://i415.photobucket.com/albums/pp233/siriusonsite/examples/9dot1Gtape.jpg

 

That example was from earlier today. I forgot to turn off the script for recycle backup Set B on Friday. True to form, it erased and filled three VXA2 tapes, apparently at normal capacity, then started asking for twenty-one new 9.1 G tapes.

 

For what its worth, vxaTool identified 3-Tape Set B as VXA-2a. Other tapes that Retrospect believes to be 9.1G show the same. There were no more erased tapes available and the script stopped. Tape 3 was the last to be written to normally and Retrospect is asking for tape 4 with a capacity of 9.1G. In this instance at least, I don't think that a hardware error or tape format error is the cause.

 

D

[rhwalker]

If the tape head was dirty or malfunctioning, would it skip parts of the tape resulting in the lower capacity?

I don't believe so. Lower capacity happens when the computer, I/O subsystem, etc., cannot get data to the drive fast enough. Maybe there are issues either with your firewire subsystem, or perhaps you need to put the drive on its own Firewire channel (you don't say whether there are any other devices on the channel).

 

Are you using the Firewire port on the front of the Xserve or the back? I am not sure that they are both Firewire 800. Also, your drive/autoloader may have firewire issues.

 

Your 9.1 GB message is meaningless. You can set any size you want for the estimated capacity in the preferences for the backup set. Retrospect writes until it hits EOT or error.

 

Russ

[twickland]

True to form, it erased and filled three VXA2 tapes, apparently at normal capacity, then started asking for twenty-one new 9.1 G tapes.

Not exactly. Retrospect is asking for a new blank tape 4, which it thinks is 9.1 GB capacity. It's estimating that you will need 21 tapes for the data if this capacity is correct.

 

You can go to Configure> Backup Sets> Configure [yourbackupset]> Options> Capacity and plug in any number you want. This number is used only to calculate the remaining capacity on a tape member that Retrospect will display to the operator. Whether that displayed capacity is 900 GB, 1 KB (the minimum Retrospect will display), whatever, it makes no difference at all as to what Retrospect actually writes to the tape member. (Retrospect doesn't use the capacity number in writing and doesn't/cannot communicate that number to the tape drive.) Retrospect will always write to a given tape member until the tape drive reports that no more data can be written to that tape--either because the tape is full, or because an unrecoverable error has occurred in writing to the tape.

 

In short, if you are actually only able to write 9.1 or 9.2 GB to a tape member, as you suggest is the case in your first post, the problem has to lie with the tape drive or library mechanism, a particular tape member, or the communication pathway between the tape drive/library and the backup computer.

[Siriusonsite]

Ah, now we're getting somewhere. To respond to earlier inquiries:

 

Russ - the autoloader is attached to one of the rear firewire 800 ports. Until I attached an alternate backup hard drive the other day, there were no other firewire devices attached.

 

Russ and Twickland - thats interesting. I changed the estimated capacity from automatic to 80GB which ought to be the minimum for X23 tapes. Perhaps a way for the next version of Retrospect to avoid this confusion might be to include the capacity estimate in the creation of the backup set.

 

The list of the members of set A shows some of them containing somewhat less than 80GB. That would probably be a hardware problem of some sort.

 

This problem seems to be erratic tape drive performance along with Retrospect taking a wild guess on the capacity of future tapes. I'll have to grind on Tandberg for awhile. Thanks for your input and help in working this out.

 

D

[rhwalker]

Russ - the autoloader is attached to one of the rear firewire 800 ports. Until I attached an alternate backup hard drive the other day, there were no other firewire devices attached.

Ok, then that's going to reduce capacity. Retrospect's driver is trying to read ahead (multiple buffering) the data on the backup hard drive, so, if that backup set is being used, then there is competition for that Firewire bus, and the tape drive on that same bus will be starved.

 

Even if that backup set is not being used, the periodic sync() syscalls in one of the kernel's background processes will cause stuff to be written to that disk because of its filesystem.

 

Russ