Video Screencast Help

Backup Job compression change problem

Created: 14 Oct 2013 • Updated: 21 Oct 2013 | 11 comments
This issue has been solved. See solution.

Running BE 2012 SP2 on Windows 2008 R2.  Recently backup time and compression changed for one of my BE jobs that is a full backup of a VM guest server.  Job had been consistently running for 7-7.25 hrs.  Two weeks ago it jumped to almost 10 hrs and then this week it jumped to 12 hrs.  Last 12 backups are as follows (time/byte count): oldest to newest -  6:53/553GB; 6:56/564GB; 6:48/545GB; 6:46/546GB; 8:32/547GM; 7:04/560GB; 7:00/560GB; 7:06/559GB; 7:10/560GB; 7:12/559GB; 9:52/562GB; 11:53/564GB.  It is causing me use more tapes on my weekly backups.  I suspect the compression ratio is distinct to the job, but I have another VM with similar sizes that does not run into the time/ compression issue.  Any thoughts or input would be helpful.

Operating Systems:

Comments 11 CommentsJump to latest comment

CraigV's picture

GHi,

 

First thing to do is to rule out hardware...download your drive manufacturer's diagnostic utility and run a compression test against the drive using a spare tape.

If this passes, check the tapes to see if there are excessive Hard Write Errors which could indicate issues with the tapes themselves.

Thanks!

Alternative ways to access Backup Exec Technical Support:

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

pkh's picture

Other than some hardware problem, compression ratios are a function of the type of data being backed up.  If the data is already compressed, like zipped and movie files, sound clips, pictures, then compressing such data may result in more data than you have started with.  See my article below

https://www-secure.symantec.com/connect/articles/c...

JacobCrow's picture

It may be a hardware problem.  Craig, I checked the tapes in question and there were no hard errors.  I was going to do a compression check when I had a problem with the diag util and now the robotic drive is erroring out.  I did not think it was a hardware issue since the problem was isolated to one full server backup in particular.

pkh, I do not suspect a data issue since file types have not changed to any degree over the course of this particular server.  I will check/review your article just the same.

Once the hardware is fixed I will provide an update as to outcome.

Thanks for the input.

CraigV's picture

Jacob: If you're using HP Library and Tape Tools (HP LTT), did you remember to stop the BE services? If you don't then the drive doesn't get detected in LTT.

Thanks!

Alternative ways to access Backup Exec Technical Support:

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

JacobCrow's picture

Thanks, I did that.  In a process to check/update firmware the tape drive failed and would not connect properly to the robotic drive.  So I have a support case to resolve that issue.

pkh's picture

Before you run the LT&T utility, you need to stop all the BE services beforehand. Otherwise, BE is in control of the library.  When you run the utility, make sure you select the write test.

JacobCrow's picture

Yes, I did that but I did not get to the point to do a write test because the tape dive failed to connect to the autoloader after I attempted to update the firmware.  The update process just seemed to hang/lock up and I lost the drive.  I have a replacement drive coming today.  Hopefully that will resolve all my issues.  Thanks for the feedback.

JacobCrow's picture

pkh,  btw I am using an AP StorageWorks 1/8 Autoloader with LTO3 tapes and I do get compression.  I just started having problems with a particular job.  Hopefully it is realted to the robotic drive.  If not I may file a case with Symantec.

Regards.

pkh's picture

It could also be your tapes.  Check that the hard and soft errors do not increase significantly.  Also, try using some new tapes.

Jaydeep S's picture

Please let us know once you have the Tape hardware replaced if you still face this issue.

JacobCrow's picture

Thanks to all for your responses.  I had the tape drive replaced and that appears to have remedied the problem.  Expected compression rate returned to the job in question.

Regards

SOLUTION