You Have Backups, but Can You Recover? Veeam, Zerto and the Recovery Gap

Short answer: Having a backup does not mean you can recover. According to Veeam's 2025 ransomware research, a survey of 1,300 IT and security leaders, 69% of organizations were hit by ransomware in the past year. The aftermath is more striking: only 10% of those attacked recovered more than 90% of their data, 57% recovered less than half, and the average recovery took 24.6 days.

Those three numbers say the same thing: almost everyone had backups, and recovery is what failed.

Where backup and recovery come apart

Backup is a write operation, and its measure is a "job completed successfully" message. Recovery is a read operation, and its measures are entirely different: is the data intact, how old is it, in what order will systems come up, will the application still recognize it?

The main reasons a green backup report ends in a failed recovery:

The backup was encrypted too. Ransomware no longer stops at production data; it looks for the backup repository and the backup server's credentials. A backup that is reachable and deletable from the network is an item on the attacker's checklist.

The order is not written down. Restoring fifty servers is not fifty separate jobs but one job with dependencies. If identity, database, application and integration layers come up in the wrong order, each reports "success" individually and the system still does not work.

Nobody tried it. An untested recovery plan is only an assumption. We covered how to run a drill that proves something in our disaster recovery failover test guide.

Why immutable backup is not a marketing term

An immutable backup is one that, once written, cannot be changed or deleted by anyone for a defined period, administrator accounts included. That closes off the move an attacker finds most useful: deleting the backup and leaving the organization with a single copy.

In practice three layers work together: immutability, a copy separated from the corporate network, and a management account with segregated access. If one of the three is missing, the other two weaken. We detailed how these layers fit a ransomware scenario in our ransomware recovery playbook.

Veeam and Zerto do not solve the same problem

The two products are often presented as alternatives. They answer different questions.

Veeam is strong on backup depth: long-term retention, immutable repositories, broad workload coverage, and restore at the individual file or object level. The question it answers: "how far back, and how cheaply, can I keep this data?"

Zerto is strong on recovery speed: continuous data protection at the hypervisor layer, recovery points measured in seconds, and protection groups that bring applications up in the right order. The question it answers: "in an outage, how fast and with how little data loss can I come back?"

For most organizations the right answer is not "which one" but "which one where". Replication with a low RPO for critical workloads, deep and inexpensive retention for the rest. Our Zerto and Veeam comparison works through that split product by product.

Where recovery targets should come from

Vendor defaults do not know your workload. Recovery point and recovery time targets should be calculated from the business cost of an outage, not from what the technology can do. We set out the method in how to calculate RPO and RTO: working out the cost of one hour of downtime per workload also tells you which system earns continuous replication.

Three questions to ask yourself

Can your backup be deleted from the production network?

When was your last real restore test, and how many minutes did it take?

Is the order in which fifty servers come up written down?

An average recovery of 24.6 days points to a preparation problem rather than a technology one. You can see how Eclit builds this layer on the disaster recovery engineering page.