Note: thi post originally appeared in the official Veeam blog.
The upcoming Veeam Availability Suite v9 has tons of enhancements and new features, but improvements around primary and backup storage will surely be one of the biggest parts of our next release.
We already announced a new addition in our list of supported storage arrays for our storage snapshots integration (EMC VNX/VNXe), but this isn’t the only storage news—on the contrary, there are plenty of them, and I’ll cover some of them in this post.
The first new feature we are announcing today is something I waited a long time for personally, and I suspected it was about to come when we had our first NFS client in v8 (as a part of our NetApp integration). For a long time, NFS users have felt a bit like second-class citizens in the virtualization world, and the lack of direct access to an NFS storage in VDDK to read data during backup operations was surely one reason to “envy” block storage users. All of the NFS-specific issues VMware backup has had in the past years didn’t help, either. Now, in v9, something similar to Direct SAN processing mode will finally be available for NFS as well. Internally, we call this feature Direct NFS. With it, any new Veeam proxy will run our new and improved NFS client to directly access any NFS share exposed to VMware vSphere, supporting both the traditional NFS v3 and the new NFS 4.1 available in vSphere 6. With the complete visibility of single files allowed by the NFS share, NFS users will be able to backup and replicate VMs directly from the NAS array and avoid the need to cross the hypervisor layer for their activities. This will result in faster backups and an even smaller load on production workloads.
Our next feature is specific to NetApp. When we added support for NetApp storage arrays in v8, one of the features our customers loved was the ability to orchestrate NetApp snapshots and create SnapMirror and SnapVault copies directly from the Veeam interface using our existing scheduling capabilities. However, proper backups, with data stored outside of the NetApp infrastructure for optimal availability, were only possible using the primary array as a source. In v9, we will add more features to our NetApp integration with Backup from SnapMirror and SnapVault. By leveraging these two unique features, users will be able to execute low-impact, storage-based snapshots (also with application consistency, if desired), replicate these restore points to a secondary NetApp array using either SnapMirror or SnapVault and then take true backups of their VMs to an isolated backup storage from these secondary locations. The backup operations will not touch the primary storage at all, which preserves its maximum performances. All the needed I/O will be consumed from the secondary array, making a better use of it instead of it just being a passive target for the copies.
Speaking of storage snapshots, the last feature will make an even better use of them. So far, Backup from Storage Snapshots and Veeam Explorer for Storage Snapshots has been able to use storage-level snapshots for backups and restores. But those are not the only types of jobs that Veeam can do. Think about our Virtual Labs for instance, which can only run VMs from backup files today. Virtual Labs are essential for most use cases, but also limited on performances for the On-Demand Sandbox use case. To address this, in v9, we are introducing On-Demand Sandbox for Storage Snapshots. By using existing storage snapshots in supported arrays (HP, NetApp and EMC running on VMware vSphere), we can create completely isolated, yet full speed, copies of your production environment in just a few clicks for fast and easy testing and troubleshooting. There are many use cases for this technology, but I’ll just give you one example: what about creating a new multi-VM environment, and then, thanks to quick storage snapshots, literally cloning it multiple times to deliver different test environments running at full I/O performance in just a few minutes for your developers? And imagine doing this straight from the storage array, without the need for a backup first. And I’m pretty sure all of you will have a different use case to take advantage of this new feature.
That’s it for today’s part of our storage-related announcements, but if you think all the storage enhancements have been covered with this post and the previous one about the integration with EMC storage arrays, well, sorry for the shameless teaser but there’s many more that I can’t share just yet.
Nonetheless, I think that’s more than enough storage-related news for one day, isn’t it?