3.7 Cloud repositories

Across the multitude of Veeam Cloud Connect deployments, we have observed that the most common design for a Cloud Repository is the usage of a Windows or Linux server as a backup repository. This is generally the most efficient choice, in terms of data density, performance, rack footprint, and price. Also, this allows the use of blockcloning technology (when combined with ReFS or XFS filesystems) and lately also the immutability option of the Hardened Linux Repository. The addition of a Capacity Tier built using Object Storage for long-term retention makes the solution even more compelling.

SMB shares are supported by Veeam Cloud Connect, but even in this scenario, it’s advisable to deploy a dedicated Windows machine that will act as the gateway server (not to be confused with a cloud gateway) to directly communicate with the SMB share. The data mover will be deployed on this machine and not on other systems, especially the Veeam backup server, which should be only used as a management console:

3.12: Select a dedicated gateway server for SMB shares

This server will ultimately act like a proper repository machine. If Automatic selection is left as the default option, inconvenient selection like the VBR server itself may happen.

There are several design choices for a backup repository, and to list them all here will be simply impossible because many will be surely left out. Instead, this guide will describe the most common option we at Veeam are observing among our Service Providers: multiple Windows/Linux Server with local storage, grouped together in a SOBR group.

This is not intended to suggest these are the best storage solutions; depending on the business and technological requirements, some Service Providers may choose to deploy different solutions.

Backup Repositories with Block Cloning

At its very essence, Veeam Cloud Connect is a service to transfer large amount of data over slow links to a secondary location. for this reason, in order to optimize its consumption Service Providers have two different solutions (that can also be combined):

• improve the bandwidth efficiency
• improve the storage efficiency

For the former, Providers can deploy the WAN accelerators described in this book.

For the latter, the main principle is the best byte is the byte we do not have to write. Block Cloning allows to store each unique block only once for each file chain, and then map the same block multiple times if more files are using it. To better understand the theory behind this technology, you can read this article by Microsoft: https://docs.microsoft.com/en-us/windows-server/storage/refs/block-cloning. It’s related to the ReFS filesystem, but the same concept also applies to XFS filesystem. The availability of block Cloning in both Windows and Linux servers allows architects to choose their preferred Operating System for their storage servers.

Here we suggest to use Linux, because - in addition to Block Cloning - Linux repositories also offer Immutability, starting from Veeam Backup & Replication v11. While the two features are not directly related (one can have Immutability without Block Cloning, and vice versa), we suggest to consider them both when designing a new storage solution for Veeam Cloud Connect.

Linux Networking

Starting from Veeam Backup & Replication v11, another important innovation has been introduced to Linux repositories: instead of a runtime deployed at each session via ssh, Veeam now installs a Persistent Linux data mover into the Linux machine. This allows for a more secure environment, since the resulting daemon can be executed with lower privileges, and we can disable completely SSH after the installation itself.

After the installation, the resulting networking configuration is like this:

Proto	Source	Port	Destination	Port	Description
IPv4 TCP/UDP	Linux_repositories	*	Domain_controllers	53 (DNS)	Allow repositories to use internal dns
IPv4 TCP	VBR_Server	*	Linux_repositories	22	Veeam VBR connects to Linux repositories for installation, can be then disabled
IPv4 TCP	VBR_Server	*	Linux_repositories	6162	Default port used by the Veeam Data Mover
IPv4 TCP	VCC_gateways	*	Linux_repositories	2500-3300	Gateways transfer data to Linux repositories
IPv4 TCP	VBR_Server	*	Linux_repositories	2500-3300	VBR transfers data to Linux repositories

Once the Linux server is added among the managed servers, the configuration of a new repository follows the usual process.

3.13: Select the path to be used as a backup repository

As explained in Chapter 2.7, concurrent tasks is an important parameter and should always be configured:

3.14: Configure path and load control

A typical Veeam Cloud Connect customer will be limited by the upload bandwidth that is available; this will be the main bottleneck in most of the use cases. However this does not mean it will be the primary bottleneck for the service provider: because the service provider is accepting several concurrent connections, the number of concurrent tasks connecting to a given repository could be notable.

For this reason, a service provider needs to check the performance of the storage solution, and has to plan for enough concurrent connections so that customers tasks are not depleting the available resources. Please refer to chapter 2.7 and the “concurrency” paragraph for deep knowledge about how concurrency works in Veeam Cloud Connect.

In the Advanced options, it’s also important to configure per-VM backup files: this option allows for better utilization of the storage and the tasks:

3.15: Configure per-VM backup files

Linux repositories still need a Windows Mount server for file-level restores. It’s suggested to use one of the other machines available in the same Storage subnet (if available):

3.16: Configure the Mount Server

Because vPower NFS is not supported to date in Veeam Cloud Connect, a service provider can safely disable the configuration of this component during the repository creation wizard and complete it.

SOBR with Block Cloning backup repositories

	XFS1	XFS2	XFS3	XFS4
server name	xfs1.cloudconnect.local	xfs2.cloudconnect.local	xfs3.cloudconnect.local	xfs4.cloudconnect.local
IP Address	10.10.110.61	10.10.110.62	10.10.110.63	10.10.110.64
Operating System <td colspan=4> Ubuntu Linux 20.04 LTS
Installed components <td colspan=4> Veeam Backup Repository
vCPU <td colspan=4> 4
RAM <td colspan=4> 16 GB
Disk <td colspan=4> 40 GB, OS disk
Disk <td colspan=4> 400 GB, Backups disk

These four servers are grouped into a SOBR group:

3.17: SOBR Group

SOBR Group is using Data Locality policy to take advantage of BlockCloning:

3.18: SOBR Data Locality Policy

Finally, SOBR Group also has a Capacity Tier connected to it:

3.19: SOBR Capacity Tier

In case the provider wants to use a Windows repository, networking requires a few more ports compared to the previous Linux repository:

Proto	Source	Port	Destination	Port	Description
IPv4 TCP/UDP	Windows_repositories	*	Domain_controllers	53 (DNS)	Allow repositories to use internal dns
IPv4 TCP	VBR_Server	*	Windows_repositories	6160	Veeam Installer from VBR to Windows repositories
IPv4 TCP	VBR_Server	*	Windows_repositories	6162	Veeam Transport from VBR to Windows repositories
IPv4 TCP	VCC_gateways	*	Windows_repositories	2500-3300	Gateways transfer data to Windows repositories
IPv4 TCP	VBR_Server	*	Windows_repositories	2500-3300	VBR transfers data to Windows repositories
IPv4 TCP	VBR_Server	*	Windows_repositories	49152-65535	Veeam RPC from VBR to Windows repositories
IPv4 TCP/UDP	VBR_Server	*	Windows_repositories	445	Veeam SMB share access from VBR to Windows repositories

You can disable the last rule and enable it only when a new Veeam component needs to be installed or upgraded because Veeam uses SMB shares to deploy the installer packages into remote Windows servers like WAN accelerators and Windows-based repositories.