Skip to content
Knowledge Hub/Guide
Guide

How Zerto Works: VRA, VPG, Journals and Checkpoints Explained

A plain-English guide to Zerto's architecture for engineers new to the platform: VRA, Virtual Protection Group, journal retention and checkpoint consistency.

Oğuzhan Gerçek··4 min read
How Zerto Works: VRA, VPG, Journals and Checkpoints Explained

Short answer: Zerto places a Virtual Replication Appliance (VRA) on every hypervisor host. The VRA captures every write made to a protected virtual machine and ships it to a journal at the recovery site. Because the journal holds changes continuously rather than as scheduled snapshots, Zerto's platform architecture documentation describes recovery points measured in seconds and a retention window configurable from one hour to 30 days.

Four concepts are enough to operate the platform competently.

1. Virtual Replication Appliance

The VRA is a small virtual machine installed on every host in the protected cluster. It captures writes as the hypervisor processes them and replicates them to the target site. Nothing is installed in the guest operating system; this is why Zerto is agentless and works independently of the application inside the virtual machine.

That makes VRA sizing and each VRA's share of host resources important. An undersized VRA becomes the bottleneck that pushes your real RPO above target.

2. The journal

Every protected virtual machine has its own journal at the recovery site. It holds a rolling history of changes. The journal is what makes point-in-time recovery possible; it is not a backup and does not replace one.

Retention is configurable from one hour to 30 days, but Zerto's own recommendation is eight days, a window that covers most scenarios, ransomware included. The reasoning is that ransomware typically enters the environment days before encryption starts, and a one-day journal only takes you back to a point where the attacker was already inside.

Journal size is change rate multiplied by retention. Underestimating it is the most common capacity planning mistake on the platform.

3. Virtual Protection Group

A VPG is the set of virtual machines protected, tested and recovered together. The rule is simple: group the virtual machines that make up one application. In a typical three-tier system, the database, application server and web front end belong in the same VPG.

Every few seconds, all journals within a VPG receive a shared checkpoint timestamp. That shared stamp is what lets the whole application be recovered to exactly the same moment, so no gap of seconds opens between a database and the service that depends on it.

The practical consequence: a VPG drawn along infrastructure boundaries rather than application boundaries produces recoveries that look technically successful but leave the application broken.

4. Checkpoints and consistency

A checkpoint is a moment in time you can return to. Zerto creates them continuously. But there is a critical distinction here, and most deployments skip it:

    Crash-consistent checkpoints. Every automatically generated checkpoint is this kind. It captures a state equivalent to pulling the plug at that instant. Write order is preserved, so the disk is not corrupted, but transactions sitting in application memory are not on disk.Application-consistent checkpoints. Created on demand, they tell the application to flush to disk and pause for a moment. For databases and message queues, this is the difference that matters.

In practice, restoring a web server from a crash-consistent point is fine. Restoring a database from the same point usually works, but it starts a recovery process at restore time, and that time is added to your RTO. For critical databases, produce application-consistent checkpoints at regular intervals.

This is exactly how ransomware recovery works: you pick the last checkpoint before encryption started. Being able to reach that moment depends on having chosen the journal retention correctly.

Mistakes new operators make

    Treating replication as backup. Replication copies corruption and encryption to the target with perfect fidelity. Zerto is not an alternative to immutable backup; we covered how the two fit together in our ransomware recovery playbook.Grouping virtual machines wrongly. See the VPG section above. It is the highest-impact design decision.Ignoring bandwidth. Continuous replication wants continuous bandwidth. Throttling to fit a narrow link quietly breaks your RPO.Never testing. Zerto supports non-disruptive failover testing. A VPG that has never been tested is an assumption; we set out how to run a drill that proves something in the disaster recovery failover test guide.

Frequently asked questions

Does Zerto need an agent inside the virtual machine? No. Replication happens at the hypervisor layer through the VRA.

How far back can I go? Up to 30 days, depending on configured journal retention and capacity. The vendor recommendation is eight days.

How frequent are recovery points? Seconds apart within the journal window. The value you actually achieve depends on bandwidth and VRA resources.

Does Zerto protect physical servers? Support is limited. Zerto is designed primarily for virtualized environments.

Should I use Zerto or Veeam? For most organizations the answer is "both, in different places." We worked through the split product by product in our Zerto and Veeam comparison.

Sources