Today is a key milestone for Veeam Availability Suite v8 (a combination of Veeam Backup & Replication and Veeam ONE) as Update 2 is now generally available. Both products have been updated, and in this blog I’ll showcase what you need to know about the most important features: FULL vSphere 6 Support, Veeam ONE updates and Veeam Endpoint Backup FREE Support.
Veeam FULLY supports vSphere 6!
When I last wrote how vSphere 6 Support is coming soon, we wanted to proactively communicate that support was coming. Since then, our QC has been busy performing our standard extended stress testing of the release candidate builds against vSphere 6 RTM code – and today we are finally making the Update 2 generally available.
As always, we did not settle for basic compatibility and are providing FULL support of vSphere 6 with the following features and enhancements, most not currently available from any other vendor:
- Support for VMware Virtual Volumes (VVols) and VMware Virtual SAN 2.0
- Storage Policy-Based Management (SPBM) policy backup and restore
- Backup and replication of Fault Tolerant (FT) VMs
- vSphere 6 tags integration
- Cross-vCenter vMotion awareness
- Quick Migration to VVols
- Hot-Add transport mode of SATA virtual disks
Let’s look into this list a little closer. While support for VVols, VMware Virtual SAN 2.0 and Hot-Add transport mode of SATA virtual disks comes easy by simply using the new Virtual Disk Development Kit (VDDK) version, it’s still important to note that our Virtual SAN support remains very advanced on the market as Luca describes. Keep in mind that this smart processing mode provides the most efficient availability technology for any EVO:RAIL and EVO:RACK solutions, as they are built on VMware Virtual SAN. Just put a virtual Veeam proxy on each host.
If you are investing in these next-generation storage technologies from VMware, then you already know that Storage Policy-Based Management (SPBM) is the way to manage VM storage requirements in vSphere going forward. With our support for VM policies backup and restore, we are able to restore VM storage policy associations upon full VM restore. This eliminates manual processes, which directly impacts recovery times. SPBM policies are important to restore because “out of policy” VMs can impact availability of either the restored VM itself, or other VMs sharing the same storage. By default, we will restore the same policies as the backed up VM had – and of course you can choose the desired policy in case of out of place restores:
Storage Policy-Based Management restores ensure the restored VM gets the same policy, or a new one, it had before the backup.
The most intriguing part of our vSphere 6 support to me is having the ability now to backup Fault Tolerant VMs with Veeam Backup & Replication. Among many other enhancements to Fault Tolerance, vSphere 6 includes the ability to snapshot Fault Tolerant VMs through APIs (and this is actually the only way that a snapshot can be created on this type of VM). And thanks to that, Veeam Backup & Replication can finally backup and replicate your Fault Tolerant VMs – just like any other VMs. This, along with other Fault Tolerance enhancements in vSphere 6 removes the remaining barriers of using Fault Tolerance in your data center, providing truly the ultimate in availability for your modern data center.
vSphere 6 also provides new APIs for programmatic access and management of vSphere tags. Tags are really a great way to set backup policies when the infrastructure is mixed and combined for resource optimization. We’ve had support for vSphere 5 tags already (of course, Luca blogged that too) and with our vSphere 6 tag support, you can continue building advanced backup policies around this very flexible infrastructure-centric framework even after you upgrade.
Another key feature that we have support for in vSphere 6 is cross-vCenter vMotion. While Veeam Backup & Replication supported protecting VMs across multiple vCenter Server systems for as long as I remember, the problem this new VMware functionality solves is jobs “losing” explicitly added VMs after they move to another vCenter, where their unique object ID (moRef) will be changed. With added support for cross-vCenter vMotion in our Quick Migration functionality, when migrating a VM to another vCenter Server, the associated entries on backup or replication jobs will be updated automatically, so the availability requirements continue to be met.
The final support for vSphere 6 point I want to cover is the ability to do Quick Migration tasks to a VVol. Quick Migration is still a part of Veeam Backup Free Edition, and is a great way to move VMs around when using vMotion is not an option, including instances when you have an unreliable or slow network links, in scenarios when vMotion is not supported, or even due to something as simple as the lack of the corresponding VMware license. This functionality can help to perform full migrations to new clusters built from the ground up with the latest vSphere 6 features and not inherit any design problems from previous clusters.
For us, fully supporting vSphere 6 means both fully leverage all the new features, and ensure that our customers can confidently run the latest VMware technologies in your data center with the availability levels you demand. You may wonder why we never rush into declaring support, and instead always take a few weeks to perform extended testing of the pre-release code against the final platform code? Because it’s backup (and the protection and availability of your data), and it cannot be rushed. Reducing the time it would take would only include additional risk, this Forums thread explains a bit more on the background of this process. If you are reading Veeam Forums weekly digests, or follow Gostev on Twitter, you likely saw him mentioning us finding a major bug with the Direct SAN access transport with vSphere 6: