Jon's bag of tricks

Avamar: Tape Backup Alternative

One of the most powerful features of Avamar software is its ability to replicate backup sets to another Avamar grid, providing offsite backups without the hassle of cutting and handling tapes. Avamar’s deduplication functionality not only reduces the amount of storage required but also the bandwidth required to replicate what is functionally the equivalent of a full backup. While the reduction in bandwidth is dramatic, the difference bytes still have to be sent across a WAN link. Sizing that bandwidth properly is critical to the effective operation of the Avamar System.

Calculate Change Rate with Script

The first thing you need to determine is your daily change rate. The easiest way to determine this is to utilize the capacity.sh script. This script is included in an optional bundle of scripts that can be obtained from Avamar support or your IDS engineer. The output of this script provides information about the total bytes added, expired and daily net change for the last 30 days. It also provides averages of these values over the same period. The average bytes added value is the value that you need to calculate the needed bandwidth.

Backup/Replication Best Practices

Avamar recommends that replication run from 10pm to 6am. This ensures that backup sets earlier in the backup window can be replicated the same day. The challenge is that replication is only performed on complete backup sets, so if you have a backup that runs for several hours after 10pm replication of that backup set will run the following day. The other consideration is that Avamar recommends that replication be completed before daily maintenance operations run, and that backup and replication operations not run during the daily maintenance operations. Avamar’s best practices guide recommends that you size your replication bandwidth to complete within 4 hours for typical changes providing a 4 hour buffer for spikes. This is an important consideration, so you don’t fall behind.

Bandwidth Sizing Example

To create a scenario, let's walk through a bandwidth-sizing example. Running the capacity.sh script, it is determined that there is a daily average addition of 50GB. In order to replicate this change rate reliably the goal is to have this replicated in 4 hours. This requires 12.5GB/Hr or 3.5MB/sec. This needs to be converted to bits so multiply by 8. 3.5MB/s * 8 = 28Mb/s. Latency and protocol overhead needs to be accounted for—20 to 25% overhead is a good rule of thumb. 28Mb/s + 20% = 34Mb/s. For this example a T3 would provide sufficient bandwidth to replicate the daily average addition of 50GB.