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 网格安装之前计算的数据以外的数据备份到此 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 Administration 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步。有时可能被误解为容量的非容量问题：

客户端备份可能不是因为“Capacity”原因而失败，而是因为“Quota”原因。这些有时可能被误认为是容量。

这种情况可以通过以下方式确认： status.dpn 命令或其他一些显示容量较低的收集输出。

此外，客户端备份也可能由于其他原因而失败或无法运行 Non-GSAN 容量原因。收集的信息应确认这一点，或者也可以在 Avamar Administration UI 中查看。

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

如果必须恢复 GSAN 容量高，其他这些容量也高，可以按任意顺序执行故障处理（作系统容量除外，它必须始终排在第一位）。

第 5 步。条带平衡和作系统磁盘平衡：

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

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

根据 Avamar 上的设计，在涉及 Avamar 容量时，最大的节点或磁盘分区是限制因素。

这是有意为之，因此任何磁盘或节点创建的条带数都不会超过其处理能力（或允许能力），因此均衡的条带对于Capacity很重要。

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

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

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

第 6 步 。 检查垃圾数据收集是否正在完成： 

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

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

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

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 存储的数据。）

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 运行时间足够长，则可能是由于垃圾收集控制之外的原因而未收集数据。以下是通常应检查的记录原因列表：

一个。验证备份是否配置为至少最终或定期过期。如果没有频繁到期的备份，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 管理 UI 中确认所有与容量相关的事件。

b.恢复备份计划程序：

dpnctl start sched

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

• 此作本身可能会“掩盖”和隐藏真正的问题，只会使它们在几天或几周后再次出现，从而导致此手动作业浪费时间。
• 此外，手动 GC 的运行效率可能不高，因为它超出了计划。
  • 有时，它会使其他问题变得更糟。有关详细信息，请参阅：Avamar：关于手动垃圾回收的使用

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

请注意，由于支持团队希望以最有利的方式帮助解决容量问题，因此不会执行上述作。