Hi
Just trying to get the most of my current environment with regard to backup performance. So was hoping to list my current setup below and see if anyone can give me some possible improvements.
I am running VMware - 3 Hosts - HP MSA 2050 SAN all SSD - 10Gig networking - 15 VM's
Veeam B&R EssentialsV10 is running on a Dell R620 Duel 6 Core Xeons - 48GB Ram - 10Gig networking. Main repository is a QNAP NAS 10gig Networking linked to the R620 as a local drive using the iscsi initiator and formatted using Refs (64k block size). The drives are WD RED Pro's set up in RAID 5.
I have my repository set to 6 concurrent tasks and my proxy set to 6 concurrent tasks. (I did have my SQL VM set as a proxy as well but i have now disabled it as that VM takes the longest to backup)
I have 1 backup job that runs at 6pm Mon-Fri on a incremental basis. The 2 machines that take the longest to back up are my Sql box and my DC. My DC stores all our user profile disks as vhdx files, so the transferred data is about 70gb each night and that's half of all transferred data for the whole job. This may just be normal but thought i would ask the question.
I then have a Backup copy job linked to the above to a cloud connect partner. This can take 12-18 hours to complete over a 50mb connection. I have asked the cloud connect partner for a new repository that is formatted to Refs in a hope that will help.
If i have missed any information please let me know.
I am a in house IT manager so my Veeam knowledge to limited to what i have taught myself with our own environment.
Thanks in Advance
Stephen
-
- Novice
- Posts: 3
- Liked: never
- Joined: Jul 25, 2019 10:14 am
- Full Name: Stephen Roberts
- Contact:
-
- Veeam Software
- Posts: 3625
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Performance Issues\vhdx best practice
Hello Stephen,
Where is the "bottleneck" according to job statistics? Basically, if job fits your backup window you'll have nothing to worry about.
Regarding backup copy: if the "bottleneck" is not on the Source side, then the issue should be addressed on provider side, a new repository might be a good idea.
However, WAN acceleration might increase data transfer speed through the network, I guess low-bandwidth mode will suit you as WAN connection does not exceed 100 Mbps in your case.
Thanks!
Where is the "bottleneck" according to job statistics? Basically, if job fits your backup window you'll have nothing to worry about.
Regarding backup copy: if the "bottleneck" is not on the Source side, then the issue should be addressed on provider side, a new repository might be a good idea.
However, WAN acceleration might increase data transfer speed through the network, I guess low-bandwidth mode will suit you as WAN connection does not exceed 100 Mbps in your case.
Thanks!
-
- Novice
- Posts: 3
- Liked: never
- Joined: Jul 25, 2019 10:14 am
- Full Name: Stephen Roberts
- Contact:
Re: Performance Issues\vhdx best practice
Hi Petr
Thanks for the quick reply. The bottleneck on my main job is "Network" at 50% on the cloud connect job it is also "Network" but at 85%
We are on Essentials licencing so we dont have WAN acceleration. Does it make much difference?
Thanks
Thanks for the quick reply. The bottleneck on my main job is "Network" at 50% on the cloud connect job it is also "Network" but at 85%
We are on Essentials licencing so we dont have WAN acceleration. Does it make much difference?
Thanks
-
- Veeam Software
- Posts: 3625
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Performance Issues\vhdx best practice
Yes, it can give significant performance increase but can be used only with backup copy or replication jobs.
You may increase number of upload streams and test a backup job. One more idea is to change block size from default to LAN target at the level of backup job settings, it might shorten duration of both backup and backup copy jobs as you will have less data to transfer.
I'd recommend to test both of these ideas separately and together to understand which approach is more efficient in your particular case.
Thanks!
You may increase number of upload streams and test a backup job. One more idea is to change block size from default to LAN target at the level of backup job settings, it might shorten duration of both backup and backup copy jobs as you will have less data to transfer.
I'd recommend to test both of these ideas separately and together to understand which approach is more efficient in your particular case.
Thanks!
Who is online
Users browsing this forum: Amazon [Bot], lohelle, Stabz and 103 guests