Veeam Cloud Connect v13: Tenant Setup and Configuration Guide

The Cloud Connect service provider guide in this series covered everything from the provider side: deploying gateways, configuring tenant accounts, setting quotas. This article is the other half of that story. If you are an organization buying Cloud Connect backup services from a provider, this is your setup guide. You will walk out of this with a working backup copy job sending data to your provider's cloud repository, a way to verify your quota usage, and a clear picture of what restore operations look like when you need them.

Cloud Connect is not a cloud backup product in the AWS S3 sense. It is a Veeam-to-Veeam architecture where your VBR installation sends data over an encrypted, deduplicated connection to a service provider who runs a VBR infrastructure on their end. Your data is logically isolated from other tenants even though it lands on the same physical repository hardware.

Your VBR installation connects to the provider's Cloud Gateway, which is a specialized component that handles the authentication, SSL encryption, and traffic routing for all tenant connections. You authenticate with credentials the provider gives you. Once connected, the cloud repository appears in your VBR console as just another backup repository, indistinguishable in the UI from a local repo except for its location.

Your backup and backup copy jobs target the cloud repository the same way they would target any local repository. The difference is that all data in transit flows through the Cloud Gateway connection, which is encrypted with a TLS certificate presented by the provider's infrastructure. You do not need to set up VPN tunnels or configure firewall rules beyond opening outbound TCP 6180 to the provider's gateway address.

Before you can configure anything in VBR, you need four pieces of information from your provider: the DNS name or IP address of their Cloud Gateway, the port it listens on (typically 6180 but providers sometimes customize this), your tenant username, and your tenant password. Some providers also issue a certificate thumbprint for you to verify during the initial connection, which is worth requesting if they offer it as it prevents man-in-the-middle attacks during the first handshake.

Your provider should also tell you your storage quota, whether the repository supports immutability, and any lease expiry date on your account. Knowing the lease date matters because when a lease expires, your ability to run jobs, restore data, and access the cloud repository all stop until the lease is renewed.

After adding the service provider, go to Backup Repositories in the Backup Infrastructure view. The cloud repository will appear here listed with the provider's name as a prefix. Right-click it and select Properties to see the quota details, including total quota assigned, space used, and space remaining. This is the same view your provider sees, so the numbers should match what they tell you.

Run a quick connectivity test by right-clicking the cloud repository and selecting Test Connection. If you get a success message, the connection path from your VBR server through the gateway to the repository is clear and working.

The most common use of Cloud Connect from the tenant side is backup copy jobs, where you copy your local backups off-site to the provider. This follows the 3-2-1 rule: three copies, two media types, one off-site. Your local backup jobs run as normal, and the backup copy job reads from those local restore points and sends copies to the cloud repository.

In addition to backup copy jobs, Veeam supports targeting the cloud repository directly from a standard backup job. This means your primary backup runs straight to the provider's cloud repository rather than to a local repository first. This works but it has tradeoffs worth understanding.

The main advantage is simplicity: you do not need local storage for backups that go off-site anyway. The main disadvantage is that every backup job now depends on WAN connectivity to your provider. If that connection is down during your backup window, jobs fail. For most organizations, a local primary backup with a cloud backup copy provides better resilience than direct-to-cloud backup. Use direct cloud backup for endpoints and remote machines that do not have a local Veeam repository available to them.

Restoring from the cloud repository works through the same restore wizards as restoring from a local repository. Go to the Home view, open the Backups node, and look under the cloud repository name. The backups stored there appear as normal backup objects. Right-click the VM you want to restore and choose your restore type.

Be realistic about restore times from cloud repositories over a WAN link. A 200 GB VM restore at 100 Mbps takes roughly 4 to 5 hours if everything goes perfectly. Plan for this in your RTO calculations. Cloud repositories are an excellent safety net for long-term retention and off-site copies, but for fast RTO you still want your recent backups on local storage. Instant VM Recovery from a cloud repository is possible but performance depends entirely on the quality of your WAN connection to the provider.

Cloud Connect has a version dependency between provider and tenant. The provider must always be running the same or newer version of VBR than the tenant. VBR v13.0.1 on the provider side is compatible with tenants running VBR 12.3.2.3617 and later, as well as any v13 build. Veeam Agent for Windows 6.3.2 and later and Veeam Agent for Linux 6.3.2 and later are also compatible with a v13 Cloud Connect provider.

When upgrading, the provider upgrades first. Tenants can then upgrade at their own pace. If your provider upgrades to v14 in the future, you will need to upgrade your tenant VBR to a compatible version before that cutoff. Your provider should give you advance notice of major version upgrades and the compatibility window.