Veeam Cloud Connect backup versus replication: which problem does each solve?

Start with the question you are actually asking

Two different worries tend to get filed under 'we need an off-site copy'. The first is 'we have lost something and need it back': a deleted folder, a corrupted database, a server encrypted overnight. The second is 'our office or server room is unavailable and people still need to work'. Veeam Cloud Connect has a separate service for each, and they are sized, priced and tested differently.

Cloud Connect Backup covers the first worry. Cloud Connect Replication covers the second. If you can say which one keeps you awake, you are most of the way to an answer. If it is both, which is common, the usual pattern is backup for everything and replication for a short list of systems.

Cloud Connect is delivered by a service provider (SP), with you as the tenant. That matters throughout this article: features, limits, pricing, support hours and data location are set by the provider you choose, so treat what follows as a way to question a provider, not a description of one provider's offer. It is also written against the Veeam Backup & Replication 13 documentation (build 13.1.2.57). Your provider may be running something older, so ask.

What each service gives you

With Cloud Connect Backup, the provider runs storage called a cloud repository and you send backups to it from your own Veeam backup server. Veeam describes it as multi-tenant, with each customer's data kept logically separate, and says tenants can back up virtual and physical machines to it and copy existing backup files to it. You keep running the jobs and doing the restores yourself. What you get is history: a series of restore points you can go back through.

With Cloud Connect Replication, the provider carves up its virtualisation capacity into what Veeam calls hardware plans, which you see as cloud hosts. Your Veeam server keeps virtual machine replicas on that host. If your site fails, you can fail over the whole group of production VMs (full site failover) or just individual affected VMs (partial site failover) and run from the provider's side. Veeam's documentation lists failback, the return to your own site afterwards, as a supported task, but the page we reviewed gives no detail on how it works. Get that explained by any provider you are considering.

The practical difference is what happens at the moment of need. A restore from backup means rebuilding something from stored data, so it takes as long as the data takes to come back and be brought online. A failover means starting something that is already built. That is faster, but the provider has to reserve compute capacity for you, and the replica has to be able to run in a network that makes sense once it is there.

Where they differ in practice

Feature lists are easy to find. These are the differences that tend to change a decision, taken from Veeam's current Cloud Connect documentation unless marked as our judgement.

• What it protects: backup covers virtual machines, physical machines and files. Replication is for virtual machines only, and Veeam's page names VMware vSphere and Microsoft Hyper-V as the supported platforms (with VMware Cloud Director as a provider-side option).
• What you recover to: backup restores into whatever you point it at. Replication gives you a running copy on the provider's hosts, which suits a short list of important servers rather than every file share.
• Networking: replication needs a plan for how users and other systems reach the replica. Veeam describes dedicated VLANs and network extension appliances for this. Its limitations page says replication to a cloud host does not support DHCP, so replicated VMs need static IP addresses. Automatic network settings detection works for Windows VMs only, and re-IP rules cannot be set for replicas on the cloud host.
• Not supported for replication to a cloud host: encrypted VMs, and Shielded VMs on Hyper-V. If you rely on VM encryption, this alone may rule replication out.
• Gaps on the backup side: the limitations page says Cloud Connect does not support NAS backup, does not support scheduled file copy jobs, and does not allow a cloud repository to be the source of a backup copy job. Some restore types are unavailable to the tenant or can only be done by the provider.
• Licensing: Veeam says machines backed up or copied to a cloud repository consume only the tenant-side licence, while machines replicated to a cloud host consume both the provider's Cloud Connect licence and the tenant-side licence. Tenant prices are not published in the pages we reviewed. Our reading is that replication will usually cost more per VM because the provider is reserving compute, but get quotes rather than assuming.
• Tighter recovery points: the provider may also offer Continuous Data Protection (CDP) alongside snapshot replication. Veeam's page says both sides need Veeam Backup & Replication 12 or later and specific minimum ESXi versions. That is a separate conversation if you need very small data-loss windows.

Neither one is automatically ransomware-proof

It is tempting to assume that anything held by a provider is safe. The NCSC's guidance on offline backups says otherwise: ransomware has encrypted connected USB and network storage holding backups, and incidents have compromised connected cloud storage too. Its test is to ask whether at least one backup is offline at any given time, and it notes cloud storage can count only if it is digitally disconnected when idle. The common 3-2-1 rule (three copies, two devices, one off-site) does not on its own require any copy to be offline.

For Cloud Connect Backup, the control Veeam provides here is insider protection. When the provider enables it for your tenant account, deleted backups and restore points move to a recycle bin on the provider's repository for a period the provider sets, instead of disappearing. From your side they look deleted, and you have to ask the provider to restore them. Veeam documents the purpose as protecting against someone who gets into your tenant console and deletes backups, or an administrator who does so by mistake. Two cautions from the same page: the provider has to switch it on per tenant (Veeam's label is a tick box reading 'Keep deleted backup files for N days' in the tenant account properties), and it is not supported if an object storage repository is assigned as your cloud repository. We did not find Veeam documentation describing true immutability for this service in the pages we reviewed, so ask the provider directly what they offer and how it works.

For replication, think about what is being copied. A replica follows the production VM, so a VM that has been encrypted may be replicated as encrypted. Whether a replica keeps usable older restore points, and how many, is something we could not confirm from Veeam's replication pages, so put that question to a provider in writing. This is our engineering judgement rather than a published rule, but we would not rely on a replica as the only protection against ransomware.

Questions to put to a provider before you trial anything

These cover the things Veeam's documentation leaves to the provider. Ask for the answers in writing; they are far more useful in a dispute than in a brochure.

• Which Veeam Backup & Replication versions do you support for tenants, and what is your upgrade policy? We could not verify minimum tenant versions from current Veeam pages.
• Where are backups and replicas physically stored, who on your side can access them, and what can you restore if my backups are encrypted? Veeam 13 lists provider-side restore of encrypted tenant backups as an opt-in feature.
• Is insider protection enabled for my account, for how many days, and is the repository object storage (where Veeam says it is not supported)? What immutability, if any, do you offer?
• For replication: which hypervisors and versions are supported, how much capacity is reserved for me, how do I get a static IP and public access after failover, and how does failback work in practice?
• Do replicas keep older restore points, and how many?
• Who can run a failover out of hours? Veeam's page says full site failover tasks can be performed by the tenant or the provider, which helps if you cannot reach your own backup infrastructure.
• What are the charges for storage, reserved compute, bandwidth and test failovers, and what happens to my data and my access if I leave?

A safe way to trial it

The aim is to get numbers from your own systems rather than from a datasheet. Provider brochures quote impressive recovery times; the only ones worth planning around are the ones you have watched happen. For illustration, imagine a fictional 25-person firm, Harbour & Finch Accounts, with a file server, a line-of-business application VM and a domain controller. They would run the sequence below with test copies first.

This assumes you already run Veeam Backup & Replication on your side and have trial access from a provider. Some providers offer trials and some do not, so do not assume yours does.

1. Write down your recovery targets in plain terms for each system you might protect: how much recent work you can afford to lose (recovery point objective, RPO) and how long you can be without it (recovery time objective, RTO). A number of hours per system is enough. This is what you will judge the trial against.
2. Pick a small test set, ideally a clone or a non-critical VM with no real personal data, so nothing sensitive leaves your site before you have agreed where it will be held and who can see it. Production systems can follow once you are happy.
3. Send a first full backup to the provider's cloud repository. This is usually the slowest part and depends on data size and upload speed. As a theoretical best case, 500 GB over a fully used 100 Mbps upload takes roughly 11 hours, and real links rarely manage that. Check back for the job finishing rather than sitting beside it.
4. Restore a single file, then a whole VM, to a location that does not overwrite production. Time both. If a restore type you rely on turns out to be unavailable to tenants, you want to find out now.
5. If you are testing insider protection, delete a test backup from your side, then ask the provider to recover it from their recycle bin. Only do this with a test backup set. It confirms both that the protection is on and that the provider can respond.
6. If you are testing replication, replicate the test VM to the cloud host and check its network settings, remembering the static IP requirement. Agree in writing with the provider exactly what a test failover does before you run one. A live failover is a production change, and failback is a project in its own right. Use a test VM, or a provider-supervised test in an isolated network, for the trial. Success is the replica starting on the provider's host and being reachable the way you expect, with the production VM left untouched.
7. Compare the timings with the numbers from step 1. Where a backup restore meets your RTO, you may not need replication for that system. Where it does not, and the system is both important and replicable, replication is worth pricing.

Which one for which business

Choose backup alone if the business can tolerate being down for the time a restore takes, and especially if your estate is mixed: file shares, physical machines, laptops, a few VMs. It is the simpler service, usually the cheaper one, and it protects against the widest range of problems, including mistakes, corruption and disasters.

Add replication for a short list of virtual machines where downtime is genuinely costly: a line-of-business application, a database server, the identity infrastructure that everything else depends on. Make sure those VMs fit the supported list above, and that you can live with static IP addressing and the failback process.

Keep your own copy as well. A provider is one extra layer, not a replacement for a copy you control, and the NCSC's point about keeping at least one backup offline still stands. If you take one thing from the provider conversation, take written answers about who can delete your data and how quickly you can get it back.