News

1/25/2011
11:32 AM
George Crump
George Crump
Commentary
50%
50%

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.

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
404040
50%
50%
404040,
User Rank: Apprentice
11/16/2011 | 12:25:59 PM
re: Deduplication 2.0 - Recovery Performance
great job
404040
50%
50%
404040,
User Rank: Apprentice
11/16/2011 | 12:26:45 PM
re: Deduplication 2.0 - Recovery Performance
fantastic.
More Than Half of Users Reuse Passwords
Curtis Franklin Jr., Senior Editor at Dark Reading,  5/24/2018
Is Threat Intelligence Garbage?
Chris McDaniels, Chief Information Security Officer of Mosaic451,  5/23/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11506
PUBLISHED: 2018-05-28
The sr_do_ioctl function in drivers/scsi/sr_ioctl.c in the Linux kernel through 4.16.12 allows local users to cause a denial of service (stack-based buffer overflow) or possibly have unspecified other impact because sense buffers have different sizes at the CDROM layer and the SCSI layer.
CVE-2018-11507
PUBLISHED: 2018-05-28
An issue was discovered in Free Lossless Image Format (FLIF) 0.3. An attacker can trigger a long loop in image_load_pnm in image/image-pnm.cpp.
CVE-2018-11505
PUBLISHED: 2018-05-26
The Werewolf Online application 0.8.8 for Android allows attackers to discover the Firebase token by reading logcat output.
CVE-2018-6409
PUBLISHED: 2018-05-26
An issue was discovered in Appnitro MachForm before 4.2.3. The module in charge of serving stored files gets the path from the database. Modifying the name of the file to serve on the corresponding ap_form table leads to a path traversal vulnerability via the download.php q parameter.
CVE-2018-6410
PUBLISHED: 2018-05-26
An issue was discovered in Appnitro MachForm before 4.2.3. There is a download.php SQL injection via the q parameter.