Backup exec 2010 not filling tapes. Why?

[peet]

Hi,

We're running Backup exec 2010, Version 13.0 2896. Our tape drive is a HP Storageworks 1/8 Autoloader 448. Product No AF203A using LTO2 tapes (200/400GB) so we have a total uncompressed capacity of  8 x 200GB => 1.6TB. Compression is set to "Hardware [if available, otherwise software]".

In our Full monthly backup, we are currently backing up 1.7TB worth of data (with varying amounts of compression), and the backup is using all 8 tapes.  The Media/Job is set to Overwrite, Not appendable. This is one job, with a single selection list covering 9 servers.

We have noticed that some tapes are not being filled before moving onto the next tape (See below 1st, 2nd and 6th tape). Effectively we have 260GB of data hogging 600GB worth of tapes. (uncompressed.) Why? 

Media Label	Allocated Date	Appendable Until	Used Capacity	Data	Compression Ratio
LTO000009	29/10/2010 22:02	Not appendable (Media full)	195.3  of 195.8	88.98	1:1
LTO000013	30/10/2010 2:31	Not appendable (Media full)	195.3  of 195.8	88.46	1:1
LTO000075	30/10/2010 6:12	Not appendable (Media full)	195.3  of 195.8	267.52	1.4:1
LTO000078	30/10/2010 10:18	Not appendable (Media full)	195.3  of 195.8	212.90	1.1:1
LTO000034	30/10/2010 16:18	Not appendable (Media full)	191.8  of 195.8	348.24	1.8:1
LTO000025	30/10/2010 19:39	Not appendable (Media full)	195.3  of 195.8	86.66	1:1
LTO000003	30/10/2010 22:46	Not appendable (Media full)	189.1  of 195.8	269.69	1.4:1
LTO000044	31/10/2010 2:40	Not appendable	77.9  of 195.8	232.20	3:1

Why are we seeing such random and inconsistent behavior? Does Backup exec not sequentially fill tapes and move on to the next?

Is the log/report information unreliable or inaccurate? or can we trust it, and take it at face value?

How should Backup exec work? Can we control or influence this?

[peet]

I have read many threads which seem to describe symptoms similar to mine, with no satisfactory answers.

This is not about compression, (we understand there is varying degrees of compression.)

The key point is, why does BE leave half a tape (or more) un-used, MARK IT AS FULL and move onto the next?

[Ken_Putnam]

I know that when v11 came out it had problems with LTO2 (specifically) drives doing this

As I recall, the solution was to use the mfg utility to initialize the tapes, rather than inventory or label within BackupExec itself

[peet]

Thanks for your reply. Sorry I'm a bit new to this. Can you please explain "mfg utility"? Thanks.

[Ken_Putnam]

Sorry,

The installation CD for the drive (providied by the manufacturer) should include a utility to manange it.  Use that to initialize or label the tapes  before letting BackupExec see them.

If you do this to tapes that currently have data on them, BackupExec will no longer be able to get to that data, so only do this when you get ready for a job with tapes that have not been initialized this way

[peet]

Great, thanks. We are discussing trying a few things and testing them this weekend. Will update with progress/findings.

To others: But for obvious reason I consider this an open/unresolved issue until we get positive results. So I would still appreciate any other suggestions or input.

[pkh]

You should look at the Used Capacity column.  This is the amount of data that is actually written to the tape and you can see that it is writing to the native capacity of the tape. 

Check your job log to see what kind of compresson is actually being used in job, hardware or software.

A reason why for the first tape 89GB of data is written as 195GB onto the tape is that some data compress badly.  For example, if you try to compress zipped files or jpegs, you actually end up with a bigger compressed file than the original.  For other types of data, e.g. text files, you can get very good compression.  An example of this is your LTO000034 tape.

[peet]

So then the ratio is actually misreported? If 89GB is taking up 195GB of tape then actually it's getting negative compression ratio of 1:2.2?

I find it frustrating that I don't know what data or report content I can reply upon or trust. 

[pkh]

There are some problems with the compression ratio.  I normally look at the actual data sent to the drive (your Data column) and the Used Capacity.

Another thing to note is that you will get very poor compression if the data are encrypted.

------------

If you are satisfied with the answers, do close out this discussion by marking one of the answers as the solution.

[peet]

Is there any way we can conclusively prove or disprove this?

Interestingly if I read the colums as you suggest, we would almost be no worse off without any compression. 1,595GB vs 1,435GB.

As some parts appear to have negative compression, and others have very good compression, Would it be feasible/plausible/adviseable to break the job up and back up half with compression and half without?

Thanks again for your input and suggestions. How did people solve anything before the internerd?

[Ken_Putnam]

As some parts appear to have negative compression, and others have very good compression, Would it be feasible/plausible/adviseable to break the job up and back up half with compression and half without?

You could certainly do that. 

(I  beleive someone has already mentioned that encrypted or previously compressed data may indeed expand when compression is attempted again.)

[pkh]

Is there any way we can conclusively prove or disprove this?

I assume that you are talking about the negative compression ratio.  You can play around by zipping up various types of files and see the results.  The compression ratio may not be the same as what you get from BE as the compression algorithm is different, but they would give you a good indication of what is happening.

You can certainly split up the job, but first you have to identify which data compress well and which do not.  Also, you would have to decide what to do with directories which contain a mixture of both types of data.  It would be an interesting acacemic exercise, but personally, I would not spend the time to do it.  It is easier to get more tapes.