Depending on which blog post do you consider, I’m really late on this news (on this blog) or I was the really first one to write about it (on the Veeam official blog).
Joking apart, by now the news is already well spread around: in the new upcoming v8, Veeam Backup & Replication will add a new storage vendor for its Backup from Storage Snapshots support, and this vendor is NetApp. All the FAS and V Series will be supported, both in 7-Mode or Clustered Mode, with the only requirement being the OnTAP OS being at least 8.1.
After playing with the tech preview for a month now, I’d like to talk a little bit more about a couple of new technologies that are going to be in there.
NFS Support
DirectSAN support in VMware VADP libraries is only available on block storage arrays. NFS was never supported by this technology; afterall, it’s name is SAN, so… The only remaining backup methods for NFS have always been HotAdd or Network Mode. However, HotAdd over NFS has several problems (read VMware KB 2010953): basically, whenever the virtual Veeam proxy is running on an ESXi other than the one where the VM that is backed up is running, during disk removal NFS receives too much file lock requests, ultimately making the VM unresponsive. If multiple VMs are running on the same shared NFS export, the locks can impact almost all the VMs in that share, even those that are not under a backup operation. Pretty scary…
So, you are ultimately left with only Network Mode. And when your ESXi management interface runs on a 1Gb connection, your best chance is to retrieve 30-40 MBs, nothing more. Yes, you can leverage now 10Gb connections, and get in this way really great results, but not all customers have 10G connections yet.
Veeam worked around this limitation, in order to offer the same capabilities of DirectSAN mode even for NFS shares. An important note: this is not what someone already called DirectNAS; the NFS capabilities are available only with NetApp storage arrays, and only in conjunction with Storage Snapshots. There is no plan to release this feature for every NFS storage.
The solution is simple and powerful at the same time: the Veeam proxy has now an NFS client (proprietary and internally developed at Veeam), and when it runs a Backup from Storage Snapshots, it connects to the NFS share just like any ESXi server would do. From here, it retrieves blocks of the VM files from the snapshot, as it would happen with a block device. Here is a sneak peek of what you can see in the TCP connections of the proxy:
VeeamAgent.exe ( the data mover) opens a connection towards the NetApp array on its port TCP 2049, and obviously this port is NFS.
Snapshot Vaulting
The other feature I like is the integration with SnapVault, called Snapshot Vaulting. For those who don’t know what SnapVault is, have a look at this post from Nick Howell. Basically, it’s a backup copy of a NetApp snapshot, saved in a secondary storage.
When Veeam Backup & Replication runs a Backup from Storage Snapshots, it creates a snapshot of the volume or NFS export where the protected VM is saved. Usually, after the backup is completed, the storage snapshot is deleted. But, since the production array already consumed I/O to create that snapshot for Veeam, why don’t we use it instead of throwing it away? After all, both Veeam and SnapVault use a storage snapshot as a starting point. If you want to use this feature, you simply need to flag the corresponding option in the backup job:
Once enabled, the backup job requests a snapshot to the NetApp array, uses it for its own needs, and also instructs SnapVault to save this copy in its catalog. You can clearly see this in the SnapVault content:
There are both scheduled copies created by SnapVault, and the Snapshot vaulted by Veeam, saved with the name of the backup job.
Additonal notes
You probably already noted in the second screenshot, there is a new option to failover a storage assited backup to a standard backup, if something fails. Before this, a Backup from Storage Snapshots was all or nothing: the infrastructure needed to be correctly working, or the job would have failed. Now, you can enable this feature and be sure a job will be completed, even if something happens to the configured infrastructure.
Finally, I started to write a series of post about the integration with NetApp, and I had already a complete 4 parts series, when my colleagues at Veeam asked for a technical whitepaper about the integration with NetApp. So, my multi-part blog series has now become a Technical Deep Dive, and if you are insterested in reading it, you can obtain it here:
Deep Dive – Veeam Backup & Replication with NetApp Storage Snapshots.
There are also detailed informations about how to create your own lab using NetApp VSA, to test all these new features. I’m interested in your feedback about the paper, let me know if you find it useful.