• EN
Solved

Veeam Backup Job - Startting time I/0 load

  • 12 November 2023
  • 4 comments
  • 44 views
NemanjaJanicic
Userlevel 7
Badge +1

Hello,

We had 13 Backup Jobs that were all started in the same time period from 21:00 to 22:00.

VBR server had 32 GB of RAM and 10 cores. It was a VM.

All Backup Jobs were with single VM inside of it.

Was this good approach or it was too much for our VBR Server to handle.
We didn’t have any off-host Proxies and VBR Server and 60% of VMs were on the same Hyper-V host.
It was acting then as only proxy for those jobs as I can assume.

What would be the better approach on this?
I’m still trying to grasp Veeam with his technologies as best I can..

icon

Best answer by HunterLAFR 12 November 2023, 22:25

View original

4 comments

Chris.Childerhose
Userlevel 7
Badge +20

It is usually best to stagger jobs so there is not much overlap.  Other than that things sound fine for your setup.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
HunterLAFR
Userlevel 7
Badge +8

Hi @NemanjaJanicic 

Looking at your info, is hard to tell, and also my knowledge regarding Hyper-V is limited, but,
https://helpcenter.veeam.com/docs/backup/vsphere/limiting_tasks.html?ver=120
here you can read the recommended specs depending on workloads, tasks, etc for the VBR Server,
and get an idea of tasks limitations, how to manage them, limit them, etc.

The amount of vms is important, but more is the number of virtual disk that the VBR is backing up.

I normally deploy 1 Proxy Server per Host (Node), to help the VBR handle the Jobs over the network, and also to not use it as a Proxy in regular bases.

You can group the vms in different tasks, so each task will be processing the vms and amount of virtual disks depending on the list and task limitation, or , another option will be to chain the tasks, for example, starting at 21:00 the initial one, and continue from there, but you will be not taking full advantage of multitasking.
if im not wrong, each virtual disk is a task.

run some tests and let us know, to help you better.

cheers.

 

 

 

Luis F.- HunterLF - HunterLAFR - lfconsulting.org
MicoolPaul
Userlevel 7
Badge +20

Hi, how many servers are being backed up within these jobs? And what roles is the VBR server performing? I’ll be honest unless you’ve got a lot more concurrent tasks or other requirements from your VBR server, I’d be worried the CPU is overspec’d and you could be causing unnecessary stress on your hyper-v server by scheduling so many CPU cores when they’re not needed.

 

If your server can handle the job concurrency, that’s fine to schedule these jobs together, if they’re fighting for the same resources you can chain the jobs to trigger after another one completes. The flipside is if each job only contained one VM to protect and you chained the backup jobs to run sequentially, you could be missing out on the ability to run more tasks in parallel.

 

The main downside to scheduling more jobs concurrently is the extra management stress it puts on VBR juggling pending tasks waiting to start up.

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
NemanjaJanicic
Userlevel 7
Badge +1

Hi, how many servers are being backed up within these jobs? And what roles is the VBR server performing? I’ll be honest unless you’ve got a lot more concurrent tasks or other requirements from your VBR server, I’d be worried the CPU is overspec’d and you could be causing unnecessary stress on your hyper-v server by scheduling so many CPU cores when they’re not needed.

 

If your server can handle the job concurrency, that’s fine to schedule these jobs together, if they’re fighting for the same resources you can chain the jobs to trigger after another one completes. The flipside is if each job only contained one VM to protect and you chained the backup jobs to run sequentially, you could be missing out on the ability to run more tasks in parallel.

 

The main downside to scheduling more jobs concurrently is the extra management stress it puts on VBR juggling pending tasks waiting to start up.

Hi @MicoolPaul,
 

Each job has 1 VM Server that is backing up.
VBR is all in one except that I don’t use it as Backup Repository, so it has Backup and Replication and basic Proxy role.

All 13th jobs were starting nearly at the same time.

Are there any ways to see how can I optimize it more, what is causing some slowness, do I have more tasks than VBR Server can handle etc.

As I’m learning more and more its really getting more difficult to configure it right.
It’s relatively small environment but a lot of new information's and configurations to grasp and watch so that I dont make some mistakes..

Comment


Terms & Conditions