Slow tape backup using GFS Media Pool

[stewsie]

We have recently connected two tape libraries to the Veeam environment. The libraries are connected to a physical server and the Veeam components installed.

Our requirements are to run a weekly full backup to tape and I have been experimenting with the media pool type. Initially I was just using the simple media pool and running various tests and performance was OK. Yesterday I configured a GFS pool and ran 4 backup jobs. The throughput to tape is very slow. The tape drives are LTO 7 and there are two drives in each library.

When using the simple media pool, throughput can be as high as 160 MB/s whereas using the GFS pool the speed was as follows

27 MB/s transferred 70.5 GB took 56:05
24 MB/s transferred 161.5 GB took 2:17:33
49 MB/s transferred 212.7 GB took 1:24:15
28 MB/s transferred 69.7 GB took 57:10

Is this just the way that the GFS pool works? If so I will not be able to use it as some jobs with run into TB and may not complete before the next weekly would be due.

If my objective is just to take a weekly full to tape could I just use the simple pool, schedule the full on a specific day and schedule so the tape job runs only on that day?

Thanks

[skrause]

Are you sure your media pool compression/encryption settings are the same on each media pool?

This really looks like the kind of symptoms I would expect when using software vs library encryption.

Also, what does the job say the primary bottleneck is?

[saeed_bashir]

Hi stewise,

I am having exaclty the same issue as you have mentioed, kindly can you share your experince and let me now if you found any solution for this.

I need to use GFS media pool as we need weekly, monhtly and yearly, this is really strange that with normal media pool the throughput is higher then GFS media pool.

[Egor Yakovlev]

Depending on variety of factors that could be 100% expected behavior - for example, if you have only incremental restore point on disk on day of GFS Full, we will have to synthesize Full backup from backup chain you have on disk, thus taking more time.
Also make sure to compare performance for same backup copied over to different media pool types, as Simple Pool with 5 backup jobs as a source could give totally different results rather than GFS Pool offloading single weekly full due to the parallel processing(use multiple drives) and job settings(offload incremental to tape, for example).
/Thanks!

[saeed_bashir]

Thanks Egor, yes there are incremental backups as its a forever incremental so that was some thing in my mid as well that it is synthesiing backups but I am getting 110 Mbs with simple media pool and 30 to 40 MB with GFS, that is a big drop, also if I have not ticked the use tape compression option in Veeam I assume tape compression will be disabled correct..??..encryption is already disabled so just making sure compression is disabled as well becuase our onsite backups are already compressed..

[Egor Yakovlev]

What is your source repository type and which version of VBR you are running?
/Thanks!

[saeed_bashir]

Source repository is QNAP NAS and we are using 9.5 update 4

[Egor Yakovlev]

Any chance to upgrade to latest v10 P2?
We have had some improvements in v10 and in case NAS is added as SMB Share to VBR console you might see significant improvements in tape operations after upgrade.

[saeed_bashir]

Yes, we can but exsisting repo is not added as SMB share but as Windows type from server connected as local drive..

I just can not comprehend why only changing Meida pool would make it that slow..

[Egor Yakovlev]

Well, if you are ready to invest some time into troubleshooting, feel free to open support case as it surely does seem abnormal.
Please, make sure to update this thread with case ID if you choose to go with it, as I would love to follow the case and find the root cause as well.
/Thanks!

[Dima P.]

Muhammad,

I'd recommend to install the latest v10 prior opening support case and check the performance with new async engine for synthetic operations for tape: GFS rely on synthetic full backup if you are taping out the backup jobs in forever forward incremental backup mode, so you should notice the performance increase. Cheers!