Backup Exec 12 selectively compressing tapes

[TheHelpful1]

We have an HP tape loader partitioned for 4 daily backups (one tape each) and one weekly backup (3 tapes). The tapes are LTO-1 with compression and recently the tapes seem to be selectively choosing when to compress the data. Our RAID data to be backed up is 557GB so with the LTO-1 compression, we should be able to back up 600GB, but around 446GB, the third tape is filled up and we get the prompt to "Please insert overwritable media into the robotic library using the import command." and Event ID 58064 is written to the event log. If compression was not working at all, then we should not have been able to write past ~300GB and if the third tape was not taking compression then it should have triggered at 500GB and not 446. I tried changing the Advanced setting from backup following Junction points to Symbolic links but that made no improvement. 

Installed update are SP5, Hot fix 358179, 141388 and 155482. Server OS is 2003 R2 SP2. 

[CraigV]

Hi,

Could be faulty tapes...especially since they are LTO1.

Check under Media and go to a tape that doesn't use compression, check for Hard Write Errors...if excessive, it indicates faulty/old tapes.

You can also do a compression test on 1 of those tapes using your drive manufacturer's diagnostic utility...

Thanks!

[Larry_Fine]

You may have a tape drive issue.  I suggest filling up one tape without using compression to test the tape drive.  If you have a clogged head, it would impact the native capacity so you would get less than 100 GB.

http://www.symantec.com/docs/TECH193200

Tapes report full before their Native Capacity is reached

[pkh]

The native (uncompressed) capacity of a LTO1 tape is 100GB.  You said that your 3 tapes filled up at the 446GB mark.  With this you are getting almost 1.5:1 compression ratio ( = 446/300).  This is a very good compression ratio.

LTO1 tapes are marketed as 100/200 GB.  The 200GB capacity is a marketing thing and it represents a 2:1 compression ratio.  This ratio is hardly achievable in real-life.  Typically the compression ratio with real-life data is closer to 1.2 - 1.3.

In your quoted example, your first tape could hold 160GB, the second 150GB and the last one 136GB, or some other combinations.  All of which are good compression ratio.  It is not necessary that your first 2 tapes hold  200GB each and the last one hold only 46GB.  The compression ratio can vary between tapes, even if they are used by the same job.  It all depends on the data being written at that time.

BTW, unless you have good reasons, you should not be following junction points and symbolic links.  Do read the Admin Guide for a fuller explanation of what this does.

[TheHelpful1]

@Craig V: We've actually tried several different LTO1 sets, most of which are brand new and run the daily backups fine.

@Larry: Will try that today on a weekly tape to see how much data gets consumed without using compression

@pkh: Our last successful offsite backup consumed 440.47GB and took ~14 hours to write at 871MB/min. With the exception of writing daily SQL bak files, the majority of the data is static. As best I can tell its those last 6GB that broke the camels' back. Also this was more of an inherited system so I'm not an expert on BackupExec. So you are saying neither junction nor symbolic should be checked? 

[pkh]

you are saying neither junction nor symbolic should be checked? 

Yes.  Unless you have very good reasons to follow them.

Regarding your tapes, they are full.  Any slight increase will mean that another tape is required.  I doubt there is anything that you can do to improve the situation.

[TheHelpful1]

Updates. I ran one daily backup without compression and instead of consuming ~33GB it took about 80GB so I know the software compression is working.

I got approval to exclude some data sets from the weekly backup which dropped the backup size from 470GB to 385GB. The kicker is that I got one successful backup that had 440GB of data and now with just 377, it failed again to compress to just 3 tapes. Without compression, I should have been able to write almost 300GB to tape (ignoring the base 10/0 change in converting the actual bytes) so even with modest compress I'm puzzled as to why I couldn't get ~377 on three tapes.

[Larry_Fine]

were you able to do the test to fill a tape with uncompressed data to see if your drive is working properly?

[TheHelpful1]

I don't have enough data to fill up the daily tapes uncompressed, but the weekly tape set do show as full before moving on to the next tape in the partition. 

Going back over my logs, I can't see why some offsite tapes were able to hold a lot more and others just dropped off. Every cancelled entry was one where it required more than 3 tapes. 

