Backup Compression not working?

[fga]

Hello together,
before i open a support ticket and open pandoras box with it i'd like to ask ya'll for your oppinion on the following topic:
We run the latest Veeam 11 Build 11.0.0.837 & VMWare 7.0.2
Tape drive: Native LTO 7 FC (Changer) with LTO 7 Media.
Repository: Server 2016 on REFS

Backup compression settings for the vmware job are set to high.
Yet we are seeing speeds way over 300MBytes/Sec going towards our LTO 7 FC drive. Not peaks. nearly permanent.
30 Second average on the fabric switch suggests around 350-370Mbytes/Sec.
Windows Task Manager on the repository box somtimes even shows speeds as high as 500Mbytes/Sec reading from disk.

So from my understanding a LTO 7 drive can not achieve speeds over 300MB/sec without applying internal compression right?
A regular half hight drive should do even less.

What i expect to see:
When Veeam compression works as intended i should nearly never see speeds above 300MB/sec going towards the tape drive.

What i do see:
Almost always speeds above 300MB/sec which suggests the drive is applying its own compression and Veeam compression is not working as good as it should. Specially on the high compression setting.
This is too seen in the fact that i can store close to 6.5 or even 7TB on a LTO7 Cart (5.5TB Native).

What do you think of this?
(Posted in VMWare cause i think this is a source related thing not tape related)

[Andreas Neufert]

LTO7 performs 300MB/s as sustained speed and can handle some faster bursts usually (it has a write cache). 750MB/s if you use compression.

As you have already compressed data with Veeam, you should not see much more speed than 300MB/s depending on the extra tape compression. If there are extra speed then it come allong with some compression.

Veeam Caches Data in RAM so a reading from disk can be higher as well for some time.

You values above are on different level. Some show MB/s (Bytes per second) and some show Mbps (Bits per second).
Maybe do the math yourself by processing time vs write statistics from the tape (should be visible within Veeam and in the Tape Library Management).

If you have concerns, please open a ticket at our support and they can have a look.

[fga]

Well i wouldn't say concerned. I'm just curious why i see such a difference when there shouldn't be one.
All values i wrote are given in MBytes/Second. Sorry for not writing them out all the time.
FC Fabric shows at the time of me writing this a 30 second average of 2.9Gbits/sec (plus minus a bit) at the FC Ports of Repository and Tape which translates to roughly 360MBytes/sec. which is what i also see in Task Manager. So the numbers do match.

As said: As we are running high compression level in veeam this doesn't really make sense to see such high speeds towards the tape drive.
I'd expect to see speeds in the region 250-290MBytes/Sec (2-2.3GBits/sec). Not 350+

[Andreas Neufert]

It is a bit hard to say from the outside what happens here. Usually tape vendors have caches in the drives that allow you to "burst" additionally 50MB/s. If then there is a compression algorithm hit it could explain it.
Maybe others can comment here about their experience. But the above looks like that we hit the nail in case of performance in your environment.

[fga]

Okay. just to be very precise here and to not to confuse anybody:
I am not complaining about backups beeing too slow. Absolutly not.
What i am seeing is that backups to tape run too fast in comparision what i would expect from the source files (veeam high compression).

So from my point of view: The Tape drive applies compression where veeam already should have compressed.

All i'm curious to know at the moment is: is this expected behaviour? From what i'm reading in the forums its not. I should have gotten close to the maximum amount of compression from veeam alone already so the tape shouldn't be able to compress the files more. Right?

Just more Info on the Repo in case that was missed out:
Server 2016 with REFS, Use per-machine backup files on, Decompress backup file data blocks before storing OFF.
All Jobs that run have set: inline dedup, compression level high, storage optimization WAN target
I know i store locally but this gives the smallest incremental files. Speed from the SAN is not a concern. We are limited in Backup speed from the SAN to the Repository by the FC Controller (8Gbit).
All I care for is the smallest possible backup files.