
As you can guess from the product name, the pillars of the data protection strategy implemented in Veeam Backup & Replication are “2-in-1”: backup and replication implemented within a single product.
The advantage of the backup mechanism is the ability to roll back to various restore points in the past, while the replication mechanism allows you to get a minimum indicator of the time it takes to restore the system after a failure - this is especially valuable for modern data centers. Today I will talk about new replication features that will be released with the release (in November!) Of the new version of Veeam Backup & Replication 8.0.
Backup Replication
In the replication task settings, you can now choose what exactly will become a source of data for replication - this is either storage system with original virtual machine data or a backup copy of the virtual machine (from among those stored in one or several repositories; it should be noted that the latest created backup copy).

A new option, when selecting a backup file as a data source, allows you to reduce the impact of data replication operations on the production storage system.
')
Built-in WAN Acceleration in Replication Jobs
In version 7.0, a built-in WAN acceleration was implemented for backup jobs to a remote site. This functionality eliminates the need to install and administer additional solutions that specialize in optimizing WAN traffic. Since Veeam is familiar with the file structure of its own backups (still!), The built-in deduplicator works with such files better than third-party WAN optimizers. Since the WAN optimization technology was successfully tested for the case of backups, we thought: “Why not use it for replicas?”. And in the new 8th version, WAN optimization technology was also implemented for replication.

It should also be noted that the cache of the WAN accelerator can be “warmed up” before launching the task by filling it with data from the existing backup repository. To do this, perform the operation Populate cache. If necessary, the cache can be reset.
Planning to switch to the replica
A very important and useful innovation is the ability to plan a switch to a replica: now you can prepare everything in advance, and at the right time perform the operation with one click through the web interface, say, from a tablet, lying in a hammock or on the coast of the warm sea (however, I hope that readers will never have to perform this operation while on vacation).
In the console, scheduling a switch looks like this:

Create a switching plan, add replica virtual machines and build them in the order in which they should be started. For each machine, you can specify a waiting time so that each subsequent one starts strictly after the previous one starts (for example, the Exchange server will start after the domain controller).
You can create several such planned scenarios by creating separate groups for more or less critical machines (for example, separating business application servers and test VMs). In this variant, you can, for example, launch a switching plan for a less important group of machines only after you have verified that the previous scenarios have worked successfully and that you have enough resources to operate another group.
It is recommended to test scheduled switching scenarios using SureReplica technology, which appeared in version 7. It allows you to test replicas for recoverability without affecting the production environment, but using a specially designed isolated virtual lab.
Virtual Lab for backups
Let me remind you how the virtual lab (or sandbox) works on the example of backup for the VMware vSphere platform.
- The task is assigned to the host; vSwitch is created on the host
- A proxy (network router on a virtual machine with NAT) provides network interaction and isolation of the sandbox from the productive network, while maintaining access to the inside of the sandbox from those computers on the production network from which you need to save network access for administrative purposes
- Using Veeam vPower technology, a given virtual machine can be run in an isolated virtual lab environment directly from a backup repository and without the need to restore to temporary storage.

The picture shows an example of running the Exchange server in a virtual lab test environment. To restore the object from the Exchange server, you must first restore the domain controller - therefore, in the restored server farm there are both of these servers.
Regarding the virtual laboratory, several important points should be reversed:
- It consumes some network resources.
- It is tied to some host. If the host shuts down, for example, for service, the virtual lab will be unavailable
- Running all the necessary virtual machines in the sandbox may take longer than launching them in production, since a certain percentage of computer time is consumed by the sandbox itself, and the storage system storing backup copies is often less productive than production storage.
The sandbox based on the backup site resources can also be used for such resource-intensive operations as testing of patches and new software versions: it would be reasonable to first test them on “cats” in a “virtual copy” and not immediately put on production.
More information about this can be found in the post
“Disaster Recovery: Network Sandbox” based on vSphere and Hyper-V in Veeam Backup & Replication v7.Virtual Lab for replicas
With the help of a
virtual laboratory for replicas , which I began to talk about above, the administrator will be able to perform automatic verification of the correctness of replicas (SureReplica), as well as use replicas to work with the sandbox. The replica technology has the following advantages:
- A virtual lab for replicas can do without consuming production resources — a host can be used to create it even from a remote site designed for disaster recovery and not loaded with production tasks.
- Unlike backups, replicas are stored on disks in the original VMware format, and not in a compressed and deduplicated archive copy format. This allows not to spend computing resources on format conversions, which gives an increase in performance.
I also note that in the version of Veeam Backup & Replication 7.0 SureReplica could be used only for the VMware vSphere platform, and in the new version it is also supported for the Hyper-V platform.
Scheduled switching
Now scheduled switching can be performed directly from the console, which simplifies the work of the administrator during data center migration, as well as with regular maintenance of servers running on the production network. The operation takes place without data loss and with a minimum shutdown: the source virtual machine shuts down, all recent changes are replicated to the target virtual machine, and then the target machine is turned on.

Additional links:
On other innovations Veeam Backup & Replication v8, which will be released in November, you can read in these posts: