Storage Channel Pipeline

Mar 29 2010   5:39PM GMT

Backup window must include data replication

Eric Slack Eric Slack Profile: Eric Slack

Dedupe’s been around for quite a while and has found its way into most backup products — even showing up in non-backup storage products as well. When looking at backup products, most customers fixate on the backup window, and more specifically, when the backup session is complete, relative to that window. This is understandable, since backups that extend beyond this allocated time can be pretty disruptive to networks and other applications. However, the completion of the backup session also signifies that point at which data is safe – which is really the objective of the entire backup process to begin with. For organizations that send these backups to an offsite location, the overall backup session time, or “wall clock” time, must include the data replication process as well.


In these cases, the backup session would include three processes: transferring data to the on-site backup device, deduplicating that data set and then replicating it to an offsite location. Depending upon the technology used, the dedupe process may be done before, during or after the time that data’s transferred to the on-site backup device. But data replication always comes last, and the methods a backup vendor uses to integrate these three processes is key.


Some backup vendors essentially have to wait until the entire dedupe process is done before starting data replication. Others can replicate out of the “back end” of the dedupe engine while new data is still coming into the “front end.” The challenge lies in deduplication technology itself, and the fact that many vendors don’t have a simple way to break this complex process up into smaller pieces, so it can be run concurrently with replication. When this happens, the wall clock time on the backup session can stretch way beyond the backup window that’s been established. While this won’t always disrupt other IT operations, it does mean that an organization’s data isn’t safe. In the worst cases, another backup session may actually begin before the previous one is complete.


As a VAR, you’ve probably got more than one vendor offering deduplication as a part of its backup solution. And, you’ll certainly compete with others in the deals you run. Many vendors define “backup window” and the time their products take to complete a backup session very differently. It would make sense to understand exactly how your vendor does these steps, how long it really takes for the whole backup session (wall clock time) and the claims they make about their performance. The ‘devil’s in the details’ and you need those details in order to educate your customers and best present your solutions.


Follow me on Twitter: EricSSwiss.

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • 22tango
    Nice post on important concerns that any IT Manager should consider. More to the point, the legacy approach of separate backup, dedupe and replication products creates these issues. Cofio now offers fully unified backup, dedupe and replication. You can get your live backup done, with any type retention, and then replicate right out of the backup repository to a live replication node for DR. You touch and move data from primary once, not several times, and achieve high dedupe rates over legacy backup approaches a a natural part of the process (10:1, 20:1, 30:1, would depend on your strategy), with full mirror going out the backend.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: