BE 2010 Low hardware compression on one day only

[calspec]

We are running BE 2010 with a LTO-2 Dell PowerFault 110T.  We have a daily backup running using hardware compression.  On Wednesdays, the backup fails because the tape runs out of room.  It appears the tape is only running with a 1.1:1 compression ratio.  All of the other daily tapes run with around a 1.6:1 ratio.  I've replaced the tape twice with new tapes and had the same result.  

The server is running 2008 R2, is our DC and AD controller, it is the only active server on the domain.  I've changed all scheduled tasks to the weekend, as far as I can tell from Event Viewer the server isn't running any other tasks that would cause the compression to slow.

We have McAfee SonicWall Enforced Client AV that's running Wednesday nights that could potentially cause this error, however this is a recent occurance.  What could be causing the compression to fail on one day only?

Thanks,
Steve

[Larry_Fine]

The compression ratio is controlled by the tape drive, not by BE, and is very dependent upon the data being fed to the tape drive.

I would look closely at what is being backed up on Wednesday, compared to the other days.

Are you running full daily backups?  or some sort of incrmental/differental?

[calspec]

It's a daily full backup using archive bit.  The same job runs daily.  The same data is backed up Wednesday as every other day.  That's why I was thinking it had to be some service that's eating it up on Wed and possibly causing the lag in data being fed to the drive.

The AV is SAAS, so perhaps it's causing network traffic that slows the server.  As far as I know, the server isn't part of the Wed scan, only the attached desktops.

I suppose I can change the scan to Tuesday and see if the failure tracks.  If so I'll just scan on the weekend when no backup runs.

[pkh]

Is the selection list the same for all days? Is it the same job for all days?

[calspec]

It's the same selectionl list and same job for all days.  It's the only job.

I'll know if it will fail tomorrow night, I scheduled the AV scan for Tues instead of Wed.  I'll report my findings.

[calspec]

It failed again last night (Monday Night), so I think there's something besides the AV causing it as AV doesn't scan until tonight (Tues Night).

I dug through all the errors and I was mistaken.  In addition to failing on Wed, it has failed one Mon and two Tuesdays.  I should also note this is a recent development, we had over a month of successful backups prior to this last month.

I am looking into upgrading our drive, but in the meantime I was hoping to get this problem fixed. I've cleaned the SCSI connections and drive heads and am re-running last nights job with the same tape.  We'll see if it passes.

[pkh]

It could also be that the tape is very close to full and any small addition to the backup caused it to overflow

[calspec]

We are definitely approaching the limit so a new larger drive is in the works.  With compression, it's about 175GB of 200GB, so there's not a lot left.

I just re-ran the same backup job on the same tape after re-seating cables and cleaning drive heads and it passed this time with a 1.5:1 compression.

Hopefully we can get a little more life out of it.

Thanks for the help,

Steve

[pkh]

A tape library would be better.

[calspec]

I agree.  The problem is the amount of zeros on the end of the price tag. 

It ran fine again last night with decent compression.  We'll see if it continues for now.

[calspec · Accepted solution]

It was a dirty drive.  I had to disassemble and clean the drive manually, using the cleaning tapes wasn't cutting it.
All is well now with 1.6:1 compression ratio every day.

Thanks,
Steve