Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Disaster recovery as a service: replication journals, re-addressing networks and failback

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A disaster recovery (DR) service is three separate engineering problems: how far back you can rewind, how recovered machines become reachable, and how you get home again. Replication dashboards report only the first. The other two are usually where a recovery stalls.

The commands below were not run in a lab. They are taken from vendor documentation, and every name and address is an example.

Interpretations are editorial; no lab testing was performed.

Why it matters

"Disaster recovery as a service" describes a commercial arrangement, not a mechanism. Whether you are comparing disaster recovery as a service in Australia or running a platform yourself, the product underneath is one of a small number of replication designs. Those designs differ in ways that change the recovery itself:

  • what a recovery point actually is, and how far back it reaches
  • whether the recovered machine can keep its address
  • whether failback sends only changes or the whole disk
  • which steps cannot be undone

This article compares five documented platforms: Azure Site Recovery, AWS Elastic Disaster Recovery, Veeam continuous data protection (CDP), Zerto and VMware Live Site Recovery. It is not a ranking. A replication lag that breaches its target is a separate fault, and we cover it elsewhere for vSphere Replication.

How it works

Five things called a recovery point

A replication journal is a time-ordered store of writes on the recovery side. It lets you pick a moment rather than only "latest". Not every product has one, and the differences are structural.

Platform What is kept Consistency by default Documented reach
Zerto 10.9 A journal per protected VM, with checkpoints written every few seconds Crash-consistent at each checkpoint Journal history of 1 to 71 hours or 1 to 30 days; Extended Journal Copy keeps retention sets in a separate repository
Veeam CDP (v13) Short-term restore points, tracked in a journal Crash-consistent for short-term points; long-term points can be crash-consistent or application-consistent, application-consistent by default when application-aware processing is on 168 hours for short-term points; long-term points beyond that, up to 95 per disk
Azure Site Recovery Recovery points built from disk snapshots Crash-consistent every five minutes; that frequency cannot be changed One day in the default policy; the oldest usable point is 15 days with managed disks and three days with unmanaged disks
AWS Elastic Disaster Recovery Point-in-time Amazon EBS (block storage) snapshots per volume, on a retention policy Crash-consistent By default, one point per 10 minutes for the prior hour, one per hour for the prior 24 hours and one per day for the prior 7 days; only the daily limit can be adjusted, from 1 to 365 days
VMware Live Site Recovery with vSphere Replication Optional point-in-time instances of the replica Crash consistency across a VM's disks; quiescing is optional Up to 24 instances per VM, for example 6 a day for 4 days

Crash-consistent means the disks look as they would if the power cord had been pulled. Azure recommends application-consistent points, taken with the Windows Volume Shadow Copy Service, for database workloads such as SQL Server. They are off by default, have a minimum frequency of one hour, and can affect a busy workload if taken too often. AWS frames it differently: a crash-consistent point "allows the successful recovery of crash-consistent applications, such as databases", though data still in memory is not replicated until it reaches the volume. The vendors differ, so your own recovery test has to settle it.

Reach is not the same as density. Azure's five-minute points exist only for the last two hours; beyond that it keeps one per hour at one-day retention, one per two hours for 2 to 7 days, and one per four hours after seven days. AWS thins out in a similar way. After ransomware, a candidate point before the earliest known compromise may no longer exist as a separate point.

So the short recovery point objective (RPO) and the application-consistent point are often different points. A database recovered from a crash-consistent point has to go through its own crash recovery. Test that it does so cleanly and within your time target.

Group consistency is a separate setting. An Azure replication group gives several VMs shared recovery points, but Microsoft says it affects workload performance and should be used only for VMs that need consistency across all machines. Zerto applies consistency across the VMs in a virtual protection group (VPG). An application tier spread over machines that are not grouped can recover with each server at a slightly different moment.

What a journal does when it fills

Zerto documents the mechanics clearly. Writes and checkpoints go into the journal until the configured history is reached. After that, older writes move to the recovery disks, and a checkpoint can only be chosen while it is still in the journal.

Two consequences follow.

The history is a target, not a guarantee. A Zerto journal starts at 16GB and grows on demand. When it nears its hard limit, data starts moving to the target disks and the maintained history shrinks, with an error if history falls below one hour. Zerto also raises a low-history alert when a VPG configured with at least one hour holds less than 75 per cent of it. The same alert page explains that a synchronisation moves old data out of the journal and removes its checkpoints.

A full datastore is a different failure. If free space on the journal datastore falls below 30GB or 15 per cent, whichever is smaller, the datastore is considered full. Writes to the journal are blocked, replication halts though history is not lost, and the RPO keeps rising until space is added. Monitor that free space as well as journal history.

Sizing is therefore write rate multiplied by time. As a hypothetical example, a VM averaging 20 MB/s of writes for 24 hours produces about 1.7 TB of journal before any compression or overhead. Use a measured peak period from your own workload rather than a daily average. A nightly batch or an index rebuild can consume hours of history, just when you may need it.

Ransomware changes the arithmetic. The candidate needs to predate the earliest known compromise, which can be much earlier than encryption. Encryption itself is a burst of writes. It can shorten the history you were counting on.

Keeping addresses or changing them

Each design moves the work somewhere else. The table compares the two extremes; a third, keeping the address in a separate virtual network, follows it.

Keep the addresses Change the addresses
What must happen The subnet moves, so routing has to follow Each machine gets a new address, so everything that refers to it must follow
Main work Network changes at failover time Preparation: rules, DNS, firewall and application settings
Partial failover Hard: one subnet cannot be live in two places Easier: machines can move individually
Typical fit Applications with hard-coded addresses Name-based applications

Keeping addresses. Azure's on-premises guidance is direct. Azure does not support stretched VLANs, so you fail over the entire subnet, and routes must change to show that it has moved. While the same range exists on both sides, you cannot connect the two sites with a site-to-site VPN or ExpressRoute, because the address spaces overlap. You also have to set the target address on the replicated item and build an Azure virtual network matching the on-premises one. A subnet failover also means every machine in that subnet moves together.

Same address, separate network. Azure-to-Azure failover reuses the source address if the target subnet has the same address space and that address is free, otherwise it takes the next available address. Network mapping picks the target network; changing it affects new replications only. The failover VM's load balancer, public IP and network security group can be set, and those resources should be created in advance. The address survives, but in a different virtual network, so no subnet has to be taken away from the source first.

Changing addresses. For on-premises sources to Azure, a DNS update is needed to point records at the new address, and you cannot reuse the same public IP.

The automation tools have narrower limits than their names suggest.

Veeam re-IP rules work only for Windows VMs, and only when failover is run through Veeam; a replica powered on some other way does not get them. Matching is by whole octet, and the subnet mask does not select which addresses match, so 10.0.0.* does not cover 10.0.1.1 even in a /23. This one matters for a service model: Veeam Cloud Connect Replication does not support re-IP rules for VM replicas on a cloud host, and Linux replicas there need their network selected manually in the wizard. If your provider uses that model, ask how addresses will actually change.

VMware Live Site Recovery allows one IP address per NIC when IP customisation is used. Subnet rules are evaluated when recovery.useIpMapperAutomatically is True, which is the default. For bulk changes, dr-ip-customizer generates a CSV you edit and apply:

/opt/vmware/srm/bin/dr-ip-customizer --cfg "/opt/vmware/srm/conf/vmware-dr.xml" \
  --cmd generate --out "/home/admin/output.csv" \
  --uri "https://psc.example.net/lookupservice/sdk"

/opt/vmware/srm/bin/dr-ip-customizer --cfg "/opt/vmware/srm/conf/vmware-dr.xml" \
  --cmd apply --csv "/home/admin/output.csv" \
  --uri "https://psc.example.net/lookupservice/sdk"

Machine IDs differ at each site, so apply the file on the same site that generated it. If a Platform Services Controller has several vCenter instances, the tool also needs --vcid.

Zerto re-addresses machines from network settings entered in its interface. On Linux, a package with a script is deployed to the recovery VM at failover or failover test. The same page warns that re-IP may work only partly if Network Manager runs alongside Netplan or an edited /etc/network/interfaces, and that /etc/hosts needs updating afterwards.

AWS Elastic Disaster Recovery leaves the traffic move to you. Redirecting production traffic is performed outside the service, typically with a DNS routing service. The recovery VPC, subnet and security group come from the EC2 launch template.

DNS is part of your recovery time

A DNS TTL (time to live) is how long a record may be cached. Lowering it during the incident does not help clients that already hold the old answer. To gain anything, lower it at least one old TTL before the failover, which for an unplanned disaster means it must already be low.

Two further limits apply. RFC 2181 notes that implementations may place an upper bound on any TTL received. And if your DR plan uses names that do not exist until failover, a client that asked earlier may hold a cached "no such name" answer, whose lifetime comes from the lesser of the SOA MINIMUM field and the SOA record's TTL.

Applications can also hold their own connection pools and cached addresses beyond DNS. Restart or test them explicitly.

Failback is a second migration

