Hello trnc,

So with backup exec it will compress any file that is not already compressed before it send the data to tape.  Now if the data has already been compressed then in most cases backup exec will not compress it a second time before sending the data to tape.  So in your case since the DR4100 is compressing the data backup exec will compress any file that is not compressed and then it will send the data to tape.

Please let us know if you have any other questions.

Hi,

The data is rehydrated as it goes to tape so yes, it should be able to be compressed.  

are you using software or hardware compression to the tape?

Are you comparing the deduped byte count or the original backup byte count? you won’t see the same compression as you saw in  dedupe

Does the tape indicate that the data is compressed or uncompressed?

Thanks, lmosla. that was my understanding. I'm trying hardware compression - software compression was not an option for the duplicate job. I didn't expect the same compression on tape that we do for dedup, but we aren't getting any. For the jobs that go straight to tape, I typically see ratios of 1.4:1 or 1.5:1. the tape indicates no compression. 3 tapes fill up and wait for a 4th. The same source straight to tape fits on 2.

Here is something from the scsi trace file I submitted in the Symantec ticket:

OK, I ran the scsi trace using the first few seconds of the actual job that didn't compress. I'm attaching the relevant events, but the short story is:

Event 1014 - Mode_Select6 shows the compression set

Event 1015 - Mode_Sense6 shows no compression

Event 1018 - Same as 1014

Event 1019 - Same as 1015

Even 1022 - Write starts

Sent. Thanks.

trnc can you send a PM to me with your Symantec case number so I can review the case notes?  thanks!