Slow repso backup to tape

[HussainMahfood]

I was using Symantec to backup the two vbk files each end of the month. It was taking 8 hrs and 50 mint.

Now using veeam tape backup feature. Backup repos to tape it is taking almost double the time. Almost 16 hours


Any comment on that and thanks in advance

[Dima P.]

Hello Hussain,

Could you please clarify how you set up backup to tape job in Veeam v7, as I believe your tape job collects more than one .vbk - and that’s why it is taking so long?

[HussainMahfood]

I am selecting repos as source to take backup and only full type backup. I disabled symantec services and used manufactor drivers

It shows backup size 3.5 tb as as the size of the vbk files. I use reverse incremental on the daily backup job to disk

Still backup time double than Symantec

Any tips ?

[veremin]

The question is how many .vbk files you have in the said repository and how many you copy with the other software vendor? Also, what are the bottleneck statistics for this job? Thanks.

[CeeAr]

Hi,

i'm seeing the same here. Backup to tape takes longer as with backupexec.
Veeam reports 92 MB/s at an average. There are very nice peeks at 140 MB/s but also sections with 40-50 MB/s. If i would see this with backupexec i would check the cache settings. Is there anything similar for B&R?

Thanks

[foggy]

Do you copy the same amount of data as previously with BE? Is it just the initial job run or the same is observed on subsequent job runs also?

[veremin]

Is there anything similar for B&R?

Nope, there is no cache concept in case of tape jobs. Thanks.

[CeeAr]

Yes, it's the same amount of data. i didn't change the VM backup to disk jobs.
The screenshot is from a full backup of one VM. As the incremental's are quite small it only hurts when performing full backup.
The last (and first) veeam full backup was about 12 TB and took 40 hours (88 MB/s)
BE: Last Full 13,7 TB, 30 hours (133 MB/s)

[CeeAr]

Nope, there is no cache concept in case of tape jobs. Thanks.

Just to be sure... I'm talking about drive cache settings.

[veremin]

You mean the tape “buffer”, right? This setting exists on device level and is “transparent” for us. That being said, whatever buffer size is supported/used by certain device, it will be used by Veeam Backup and Replication. Thanks.

[CeeAr]

You mean the tape “buffer”, right? This setting exists on device level and is “transparent” for us. That being said, whatever buffer size is supported/used by certain device, it will be used by Veeam Backup and Replication. Thanks.

Yes, i think so Thank's for clarifying

So, is there anything else i can do? Do others have such varying transfer speed to tape?

Thank you

[NightBird]

Same problem here.
Remote repo, gigabit connection.

Before with CA ARCserv the Gigabit link was saturated (ie 900mbits/s) now with native tape support about 500-600mbits/s the network flow is unstable.

[mongie]

I find Veeam tape writing to be much slower than Backup Exec as well...

I also find the way that Veeam will write all full backups in a chain to tape to be seriously frustrating. When I have a file server backup that is 3.5TB for 1 VBK, its pretty annoying to somehow have to backup 4 fulls, when I run a tape backup.

[Gostev]

To all: remember this was 1.0 version of tape support, and our primary goal for the first release was stability and wide device support, not performance. It is better to handle the data reliably, than fail fast we can always work on improving performance in future releases! It is really a good problem to have, when pretty much the only complaint on a massive new feature is somewhat slower performance (not even by order of magnitude, less than 2 times).

@NightBird do you know if CA uses proprietary tape format, or MTF? We went with standard for better compatibility, however it limits us in some acceleration techniques only possible with proprietary formats.

@mongie can you please explain the issue in different words, as I don't fully understand? If it's unrelated to performance issue discussed here, please create a new topic.

[CeeAr]

It is really a good problem to have, when pretty much the only complaint on a massive new feature is somewhat slower performance.

I totally agree. It's still a huge advantage over BE. Just want to make sure that we didn't miss something.

[veremin]

I also find the way that Veeam will write all full backups in a chain to tape to be seriously frustrating. When I have a file server backup that is 3.5TB for 1 VBK, its pretty annoying to somehow have to backup 4 fulls, when I run a tape backup.

Feel free to post your feature request in the corresponding thread. Not only does it have a workaround that allows bypassing existing limitation, but also it helps us to have all eggs in one basket, thus, understand better the strength of users' demand for particular feature and make a decision accordingly.

Thanks.