Failback copies data back while the recovered system keeps running, then cuts over. The differences are in what gets copied and what happens to the old disks.

Azure. The order is commit, then reprotect. The VM status must be Failover committed before reprotect starts. Reprotect then replicates back to the primary, seeding and then sending deltas. The primary region must be available, and the target network cannot be changed during reprotect.

Warning: commit deletes all the available recovery points for that VM, and you can no longer change the recovery point. Going home therefore starts by giving up the other points. After ransomware, the first point you chose may prove infected, so finish validating it before you commit.

AWS. To return to a non-AWS site you boot the Failback Client ISO on the server receiving the data. The documented prerequisites are specific:

  • volumes the same size or larger than the recovery instance
  • TCP 1500 reachable on the recovery instance, with TCP 443 outbound from it
  • access from the server to S3, or an S3 interface endpoint with private DNS
  • at least 4 GB of dedicated RAM on the server
  • for Windows, the same boot mode (BIOS or UEFI) as the source
  • x86_64 only; arm64 failback to on-premises is not supported

For a static-address failback client, record its address, mask, gateway and DNS requirements in the tested boot procedure. Starting that client leads into block-device selection, so this article does not provide an executable initialisation command.

Warning: the Failback Client replicates onto the local block devices you map, overwriting what is on them (our reading of the block-device mapping steps). Temporary credentials expire after one hour by default, so complete initialisation inside that window. Selecting Failback when instances show Ready and Healthy stops replication and starts conversion.

Veeam. Failback has two phases. The first synchronises while the replica stays in service, and it can take a long time on a large VM. The second switches, powers off the replica and sends the remaining changes. You choose whether that switch happens automatically, at a scheduled time or manually. Returning to the original VM or an already recovered VM transfers differences only; failing back to a VM recovered from the replica to a new location transfers the whole VM. If the source VM is running, Veeam powers it off. Anything written there since the failover is lost to this process. Failback is then an intermediate step that needs to be finalized. Commit confirms that production works and resumes replication. Undo powers off the production VM and reverts the replica to its pre-failback state.

Zerto. During failover, data is promoted from the journal while the machines are usable. With reverse protection, the original disks are used and a Delta Sync reconciles them. Afterwards you move the VMs back. On a planned move, a bitmap sync can become a delta sync if the original VM was powered on or moved to another host.

Warning: the Move page says that without reverse protection the original disks are deleted, and a later reverse protection needs a full sync. The Failover Live page adds that with reverse protection, VMs already protected in other VPGs are removed from them and those journals are reset.

VMware Live Site Recovery. Reprotect reverses direction and forces a synchronisation. With vSphere Replication, the original VMDKs act as initial copies, so most of the "full sync" is checksums. After a disaster recovery run, it requires a planned migration to finish successfully once both sites are up. If the original site cannot be restored, reprotect is unavailable, and you must reinstall Live Site Recovery on both the protected and recovery sites.

Warning: the reprotect wizard asks you to confirm that the operation is irreversible.

What to choose and why

These are our recommendations.

Choose the recovery point deliberately. Azure's Latest gives the lowest RPO, while Latest processed gives the lower recovery time. If the source region is down, log processing stops and you fail over to the latest processed point. Write down which option applies to which incident type before you need it. For ransomware, the newest point is usually the wrong one.

Test with isolation, and test often. Azure says to always use a nonproduction network for test failover, and flags a readiness issue if no successful test has run within 180 days. Live Site Recovery can create an isolated test network. Zerto recommends an isolated network, and warns that test changes go to scratch volumes which, at their limit, end the test.

Order the recovery. Identity and DNS come first, then data, then applications, then the front door. AWS recovery plans run ordered steps, with servers in a step recovered in parallel, but within one account and Region. Treat cross-account or cross-Region designs as a separate plan.

Prepare the guest before you need it. For on-premises machines failing over to Azure, Microsoft's list covers firewall profiles for RDP, removing static persistent routes and WinHTTP proxy, disk-online policy, and no pending Windows updates. On Linux, SSH must start at boot.

Plan failback in the first hour. Before anyone changes data in the recovery site, record:

  1. which recovery point was used
  2. the time production traffic moved
  3. whether the original disks still exist and are unchanged
  4. who may power on the original machines

AWS's instruction applies widely: replicate data written during the failover back before you redirect users.

Questions to put to any provider. Who performs the network change? Is re-addressing supported in the provider's replica target? What is the real journal or snapshot history under load? Which side pays for failback traffic and how long does it take? Can you run a test without their staff present?

Risks and limits

Sources

Opened 10 November 2026.

This article was originally published on .