Avamar GSAN 或用户容量解决路径

有关初始概念和对操作系统 (OS) 容量的了解，请参阅 Avamar：容量常规培训 — 解决方案路径

通常，最简单的理解方式是将 GSAN 容量视为客户端备份的空间和利用率。

• 了解重复数据消除的基本知识
• 了解检查点、检查点验证 (hfscheck) 以及垃圾回收的基本知识及其重要性。
• （或用户）容量和操作系统容量 GSAN 两者之间的差异
• 更改速率
• 稳定状态

• 网格访问状态更改为“管理员模式”时，备份或复制失败

  • 客户端备份作业可能会失败，并显示类似于以下内容的消息：  ”avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• 自动禁用备份计划程序（直至有人确认和清除）

• 80% - 容量警告
• 95% - 已达到运行状况检查限制（这有时会禁用备份计划程序，至少直到手动确认为止）
• 服务器只读限制达到 100%（网格进入管理员模式）

1. 借助重复数据消除技术，Avamar 只需要保存和存储每个客户端备份作业之间的细微更改和差异。新备份（或传入复制）运行时，可以添加新数据并增加 Avamar 容量或利用率值。 
2. 经过一段时间后，备份将根据所配置的保留期和过期设置自动过期；届时，Avamar 网格上将不再保留这些备份，因此它们无法再用于还原。 
3. 当名为垃圾回收 (GC) 的 Avamar 维护作业运行时，它会查找因这些备份过期而不再需要的所有唯一部分或数据块。GC 会确认没有其他当前备份共享同一数据（因为重复数据消除所致），然后删除或释放不再需要的数据块，以回收空间并降低 Avamar Server 的利用率。

当每日新传入的数据量与每日清理的数据量大致相同时，这种状态称为“稳态”。这正是每个已安装的 Avamar 网格的目标。

在设置和配置新的 Avamar 网格之前，将进行常规安装前规模调整计算，以确定存储备份数据所需的容量。这些计算基于客户保留要求和要备份的数据量。此外，它还会估算平均有多少数据能够进行重复数据消除，以及其他相关情况。

1. 垃圾回收未持续运行
2. 垃圾回收性能缓慢或运行时间不够长
3. Avamar 网格安装之前的重复数据消除估计值不够准确
4. Avamar Grid 安装之前计算之外的数据将备份到此 Avamar Server。
5. 其他原因

验证以下每个故障处理步骤是否适用于环境：

步骤 1.数据收集：

确保 Avamar 网格不存在任何其他非容量问题。如果存在，应在对容量进行故障处理之前予以解决。

这包括硬件错误、数据完整性问题（包括离线节点）、离线条带、检查点验证故障或失败的维护作业。如果上述任何一项存在问题，则必须停止容量故障处理并解决其他问题。一旦其他问题得到解决，可以重新评估容量。

请运行运行状况检查（Avamar: 如何在 Avamar Server 上运行 proactive_check.pl 运行状况检查脚本），但至少 status.dpn 命令可以快速概述和验证大多数相同问题。请参阅 Avamar：如何理解“status.dpn”命令生成的输出（英文版）

有关其他信息，请参阅以下文章：Avamar：如何正确应用“Avamar 故障处理层次结构”方法。

如果在解决任何非容量问题时需要帮助，请向 Dell Technologies Avamar 支持团队提交服务请求。

步骤 2. 容量信息收集： 

有关解决 Avamar 容量问题所需的所有必要信息，请参阅以下内容：Avamar：如何收集故障处理容量问题的信息

至少 status.dpn 命令或 Avamar 管理 UI 中的值显示 GSAN 容量。

步骤 3. 检查操作系统容量是否已满：

以下命令可帮助显示每个磁盘分区的操作系统容量的当前值。如果任何值达到或超过 85%，如第二个示例输出所示，则认为操作系统容量高：

avmaint nodelist | egrep 'nodetag|fs-percent-full'

输出示例：

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

仅当操作系统容量低于 85%时，才应该采取措施。 GSAN 容量故障处理继续。 

步骤 4. 有时可能会被误解为容量的非容量问题：

可能客户端备份失败不是因为“容量”问题，而是因为“配额”问题。它们有时可能会被误解为“容量”问题。

可以通过 status.dpn 命令或其他显示容量较低的收集输出来确认此情况。

客户端备份也可能由于其他 Non-GSAN 容量原因而失败或未运行。通过回收的信息，我们可以确认这一点，也可以在 Avamar 管理界面中查看。

• Avamar：元数据容量解决方案路径
• Data Domain：Avamar 集成解决方案路径的高容量

如果 GSAN 容量很高，其他相关容量也较高，故障处理可以按照任意顺序进行（除操作系统容量以外，操作系统容量必须始终优先）。

步骤 5. 条带平衡和操作系统磁盘平衡：

Avamar 上的“条带”是备份数据存储在数据节点上的容器文件（单节点 Avamar 网格除外）。

理想情况是，条带在网格内的不同磁盘和节点之间保持“平衡”或均匀分布，但有时它们可能会变得不平衡。

按照 Avamar 的设计，最大的节点或磁盘分区是限制 Avamar 容量的因素。

这是有意为之，旨在确保任何磁盘或节点创建的条带数量都不会超出其可处理能力（或允许范围），因此保持条带平衡对于容量管理至关重要。

