When someone says, “data protection,” one of the first things that comes to mind is backup. Whether we’re up against the ever-evolving threat of ransomware or dealing with the simple mistake of an employee clicking a malicious link, backups serve as a kind of magical rewind button. For many organizations, this is enough to meet their recovery point objectives (RPOs).
But what about recovery time objectives (RTOs)? What about when the question isn’t just if we can recover—but how quickly we can get back up and running?
That’s where replication comes in. Replication is a technology that allows you to maintain an up-to-date copy of your virtual machines in a secondary location, so if something goes wrong—a failure, breach, or encryption event—you can simply fail over to the replica and continue working with little to no downtime. Whether you’re replicating to a secondary host or an entirely different data center, replication enables true business continuity and disaster recovery.
Backups and replicas go hand-in-hand, but they’re not the same. Each has its own use cases and trade-offs. I like to explain it with a simple analogy: imagine a car in a garage.
Let’s say you have a car that you rely on to get to important places at a moment’s notice. To ensure you’re never stranded, you have two options:
- Buy all the parts you’d need to rebuild the car and store them in the garage. This option is cheaper and takes up less space, leaving room for other items. But if your car breaks down, you’ll need time to reassemble it. That’s your backup—you’ve got everything you need, but getting back on the road takes time.
- Buy a second car exactly like the first one and keep it ready to go. This takes up more space and is more expensive, but if your primary car fails, you can just hop in the backup and drive away. That’s your replica—ready when you need it, with minimal delay.
Most businesses opt for the best of both worlds: backups for long-term retention, immutability, and granular file- or application-level recovery, and replicas for critical workloads and full-scale disaster recovery. Many backup solutions also offer quick recovery options—like Veeam’s Instant VM Recovery. While it doesn’t provide the same I/O or performance as a live replica, it’s a great option when replication would be too resource intensive.
It’s important to understand the underlying difference: backups are compressed and deduplicated on a repository, while replicas are 1:1 copies of virtual machines that reside on your production datastore.
What About CDP?
Before we dive into how replication works in Veeam specifically, there’s one more thing to mention: CDP (Continuous Data Protection). While traditional replication delivers fast RTOs, it still relies on snapshots, which makes capturing constant data changes challenging. CDP solves that. It creates replicas just like standard replication but uses a different mechanism—Veeam’s I/O filter driver—to achieve much more aggressive RPOs, sometimes down to just seconds. This makes CDP ideal for mission-critical workloads where near-zero data loss is a must.
Platform Support and Compatibility
Today, Veeam Backup & Replication supports hypervisor-based replication for both VMware and Hyper-V. While backups allow for flexibility like cross-hypervisor restores or physical-to-virtual migrations, replication is only supported between like hypervisors.
If you’re replicating from an older host to a newer one, be sure to check hardware compatibility. Both VMware (now Broadcom) and Microsoft publish their compatibility matrices online:
- VMware Compatibility
- Hyper-V Compatibility
Planning for Deployment
Before deploying Veeam in your environment, take the time to plan properly and follow best practices. If you’re relying on replicas during a failover, chances are you’re in a disaster scenario—and the last thing you need is an unexpected issue slowing down your recovery.
Architecture Overview
Let’s look at the puzzle pieces involved. The two core components for replication are:
- Backup Server
- Backup Proxy
Optional components include WAN accelerators and backup repositories, but let’s start with the basics.
Backup Server
Think of the backup server as your command center. It’s where jobs are created, roles are assigned, and where failover happens during a disaster. Best practice is to deploy your backup server at the DR site. If the backup server goes down with your production site, you’d have to reinstall Veeam, adding time and complexity to your recovery process.
While you could manually power on replicas via vSphere or Hyper-V, failing back to production and resuming replication jobs would become significantly more complicated.
Backup Proxies
Proxies are the data movers—the real workhorses. For replication, you’ll need at least one proxy that can access the source and target datastores. Proxies can scale both vertical and horizontally, depending on the size and performance requirements of your environment. Proper sizing depends on how many virtual disks you plan to process in parallel.
Check out the Veeam Best Practices Guide for detailed proxy sizing recommendations and architecture planning.
- For vSphere: Proxies are dedicated Windows or Linux machines assigned by the backup server. By default, the backup server also functions as a proxy.
- For Hyper-V: You have two options:
- On-host proxy: The Hyper-V host itself acts as the proxy. No need to create or size additional machines.
- Off-host proxy: A dedicated physical Windows machine handles proxy duties. This reduces load on the host but requires a clustered Hyper-V environment with shared storage.
WAN Accelerators
WAN accelerators are optional components that can speed up the transfer of replicas across a wide-area network (WAN). They do this through a combination of network traffic compression, multi-streaming uploads, global data deduplication, and variable block size deduplication. At a high level, WAN accelerators optimize data transfer and reduce the amount of data sent over the WAN by caching redundant blocks.
Using Backups for Replication
Another option for replicating between data centers with limited bandwidth is using your backup repositories as the source for replication jobs. Backup files are compressed and deduplicated and are therefore smaller than replica equivalents. Veeam offers two methods for using backup files to help with replication.
The first option is replica seeding. Replica seeding uses a backup file during the first run of a replication job, which is always when the largest amount of data is processed. Subsequent replication runs—or incremental jobs—are taken from the source production machines.
Replica from backup is the second option. While these two approaches may seem very similar, there’s a key difference: replica seeding uses the backup repository only for the initial full replication. In contrast, replica from backup uses the backup repository for all replication jobs—both full and incremental.
Network Mapping and Re-IP
Veeam Backup & Replication makes it easy to configure networking for your replicas in a disaster recovery scenario. After you specify the destination for your replica VMs, you can select a target network that maps to the source network. This way, you don’t have to configure network settings manually after the fact.
Re-IP allows further network configuration by mapping IP addresses in the production site to IPs in the disaster recovery (DR) site. When you fail over, the replicated production machines will be assigned the new IPs as specified in the Re-IP step of the job. Keep in mind that this is only supported for Windows VMs.
Failover
Recovering from a disaster using Veeam replicas can be done in a variety of ways. If you just need to recover a few machines, you can simply select “Restore from replica” in the VBR console and run through the wizard. If you need to fail over many VMs or your entire data center, it’s easier to perform a failover plan or a planned failover. Let’s look at the different options and when to use each.
Failover Plan
When a major disaster strikes, the last thing you need is complexity during recovery. A failover plan is your ticket to push-button recovery. Simply click on your failover plan in the VBR console and select “Start.” The VM replicas will spin up in a predefined order, with boot delays and any custom scripts you’ve added into the plan. Within minutes, your entire data center can be up and running at the DR location.
Planned Failover
While disasters can be unpredictable, there are scenarios where you have some warning. Perhaps you know a tornado is heading toward your data center, or maybe you’re performing a planned migration. In either case, a planned failover allows you to proactively move workloads with almost no data loss.
The difference between a failover plan and a planned failover isn’t just about timing. A planned failover goes a step further to minimize data loss. When you initiate it, Veeam triggers one last snapshot and then powers off the production machines—ensuring the replica is as up to date as possible.
Finalizing Failover
While it may seem like failing over is the final step in disaster recovery, it’s actually a temporary measure. There are three options to choose from when finalizing recovery.
The first option is Undo Failover. This action cancels the failover and switches back to your production machines. It should only be used if the failover was a mistake or a test. All changes made on the replicas will be lost, and the production machines will revert to their last state before the failover.
The second option is Failback. Failback takes the changes made on the replicas and merges them back into the original source machines. You can also fail back to a new VM that’s already been recovered in a different location. In either scenario, failback happens in two phases.
In the first phase, Veeam synchronizes the state of the production VM with the current state of its replica. This process can take time—especially for larger VMs—but users can still access and work on the replicas while synchronization is in progress.
In the second phase, Veeam Backup & Replication switches operations from the VM replica back to the production or source VM. The replica is automatically powered off, and any additional changes made on it are transferred to the source VM. There’s also an option to perform a Quick Rollback, where VBR uses CBT (Changed Block Tracking) to identify only what has changed instead of reading the entire VM. Quick Rollback should only be used if the failback is due to an issue at the guest OS level.
The third option is Permanent Failover. In this scenario, Veeam Backup & Replication removes snapshots (restore points) from the VM replica, and all changes written to the snapshot delta file are committed to the replica VM, bringing it to its most current state. This option should be used for permanent data center migrations or when you must run off the replica long-term. Typically, if a replica is running for more than 72 hours and failback isn’t possible, you should finalize with a permanent failover.
Summary
Whether you use Veeam for your data protection needs or not, it’s imperative to understand the different methods available and ensure your recovery objectives can be met.
There are many factors that go into creating a data protection strategy, including cost, RTO/RPO, infrastructure, and more. Often, it can be helpful to categorize your workloads into Tier 1, Tier 2, and Tier 3. Tier 1 workloads may require Continuous Data Protection (CDP), Tier 2 may benefit from replication, and Tier 3 workloads might be adequately protected with backup jobs.
Having a combination of backups, replicas, and possibly even CDP provides a strong foundation for your data protection needs. Additionally, it’s important to test your backups and replicas periodically to ensure recoverability.
Implement all of this into a DR runbook with clear steps and procedures to follow, and you can have peace of mind knowing your data is safe and resilient.
The post Putting the Replication in Veeam Backup & Replication appeared first on Veeam Software Official Blog.
from Veeam Software Official Blog https://ift.tt/S9FPDpQ
Share this content: