Review: Veeam Backup & Replication 6.5

Disaster happens -- it's a fact of life. The only thing IT pros can do is be prepared and keep systems as recoverable as possible.

Having recently migrated a good portion of my environment to a virtualized configuration, I wanted to find a backup and recovery application geared toward this new architecture. I already had the benefit of attending several demonstrations from Veeam Software, which specializes in backup and recovery of virtualized environments, and was anxious to see the application in action.

My experience with Veeam Backup & Replication 6.5 has been first-rate and uncovering several additional features has allowed me to find even more things that are quite useful as my journey into a virtualized world continues.

The latest release, Veeam Backup & Replication 6.5, is a data protection platform created for virtualized environments. It supports VMware hypervisors and Microsoft Hyper-V. When I first began configuring the application and started to put jobs into it, I was pleasantly surprised with the process. I found the basic backup interface (Figure 1) straightforward and easy to work with.

[Click on image for larger view.]Figure 1. Several backup jobs are queued in the main Backup & Replication interface.

Veeam uses an incremental snapshot technology to capture a full backup and changes in the data after that point, and does so in a reasonable amount of time.

Initial Backup
Backup & Replication lets you include multiple VMs in the same job, allowing related machines to be grouped together. On the first run of a backup job, all of the used space within a machine is backed up. Then incremental backups occur on a set schedule to capture changes to the VM data.

By default, Backup & Recovery keeps 14 snapshots of each job. This can be changed to accommodate the needs of your organization.

In addition to the full and incremental backup process, the application also supports reverse-incremental backups. The two differ in how they write backup data for storage. Incremental backups reduce the time needed to migrate the backup data to tape in a disk-to-disk to tape configuration. Reverse-incremental backups can be used to keep the latest backup image in a restore-ready state. In a disk-to-disk scenario this would keep the newest snapshot ready to restore as needed.

Backup Scenarios
Administrators can back up any VMware or Hyper-V virtual disks (VMDKs or VHDs) attached to those guests. Veeam cannot back up physical servers and storage, such as iSCSI devices attached directly to the guest environment. By default, all virtual disks attached to the VMs are included in backup jobs. If there are disks connected to a VM that you do not wish to back up, you can exclude them.

Anything goes as far as things living inside the guest. The real power of the application is in the restoration capabilities. The file-level and instant-recovery options are worth their weight in gold simply because of the detail available and the speed at which the recovery happens. These really impressed me both during the demo and in my own use of the software. The ability to dig into the files stored as part of the backup and then recover just what's missing or needed has been helpful on a few occasions.

In addition to plain backup and recovery, Veeam has brought in a technology that allows easier testing of exact duplicates of your environment without actually creating those duplicates and constantly re-working both machines to ensure they're the same. This is done using SureBackup and Virtual Lab capabilities.

Virtual Labs and SureBackup
I've long wanted to test scenarios and verify a backup. Relying on the checkbox to verify upon completion might leave you sorely disappointed because that simply ensures the write completed successfully. Using Veeam to create a Virtual Lab environment is a feature I think is incredible.

What this technology does is create a VM to act as a proxy between the lab environment and the production environment. Routes are created on the Veeam server to allow traffic to pass into the lab, but not to pass out. There are no actual network connetions on the virtual switch created by the lab, which completely separates the data behind the proxy from the production environment.

The process also creates its own data store to ensure data written to lab machines is redirected to its own location. This ensures that changed information can be used while the lab machines are online.

When the lab machines are running, the backup jobs for the selected VMs included in the lab are powered on in read-only mode. This is the reason for the additional data store, which holds the writes for running lab machines. When this configuration is used, you can spin up fully tested backups in a running scenario.

Other reasons to use the lab technology might be to test patches for guest OSes and applications to ensure things will not corrupt, break or otherwise affect a production environment.

One example I've looked at was creating a lab to hold one member server and an Active Directory domain controller. When the DC role is specified at the creation of the job, there's some magic that happens during the backup of the system to put the DC into non-authoritative mode. This ensures that a recovery of the DC won't assume it's authoritative for the domain and write its data all over your environment.

If it were left to do that, data within the directory would be wrongly overwritten and replicated around the network causing more than a few headaches down the road. As long as the snapshot backup of the DC is non-authoritative, when the recovery completes and the machine is brought back into production, it will receive updates via replication. This will bring it back up-to-date rather than allowing it to send old information to other DCs.

Off-Site Replication
A backup of a VM that's easy to configure and work with is great -- and fast restores are even better -- but what about off-site backup storage? In many environments archiving to tape is a common way to store things off-site. Now that disk-to-disk is becoming more popular or preferred for the speed of restoration, Veeam supports replication using a proxy server on both ends. This allows the application to transfer data from the source site to the destination site.

To configure a disaster recovery (DR)replication job, you'll need a Veeam proxy to manage the data in both sites. In the source site the Veeam server that handles your backup jobs will do the trick. In the destination or DR site, a basic virtual server running Windows with the Veeam Backup agent installed can be added to Veeam as a backup proxy. The outbound bandwidth settings will aid in throttling bandwidth for replication jobs between sites.

Once you've configured the proxy, you can create a replication job, which uses both the source and destination site proxies to send data to an alternate site. Because Veeam Backup & Replication exists in the DR site as well, you can use the replicated environment from the DR site if needed during a recovery. When the primary site is running again, a replication job to pass the current information back in the other direction could be run to move the VMs back to the primary location.

The application also displays real-time progress about each job as it's running.

Configuration Backups
A much-needed configuration ensures the configuration database is backed up. In previous releases, there was no backup for the Veeam configuration data.

Veeam has also included Microsoft Windows PowerShell access via a snap-in to enable access to the application through a Windows PowerShell command line. For those who use Windows PowerShell to manage their environments, Veeam is fully compatible. Jobs can be managed within Windows PowerShell and scripted to allow for automation of the backup environment.

Overall, Veeam provides a number of interesting features that can improve backup in any virtual environment. Configuration is fairly straightforward and the support staff is knowledgeable when issues arise.