2.6 Backup Repositories

Backup repositories are the destination of backup and backup copy jobs in Veeam Backup & Replication. They can also store configuration backups of remote Veeam Backup servers. You can create them using two main tyopologies:

• Block Storage
  • Windows or Linux machines with local attached or remote storage carved out of a SAN
  • storage appliances exposing their disk space via network protocols like SMB or NFS
  • one of the supported deduplication appliances
• Object Storage
  • Object storage installed on premises at the provider, using S3-compatible protocol
  • Public object storage operated and sold by a larger service provider, acting as a supplier to the Cloud Connect service provider
  • Veeam Data Vault, a cloud object storage directly offered by Veeam

2.10: Veeam Backup & Replication supports different repository types

Once a backup repository is configured and registered in the Veeam Backup & Replication console, a new cloud repository can be created and assigned to the user during the creation of a new Veeam Cloud Connect customer consuming backup resources, using a portion of the existing backup repository.

From a service point of view, a cloud repository is a remote repository exclusively assigned to its user. From an infrastructure point of view instead, a cloud repository is a sub-folder of a backup repository with an applied quota.

For a Veeam Cloud Connect deployment, there are no special requirements for repositories compared to regular repositories used in private environments, but the general rules of Veeam Backup & Replication are still valid. Service providers can leverage Veeam Scale-Out Backup Repositories (SOBR) and Per-VM backup chains to further improve the efficiency of their Cloud Repository.

Extreme caution should be taken for the use of deduplication appliances: As tenants have the option to encrypt their backup files, and service providers cannot forcefully disable this option (but they can force mandatory encryption if needed), encryption itself can nullify any advantage of deduplication appliances, which are going to be filled with encrypted backups that cannot be deduplicated. If a service provider can control the configuration of incoming backup jobs or backup copy jobs, a deduplication appliance may be a valid choice, but for those service providers offering Veeam Cloud Connect Backup as an unmanaged solution, a deduplication appliance is not a correct choice. Also, specific limits on supported/integrated deduplication appliance may limit the choices available when using one of those; for more information, read the corresponding part of the User Guide: Limitations for Cloud Repository.

Monitoring

Monitoring considerations are different for Windows and Linux repositories.

Windows repository

The services running on a Windows repository server are:

Service Display name	Service Name	Startup Type	Log On as
Veeam Data Mover Service	VeeamTransportSvc	Automatic	Local System
Veeam Installer Service	VeeamDeploySvc	Automatic	Local System

Linux repository

Starting from v11, Veeam DataMover is deployed as a permament agent into the Linux machine. This new design allows for better security:

• SSH port can be disabled once the agent itself has been deployed
• access to SSH for the initial installation can be done with a single use credential; the credentials will NOT be stored in Veeam, so no attacker can find the credentials by compromising the Veeam server,
• the deployed Veeam service that listen over the network runs under a dedicated user, not as root.

The services running on a Linux repository server are:

Service Name
veeamdeployment
veeamtransport

You may have read in Veeam documentation the service veeamimmureposvc. This is the service dedicated to manage immutability, but it will not appear in the service list as it’s spawned from Veeam Transport as you can see here:

2.11: Veeam DataTransport service on Linux

You can learn more about Veeam Immutability in the dedicated page of the User Guide: How Immutability Works .

Protection

Backup repositories are the components storing customers’ backup data, and losing them means losing the customers’ data. Because of the many available technologies used to build a repository, there are no universal considerations that apply to every scenario. A service provider must carefully evaluate the available options in regards to the technology used to create the backup repository.

Design

There used to be an additional section here, about sizing and other design considerations. Due to its constantly growing size, we decided to move it to a new dedicated chapter: 2.7 Repository design considerations