Jump to content

Not getting native capacity on X23 tapes


Recommended Posts

Hi all,

 

I have had my Exabyte VX-2 drive checked and it is functioning perfectly.

 

Problem is I'm only getting 70G of data on an X23 tape (s/b 80G). I have tried multiple settings in Retrospect (compression on/off, etc), but have never gotten anything above 70G on a tape.

 

I'm using a Power Mac G5 (dual 2GB) and running data from an internal hard drive to my Exabyte FW drive.

 

I'm archiving a directory with 128MB TIFF files (not sure this matters) and Exabyte tech support recommended turning hardware and software compression off. Since they are TIFF files, they should not compress much further anyway.

 

Any ideas?

 

Thx,

James

Link to comment
Share on other sites

hi jw,

 

even if you turn on the 'software compression' within Retrospect it will ignore that if hardware compression is on. on the VXA drive, all of the compression is handled by the drive, Retrospect just hands off the data until the drive reports the tape as 'full'.

 

you are right that the .tiff files won't really compress much anyway, but also be aware that there are other factors regarding the amount of data that can be put on a tape. even exabyte acknowledges this:

 

http://www.exabyte.com/support/online/kb/display.cfm?id=160

 

Quote:

compressed files on your hard disk will not compress any further when fed through the tape drive's hardware compression chip. If you are backing up a high percentage of already compressed files, such as MP3, AVI, and JPG files, then you will not see any further compression at the tape drive level. In fact, as the data is compressed twice, it may actually expand. Try turning off hardware compression and software compression in your backup application.

 


i would suspect that applies to .tiff files too....

 

you should definitely try cleaning the drive, and using new media but it sounds to me like you are savvy enough to have tried that already. this may be the amount of data that you can get of this type on the tapes. i'm not sure how you'd turn off compression on the drive, but it sounds like that might be worth a shot.

 

there are some other ideas on the exabyte page.

Link to comment
Share on other sites

Simply as a data point, we are consistently seeing about 118 to 120 GB per X23 tape (compressed) on our Exabyte VXA-2 1x10 1u (SCSI interface to ATTO UL4D) on our Xserve G5 single processor 2 GHz 2 GB RAM, Retrospect 6.1.126, Mac OS X Server 10.4.5. The backup is mostly of Retrospect clients over 100BaseT (probably about 15 to 25 GB each on the initial backup), with the Xserve drives being a SoftRAID RAID 1 mirror with underlying RAID 5 on Apple Hardware RAID (3 x 250 GB ADMs) and Seagate Cheetah drives on the same SCSI channel as the Exabyte, so we've got a somewhat fast disk subsystem on the Xserve which shouldn't starve the Exabyte, but the data speed from the clients is somewhat slow. Most of our files are word processing docs, etc., which should compress well, and we use hardware compression.

 

 

 

In fact, I've considered spending the $1400 to upgrade the drive to a VXA-320 to get double the capacity per tape - it would pay for itself in a few months with two fills of the tape autoloader, and would make the autoloader more unattended.

 

 

 

But unless you have a slow dual PM G5 (you don't say the speed), you should be able to feed your VXA-2 drive at max rate. Do you happen to have anything else on the Exabyte's Firewire channel? (another disk drive, camera, etc.) Also, is your Firewire FW400 or FW800 ? That could be throttling your data rate.

 

 

 

One other thing - is anything else running on your computer while Retrospect is doing its backup? Do you get the same results if you are logged out and Retrospect does a scheduled backup?

 

 

 

Russ

Link to comment
Share on other sites

My Mac is a Dual 2Ghz G5 (not the current Dual-core, the previous G5).

 

I'm not running anything else on it while the backup/archive is running.

 

The tech at Exabyte looked at my log file and said he thinks it's NOTHING to do with the tape drive. He did mention that he sees a lot of "small reads" instead of large reads - not sure what this means, but he suspected something software related.

 

The Exabyte VXA-2 does not come with FW800, only FW400. I didn't want to spring for a SCSI card or I might have considered the 320, oh well.

 

Some specs...

I ran my first tests going from LaCie external FW800 drives to the Exabyte:

No compression at all: 54G

Hardware compression: 59.6G

 

I then purchased a second internal SATA drive for the Mac (7200rpm/16MB buffer). I suspected that perhaps the LaCie to Exabyte was causing the Exabyte to wait for data.

With HW Compression: 70.2G

 

I am now running from my internal drive with NO compression, but I'm not optimistic.

 

I'm ready to chuck it though and just accept the 70G per tape. I have about 1TB of images to back up, so maybe it'll cost me a couple more tapes I guess.

 

Any further thoughts are more than welcomed! Thanks to you both.

 

James

Link to comment
Share on other sites

I'm out of thoughts. You seem to have it all covered. The "small reads" shouldn't affect capacity, because capacity is determined while writing.

 

Have you tried the Exabyte "vxatool" to do an "extended read/write test" with a humongous data size (120 GB, for example) ? That would isolate the tape drive's performance from the source drive and from Retrospect, because the Exabyte vxatool would just pump out data to the drive. I don't have insights into the vxatool code, so I don't know whether it tries something stupid like trying to allocate a humongous data buffer the same size as the requested amount of data.

 

But this might give some insight as to the Firewire to Exabyte VXA-2 bandwidth and "best case" capacity. I've never used the vxatool on a Firewire Exabyte VXA-2 (only our SCSI VXA-2), but the manual indicates that it should work. Be cautioned that I think that the Exabyte diagnostic does something to the tape that Retrospect doesn't like. I think I had to use a bulk eraser to restore the tape to usability when I tried it.

 

Note that a V23 uncompressed VXA-2 tape will only hold 80 GB, so you really aren't that far off with 70 GB. I think that we get the 118-120 GB (compressed, out of 160 GB max) because our stuff is highly compressible.

 

Regards,

 

Russ

Link to comment
Share on other sites

I have decided that I'm not going to get more than 70G on my X23 tapes. I am achieving this amount using Hardware compression on the Exabyte.

 

According to my Retrospect Help docs:

A 74-minute CD-R disc has a nominal capacity of 650 megabytes. For everyday use this means you will typically achieve capacities around 600MB.

 

For typical everyday use, when your tape is full, it may store up to 30% less data than its ideal maximum capacity.

 

You can effectively increase the capacity of your media by using compression, either Retrospect's data compression option (see Backup Options) with a removable disk drive or CD/DVD drive, or the hardware compression of an equipped tape drive (see Compression).

 

The benefits of compression depend largely upon how well the data you are copying compresses. Text compresses well, for example, but applications do not.

 

----

Since I am achieving about 10G less that native 80G (12.5% less than max), I guess I should accept this and move on.

 

Thanks again waltr and russ.

Link to comment
Share on other sites

Quote:

Since they are TIFF files, they should not compress much further anyway.

 


 

I'm not a compression expert (although I was once in the same room as Raymond Lau), but uncompressed TIFF files are, depending on their makeup, quite compressible.

 

As a test, I created a 3080 x 3955 pixel file in GraphicConverter, filled all the pixels with one color, and saved it as TIFF. This 12 megapixel image took about 35 megabytes on disk.

 

Running it through StuffIt 10, the resulting .sitx file was only 4 kilobytes.

 

Of course, complex real-world TIFF images will not compress nearly this well, since it's the similarity of data that allows for loseless compression. But there's nothing about the file format that prevents data compression from being effective.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...