Most IT staff already understand the differences between a recovery point objective (RPO) and a recovery time objective (RTO) and many companies use storage system snapshots to meet specific RPOs and deliver faster RTOs. Yet what is not always so clear is that the few seconds it takes to create a snapshot does not necessarily translate into a recovery time that is equally as fast.
The rapid creation of a snapshot can result in an illusion that application recoveries are just as fast. Since snapshots typically only take seconds to create on most storage systems, companies can incorrectly assume that application recoveries will also only take seconds or minutes to perform. The unpleasant reality is that snapshot recovery times can vary by storage system and may not restore the data back as fast as IT staff expects or to the state that the application expects it in.
For example, some storage systems only create snapshots in a read-only state. While the snapshot may be available immediately, if the application requires read/write access to the data in order to recover from a failure, IT staff still need to copy the data back to the production volume thereby lengthening the application recovery time. Another potential problem is the requirement for the source volume to remain available in order to access the data since snapshots typically copy pointers of the source volume to the target volume. However if the volume to which the index is pointed is corrupted or inaccessible, so is the snapshot. To recover the application in this circumstance could require a complete restore of the data from tape.
Of course, not every storage system has such a radical disconnect between the time it takes to create a snapshot and the time it takes to recover it. One such example is Compellent’s Storage Center storage system where data recoveries are nearly as fast as the creation of the snapshot.
In discussing this feature with Compellent’s Senior Product Manager, Bob Fine, he explained that Compellent’s snapshot technology, called “Data Instant Replay“, is based on thin provisioning. Using thin provisioning, the amount of data that each snapshot or replay needs is minimal plus it give users a wide range of choices for recovery without the wait. They can do local read-only recoveries, local read-write recoveries and, because the amount of data on each snapshot is so small, configure another Compellent Storage Center storage system at a secondary location and do a full recovery of the data and application in seconds or minutes.
The more difficult question that companies need to answer is how do they bring Compellent into their environment? The glitch with using storage systems based on thin provisioning is that the volume managers used by most operating systems do not recognize thinly provisioned storage system volumes. As a result, data migrated on a block-by-block basis from existing volumes to Compellent’s thinly provisioned volumes consumes just as much storage space as before. While the data migration does not negate the benefits of Compellent’s Storage Center Data Instant Replay, it does negate one of the other primary benefits that thin provisioning provides – the prevention of storage over provisioning.
As its name suggests, Compellent’s Storage Center is a compelling product for companies to evaluate but they need to exercise caution in how they implement it and in what circumstances. Compellent’s Data Instant Replay feature should match the snapshot capabilities of other storage systems and exceed many in its recovery capabilities. However Compellent’s use of thin provisioning to provide this feature should give companies pause about what types of application data they should migrate to Storage Center and what other promised benefits of its thin provisioning feature it will not be able to deliver.