Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Backup Exec 12 selectively compressing tapes

Created: 14 Feb 2013 | 15 comments

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. 

Comments 15 CommentsJump to latest comment

CraigV's picture

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!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Larry Fine's picture

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

If you find this is a solution for the thread, please mark it as such.

pkh's picture

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's picture

@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's picture

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's picture

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's picture

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

If you find this is a solution for the thread, please mark it as such.

TheHelpful1's picture

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's picture

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.

If you find this is a solution for the thread, please mark it as such.

TheHelpful1's picture

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's picture

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

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

TheHelpful1's picture

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

Larry Fine's picture

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.

If you find this is a solution for the thread, please mark it as such.

TheHelpful1's picture

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's picture

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.