3.6 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. Lately, also Object Storage using the S3 protocol has become a interesting choice.

Two main criteria should be used to choose the storage solution for Veeam Cloud Connect; in order of importance, they are Immutability and Block Cloning. We explained in details why these options are important in the dedicated chapter Repository Design in the Architecture section.

Because of these two requirements, eve if there are several design choices for a backup repository, the two main options available are:

• Linux Hardened Repository
• Object Storage with S3 Object Lock

Windows Repositories (and Object storage with no support for S3 Object Lock) are still very common among service providers, but they lack Immutability. At the next hardware refresh, providers should really consider to choose a more secure option.

In the rest of this page, we will describe the most common option we at Veeam are observing among our Service Providers: multiple Linux Servers with local storage, grouped together in a SOBR group. 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, or just increase the available bandwidth, especially at the Tenants’ end.

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 allows architects to choose their preferred Operating System for their storage servers. However, we highly recommend to use Linux because - in addition to Block Cloning - Linux repositories also offer Immutability. 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.

Notes on Linux repositories

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 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.

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

3.13: Configure path, immutability 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. It should already be the default option, but better check it.

3.14: 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.15: 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

In summary, a possible design for the SOBR group of a Veeam Cloud Connect system could look like this. There could be 4 Linux repositories:

Server	XFS1	XFS2	XFS3	XFS4
server name	xfs1.cloudconnect.local	xfs2.cloudconnect.local	xfs3.cloudconnect.local	xfs4.cloudconnect.local
IP Address	172.27.219.61	172.27.219.62	172.27.219.63	172.27.219.64
Operating System	Ubuntu Linux 22.04 LTS

Each exposing one volume for backups. These volumes will then become the 4 simple repositories, finally grouped into a SOBR group:

3.16: SOBR Group

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

3.17: SOBR Data Locality Policy

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

3.18: SOBR Capacity Tier

Object Storage buckets can be used in replacement of Block Storage repositories, either as simple repositories or as extents of a SOBR group. In this case, one or more gateways are used to mount and exposed the different buckets, as described in this design:

3.19: Object Storage in Gateway mode

We usually refer to this design as Connection Through Gateway Server.

Direct Backup to Object Storage

A new and interesting design choice for Veeam Cloud Connect (and more in general for Veeam Backup and Replication) is the option to send data directly into an object storage, without a gateway. This is referred to as Direct Backup to Object Storage, often shortened as DBOS.

In Veeam Cloud Connect, this design can potentially bring a heavily simplified design, that can scale based solely on the performance of the Object Storage, while the rest of the system becomes a control plane not involved in the data traffic of backup and restore operations.

3.20: Direct Backup to Object Storage in Cloud Connect

DBOS only supports VM and Agents backups, and there are a few additional limitations you should care about; but especially for the latter it can be a very interesting solution when agents are scattered geographically and can connect from multiple locations over time.

We have a dedicated white paper that you can read to learn more about this design: V12 Enhanced security and scalability with object storage Secure Mode.