Deduplication 2.0 - Recovery Performance"It's all about recovery", you'll here it in almost every sales presentation by a backup vendor. That advice holds true for backup deduplication devices as well. A common mistake is to assume that because deduplication products, most often disk based, that they also offer the best recovery performance. This is not always the case and as we move into the next dedupe era it has to improve.
"It's all about recovery", you'll here it in almost every sales presentation by a backup vendor. That advice holds true for backup deduplication devices as well. A common mistake is to assume that because deduplication products, most often disk based, that they also offer the best recovery performance. This is not always the case and as we move into the next dedupe era it has to improve.A common cause of poor recovery performance seems to be in poor meta data management. Most deduplication systems build some form of a table that tracks what type of data has been written to disk and where it is stored. It is the responsibility of this table to compare new inbound data to data that is already on disk and eliminate the redundant segments. It is also the responsibility of this table, in most cases, to put these segments back together when the backup application requests a file to be recovered. Interestingly as we discussed a while ago in our article "All Deduplication Is Not Created Equal" and what we have seen in repeated testing in our labs is still true today how well this table is managed and accessed can impact recovery performance. In some cases we have seen that the further you get away from the original data set the more of a performance hit poor meta-data management makes.
For example if you do 40 full backups of a data set that changes slightly between sets, meaning that the deduplication ratio is fairly high, and then try to recover from the 3rd copy and then 37th copy. With some deduplication systems you will find a significant difference in the time it takes to recover that data between those two interations of the backup data set. This is certainly something to test in any deduplication system that you are evaluating to make sure your perspective vendor has addressed this issue. It is also something that all deduplication vendors need to keep working on to make sure their systems don't have that problem. Versus straight un-deduplicated disk, a small less than 5%, performance loss is probably acceptable but anything more could begin to significantly impact recovery windows.
The other area where recovery performance is going to become increasingly critical is as data protection solutions continue to add a recovery in place type of capability, as we discuss in our article "Virtualization Powered Recovery". In this instance you can leverage the fact that disk backup technology is in fact disk and running a server instance or other type of data set directly from the backup device is now possible. The performance focus shifts from fast streaming reads to purely random interactive reads. While no one is expecting primary storage like performance, deduplication hardware vendors need to make sure that they can handle this change in requirement from the deduplicated area or they may need to provide a non-deduplicated staging area, to at least keep that performance acceptable.
Another event that impacts recovery performance is what happens when a disk has failed on the backup deduplication system and you need to recover data while the rebuild is underway? We will address RAID data protection and how it is implemented on deduplicated systems in an upcoming entry.
Track us on Twitter: http://twitter.com/storageswiss
Subscribe to our RSS feed.
George Crump is lead analyst of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. Find Storage Switzerland's disclosure statement here.