Elapsed Time increase, Job Rate reduction and more tapes required

[Marcopolo]

Our last two full backups, which run every Friday have suddenly increased in Elapsed Time and reduced Job Rate (our differential look fine), to the point that their running into Tuesday Morning for Verify (usually verify finishes early Monday AM).

There have been no changes (even if there was I would expect to see the differential reported differenty) to the server OS that I can see.

Also, the byte count compared to one of late July is the same (file count and area size aren't that different) but it now requires two additional tapes (800gb/1.6tb).

The only obvious observation is maybe a tape clean will help but any other thoughts on these additional times and tapes required?

I can see the Compression Ratio is 1:1 but two additional tapes and no apparent byte increase is not logical

[CraigV]

Compression plays a major role in the number of tapes required. 1:1 = no compression at all which will mean additional tapes.

Have you made sure there are no maintenance tasks starting on a Friday night? AV scans, Windows, storage/server maintenance, application maintenance etc? Also, check the write statistics on the tapes to rule out Hard Write Errors = problems and the tapes can probably be replaced.​

You should also download your tape manufacturer's diagnostic utility and, after stopping the BE services, run a write test with compression to see if this is working.

Thanks!

[Marcopolo]

I'm just not convinced how the 'near' same byte count can all of a sudden require 2 x additional 800gb native tapes (It's bad enough when you see the 'Data' written is so low compared to the used capacity). It doesn't fill one with confidence seeing 370gb media full on a 800gb / 1.60tb, then you calculate 12 x 800gb native whiich reads even worse.

There are no tasks on this server and nothing new has been added anywhere.

I'll run some tools and report back, as well cleaning the heads.

Thanks

[Larry_Fine]

Are you stating that your tapes are getting marked as "full", even when they only have 370 GB, which is well short of the native 800 GB capacity?

It sounds like you may have a clogged tape head.  This technote should help.

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

[pkh]

It could also be that the tapes are bad causing a lot of retries and having a lot of areas marked as unusable, thus reducing capacity and increasing backup time.  Check the error counts of the tapes, especially the hard errors.

You should try using some new tapes.

[Marcopolo]

Yes Larry, that's correct. Thanks, I'll have a read and report back.

pkh, these were new tapes that we used

[Marcopolo]

Quick question about the compression test referenced in the document above. Can I use a new tape for the test, or do I need to use an existing tape?

[pkh]

You still need to check the error count. If they are high for all your new tapes, then there is something wrong with the tape drive

[Marcopolo]

There's 160 soft write errors on one tape and 333 on the other, so I'm not too worried about those.

[Marcopolo]

Just to clarify this, Under Devices and viewing each media slot.

Appendable Until field reports (Media Full)

Used Capacity field reports 779.8GB of 781.5GB which looks correct

Data field fluctuates as mentioned, never reaches anywhere near 780gb

[pkh]

The actual amount of data that you can put on a tape with compression is highly dependent on your data. If you are compressing darts which are already compressed like zipped files, movies and sound clips then you may end up with more data then you started with. See my article below https://www-secure.symantec.com/connect/articles/compression-short-explanation

[Marcopolo]

So are you saying a tape that has 779.8GB of 781.5GB used but reports the 'Data' written to tape of 513gb is compressed data and it reports it this way because once uncompressed the amount is larger?

I've added up our Tape Backup, and it's about 5.5TB (going by the BE job log), which still doesn't equate to 12 x 800gb native tapes.

Sounds to me that it would be better to backup actual file size because nothing adds up!

[Larry_Fine]

http://www.symantec.com/docs/TECH193200  suggests running a capacity test with compression turned off, specifically to avoid any confusion about what may (or may not) be happening with compression (or even worse, reverse compression).  The native capacity of a tape cartridge is the only that the vendor guarantees, so that is what should be tested.

Simply put, if you have a tape that is marked full and only has 513 GB when it should hold at least 800 GB, then you are a prime candiadate for having a clogged tape head, which, unfortunately, is generally not user-fixable.

As far as I have heard, it doesn't matter if you use a new or an old tape for this test.  Your errors counts sound reasonable, so I doubt that media with a couple hundred soft (recovered) errors is bad.

[pkh]

Turn off compression in your job, run a backup and then add up the Data written