Data ONTAP 8.2 RC1 has been posted to the NetApp support site. Being a Major Release after 8.1.x, it has a lot of new functionalities. Here is a quick list of features (not exhaustive) that have been added to Clustered Data ONTAP (cDOT) 8.2 –
I had a great last week and the highlight of my week was a customer saying “This is too good to be true” after a Clustered ONTAP presentation and then the same thought crossing my mind during an ONTAP roadmap session. There are great things coming in not so distant future which I can’t share just as yet. You can surely expect NetApp to further raise the level of the newly created Scaleout Unified Storage Market just like it did with Unified Storage.
Coming back to what I wanted to discuss. One of the things that some customers/partners bring up about Clustered ONTAP is that if the NetApp LUNs/volumes are limited to a single node or if they are striped across the nodes.
I met a relatively new NetApp customer a few weeks back for discussing the best practices around vSphere and NetApp. While going through the some of the stuff, he brought up a point around VSC Backup & Recovery (SMVI) that when he tried restoring a complete Datastore from a NetApp Snapshot backup, he found it to be much faster than restoring a VM from the same Snapshot. I explained to him that while the Datastore restore utilizes SnapRestore which simply reverts the pointers of the volume to a previous point in time resulting in near-instantaneous restores, the VM restore utilizes something called Single File SnapRestore (SFSR) which copies back the files from the snapshot copy to the Active File System.
So the time taken to restore a single VM is dependent upon the size of the VM. I also shared with him a great workaround to achieve instant restores of VM by mounting the backup through VSC, adding the VM in the mounted backup to the inventory, powering it on and using Storage vMotion to move it wherever one wants. My colleague Keith Aasen (also a fellow Canadian) has documented the process here https://communities.netapp.com/docs/DOC-10862
While the above process is great for instant restores, wouldn’t it be nice if the SFSR process itself was faster?