Define data movers, transport services, and bottleneck detectors?

Veeam bottleneck source
As a platinum Veeam® Cloud & Services Provider, we frequently receive questions about backup performance, especially backup copy jobs. Veeam Backup & Replication (VBR) detects performance issues during job processing, which are not always evident. Understanding these bottlenecks allows you to troubleshoot latency quickly.

Whether backing up VMware vSphere, Microsoft Hyper-V, or physical servers, performance usually dictates how quickly backups run and determines recovery point objectives. Veeam uses a built-in indicator that analyzes all components during the backup or replication process, which are:

Source — source disk reader – indicates the source storage, such as a VMware datastore
Proxy — backup proxy, responsible for processing VM data
Source WAN accelerator — WAN accelerator deployed on the source side
Network — network queue writer, responsible for sending processed VM data from the backup proxy over the network to a backup repository or another backup proxy
Target WAN Accelerator — WAN accelerator deployed on the target side
Target — target disk writer – backup storage or replica datastore

Important note: VBR will always indicate one of these components as a bottleneck, even if no performance issues exist. It displays the component with the most work time during a job.

An unmentioned performance bottleneck is throttling. If you apply throttling to a job or network traffic that becomes the primary slow point, you will see ‘throttling’ as the bottleneck.

We’ll focus on four areas: source, proxy, network, and target.

Source

The source is the location of the production data, such as a VMware datastore or a Hyper-V Cluster Shared Volume. Backups happen while production VMs are running by taking snapshots and reading data. Slow or over-subscribed disks will hamper this process and cause issues with production virtual machines and backup jobs.

Proxy

By default, Veeam installs the Backup & Replication console, proxy, and repository on the same server. You may split, separate, and add to these as necessary for your environment. The proxy is the data mover and where deduplication and compression occur, and these processes are CPU intensive.

Network

The network component looks at the path from the proxy to the repository. If running these on the same server, you should not see a network bottleneck, but a NAS or other network storage device could become a choke point. The network bottleneck for a backup copy job to a cloud provider would be your internet connection and both speed and stability of the connection impact performance.

Target

The target is the repository, whether local or in the cloud. Slow disks in the local backup storage are the primary cause of a target bottleneck. A target indicator highlights a problem on the service provider side during a backup copy job.

How to fix Veeam bottlenecks

Since every component in the backup process is a subset of technology, you can adjust these areas based on your needs. Faster disks, networks, CPUs, and RAM will solve many problems—identifying the issue is often the most challenging step. Veeam provides ways to reduce impacts where possible, such as limiting the number of concurrent tasks and changing the transport mode. Following best practices for the number of VMs per job and the size of production virtual disks can also improve performance. You may also consider splitting up jobs or staggering runtimes to reduce system loads.

More DRaaS & BaaS Articles

Should I Outsource Disaster Recovery?

Should I Outsource Disaster Recovery?

Business continuity in the aftermath of a disaster is likely the stuff of nightmares for an IT manager. Discovering that your disaster recovery (DR) execution falls short of your expectations is devastating, costly, and potentially career-limiting. While keeping all...

Disaster Recovery as a Service

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *