Our Thinking / Field Notes / The Guide

STEP-BY-STEP GUIDANCE / BACKUP AND RECOVERY

Connect Veeam to a Cloud Connect Provider for Off-Site Backup

How to add a Veeam Cloud Connect provider to Backup & Replication, check its certificate, send backups and backup copies to an encrypted cloud repository, test a restore and plan for v12 End of Support on 28 February 2027.

Start here

On your own Veeam Backup & Replication server, add the provider with the Service Provider wizard using the gateway name, port (6180 by default) and tenant account your provider gave you. Check the TLS certificate before you continue, using the thumbprint if it is self-signed. Then point a backup job or, usually better, a backup copy job at the cloud repository with backup file encryption switched on, and prove it works by restoring something. If you are still on Veeam Backup & Replication 12, plan the move to 13 now: version 12 reaches End of Support on 28 February 2027, and your provider has to upgrade before you do.

What to have ready before you connect

Veeam Cloud Connect is the service a provider runs so that you can send backups to their storage over the internet. The provider gives you a tenant account and a cloud repository, which is simply a backup target that lives on their side. You do the connecting from your own Veeam Backup & Replication server, not the provider's.

Get these from your provider before you start. Ask for the thumbprint over a different channel from the one that carries the account details, such as a phone call or the support portal, so that a single intercepted email cannot compromise both.

Check the version question at the same time. The provider's backup server must run the same version as yours or a newer one, and for a 13.1 provider Veeam lists supported tenants as 12.3.2 (from build 12.3.2.4854) and 13.0.1 or later. Version 13.0.0 is not supported. If your build is outside that range, update it first or ask the provider which versions they accept.

Your network also needs to let the right machines out. Port 6180 on the cloud gateway is used by your backup server, but also by the proxies and repositories that actually move the data during jobs, so test from those machines as well as the server. Veeam lists both TCP and UDP for these components. Your backup server also needs to reach the certificate revocation lists of the CA that issued the provider's certificate, on TCP 80 or 443.

  • The DNS name (or IP address) of the provider's cloud gateway and the port, which is 6180 unless they say otherwise
  • A tenant account name and password created for you by the provider, and the name or size of the cloud repository allocated to you
  • The certificate thumbprint, if the provider uses a self-signed certificate
  • Outbound access to the gateway on port 6180 from your backup server and from the proxies and repositories that will run jobs
  • Local administrator rights on your Veeam server and a role in Veeam that lets you add infrastructure and create jobs
powershell
Test-NetConnection -ComputerName YOUR_GATEWAY_NAME -Port 6180

Connect to the service provider

This is a one-off task and it only reads from the provider side, so there is no data risk. It does create the trust relationship every later job relies on, which is why the certificate step deserves a proper look rather than a reflexive click.

The Test-NetConnection command above runs in Windows PowerShell on the Veeam server (and ideally on a proxy or repository server too). It only reads the network path and changes nothing. Replace YOUR_GATEWAY_NAME with the gateway name from your provider. Look for TcpTestSucceeded : True in the output. It tests TCP only; UDP cannot be proven this way, so ask your firewall owner to confirm that rule.

  1. Open the Veeam Backup & Replication console on your own backup server. In the Backup Infrastructure view, find the Service Providers node and choose to add a service provider. This starts the Service Provider wizard.
  2. On the cloud gateway step, enter the DNS name or IP address your provider gave you and check the port. The default is 6180.
  3. On the certificate and account step, the wizard shows details of the TLS certificate it received from the provider. Click the certificate link to open it. If it was issued by a public certificate authority, Veeam treats extra verification as optional. If the provider uses a self-signed certificate, paste the thumbprint they gave you into the Thumbprint field and click Verify. If it does not match, or the certificate has expired, stop there and tell the provider. Do not carry on because the connection happens to work.
  4. Under Credentials, choose the tenant account the provider issued, or click Manage accounts (or Add) to enter it. If the provider allocated resources in VMware Cloud Director, the account name must be in the form Organization\Username or Username@Organization. Active Directory sign-in is deprecated for new Cloud Connect tenants from version 13, so expect a tenant-specific username and password rather than your domain login.
  5. Click through the next pages. The wizard retrieves the resources your provider has allocated to you. The pages for replication resources and network extension appliances only matter if the provider has given you replication services; for off-site backup alone there is nothing for you to decide on them.
  6. Review the results and finish the wizard. Success looks like the provider appearing under Service Providers, with your cloud repository listed beneath it.

Send backups straight to the cloud repository

There are two sensible ways to use the repository and we generally prefer the second one, covered in the next section. A backup job pointed straight at the cloud repository is the simplest to set up, but it ties your production backup run to your upload speed. A local backup job followed by a backup copy job to the cloud keeps a fast local restore point and sends the off-site copy in the background. That is our engineering preference, not a Veeam requirement.

If you do want a direct job, create a new VM backup job in the usual way and follow the wizard: Name, Virtual Machines, Storage, Guest Processing, Schedule and Summary.

  • Keep the job name under 50 characters to avoid long-path problems.
  • Log backups cannot be enabled on jobs that write to a cloud repository. To protect database transaction logs off-site, back up to a local repository and use a backup copy job in immediate copy mode, with Include database transaction log backups selected.
  • Cloud repository quota is counted against the source data size the repository reports, not the space physically used after compression, so a quota can fill sooner than you expect.
  1. On the Storage step, choose the cloud repository from the Backup repository list.
  2. Set the Retention policy in days. Use the GFS option if you want weekly, monthly or yearly full backups kept for longer.
  3. Open Advanced and go to the Storage tab. Select Enable backup file encryption and choose a password, adding one with Add or Manage passwords if none exists. Read the encryption section below before you save this.
  4. On Guest Processing, enter credentials with local administrator rights on the guest if you want application-aware processing.
  5. On Schedule, leave Run the job automatically selected unless you intend to start it by hand. If you clear it, no cloud backups happen until you run the job.
  6. Finish the wizard and run the job once. The first run uploads a full backup, so how long it takes depends on your data and your upload bandwidth. For a large environment that can mean hours or days, and the link is usually the bottleneck rather than Veeam. Carry on to the restore test once the job session shows Success.

Create a backup copy job to the cloud

The backup copy job takes restore points that already exist in a repository on your side and copies them to the cloud repository. Veeam notes that the source for a backup copy to a cloud repository must be a repository configured locally on the tenant side.

You choose between two modes. Immediate copy sends new restore points as soon as they appear in the source repository. Periodic copy sends the most recent restore points on a schedule. Immediate copy is the one that supports transaction log backups. Periodic copy suits you if you want the upload confined to a window that does not fight with business traffic.

A word on retention. If your provider has enabled deleted-backup protection on your tenant account, Veeam recommends GFS retention on the copy job so that an attacker who shortens retention cannot cut away your chains. Without GFS the job finishes with a warning in this situation.

  1. On the Home tab, choose Backup Copy, then Image-level backup.
  2. On the Name step, enter a name under 50 characters and choose Immediate copy or Periodic copy.
  3. On the Objects step, click Add and pick From jobs or From repositories. Use Exclusions to leave out specific VMs.
  4. On the Target step, choose the cloud repository from the Backup repository list. To keep long-term full backups, select Keep certain full backups longer for archival purposes and click Configure to set the GFS options.
  5. Still on the Target step, click Advanced and open the Storage tab. Select Enable backup file encryption and choose a password.
  6. On the Data Transfer step, choose Direct unless your provider has told you the cloud repository uses WAN accelerators. If it does, choose Through built-in WAN accelerators and set the source WAN accelerator.
  7. On the Schedule step, set your transfer window. Immediate copy lets you block network transfer during chosen hours; for periodic copy, either leave Run the job automatically selected or plan to run it by hand.
  8. On the Summary step, select Enable the job when I click Finish for immediate copy, or Run the job when I click Finish for periodic copy, then click Finish. The first copy of a large backup chain can take a long time over a typical business connection, so watch that it starts cleanly and then let it run.

Encryption: who holds the key

Enabling Enable backup file encryption means the data is encrypted before it leaves your network and stays that way in the provider's repository. That is the point of using someone else's storage. It also means the password is a single point of failure that your provider cannot fix for you.

Store the password somewhere that does not depend on the systems you are protecting, such as a password manager with a recovery path that more than one trusted person can reach. If you are using a Key Management System, add it to Veeam first, because Veeam contacts the KMS as soon as you select it.

Veeam also offers password loss protection through Veeam Backup Enterprise Manager, which needs to be enabled in advance and needs a paid licence. If you rely on it, test a recovery before you need one. Encryption also reduces how much a provider's deduplicating storage can save, so quota planning should assume your protected data is not shrunk further on their side.

Prove it worked with a restore test

A green job is not the same as a usable restore. The test below reads from the cloud and writes to a scratch location, so it does not touch production data. Pick a small VM or a few files so you are not waiting on a large download. Restore speed depends on your download bandwidth and the provider's connection, so treat the first result as a measurement rather than a promise.

Be aware of what tenants cannot do from a cloud repository. Veeam lists Instant VM Recovery and restores to Amazon EC2 and Microsoft Azure as unsupported on the tenant side. If you restore files from a different machine to the one running your console, that machine needs a network route to the cloud gateway.

  1. In the console, find the backup that is stored on the cloud repository and select a recent restore point.
  2. Restore a few guest files, or a small VM, to a scratch location rather than to production. Enter the encryption password when asked.
  3. Open the restored files, or boot the restored VM on an isolated network, and confirm the content is what you expect.
  4. Write down how long the restore took and from which restore point. That is the number you will want in a real incident.

If it does not connect or a job fails

Most failures come down to the network, the certificate or the version pairing. Veeam Support can help isolate certificate problems but will not generate, import or install certificates, so certificate faults go back to your provider.

  • Certificate validation failed, or the transport stream was closed: port 6180 is probably blocked in one direction, or something in the path is inspecting TLS. Allow the port between your servers and the gateway, and exempt the traffic from deep packet inspection.
  • The same error but the network is open: ask the provider to check that their certificate has not expired, that the private key is installed on their Veeam server and that the full chain up to the root CA is present. Veeam's guidance lists these as the common provider-side causes.
  • The connection works but jobs fail to upload: the proxies and repositories connect to the gateway directly during jobs, so test port 6180 from them, not only from the backup server.
  • Backup copy jobs fail after you upgrade to 13.1 and the provider uses a publicly trusted certificate: Veeam fixed this in build 13.1.1.18, so update your build.
  • Jobs fail with the repository apparently half empty: check your quota. It is counted against source data size, not stored size.
  • You cannot connect at all after a version change: confirm with your provider which Veeam version they run. A tenant cannot be newer than the provider, and 13.0.0 is not supported.

Veeam 12 End of Support on 28 February 2027 and what changes in 13

Veeam Backup & Replication 12 reached End of Fix in November 2025. Veeam's lifecycle page says a version in that stage is still fully supported and still gets security updates, though issues fixed in a current release may require you to update. Version 12 reaches End of Support in February 2027, and Veeam's own security bulletin for 12.3.2 P4 gives the date as 28 February 2027. After that date the version no longer receives security updates and getting support means upgrading to a supported version. Version 13 is listed with both End of Fix and End of Support in November 2028. Some third-party trackers show 1 February 2027; Veeam's own documents say the end of February.

As we write this, in early November 2026, that is under four months away, and for Cloud Connect users the order matters. For a major version, Veeam says the upgrade must start on the provider side. Tenants on earlier versions can carry on using the provider's resources, but may not get new Cloud Connect features. So the first practical step is to ask your provider which version they are on and when they intend to upgrade, rather than upgrading your own server first.

On your side, these are the differences worth checking against Veeam's current upgrade checklist for your environment:

  • In-place upgrade to 13 needs an existing installation at 12.3.1.1139 or later. Older 12.x builds should be updated to the latest 12.3 release first.
  • Your build should be 12.3.2 (from 12.3.2.4854) or 13.0.1 or later to work with a 13.1 provider. Aim for the latest 13.1 build; the latest listed in Veeam's release information at the time of writing is 13.1.2.57, dated 27 October 2026.
  • Veeam announced that Backup Copy jobs still in legacy mode, and jobs with backup metadata not upgraded to the version 12 format, block an upgrade to 13. If your off-site copy jobs are old, check them before the upgrade window.
  • Active Directory authentication for Cloud Connect tenants is deprecated from version 13: existing setups keep working, new ones cannot use it, so use tenant-specific credentials as above.
  • Veeam lists 64-bit Windows Server 2016 to 2025 as supported for a tenant backup server, and also supports the Veeam Software Appliance on Linux. Check the current system requirements for your own operating system before you start.
  • Take a configuration backup before any upgrade.

Your backups are off-site. But will they survive an attack?

Moving your backups off-site is a good start. But what happens if ransomware or a compromised account wipes out those backups too?

With Rismor exoVault, you continue using Veeam Cloud Connect as normal. We go a step further, keeping protected copies of your backup data in separate storage, beyond the reach of your Veeam credentials.

If your accessible backups are deleted or damaged, we can recover your repository from those protected copies, giving you a way to restore your systems when it matters most.

Technical terms explained
cloud gateway
The server on the provider's side that tenants connect to, by default on port 6180. It passes backup traffic to the provider's cloud repository.
cloud repository
The storage space a provider allocates to you for backups, shown in your Veeam console once the provider has been added.
End of Support
The stage at which Veeam stops supporting a version and no longer issues security updates for it.
GFS
Grandfather-father-son retention. It keeps weekly, monthly or yearly full backups for longer than the normal daily retention.
thumbprint
A short fingerprint of a TLS certificate. Comparing it with the one your provider gave you through another channel shows you have reached the right server.
Veeam Cloud Connect
A Veeam feature that lets a service provider host backup storage and other resources that customers use over the internet from their own Veeam Backup & Replication server.

Sources and further reading

KEEP THE CONVERSATION GOING

Keep a recovery route beyond your Veeam account

Explore how exoVault protects your Veeam Cloud Connect repository with separately controlled snapshots and replicas, and find the right way to connect your backups.

Discover exoVault - and keep your backups recoverable