LTO6 write speed in Veeam slower than LTO5

[martin_nz]

Hello
I have recently moved from LTO5 tapes to LTO6 in order to increase capacity of my backups. Since the change I have noticed that the write speed of the backups has dropped from 80Mb/sec down to 50Mb/sec so my backups are taking about 2 hours longer to complete.

Has anyone else encountered something similar to this inside Veeam?

[DaveWatkins]

Do you have one drive or multiple drives, and if multiple how many in the library? What are the specs of the repository you're backing up from and is it local to the tape drives or over the network? What do the bottleneck stats say on the tape job?

[martin_nz]

I just have one drive. The repository is on a SAN LUN (A VMDK attached to a server) and it is over the network. The bottleneck stats say the target is at fault.

[DaveWatkins]

I'm assuming it's a SAS connected drive? Is it a new SAS card or are you using the same card that you were using for the LTO5 drive?

Assuming the same card (so we know it's good), you could check the block size it's using under the drive properties in Veeam. I've got an LTO6 library here with IBM drives and it's using a block size of 1048576 (the max) and I can saturate the drives easily, although I'm also not pulling my data over the network. That's likely to be where your bottleneck will end up unless you have a 10Gb link from tape server back to the host with the repository on it

[martin_nz]

It's a SAS connected drive. The tape drive has always been an LTO6 drive but we have only just started using LTO6 tapes - LTO5 tapes that were at a lower capacity were used previously.

I have already increased the block size to the max. I certainly don't have a 10GB link from the tape server to the host with the repository on it.

[DaveWatkins]

Ahh, so it's not actually a new drive either, right.

The fact that you're pulling your data over the network is going to limit your max speed to less that the drive can do since the most you can pull is about 112MB/s and the drive will do 160MB/s even if you do have multiple 1Gb network connections at both ends, it's still a single stream, but as you aren't even getting close to that it's unlikely to be the problem.

If you haven't already it might be worth running a cleaning tape through the drive, and if that doesn't help try some different block sizes perhaps. My repo and drives are on the same machine so I don't have to worry about network bandwidth or latency from a shared storage system. The only other thing I can think it might be is that data matching speeds for LTO6 are higher than LTO5 and if you can't feed the drive above it's minimum data matching speed it'll have to rewind and slow things down massively. If that were the case thoguh I wouldn't really have expected the drive to be able to max out the LTO5 data rate that it was obviously doing.

I believe Veeam support has a tape drive testing tool that can confirm the drive itself can push it's full data rate. That might be the next step.

[martin_nz]

I will see if I can get the tape drive testing tool from Veeam and a different block size on the drive.

[martin_nz]

Just another thing - my source server with the data on it is also a veeam proxy. Will this have any impact?

[martin_nz]

Also, how does a Veeam tape backup processing rate differ to the throughput rate?

[DaveWatkins]

If other jobs aren't running at the same time it being a proxy shouldn't hurt it.

My understanding of processing rate and throughput (and I might be wrong on this one) is processing rate is before compression, dedup and encryption. It's basically a measure of how much data the system is reading/processing. For example on a backup with a VM that has corrupt CBT the backup will have to process the entire VM's data, but only write a small fraction. Throughput rate I believe is data sent to the target after compression, dedup and encryption.

When sending to a tape drive, I'd expect them to be the same or similar since you wouldn't be compressing them any further (since they are already compressed)

[EricB]

Hi, not that it will help you a lot but it's not like there is an LTO6 issue with Veeam V9 U1.
I'm currently running a deployment that uses an HP LTO6 solution and with that i get normal backup speeds with Veeam around 157MB/s which I sometimes am limited to 1GbE as some of the backup files are on a different server/scale out extent and the network connectivity is GbE. When the files are local on the server speeds go up further.

Like said earlier, network connectivity will be limiting but you also might want to check drivers and firmwares.
Other factors that might have an influence, dont select hardware compression if you are backing up veeam compressed files.
Also, you might want to do a test without encryption in case you have enabled it.