Wasting tape

[anothersmurf]

Retrospect 8 seems to waste large amounts of tape (~25% - 50% of rated uncompressed capacity) by insisting on new media when the current media is not yet full.

 

I'm using a Firewire VXA-2 tape drive with X23 tapes. Using VXA-2, the tapes have a native (uncompressed) capacity of 80GB. Under Media Sets/Members, Retrospect shows the tapes as having a capacity of anywhere from 73.2 - 78.1 GB, depending on the X23 tape in question. But even if I assume that VXA is seriously ripping me off on tape capacity, Retrospect insists the tapes are full when holding as little as 40.7 GB of data... making me waste the rest of the tape and insert a new tape in order to continue backup. I have never managed to get more than 62 GB of data to fit on a single 80GB tape, which means Retrospect 8 is regularly wasting quite a lot of capacity.

 

Anyone know how to make Retrospect use the whole tape?

[Maser]

You still have Retrospect 6 (if I remember you from another thread...), right?

 

Does your drive work with Retrospect 6? If so, if you back up the same source data with the *same tape and drive* -- do you get more data on the tape with Retro 6 than with 8?

 

(I'm just curious as I don't use tape...)

[anothersmurf]

I still have and use Retrospect 6, but with a different (VXA-320) tape drive. The last time I used the VXA-2 drive with Retrospect 6, I didn't notice it wasting tape. (About 1.5 years ago.)

 

If the backup set is young when Retrospect 8 decides the tape is too full to continue, I can forget/erase the tape, run the backup again, and and fit more data on the tape than was allowed the first time around. Which makes me think there's no physical problem with the tape or the drive.

 

What do you use instead of tape? Giant RAID array?

[Maser]

I still have and use Retrospect 6, but with a different (VXA-320) tape drive. The last time I used the VXA-2 drive with Retrospect 6, I didn't notice it wasting tape. (About 1.5 years ago.)

 

If the backup set is young when Retrospect 8 decides the tape is too full to continue, I can forget/erase the tape, run the backup again, and and fit more data on the tape than was allowed the first time around. Which makes me think there's no physical problem with the tape or the drive.

 

What do you use instead of tape? Giant RAID array?

 

 

Not that I know anything about tape drives, but are you sure the firmware is current the VXA-2?

 

 

And, yes, I use a big RAID array (that I backup the incremental changes to the media sets to another RAID array once a week.)

[rhwalker]

There are three possible explanations, and it's unclear from your testing which is happening:

 

(1) Retrospect 8 is writing to the tape in uncompressed mode. This bug has been reported before.

 

(2) Retrospect 8 is causing larger inter-block gaps on the tape due to the tape drive's data pipeline becoming starved (the drive will increase the inter-block spacing in such situations to prevent "back hitching" - rewind and get a running start again for next block) to keep the drive in streaming mode.

 

(3) Retrospect 8's tape error routines are too sensitive, and are giving up, believing that the tape is bad when, in fact, it's just a soft (correctable) error.

 

Issue 1 can be tested by using the Exabyte (Tandberg) diagnostics to erase the tape into VXA-2 compressed mode before using the tape with Retrospect. Blank VXA-2 tapes, for compatibility, indicate that they are uncompressed. This bug has been seen before (and fixed) with Retrospect 6, and might have resurfaced with Retrospect 8. I always barcode and pre-label blank tapes, so I wouldn't have run across this issue, but you might test.

 

Issue 2 can be tested by running on hardware that is not compute bound. I would expect such large inter-block gaps if you are running on a G5 PPC, because that architecture has to do all of the byte-swapping to fix things up for Retrospect 8's Intel-native (little-endian) format. You don't say what your underlying hardware is. Retrospect 6, which was quite mature and optimized, didn't have this problem because there wasn't the byte-swapping issue (Retrospect 6 was PPC optimized for big-endian). Also, I've never used the Firewire version of this drive, only the SCSI version, so I don't have a clue whether there is a performance penalty (whether because of Firewire I/O speeds or because of overhead with Retrospect's Firewire driver interface). Don't know whether Retrospect 8 has been optimized for speed yet - right now, it just "crashes quickly".

 

Issue 3 is harder to test because you will have to get error-free transfers. Use new tapes, use a cleaning tape before each backup session. This issue, if the problem, can only be fixed as Retrospect matures, if that happens.

 

Russ

[Daniels]

Number 2 explains why I sometimes experience this problem of my AIT-3 tapes filling up before they should. Fortunately I use a library system and barcoded tapes so I do not have to babysit the backup. My media sets always contain extra tapes so I will not run out of space for the media set. In the very rare case I do run out of space I will recycle the media set.