Aside from our proxies and repositories there are number of remaining Veeam Backup & Replication Core Components to cover. Today we will try and finish the component section of Module 3 of the Veeam VMCE v9 Study Guide. Some of these components are required, where as some are optional – but all are certainly fair game on the VMCE exam so its best to know them!
Guest Interaction Proxy
During a backup Veeam will interact with the guest to do several things – to do this it deploys a run time process within each VM it is backing up (be it windows or Linux) to do the following options
- Application Aware Processing
- Guest File System indexing
- Transaction Log processing
Older versions all of this was done by the backup server, causing higher resource usage on the Backup server or issues if the backup server and processed VMs had degraded, slow or non-existent network connectivity. As of 9, the process of doing the above 3 actions and deploying these run-time process can be done with a Guest Interaction Proxy (Windows only, will not work with Linux VMs). Again, interesting facts about the GIP.
- Only utilized when processing Windows based VMs. Linux VMs will still receive these packages from the Backup Server.
- Only available in Enterprise and Enterprise Plus editions.
- Can utilize multiple Guest Interaction Proxies to improve performance, recommended to have on at all sites if you have a ROBO setup.
- Can only be deployed on a Windows based server, be it physical or Virtual.
- Must have either a LAN or VIX connection to the processed VM.
- Can be installed on the same server as the proxy, repository, backup server, WAN Accelerator, etc.
- Defined on the Guest Processing step of the backup/replication job. We can assign each job manually to use a certain proxy or let Veeam decide. If letting Veeam automatically determine which proxy to use it will go in the following order
- A machine in the same network as the protected VM that isn’t the Backup Server
- A machine in the same network as the protected VM that is the Backup Server
- A machine in another network as the protected VM that isn’t a Backup Server
- A machine in another network as the protected VM that is a Backup Server.
- If at any point it finds more than one meeting the above criteria, it selects the one which is “less loaded”. The one with the least number of tasks already being performed.
- If at any point a GIP fails, the job can fail over to the Backup Server and utilize it to perform GIP roles as it has done in previous versions.
Mount Server
A mount server is required in order to restore VM guest OS and application items back to their original locations. Veeam uses this server to mount the content of the backup file to a staging server, this server, should be located in the same location as the backup repository where the files are stored, if it isn’t you may end up having restorations traverse a WAN twice. To help prevent this Veeam implements a mount server.
When a file or application item is restored to the original location, Veeam will mount the contents of the backup from the repository onto the mount server, and then copy the data from the mount server to the original location.
Interesting tidbits about mount servers…
- Direct SQL and Oracle restores do not go through the mount server, they are mounted directly to the target VM.
- A mount server is created for every backup repository and associated with it. This is a Repository setting.
- By default the mount server is created on
- Backup Repositories – if they are windows based. The default mount server would be themselves.
- Backup Server – For any Linux based or shared folder backups, and deduplicating storage devices the mount server is the backup server
- Veeam Backup & Replication Console – Anywhere the client is installed so is a mount server, however it isn’t automatically registered within B&R
- Scale-Out Backup Repositories require you to assign a mount server for each and every extent included.
- Mount servers can only be Windows based, but can be physical or virtual.
- In order to restore from storage snapshots the mount server must have access to the ESXi host which will host the temporary VM.
WAN Accelerators
WAN acceleration within Veeam works by using dedicated components to globally cache data and deduplicate data between sites. Basically we would need a WAN accelerator at both our source and target sites to do so. These sit in between the proxies, meaning data would flow through source backup proxy, then to the source wan accelerator, then to the target wan accelerator, then to the target backup proxy, then to either its replication target or backup repository.
Each accelerator will create a folder called VeeamWAN. On the source, files and digests required for deduplication are stored here. On the target, a global cache is stored.
WAN accelerators can require a lot of disk space to hold either the digests or global cache, therefore require some sizing exercises when creating them. Certainly this depends on the amount of source VMs you are backing up, but a rule of thumb is to provide 20GB of disk space for each TB of VM disk capacity. On the target we store Global Cache which is a little less lightweight in terms of capacity requirements. The recommendation here is to provide 10GB of space for each type of OS you are processing – by default, 100GB is allocated, so 10 OSes. Some situations may require us to utilize extra space on the source accelerators depending if digest data needs to be recalculated or we have cleared the cache. In order to help suffice this it’s also recommended you provide 20GB per 1 TB of source VM on your target cache as well.
Interesting tidbits about WAN acceleration
- Must be installed on a 64 bit Windows Based machine, physical or virtual
- Can be intermingled with other proxies and repositories
- For digest data on the source accelerator, provide 20GB of space for each 1 TB of data being backed up.
- For global cache provide 10GB of space for each OS (Default is 100GB)
Veeam Backup Enterprise Manager
This component is optional and is really intended for those that have a distributed deployment containing multiple backup servers. VEB essentially federates your servers and offers a single pain of glass viewing at your backup servers and their associated jobs. From here you can do the following
- Control and Manage jobs
- Edit and Clone Jobs
- Monitor job state
- Report on success/failure across VBR Servers
- Search for guest OS files across VBR Servers and restore via one-click
Interesting tidbits around VEB
- Can be installed on either physical or virtual, so long as its windows
Veeam Backup Search
Veeam Backup Search is an option that will greatly help reduce load from the VEB server if you frequently need to search through a number of backups. Basically, Veeam Backup Search is deployed on a Windows machine running Microsoft Search Server, which basically runs the MOSS Integration service and updates index databases of MSS – leaving VEB the ability to simply pass the Backup Search queries and have the data passed back.
Veeam Gateway Server
The Veeam Gateway server is almost like a connector service, bridging the network between backup proxies and backup repositories. The only time we would need to deploy a gateway server is if we are using one of the following scenarios
- Shared Folder backup repositories
- EMC DataDomain or HPE StoreOnce appliances
ExaGrid, another supported deduplicating appliance with Veeam actually hosts the Veeam Data Mover service directly on the box, Shared Folder backup repositories and the DataDomain/StoreOnce appliances do not – thus, we use a gateway server to host and run the Veeam Data Mover services for them. The gateway server is configured during the “Add Backup Repository” wizard. When prompted we can select our gateway server manually, or chose to let Veeam decide the best fit. If we let Veeam do the choosing our Gateway server is selected following the below criteria
- For a backup job, the role of the gateway server is assigned to the proxy that was first to process VM data for a backup job.
- For Backup Copy jobs, the role of the gateway server is assigned to the mount server associated with the backup repository. If for some reason the mount server is not available this will fail over to any WAN Accelerators that might be used for that job.
- For Backup to Tape jobs the role of the gateway server is assigned to the Veeam Backup Server.
Veeam will select a different number of gateway servers per job depending on the multitasking settings of the repository – PerVM backup chains by default have multiple write streams, therefore each VM will be assigned a gateway server. Where as the normal backup chains only have one gateway server assigned.
Tape Server
A tape server in Veeam Backup and Replication is responsible for hosting a tape device. Simply put its a windows machine that is connected to some sort of tape library. The tape server takes on somewhat of a proxy role for tapes, performing the reading and writing to tapes.
