Avamar：复制对显示不同的容量用量水平。如何调查原因。

“服务器利用率”值之间存在差异的缘故和可能的原因：

网格之间的逻辑或物理差异：

• 源网格和目标网格上的数据节点数量不同。
• 每个网格的数据节点具有不同的磁盘配置。
• 条带在每个系统内的数据节点之间均衡分布（不超过 2%）
• Avamar 版本之间的存储和奇偶校验要求不同。如果源软件和目标软件版本不同，则可能会观察到使用量差异。
• 两个网格的 Avamar Server 磁盘只读级别可能不同。   
• 一个网格可能配置为 RAIN 奇偶校验，另一个网格则没有。

复制配置：

• 复制到目标系统的备份可能具有与源系统不同的保留策略。有关详细信息，请查看 expiredelta 标记。或者，复制的备份可能仅涵盖特定时间跨度。例如，过去 4 周的源系统备份。
• 复制可以配置为仅将一部分客户端从源系统复制到目标系统。检查是否使用了包括或排除设置。
• 客户端及其关联的备份可能已从源系统中删除。删除源系统上的客户端或备份不会从目标系统中删除相同的备份。备份将保留在目标系统上，直至其根据保留设置到期。
• 可以为源系统上的备份或客户端更改保留策略。保留策略的更改仅影响新备份。新备份复制到目标系统并遵守更新的保留策略。目标上已存在的备份将继续遵守复制时对其应用的保留策略。

之前的容量管理活动：

• 客户注意到 Avamar 复制对系统中的一个接近容量上限，然后采取措施减少容量，这种情况并不少见。切记，Avamar 复制对由两个独立托管的系统组成。如果在一个系统上执行操作，则必须在另一个系统上也执行相同的操作。 
• 如果在源系统上删除备份或减少保留，则必须在目标系统上进行相同的更改。以这种方式管理容量的最佳方法是使用 modify-snapups 脚本。可以使用相同的备份修改或删除选项在两个 Avamar Server 上运行该脚本。  

不同的条带结构（例如，一个系统上有多个奇偶校验条带）：

• 由于两个 Avamar 系统相互独立，它们最终可能会具有不同的条带结构。多节点系统使用奇偶校验条带来保护数据，因此可能会出现差异。根据其容量历史记录，两个多节点系统包含相同的备份，但一个系统的奇偶校验条带数可能比另一个多。
• 与常规条带一样，奇偶校验条带创建后，将始终保留在系统中。与常规条带不同的是，它始终占用 Avamar Server 中的固定空间量。即使其奇偶校验组安全条带不包含任何数据也是如此。垃圾数据收集对此行为没有影响。
• 当复制源系统上出现严重的容量问题时，复制目标系统会受到间接保护。但是，如果其中一台机器在容量方面管理不善，则任何一台机器都可能出现这种情况。
• 相关文章：即使在删除所有备份并进行垃圾数据收集后，Avamar 仍会显示高达约 30% 的利用率

备份仍在 MC_DELETED 中：

• 需要注意的一种罕见情况是，在源系统上删除客户端后，其备份仍然保留。这可能会导致源系统的利用率高于目标系统，因为在目标系统中，备份会自然过期。您可以使用带有 backupcompare 选项的 dump_root_hashes.rb 脚本来检查此情况。

目标系统上来自非复制备份的数据：

• 如果系统*只进行单向*复制，请在目标系统上检查 /REPLICATE 和 MC_SYSTEM 以外是否不存在任何客户端。

其他行为：

• 复制作业可能无法可靠地完成。发送到目标系统的数据可能会“滞后”源系统数天。
• 两个系统都包含相同数量的已消除重复数据的数据，但每个系统的奇偶校验开销不同。在以下情况下会出现此问题： 
  • Avamar 源系统几乎已满。 
  • 从源系统中删除了许多备份以降低其容量水平。 
  • 然后，将已消除重复数据的数据从源系统复制到目标系统。 
  • 两个系统上的重复数据消除数据量相同。
  • 源系统最初存储的奇偶校验开销多于目标系统。
• 复制不会将物理条带从源网格复制到目标网格。相反，允许目标网格自行确定条带和数据块的存储位置。
• 有时，目标 Avamar 系统存储数据的效率要高于最初备份数据的源网格。

了解复制环境：

• 记下源 Avamar 系统的完整主机名。
• 检查受影响系统的复制配置，以了解哪些系统复制哪些数据以及复制到何处。 
  • 如果环境比从一个 Avamar Server 复制到另一个更复杂，绘制示意图可能会有所帮助。
• 如果源系统集成了 Data Domain (DD)，请了解客户的问题是否与在 DD 设备之间复制的备份有关。
• 记下目标 Avamar 系统的完整主机名以及接收复制备份的任何关联 DD 设备。

检查网格的整体运行状况和情况：

• 在两个网格上运行主动检查脚本以获取 hc_results.txt，查看该文件以了解系统的整体情况。 

容量差异有多严重？