Name	Job Status	Percent Complete	Start Time	End Time	Elapsed Time	GB	Job Rate
Offsite	Successful	100%	11/30/2012 22:00	12/1/2012 5:14	7:14:50	259	1,082.00 MB/min
Offsite	Successful	100%	12/7/2012 22:00	12/8/2012 5:56	7:56:06	362	1,283.00 MB/min
Offsite	Canceled	N/A	12/14/2012 22:00	12/17/2012 13:51	63:51:53	315	851.00 MB/min
Offsite	Successful	100%	1/23/2013 11:33	1/24/2013 0:10	12:36:52	434	1,105.00 MB/min
Offsite	Successful	100%	1/25/2013 22:00	1/26/2013 13:39	15:39:02	439	872.00 MB/min
Offsite	Successful	100%	2/1/2013 22:00	2/2/2013 12:27	14:27:34	440	871.00 MB/min
Offsite	Canceled	N/A	2/8/2013 22:00	2/9/2013 21:00	23:00:20	444	861.00 MB/min
Offsite	Canceled	N/A	2/11/2013 10:59	2/12/2013 9:59	23:00:08	443	1,108.00 MB/min
Offsite	Canceled	N/A	2/12/2013 10:36	2/12/2013 23:43	13:07:09	447	1,114.00 MB/min
Offsite	Canceled	N/A	2/12/2013 23:48	2/13/2013 13:43	13:55:02	298	805.00 MB/min
Offsite	Canceled	N/A	2/14/2013 11:49	2/15/2013 9:46	21:57:30	447	1,120.00 MB/min
Offsite	Canceled	N/A	2/15/2013 22:00	2/19/2013 9:34	83:34:44	446	881.00 MB/min
Offsite	Canceled	N/A	2/22/2013 22:00	2/25/2013 11:07	61:07:48	386	685.00 MB/min
Offsite	Canceled	N/A	2/25/2013 11:21	2/27/2013 9:37	46:15:54	348	913.00 MB/min

[Larry_Fine]

re: I don't have enough data to fill up the daily tapes uncompressed

You can run a job multiple times to fill up a tape.  I suggest creating a temporary test media set to avoid confusion with your real backups.  If you have 100GB native tape and only 40GB of data to backup, just run the jobs 3 times, appending data.  You can cancel the job when the first tape gets full.  There is no need to actually span to a second tape.  Then look at the properties of the tape.  If it is significantly less than the native capacity of the media, then you have a hardware problem.

[TheHelpful1]

Ok, chose enough files to fill up the test tape and it queued at 99.30 GB of data (no compression) when trying to write 100 GB worth of data.

Tape properties say used cap 97.8GB and avail cap 90.0MB and compression ration 1:02:1. All totalled this tape has written 4.18TB and read 4.05TB with 134 mounts. 

[CraigV]

...and any Hard Write Errors that are excessive?

[TheHelpful1]

Nope. Hard read and write are zero. Soft read and write are 95 and 597 respectively. 

[Larry_Fine]

So it looks like you can cross my idea of a clogged tape head off the list of possibilities.

So i would follow the other posters suggestions of focusing on media issues or different data sets that are not compressing as well as other data sets.  To isolate the compressibility of different data sets, you would have to back them up one set per tape (with overwrite) then look at the tape properties to see what compression was obtained.

[TheHelpful1]

The daily tapes have one consistent data set with the only dynamic data being SQL bak files. The weekly tape set is the standard daily set, plus the system state of the host and the quarterly backup ghost images for the core member servers. All totalled the data that needs to be written to tape is about 377GB, so I can see why the last set stopped at 348, but having the same brand of LTO-1 tapes across the board for slot 3, I don't understand why the last successful set wrote 440GB. 

At least in the case of the last attempt, the third tape (new, out the box and added to the weekly set) does show it wrote 199GB of data for its first run.

[TheHelpful1 · Accepted solution]

I finally got a successful backup 348GB of data for 3 tapes, the last tape having used 84.6GB of 97.9GB. Software compression was used, but as some have suggested, it looks like the tapes themselves are the culprit. If all were compressing like tape 3, I should be able to fit at least 450GB across 3 tapes without any issue. The fact that tape 1 and or tape 2 didn't fill out their max under compression before tape 3 was called seems to be the culprit. I manually totalled up my selection list and it only came to 334GB worth of data so that leaves ~14GB from the system state backup. 

Tape 1 and 2 have been in rotation for several years, being written to once every 10 weeks for offsite storage so hopefully I can use this as leverage to upgrade our tape loader to an LTO 2 or even 3. This week I'm going to load all brand new tapes for the offsite to test my if using brand new tapes will get me back to the capacity I use to have.