Avamar：备份性能行为和理论

本文的目的是介绍在 Avamar 备份期间发生的情况，重点帮助读者了解备份性能行为。

本文是以下文章的配套文章：

• Avamar：解决备份性能缓慢的问题
• Avamar：调整备份以快速完成

Avamar 备份期间会发生什么情况？

avtar 备份过程：

1） 将文件和哈希缓存文件加载到内存中

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2） 创建 VSS 快照（在 Windows 上）：

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3） 遍历数据集定义的所有文件对于源数据集
中的所有文件，avtar 会获取完整路径，并将其与类似统计信息的元数据相结合，以计算哈希值来唯一标识该文件。

有关更多详细信息，请参阅 Avamar：当 avtar 在文件扫描阶段读取文件时会发生什么情况。

4） 将计算的哈希值与本地客户端缓存中的哈希值进行比较 Avtar 会在文件缓存

中查找文件的哈希值。它会检查它是新的，或者自上次备份以来是否已被修改。

如果文件缓存查找成功，则文件存在且保持不变。

如果查找失败，则表明文件是新的或已更改。必须读取和处理它。

有关更多详细信息，请参阅 Avamar Client — 在 avtar 认为文件已被修改之前，必须进行哪些更改？

5） 处理新的和修改的文件 对于任何新的或修改过的文件

， avtar 必须：

• 读取整个文件
• 将其分解为可变大小的区块
• 压缩每个区块
• 计算每个区块的哈希值

6） 检查 Avamar Server 上是否存在缺少哈希值的情况。

Avtar 通过网络将任何缺失哈希的数据发送到 Avamar Server，以检查它们是否已存在。这些称为“ispresent”请求。

7） 数据写入 Avamar Server（如果适用，还写入 Data Domain）。

有关更详细的工作流，请参阅随附 的Avtarprocess.pdf。


从性能角度概述 Avamar 备份：

按照上述阶段，我们将它们拆分为对备份性能影响最大的“阶段”：

阶段 0。创建 VSS 快照。

卷影拷贝服务 （VSS） 创建源数据集中指定的卷的快照。在备份运行期间，应用程序可以继续写入到卷。
Avamar 备份卷的只读“冻结”快照，而不是可写卷。这可确保它有一组一致的数据进行备份。

VSS 快照需要几秒钟才能完成。如果客户端遇到 VSS 问题，这会延迟或阻止备份继续。

第 1 阶段。文件扫描阶段。avtar 进程统计目标数据集

中的所有文件对于具有数百万个文件的客户端，此阶段可能是最耗时的。
数据库数据包含较少的较大文件，因此文件扫描阶段只需很少的时间。数据库客户端通常在阶段 #2 期间消耗其时间。

对于在 RAID 5 配置中具有旋转磁盘的客户端，文件扫描性能通常为每小时 ~100 万个文件。这从每小时 300,000 到 300 万不等。这取决于 客户端环境和要备份的数据的特征。

从 v7.3 开始，备份到 Data Domain 的 Linux 客户端可以利用 Linux 快速增量 （LFI） 功能。这可避免每次运行备份时扫描整个数据集。

关键资源： 存储备份数据的磁盘的随机寻道性能。

第 2 阶段。Avtar 读取更改的文件，然后对数据进行分块、压缩和哈希处理。

在此阶段会进行大量计算。对于每个修改的文件或新文件，avtar 会将其分成小块。它压缩每个区块，并将哈希计算为“指纹”来识别区块。

数据库备份中的文件通常很大，并且往往每天都在变化。Avtar 大部分时间都处于此阶段。最好使用官方 Avamar 数据库插件，利用增量备份功能、事务日志等，确保高效处理数据库。

典型的文件处理性能约为每小时 100 GB，但最高可达每小时 300 GB。这与环境有关。

关键资源：客户端磁盘和 CPU

对于在将数据发送到 Avamar Server 时没有瓶颈的 LAN 备份，阶段 #1 和 #2 花费的时间最多。

在下图中，考虑到图形条形中的面积量与备份所需的时间相对应。更改的文件可能会显著增加所需的时间，尤其是在这些文件很大时。

对于文件系统数据集，预计每天更改 ~0-3% 的文件。

Avtar 必须通过执行两个 I/O 操作对发生更改的每个文件进行“stat（）”，其中一个用于检查文件属性，另一个用于安全属性。

要实现文件系统备份每小时 1~100 万个文件/小时的基准扫描速率性能， avtar 每小时需要大约 200 万个查找操作，即每秒 600 个查找操作。

例如：如果备份的更改率为 3%，则 100 个文件中有 97 个文件需要两次磁盘查找操作才能确定它们是否发生了更改。其余三个确实发生了更改，必须进行扫描、分块、压缩和哈希处理。

这仅考虑文件扫描阶段，而不考虑处理任何已修改文件所需的 I/O 资源。
修改后的文件中的数据越多，完成备份所需的工作就越多。

第 3 阶段。检查 Avamar Server

上是否存在哈希值阶段 #1 和 #2 生成指向备份元素的哈希值。这些元素可以是唯一的文件区块、文件系统或整个备份。

哈希值将写入客户端缓存文件，并与 Avamar Server 上存在的哈希值进行比较，以检查是否必须添加任何新数据。无论 Avamar Server 还是 Data Domain 是目标存储，都是如此。

Avamar Client 和 Avamar Server 之间的哈希比较通常很快。如果 Avamar Server 存在以下情况，则它们不应该成为备份的瓶颈;

• 健康
• 在常规负载水平下
• 位于与客户端相同的 LAN 网段上

由于哈希只有 20 字节大小，因此此阶段受网络延迟的影响更大，而非网络带宽。当哈希到达 Avamar Server 时，数据节点的磁盘子系统的常规负载和随机寻道性能决定了检索哈希的速度以及与客户端发送的哈希进行比较的速度。

关键资源：网络响应时间和 Avamar 数据节点随机寻找性能。

物理 Avamar 随数据节点的数量和大小而扩展的随机寻道性能。AVE 系统的性能较差，与单节点系统相当。

第 4 阶段。通过网络将新区块发送到 Avamar Server 或 Data Domain

当客户端向服务器发送新的唯一区块（最大 64 KB）时，性能主要取决于网络带宽。这主要影响基于 WAN 的客户端，这些客户端每天都会生成大量更改的数据。它还会影响那些通过拥塞网络链路运行的用户。

下图示了客户端将数据发送到 Avamar 系统和 Avamar - Data Domain 集成系统时的数据流。






关键资源：客户端和服务器

之间的网络带宽第 5 阶段。写入 Avamar Server 或 Data Domain

的数据备份数据必须写入 Avamar Server 或 Data Domain 系统。

关键资源：Avamar Server 磁盘写入性能和常规加载。