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

Disaster Recovery Case Study

Disaster Recovery Case Study

What could be more critical than getting First Responder communications back online on a busy Friday night? This was a critical situation for a local municipality.  In this disaster recovery case study, hear Brian Childers, president of Comport Consulting share his...

Managing the Risk of Having Data in the Cloud

Managing the Risk of Having Data in the Cloud

In this webinar, we discussed the March 2021 OVHcloud fire in Europe and the challenges of maintaining and protecting data no matter where it resides. Many customers lost data due to the fire and not having backups, offsite backups, or a disaster recovery plan. Our...

Your Business Data, Your Corporate Responsibility

Your Business Data, Your Corporate Responsibility

As the OVHCloud fire demonstrates, never assume your business data is safe, and always back it up offsite.-SDIS-67 On March 10th, 2021, OVHcloud, a colocation, hosting, and data center provider in France, experienced a devastating fire that destroyed one of its...

Disaster Recovery as a Service

0 Comments

Submit a Comment

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