• 客户应提供相关的屏幕截图，展示源系统和目标系统之间存在容量使用差异的情况。
• 如果容量差异小于 5%，我们认为无需担忧。
• 请查看 Avamar Administrator UI，以了解 Avamar Server 容量和元数据容量（如果集成了 Data Domain）的水平。
• 请注意 UI 容量显示的工作原理（详见 v7.2 及更高版本的 Avamar GUI 控制面板中显示元数据利用率而不是 Avamar 利用率）。
• 在两个系统上运行以下命令。服务器利用率值提供了 Avamar Server（但不包括 Data Domain）容量水平的整体值：

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

检查两个网格上的硬件是否相同：

• 比较“相似”系统的容量差异才有意义。 
• 使用主动检查输出，记下系统中存在的节点类型。
• 以下命令显示物理节点的总数、总大小和已用空间：

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• 通过此输出，可以轻松确定系统中节点的数量和大小。即 (23.3 / 3 = ~7.8 TB).。 
• 每个节点上硬盘分区的数量和大小必须证实这一点。

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• 利用此信息确认以下各项：

检查软件版本和配置：

• 使用 status.dpn 命令的输出比较每个系统上运行的 Avamar 版本。
• 对于多节点系统，请确认两个系统都配置了 RAIN 奇偶校验Avamar — 如何确定服务器是 RAIN 还是非 RAIN
• 检查并比较两个系统上与容量相关的 Avamar Server 配置参数。例如：

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

检查条带平衡：

• 检查 status.dpn 输出，并记下每个数据节点上的条带总数。条带数可在括号中找到（例如 onl:xxx）。 
• 每个数据节点上的条带总数差异应小于 2%。  

检查垃圾数据收集是否在两个系统上正常运行：

• 如果垃圾数据收集未一致且有效地运行，则不会删除过期数据。系统报告的容量用量会高于预期。 
  • 有关信息，请参阅受限说明中的“GC 解决方案路径”一文。  

确保复制成功完成：

• 确保从源系统到目标系统的所有复制任务均成功完成。如果还没有成功完成，则可能是仍有数据需要从源系统复制到目标系统。  

检查复制配置：

• 检查复制配置（在 UI、CLI 或日志中）是否存在以下任何标记：  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

检查两个系统的接收率和数据删除率：

• 在两个系统上运行 proactive_check.pl --capacity，并比较源系统和目标系统的接收率。
• 如果目标纯粹是目标系统，并且从源系统接收所有备份，则其接收率应与源系统的接收率非常接近。
• Avamar NEW 或 DDR NEW 列显示要添加到这些系统的新数据量。
• 此外，请密切注意“removed”“mins”和“pass”列，以了解两个系统上的垃圾数据收集行为。
• 此信息可让您清楚地了解两个系统上发生的情况。
• 如需详细了解如何解读输出，请参阅 Avamar：如何使用 capacity.sh 脚本管理容量  

转储每个系统上存在的备份列表：

• Dump_root_hashes.rb 脚本是一个实用程序，可帮助比较 Avamar 源系统和目标系统上存储的备份之间的差异。即使备份托管在 Data Domain 存储上也是如此。   
• 请参阅 Avamar：Avamar：如何使用 dump_root_hashes.rb 脚本生成客户端和备份列表，了解有关下载实用程序和应用场景（包括比较两个 Avamar 系统的内容）的信息。
  • 运行该工具。检查所有客户端上的备份数量是否存在不一致。注意 +/-2 的差异）。  
• 如原因部分所述，非对称容量管理会导致两个系统之间存在差异。查看输出以确定是否是这种情况。
• 此外：
  • 检查目标系统中是否存在来自非复制备份的数据。
  • 检查源系统中是否存在未复制到目标系统的数据。  

检查不同的条带结构（例如，一个系统上有多个奇偶校验条带）：

• 由于两个 Avamar 系统相互独立，它们可能会具有不同的条带结构。多节点系统使用奇偶校验条带来保护数据，因此可能会出现差异。根据其容量历史记录，两个多节点系统包含相同的备份，但一个系统的奇偶校验条带数可能比另一个多。  
• 与常规条带一样，奇偶校验条带创建后将保留在系统中。与常规条带不同的是，它始终占用 Avamar 中的固定空间量，即使其奇偶校验组安全条带不包含任何数据也是如此。垃圾数据收集对此行为没有影响。
• 当复制源系统上出现严重的容量问题时，复制目标系统会受到间接保护。但是，如果其中一台机器在容量方面管理不善，则任何一台机器都可能出现这种情况。
• 相关文章：  即使在删除所有备份并进行垃圾数据收集后，Avamar 仍会显示高达约 30% 的利用率  

备份仍在 MC_DELETED 中：

• 需要注意的一种罕见情况是，在源系统上删除客户端后，其备份仍然保留。这会导致源系统的利用率高于目标系统，因为在目标系统中，备份会自然过期。您可以使用带有 backupcompare 选项的 dump_root_hashes.rb 脚本来检查此情况。