Veeam Backup and Replication appliance has a scale out architecture, in which multiple components (both for data processing and control) work together in a coordinated fashion. This blog provides a brief overview of these components.
Veeam Backup Server
Veeam Backup Server is the core component of Veeam Backup & Replication. It is responsible for job scheduling and management, indexing tasks, and general orchestration of the backup and replication environment. Component requirements and features will affect how you install the backup server, for instance one or multiple datacenter locations. Whether to install additional backup servers or services in remote locations to optimize data streams.
Before installing the Veeam Backup Server (VBR), it is important to understand the different data streams generated by the VBR services.
You may deploy the Veeam Backup and Replication Server as either virtual or physical server. It will run on Windows server 2008 R2 or higher with 64-bit operating system type only. It is recommended to install Veeam Backup & Replication and its components on a dedicated machine.
In most cases, virtual is the recommended deployment. It provides high-availability for the Veeam Backup Server component through features like vSphere Fault Tolerance, vSphere High-Availability or Hyper-V Failover Clustering. It also provides flexibility in scaling and sizing as the environment grows.
The virtual machine can also be replicated to a secondary location such as a disaster recovery (DR) site. If the VM itself should fail or in the event of an infrastructure/datacenter failure, the replicated VM can be powered on. Best practice in a two site environment is to install the VBR in the DR site. In the event of a disaster, the backup server is already available to initiate the recovery.
In small to medium environments (up to 500 virtual machines (VM)), it is common to a single physical server running the Veeam Backup and Replication server, backup repository and backup proxy components. This is also called an “Appliance Model” deployment.
In large environments (over 2500 VMs) running the Veeam Backup and Replication services on separate servers either physical or virtual will provide better performance. When running several jobs concurrently, consuming large amounts of CPU and RAM, scaling-up the virtual Backup and Replication server to meet the system requirements may become unpractical.
One advantage of having the Veeam Backup and Replication server running on a physical server is that it runs independently from the virtual platform. This might be an ideal situation when recovering the virtualized platform from a disaster.
In an enterprise environment, you may choose to install an additional VBR to speed-up the recovery process in the event of a disaster. You may reuse existing availability components such as a repository server or proxy for the standby Veeam Backup and Replication server.
A backup proxy is a lightweight Veeam architecture component that sits between the data source and the backup target, processing jobs and delivering backup traffic. Backup proxy tasks include retrieving VM data from production storage, then compressing, deduplicating, and sending that data to the backup repository. Using more than one virtualized (or physical) backup proxy lets you easily scale your backup infrastructure based on the size of your system.
- In a simple deployment scenario for smaller environments, the Veeam backup proxy is automatically installed on the VBR as part of the Veeam Backup and Replication installation.
- In advanced deployments, the proxy role is manually assigned to one or more windows servers. This way, the Veeam backup server is offloaded, resulting in smaller backup window and better performance.
A backup repository is a storage location used by Veeam Backup and Replication jobs for storing backup archives and their related metadata for future restores. A repository may be a Linux or Windows server, a third party NAS device, or a deduplication appliance. Repositories can be physical or virtual, depending on available hardware and requirements. A backup repository can be used to store multiple jobs, but a job can be stored only in a single repository.