Thousands of people at VMworld, I get two Nintendo 3DS Streetpass hits. Neither from conference attendees that I can tell. Conversations about XtremIO (Project X if you're in marketing) on the Route 6 bus between the hotel and Moscone, but no puzzle swap game pieces for Zilla.
Gamification my arse, you people need to get with the program!
I'm also on the ground floor of my hotel, next to a rather busy intersection. No blinds, just bizarre shutters who's privacy capability is questionable. Since I like to air dry after a shower I should be on the news by the end of the week.
Watch the skies for that one.
Moving onto the reason why I'm here this week, apart from finding even more limitations in using the iPad as a creative tool and writing a Day 1 blog post during Paul Maritz's keynote, when people consider deploying virtualization solutions into their environment one of the very first questions they ask themselves is 'How do I back this up?'
It's a question asked so frequently that VMware themselves have expended effort on an answer. First with VMware Consolidated Backup (VCB), then with the VMware API For Data Protection (VADP) and with VMware Data Recovery (VDR).VADP has been stupendously successful in VMware backup, controlling the snapshot process and providing time saving functionality such as Change Block Tracking & Changed Block Restore, it truly has become the defacto method by which backup applications interact with vSphere.
To address the SMB market VMware developed VMware Data Recovery, VDR being easy to deploy and directly integrated at the managment level with the rest of vSphere suite.
While VDR was practical and functional through it's use of VADP, there was always a question over how scalable it was going forward and how much development effort would be required to build on VADP. So, VMware were faced with a choice. They could continue to develop VDR on their own, or they could take the solid core of another product and build on top of and around that.
They chose to build around a core technology. That technology now and going forward being EMC Avamar.
Now, while I'd love to say I could extend my hand out from EMC and make things happen at VMware, that is not the case. VMware always have the option to make acquisitions and forge alliances which could cause consternation back at EMC. They can do this if it's clearly good for VMware to do so. This was a beauty contest and it was a beauty contest which Avamar won.
And so after months of effort, today VMware introduce vSphere Data Protection as embedded functionality inside vSphere 5.1. Available to anyone with Essentials Plus licensing and above for no additional charge, VDP allows for the deployment of VDP virtual machines with up to 2TB of deduplication storage each of which capable of backing up 100 virtual machines using Avamar variable length data deduplication. Image level backup and granular recovery fully integrated into the new vSphere Web Client.
And it"s as easy to deploy as VDR was, meaning if you want to use it as you primary backup system or just spin something quickly up for a proof of concept it's only a few clicks in vSphere to do so.
What about the future? Well, it's not for me to speculate on VMware's product but what I can say with assurance is that it'll develop in lockstep with the vSphere suite. What comes next is already planned.
And what comes next for VDP users who step out of SMB backup and want something spanning the mid-market and the enterprise? There's a full migration path from VDP to EMC Avamar at launch. Start with VDP and if you like it and want to do more with it you can move all your data and policies to Avamar and do just that.
To VMware, Avamar at the core of VDP allows them to focus on advancing the APIs everyone uses to backup vSphere. To me, Avamar at the core of VDP now puts Avamar everywhere. From the largest enterprise deployments to the single VDP instance backing up anywhere from 1 to 100 virtual machine images.
I look forward to seeing how VMware develop vSphere Data Protection over the coming releases and the coming years.
