No, not really -- but a surprising number of IT shops have moved beyond simple snapshots towards continuous data protection -- a DVR-like model that allows recovery to any point in time, and not just to potentially stale snapshot.
There's a lot to like in the product: extreme flexibility in defining protection modes, well-integrated with applications, operating systems and hypervisors alike, extremely efficient in its use of network and storage resources, and seriously storage agnostic on the back end.
Customers have embraced the product enthusiastically -- there are now over 10,000 RecoverPoint units in production today, and more of our customers are coming on board every day.
Don't get me wrong: snaps are handy things to have around, and they've saved more than one administrator's bacon over the years.
But when you start studying the challenges associated with larger environments, better automation, efficiency, etc. -- you start looking for something with a bit more architectural meat on it. And that's where RecoverPoint shines.
Today, EMC is announcing version 4.0 of RecoverPoint. This is no minor release; there's a slew of new capabilities that are worth reviewing. Hopefully, you'll come away with the same conclusion I've reached: snaps have their historical place, but the industry is moving to a continuous data protection model for recovery -- for good reasons.
If I'm not mistaken, EMC was the first storage vendor to introduce array-based disk copying. The year was 1997, the product was TimeFinder, and it only made full copies at the outset.
But even with those early limitations, customers found all sorts of ways to use a quick copy of production volumes: speeding up backups, testing, decision support and more. TimeFinder was complemented by SRDF, which made copies at a distance. The combination proved to be very popular, especially in larger enterprises. To this day, the current instantiations of these technologies lie at the heart of so many mission-critical environments.
But things change quickly in IT, and EMC doesn't like to be caught flat-footed when technology shifts are brewing. By 2005, we saw that a new replication model was starting to emerge: continuous data protection: essentially a sequence of logged changes that could be recovered to any arbitrary point of time. It was pretty clear that this new model could do some very cool things that SRDF and TimeFinder couldn't easily do. In 2006, we decided to acquire the best technology on the market (Kashya), and started to build a new product line: RecoverPoint.
As the product evolved and matured, we started to steer our customers towards RecoverPoint as the preferred solution if it fit the requirements. It's now 2013, and -- as you'll see -- we have a very mature and differentiated set of capabilities now as a result.
How It Works
My brief description is no substitute for an in-depth review, but here's a quick synposis.
The splitter most often lives in the storage array, but also is finding a new home within the VPLEX layer as well. There's also a host-based version.
The RecoverPoint appliance is where the magic happens: it coalesces and compresses the new writes, and lands them in potentially multiple new locations: on the same array, on a different array in the same data center, or at remote facilities.
Policy is set on a per-application basis: frequency of checkpointing, degree of protection, etc. The RecoverPoint application orchestrates all the magic across multiple splitters and appliances. It knows about consistency groups (applications that must be kept logically consistent across multiple resources), application integration, operational and administrative workflows, resource utilization, performance, alerts, and so on.
In the hands of customers, RecoverPoint is being used for disaster recovery (obviously), but more pragmatically for operational recovery as well. If something gets corrupted for any reason, it's pretty simple to quickly roll back to the precise point of time before the corruption occurred.
A handful of customers are starting to use RecoverPoint to relocate workloads between data centers -- it's a quick failover, and the workload is moved.
Talk to most any RecoverPoint customer, and they'll usually break into a smile when the topic comes up. The story is pretty much the same: the stuff just works, and works very well indeed.
Protecting and recovering data is now one less thing they have to worry about.
What's New In RecoverPoint 4.0
There's an awful lot here, I'm just going to go with the bits that I find particularly interesting.
The first thing that jumped out was the new topology flexibility. Up to 5 RecoverPoint clusters (basically a RecoverPoint domain running in a data center) can now be interconnected in a potentially infinite number of ways: hub and spoke, peer-to-peer, fan-out -- or any combination of models using the same resources.
Topologies can be easily defined and re-defined -- and a single console manages it all. If you can imagine it, it probably can be done. Great for IT shops that have multiple data centers -- and want to put all their assets to work in protecting applications efficiently.
Purchase RecoverPoint, and you can spawn up a reasonable number of virtual data-moving appliances to get more bandwidth if needed at no extra (software) cost.
A quick rule-of-thumb -- a single vRPA running on 8 vCPUs and 8 GB RAM is good for ~8500 write IOPS and ~80 MB/sec throughput. Add more vRPAs and things scale linearly. This initial version only works with the splitter found in the VNX storage array (attached via iSCSI to the virtual appliances), but -- even with this restriction -- the initial costs for a decent deployment can drop by around 60% when you bring your own ESX hardware.
Administrators can now easily select an arbitrary point-in-time from vCenter, and recover either in-place or to a new location -- no need to leave the VMware environment.
A great demo of this will be at EMC World, if you're interested.
Not to forget other hypervisors, there's new Hyper-V support for CSVs (Clustered Shared Volumes) as well as ODX offloads.
For those of you who are using EMC's SRDF, there's a new integration between SRDF and RecoverPoint. For almost two decades, SRDF has been the de-facto standard in high-end replication, disaster recovery and business continuity: superior performance, rock-solid, feature-rich , extremely mature, etc.
All well and good, except the SRDF model is a remote mirroring model -- which means that any potential data corruption would be copied faithfully and expeditiously to the other side.
Historically, SRDF would be used in conjunction with TimeFinder (snaps) to provide additional point-in-time data protection, but now RecoverPoint can perform this task using a continuous model. The result is a combination of uber-performant remote mirroring and continuous data protection.
Rounding out the new version, a significant per-cluster scale increase in number of production and replicated volumes, with a new aggregate capacity of 2PB for production and copies.
There's more, but this post is getting long already :)
And A Preview Of Things To Come
At one of the EMC World sessions, there will be a preview of a forthcoming version that uses a different replication model -- per-VM instead of LUN-based. The motivation is clear: today's LUN-based model can be unnecessarily complex for an all-VMware shop that uses VMs as their basic unit of compute. You have to map LUNs to VMs, a given LUN may support more than one VM, and so on.
If you're an all-VMware shop, it's a pretty slick demo waiting for you at EMC World.
Are Snaps Dead?
For many IT shops, lashing together various array-based snap technologies has started to reach its logical limits: too complex, too slow, too inefficient, too inflexible, too brittle, tied to specific arrays, etc.
These people start looking for something better -- something they can grow with, something that won't break the bank from either a capex or opex perspective, something that's well integrated with what they're using today.
And, for so many folks, once they discover what RecoverPoint can do, it's a done deal.