The meaning of a task on a repository is different when it comes to synthetic operations (like creating synthetic full). That means that only 4 tasks will be processed, leaving idle resources. Suppose you have 3 proxies set to 4 tasks each (that means that on the source side, 12 virtual disks can be processed in parallel), but the repository is set to 4 tasks only (that is the default setting). This brings us to our first important point: it is crucial to keep the resources and number of tasks in balance between proxy and repository. On the repository side, you can find a very similar setting: If you go to the proxy properties, on the first step you can configure the maximum concurrent tasks this proxy can process in parallel:įor normal backup operations, a task on the repository side also means one virtual disk transfer. Veeam Backup & Replication is able to process multiple tasks in parallel, but the number is still limited.
So, if you have a job with 5 VMs and each has 2 virtual disks, there is a total of 10 tasks to process. To start, we must examine the notion of a “task.” In Veeam Backup & Replication, a task is equal to a VM disk transfer. Tasks balancing between proxy and repository That means there are always two components involved, even if they are essentially on the same server and both must be taken into account when planning the resources. Its job is to apply a target-side deduplication and save the data in a backup file (.VKB. The target agent is running directly on a Windows/Linux repository or a gateway if a CIFS share is used. Let’s take a backup job as an example: a source agent is running on a backup proxy and its job is to read the data from a datastore, apply compression and source-side deduplication and send it over to a target agent. Let’s review how data flows in a Veeam infrastructure during a backup (we're using a vSphere environment in this example):Īll data in Veeam Backup & Replication flows between source and target transport agents. An unbalanced backup infrastructure can slow down due to unexpected bottlenecks or even cause backup failures because of overloaded components. Such system can only work efficiently if everything is balanced.
For example, if you have multiple proxies and one goes offline, the backups will still be created. You can achieve a High Availability for some of the components.If you need to expand your backup repository, you can switch to scale-out backup repository and add new extents as needed. If your backup window increases, you can deploy an additional proxy. For customers with branch offices, it is possible to localize the majority of backup traffic by deploying components locally.However, distributing components can give several benefits: Of course, several components can be installed on a single server (provided that it has sufficient resources) and many customers opt for all-in-one installations. Examples of such components are the Veeam server itself (as the management component), proxy, repository, WAN accelerator and others. This means that Veeam as a backup solution consists of a number of components, each with a specific function. Veeam Backup & Replication is a modular system.
Overview of a Veeam Backup & Replication infrastructure
#Veeam backup repository recommendations how to
This time, the blog post is aimed at giving the reader some insight on a Veeam Backup & Replication infrastructure, how data flows between the components, and most importantly, how to properly load balance backup components so that the system can work stably and efficiently. In our previous blog posts, we examined tape configuration considerations and some common misconfigurations.
#Veeam backup repository recommendations software
It is something that we take as a great achievement, but as we see in our support practice, it can sometimes lead to a “deploy and forget” approach, without fine-tuning the software or learning the nuances of its work. Veeam Backup & Replication is known for ease of installation and a moderate learning curve.
0 kommentar(er)
