Is my 232 still good?

[Chris Luthe]

We have an ML350 G4p with internal Ultrium 232 that has been working fine for a year or two, but in the last few months the backups have started requiring two tapes - I would arrive in the morning to find a "please insert next tape". Which is odd, since I'm compressing a 136GB drive onto 200GB tapes (Acronis True Image, normal compression - max compression didn't work either). In the last fortnight it has been happening more.

On suggestion that the drive's compression may be playing up, I downloaded and ran HP Tape Tools and got the attached readout.

I then updated the firmware and ran a speed test, came out fine. Ran this test again, same failure.

The backups 'seem' to be working, but does this indicate that the compression has had it?

[thomasr]

I think your drive is fine.

First thing -- the 200GB capacity that you see on that tape is following the industry custom of quoting capacity assuming that the tape drive is able to compress your data 2:1. Most customers I talk with have compression in the 1.3:1 range, which is in line with what you report (getting just under 140GB on a 100GB tape).

If you're compressing in some other application (Acronis) the tape drive won't be able to further compress the data at all (unless Acronis does a really poor job of compression, which I do not suspect).

Nonetheless, if you let the tape drive perform the compression, it's an operation with no overhead for your system CPU, unlike application-driven (Acronis) compression, which usually has a goodly CPU hit.

From what I can tell, your tape drive is working correctly.

What can you do? I'd start by turning off Acronis compression to see if compression is handled more efficiently by the tape drive.

Clean out all those files you haven't touched for years. Consider setting aside a backup tape for archive that contains those files. Make sure that you're not selecting temporary files and directories as part of your backups. You can usually do this both at the directory level (exclude C:\temp, for instance) and file level (most backup applications allow you to exclude certain file extensions such as *.tmp, etc.)

And if that doesn't get you where you need to be, one workaround is to create two backup jobs, each for about half of your disk (one might backup the Windows and Program Files directories; the other backs up the rest of the system), with one job running on Monday night, and the other running on Tuesday night (or whatever) so that neither one fills up a tape.

And last... get a bigger tape drive. An Ultrium 448 will have twice the capacity (200 GB uncompressed/native) and be significantly faster as well (if your disk can feed it).

I hope this helps.

[Chris Luthe]

Thank you very much for the reassuring reply.

I'm aware that "200GB" really means 100GB, but Acronis does specify that its "normal compression" is also 2:1 (it says the image should be ~78GB) which is why I was concerned. And yes, the Max compression takes a massive CPU/disk hit - basically the entire network went dead while it was finishing yesterday morning (it's our AD/Exchange server).

So if I tell Acronis to not compress the data, will the tape drive automatically do that on its own, or do I need to tell it to somewhere?

I could split the backups into company info and "rest of C:", that'd work. It's currently doing a complete C: backup every night. Trust me, I've been trying to clean out files for months. We're at 3% free space and I'm running out of redundant files to clear out. Hopefully we'll get a server upgrade soon.

[thomasr]

0000
I'm aware that "200GB" really means 100GB, but Acronis does specify that its "normal compression" is also 2:1 (it says the image should be ~78GB) which is why I was concerned. And yes, the Max compression takes a massive CPU/disk hit - basically the entire network went dead while it was finishing yesterday morning (it's our AD/Exchange server).
0000

I don't care what the marketing guys at any tape or application vendor say... the compression they get is dependent on the type of data they are backing up, not any claim they make. JPG, MPG, compressed, and encrypted files will compress almost not at all. Text files will compress about 2:1.
With very few exceptions, customers tell me that the compression they see is typically very close to 1.3:1... which is in line with what you are actually seeing.

0000
So if I tell Acronis to not compress the data, will the tape drive automatically do that on its own, or do I need to tell it to somewhere?
0000

Well, I don't know for sure -- but if Acronis knows how to use a tape drive, it should know how to use the tape drive's compression. Look in the job properties, and see if there is a "HW compression" option.

As long as that is selected, the tape drive will use the compression path.

0000
I could split the backups into company info and "rest of C:", that'd work. It's currently doing a complete C: backup every night. Trust me, I've been trying to clean out files for months. We're at 3% free space and I'm running out of redundant files to clear out. Hopefully we'll get a server upgrade soon.
0000

Hey -- the really good news is that surveys of storage users consistently show that most companies only use 20 or 25% of the available space -- You're doing a remarkable job in exceeding all expectations!

The suggestion about splitting your job into two was thrown out only as a workaround, because I know that sometimes budget constraints prohibit other possibilities (like upgrading to an LTO-2 or LTO-3 tape drive for double or quadruple the capacity).

[Richard Bickers]

I just looked at the output from LTT's assessment test and it doesn't sound too healthy. The 1.4GB reported is per wrap (one pass up the tape) and that should be more like 2GB on a health drive. I'm suspecting some sort of error rate problem maybe from dirt, dust or contamination of some sort. Since the drive has been working well for two years, has there been any recent construction that could have blown dust in via the air conditioning?

Have you tried different tapes? Maybe the tape has got dirty. Can you use a cleaning tape? Maybe try 2 or 3 times to shift anything stubbon.

The drive is still going because they are very robust but a sudden drop in capacity (based on what the assessment test is showing) suggests an error rate problem and the drive is compensating by using more tape.

Can you attach the support ticket? We could tell a lot from that. Best pull one after your backup.

In general, software compression gives higher compression ratios than hardware compression (maybe 30% better) but they take a lot more in the way of system resources as Thomas says.

My gut feel is your issue *is* with the drive but maybe a clean will resolve it.

In the meantime you can carry on with reduced capacity but I'd worry that it could fail completely if the contamination gets any worse.

Perhaps this is a good time to upgrade anyway...

We'll take a look at the ticket if you can post it here.

[Chris Luthe]

Here is a support ticket I generated just now. Let me know if you'd like it in a different format.

[Richard Bickers]

Thanks. That's the best format as I can view it with LTT at my end and dig deeper.

It doesn't show what I was expecting though... It shows last few writes on various tapes having great margin and yet it also shows the assessment test failing with very poor margin on tape F64UP9N011 (which is different again). Is there something up with that tape?

Anyway, it does seem your drive is fine so that's good. Hardware compression is enabled too so that should be working too (although some apps can turn it off if configured to do so).

One thing you could try is to use the device performance test and write a full volume at 2:1 compression ratio. That will verify (a) the amount of data you can get on the tape and (b) that the performance is fine.

If you run the assessment test again on one of the good tapes and it fails I'd like to investigate a bit further. If so, then could you please attach the EventLog.ltt file to this thread.

Results are a bit inconsisent... but it looks OK for the last few tapes anyway though only tape F64TRNf436 was written full volume so it's not conclusive on the others.

Hmmm. Good luck.