Each simulated "backup day" should include a single backup (i.e., one backup set copied until it's complete), simultaneous backups (as many simultaneous copies as you have tape drives), deduplication and replication. If possible, the simultaneous backups should supply enough throughput to reach that system's maximum throughput. Once all of those activities have completed, the next day's "backups" can continue by copying the next set of backup tapes into the system.
|Dedupe testing tips|
Use real data: To get accurate results, all testing should be done using copies of the data you actually back up.
Try restores, too: It's not enough to just test backup performance, you should also test dedupe products by doing typical restores.
Recreate replication: It's likely you'll also replicate backup data to a disaster recovery site or vaulting facility, so you should test how well -- and how quickly -- a dedupe product handles replication.
Tally costs correctly: The actual price of the dedupe product might not reveal the total bill for the solution. Be sure to include the cost of any new disks or disk systems, as well as software upgrades that may be required to implement the product correctly.
The beginning of each simulated "backup week," including the first one, should include a number of simulated restore tests. The best way to test restore speed is to actually copy a predictably sized backup set from the dedupe system to tape. You should do two single restores by themselves (i.e., one backup set copied from the dedupe system to tape until it's complete), followed by two sets of simultaneous restores (as many simultaneous copies from the dedupe system to tape as you have tape drives). The reason you should copy two sets in each test is that you want to copy from the oldest and newest backups in each test cycle. What you're looking for with these tests is a difference in restore time from older backups in relation to newer backups, and from backups when the system is relatively empty to when the system is relatively full.
One key to doing this right is automation. This will allow you to do testing around the clock and will provide the best way of documenting the timing of all activities. Automating things is also the key to ceteris paribus, which is absolutely essential when testing multiple systems. If possible, another approach is to use a completely separate backup server and tape library. That will isolate the test from the backup traffic, both for the sake of production backups and to ensure that production backups don't impact the test.
Testing source dedupe
In most cases, source dedupe is being considered as a replacement for some backup software that's already "doing the job" via backups to an inexpensive tape device. While that configuration comes with a lot of drawbacks that source dedupe intends to fix, the fact that you're replacing an existing product creates a greater burden of proof on the source dedupe product.
Basic backup functionality. You'll be using this product to perform all backups and restores for supported clients. Make sure you try everything with this product that you currently do with your backup system. Schedule automated backups and see how it reports their success. If any of them fail (and you should force some of them to fail), what happens next? What's it like to rerun failed backups? What are restores like? Can the administrator do them or can users do them? Use the same workflows you're accustomed to using and see if they can be adapted to this new product.
Advanced backup functionality. Do you plan to replicate these backups to a second location? Once you've replicated all backups to a centralized location, do you plan to copy some or all of them to tape? How does that work?
Performance. What kind of backup performance do you get? How fast is the replication? How much data is sent across the wire? (Don't assume that two different deduplication products will send the same amount of data over the wire.) If you're planning on replicating across long distances, how do latency and an unreliable connection affect the overall performance and stability of the product?
This was first published in May 2009