Avamar: VSR vs AMS Replication

Automated Multi-Streaming (AMS)

Automated Multi-streaming replication inflates a backup on the Data Domain. It uses multiple streams to "slice" the backup up before sending it to the target Data Domain.
AMS replication is supported in Avamar 7.0 and later.

Key Features of AMS:

• Leverages multiple parallel streams to process and send backups to the replication target

• Introduced in Avamar v7.0

• By default the Avamar uses six streams per concurrent process, but this value can be changed using the proper flags.

• AMS must scan the entire backup rather than just the changes, so it often has to more data to scan than if VSR were used. 

• AMS typically has better performance with high change rate clients when the bandwidth between the sites is large. 

• AMS can cause space differences between the source and target Data Domains. This is discussed further here Data Domain: Space usage on destination DD is higher than that in the source DD when data is the same

• No restrictions on client types for this type of replication. 

Example of Avamar choosing AMS Replication:

<snip>
2015-11-22 10:05:55 avtar Info <6654>: Replicating backup 367, 528.7 GB
2015-11-22 10:05:56 avtar Info <40047>: id:1 VSR selected because file size is too small for NCR (container.1.cdsf)
2015-11-22 10:05:56 avtar Info <40050>: id:2 NCR selected because it could not be determined if VSR is possible (container.2.cdsf)
<snip>

Virtual Synthetic Replication (VSR)

Virtual Synthetic replication is a single stream replication process. It leverages the previously replicated backup so that only the changes are scanned and sent to the target Data Domain.
Once those changes have been sent, the target Data Domain can virtually synthesize a full backup. It uses the backup from the previous replication as a base file. The backup is put together with the newly replicated changes. This is in contrast to the AMS process which requires the full backup be scanned. VSR is supported in Avamar 7.1/DDOS 5.5 and up.  

Key Features of VSR:

• Single Data Domain stream consumed per concurrent Avamar process.

• Introduced in Avamar 7.1/DDOS 5.5

• By default Avamar attempts to user VSR whenever possible

• Replicates only the changed data 

• Highly network efficient 

• Ideal for low change rate clients

• Only compatible with NDMP, VMware Image, and File system backups

Requirements for VSR:

1. All these conditions must be met, otherwise replication defaults back to AMS:

2. Both the replication source and the replication destination Avamar servers must be at AV7.1 or later

3. Both the replication source and the replication destination Data Domain systems must be at DD OS 5.5 or later

4. Backup dataset must be compatible with VSR; that is, backup dataset must be VMware image, file system, or NDMP backups to AV/DD

5. "Base" backup, which is the immediate previous backup of that dataset, must exist on the replication destination

6. The replication method must be set to default or to force VSR

7. If the backup leverages the snapview process, then all the partials must also be replicated in the correct order for VSR to work correctly. See the additional notes on VSR section for further details

When attempting to replicate a backup, the initial replication leverages AMS to seed the base file on to the replication target. Once the base files are located on the target Data Domain, VSR is used assuming all VSR requirements are met. As long as VSR continues to work correctly, the base file is then updated every time the replication completes.

Example of Avamar choosing VSR replication:

<snip>
2016-03-15 07:37:17 avtar Info <6654>: Replicating backup 471, 100.0 GB
2016-03-15 07:37:17 avtar Info <40198>: id:19 VSR selected because file size is too small for NCR (16912D3D130B98D763593BD4DCD0BC586766FE46)
2016-03-15 07:37:17 avtar Info <40198>: id:20 VSR selected because file size is too small for NCR (04C560CC90AC7A626F4E7866573CF93D7D32EFE6)
2016-03-15 07:37:17 avtar Info <40198>: id:21 VSR selected because file size is too small for NCR (9D78E4B1CD2DF728D7A45B2E374D6D28A853ED2C)
2016-03-15 07:37:17 avtar Info <40198>: id:22 VSR selected because file size is too small for NCR (41A1BDB73F3BB615E03A95FC3758CDE1A2725E6F)
2016-03-15 07:37:17 avtar Info <40198>: id:23 VSR selected because file size is too small for NCR (1D6784C9E27240132EB7FBFEE3C0D4136D81AA8D)
2016-03-15 07:37:17 avtar Info <40198>: id:24 VSR selected because file size is too small for NCR (FC295BC80B73D67BFE437291253D46FAD42650C2)
2016-03-15 07:37:17 avtar Info <40198>: id:25 VSR selected because file size is too small for NCR (93B06F7711E1F64111BCAD4FBE966E051655EB94)
2016-03-15 07:37:17 avtar Info <40198>: id:26 VSR selected because file size is too small for NCR (55A58F9CDCB82A6756853E3D84A3D2A6993F2C3D)
2016-03-15 07:37:17 avtar Info <40200>: id:27 VSR selected because all base files are available (6122D9EF93CB95529D5E59327A3FF4789B0D0911)
<snip>

Additional Notes on VSR 

Sometimes where Avamar leverages partial backups VSR will not always be a viable solution. By design, Avamar expires partial backups every 7 days. If a backup is not replicated with all its partials within that 7-day time limit, Avamar removes them. This typically affects large backup clients like NDMP. For additional information about this issue, see the following knowledge article:

For Avamar 7.2.X NDMP clients not taking advantage of VSR - partial backups expired in Avamar 7.2.