例如，在为 Avamar 网格扩展添加额外的数据节点时，必须运行平衡操作，以将条带均匀分配到新节点，从而降低整体 Avamar 容量百分比。

需要了解的另一种平衡类型是操作系统磁盘平衡。这仅限于同一节点上的数据分区，而不是多个节点上的分区。 

但如果在同一数据节点上，某个分区比另一个分区大得多或小得多，则可能会超出称为“freespaceunbalance”的限制。虽然，这通常是操作系统的问题，而并非 GSAN 容量的问题，但系统可能会将其报告为 GSAN 容量问题。

步骤 6. 检查是否完成了垃圾回收： 

运行以下命令以获取有关垃圾回收的信息：

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

理想情况下，输出将显示 GC 在过去 30 天内已完成：

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

GC 故障消息可以包括但不限于以下内容：

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

GC 出现故障，请首先使用以下文章作为参考来解决此问题：Avamar：故障处理垃圾回收 (GC) 故障（解决方案路径）
（如果任何问题已得到解决，请转至下一步。）

步骤 7. GC 运行时间是否足够长？

运行以下命令以检查 GC 允许的最大时间：

dumpmaintlogs --types=gc --days=30 | grep gcflags 

输出示例：

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

记下 maxtime 值，在本示例中为 14400（秒）。
（值为 0 表示无限制）

b. 运行以下命令以确定 GC 运行了多长时间以及完成了多少“遍”：
（遍数与所存储的备份数据的层级结构有关。请 GSAN 将 GSAN 容量想象成一个洋葱，由一层层的结构组成。在看到内部层之前，必须将外层剥离或移除。每一遍都是 GSAN 存储数据 GSAN 的一层。)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

输出示例：

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

请注意遍数和 elapsed-time （秒）。

c. 假设 maxtime 为非零，计算 2/3 的值 maxtime，并将其与已用时间进行比较。
（在上述示例中，14400 的 2/3 为 9600，并且所有已用时间输出都远低于此数值。）

各种问题可能会导致 GC 运行缓慢，或者无法扫描所有内容。这可能包括在过去较长一段时间或数日内未能获得足够的运行时间、错误的配置、错误以及其他问题。

如果有与 maxtime（即，遍数）相关的问题，请向 Dell Technologies Avamar 支持团队 提交服务请求，以进行进一步调查。

步骤 8.如果怀疑 GC 未删除足够的数据或预期的数据，请执行以下操作：

一旦确认 GC 运行时间足够长，就有可能是因为垃圾回收控制之外的原因而未收集数据。以下列出了通常应检查的已记录原因：

a. 验证备份是否已至少配置为最终过期或定期过期。如果没有频繁到期的备份，则 GC 将没有太多的工作要做。

b. 使用下文来查找“变更率最高”的客户端：Avamar：如何使用 capacity.sh 脚本管理容量。（查看“% OF TOTAL”以及“CHGRATE”。）

c. 参照 Avamar：，检查是否存在跳过的哈希Avamar 垃圾回收报告无法清理的“跳过的哈希”。如果这些情况偶尔发生，这是正常的，可以忽略不计。

d. 存在一个标志或选项，用于强制 Avamar Server 保留每个客户端的最新备份。此设置是处于安全考虑，旨在防止客户端的所有备份因意外而过期。在数据清理和垃圾回收方面，这可能会导致其他问题。Dell Technologies Avamar 支持团队可以确认此功能是否已启用。

e. 如果备份最近已从 GSAN 切换至 DD 后端，或者发生了意外的 GSAN 备份，但 GSAN 容量不会减少，请向 Dell Technologies Avamar 支持团队创建服务请求，以进一步调查。

步骤 9.Avamar 网格过小，不足以满足要添加的当前或预期数据量：

对于高容量问题，在排查完所有其他解决方案和可能的原因之后，如果确认该问题既非配置问题，也不是与意外数据相关的问题，则：

这意味着数据可能需要被删除，或者可以考虑将某些客户迁移到其他 Avamar 网格，添加新的数据节点等选项。

步骤 10.确认任何容量事件并在需要时恢复备份计划程序：

容量问题得到解决后，在 Avamar Admin UI 中确认所有与容量相关的事件。

b. 恢复备份计划程序：

dpnctl start sched

有关其他 Avamar 容量问题、培训、故障处理等，请参阅：Avamar：容量故障处理、问题和疑问 — 所有容量（解决方案路径）

• 此操作本身只会“掩盖”和隐藏真正的问题，导致这些问题在几天或几周后再次出现，从而让先前的人工工作成为无用功。
• 此外，手动 GC 可能无法高效运行，因为它是在计划外运行的。
  • 它有时会使其他问题变得更糟糕。有关详细信息，请参阅：Avamar：有关手动垃圾回收的使用

• 通常不会执行此更改或操作，默认情况下不应考虑。Avamar L2 工程师或主题专家 (SME) 必须批准此更改。
• 令人遗憾的是，此类操作可能会以多种方式对 Avamar 网格造成永久性损害，而这些损害只能通过添加额外的存储节点或重新部署来解决。

了解不会执行上述列出的任何操作，因为支持团队希望以最有利的方式帮助解决容量问题。