As with target dedupe, there's no substitute for real data during testing. But unlike target dedupe, it can be very difficult to reliably test these products doing anything short of backing up the types of systems you plan on actually backing up. You can back up test systems, but the test is only valid if you can simulate user activity, such as emails to the Exchange database, and new and updated files in the file system. Without those changes, your source dedupe system will perform very well, but will offer no insight into how it's going to perform in the real world.

Most people can't simulate real user activity on a large test environment, so their only alternative is to back up real systems. Once you've verified in a test environment that the software in question can run on the types of systems you'll be testing, you need to begin a proof of concept on "real" systems that will represent the types of systems you'll be backing up. To minimize risk, it's best to start with systems that aren't currently being backed up and don't have a mission-critical uptime requirement, such as laptops. Select a few users to pilot the software, make sure they're aware it's a pilot and ask them to report their experiences to you. Once you've logged a little time with those types of systems, you can expand to file servers at a remote site, followed by application servers (such as Exchange). Just remember that each time you start backing up a new type of system, you risk negatively impacting

Requires Free Membership to View

the stability or performance of that system -- so you must watch for any instabilities during each test.

Any systems already being backed up in the proof-of-concept test should continue being backed up via the previous method until you're in production with the new system. If they're Windows systems, you must verify that the two programs won't interfere with each other by resetting and/or using the Windows archive bit. The worst-case scenario would be if they're both using it, as new or modified files would get backed up by the next backup product to run and wouldn't get backed up by the following product. You must verify how the archive bit will affect two products running in parallel.

Make sure to get answers for all of these questions. Also simulate all of the things that are likely to happen, such as a laptop user suspending their laptop in the middle of a backup, an Ethernet cable being unplugged or an Internet connection timing out. The hardest question to answer may be how many bytes are actually sent across the network, so you may need third-party network monitoring software to get a verifiable number.

Nothing proposed here is easy. However, the potential risks of buying dedupe systems without proper testing are simply too great to consider skipping testing. With some dedupe vendors possibly exaggerating their products' prowess, testing is the only way to separate truth from fiction -- and probably save some money in the process.

BIO: W. Curtis Preston is an executive editor at and an independent backup expert.

This was first published in May 2009

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

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

Your password has been sent to: