Avamar GSAN 或用户容量解决路径

Summary: 此解决方案路径文章用于在 Avamar 上处理和解决 GSAN 容量（也称为用户容量）问题。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

有关初始概念并了解作系统 （OS） 容量，请参阅 Avamar：容量一般培训 — 解决方案路径

通常最容易考虑 GSAN 作为客户端备份的空间和利用率的容量。

如本培训文章所述，要继续阅读本文的其余部分，应合理地了解以下主题：
  • 基本了解重复数据消除
  • 基本了解检查点、检查点验证（hfscheck）和垃圾回收，以及它们的重要性。
  • 两者的区别 GSAN （或用户）容量和作系统容量
  • 更改率
  • 稳态
 
高影响 GSAN 容量可以包括：
  • 当网格访问状态更改为“管理员模式”时备份或复制失败
    • 客户端备份作业可能会失败，并显示类似于以下内容的消息：  ”avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • 自动禁用备份计划程序（直至有人确认并清除）
 
当超过以下阈值时，Avamar 管理 UI 中会生成事件警告或错误：
  • 80% — 容量警告
  • 95% — 达到运行状况检查限制（这有时会禁用备份计划程序，至少在手动确认之前是这样）
  • 100% — 达到服务器只读限制（网格进入管理员模式）

Cause

简要总结：Avamar Server 和 GSAN 容量对备份数据进行“重复数据消除”，这意味着当某些字节或数据块相似时，只需要将该区块存储一次。任何数据都可以针对 Avamar 网格上备份的相同或不同客户端的任何其他数据进行“重复数据消除”。由于这些数据块较小，因此可以找到许多重复项并节省大量容量，而无需重复备份。
客户端备份数据的容量生命周期：
  1. 由于使用了重复数据消除，Avamar 只需要保存和存储每个客户端备份作业之间的细微更改和差异。当新备份（或传入复制）运行时，它可以添加新数据并提高 Avamar 容量或利用率值。 
  2. 经过一定时间后，备份将根据其配置的保留期和到期时间过期，并且在可用于还原的 Avamar 网格上找不到备份。 
  3. 当名为垃圾数据收集 （GC） 的 Avamar 维护作业运行时，它会查找由于这些过期备份而不再需要的所有唯一部分或数据块。GC 验证没有其他当前备份共享相同的数据（由于重复数据消除）， 然后删除或释放不再需要的那些数据块，以减少 Avamar Server 容量或利用率。
 

当每天添加的传入数据量与每天清理的数据量大致相同时，这称为“稳定状态”。这是安装的每个 Avamar 网格的目标。

在设置和配置新的 Avamar 网格之前，将进行常规安装前大小计算，以确定存储备份数据所需的容量。这些计算基于客户的保留要求和要备份的数据量。它还估计平均有多少数据可以进行重复数据消除等。

但是，有时容量无法达到稳定状态。这可能是由以下原因引起的：
  1. 垃圾数据收集未始终如一地运行
  2. 垃圾数据收集性能缓慢或运行时间不够长
  3. 安装 Avamar 网格之前的重复数据消除预估不够准确
  4. 将 Avamar 网格安装之前计算的数据以外的数据备份到此 Avamar Server。
  5. 其他原因

Resolution

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

提醒：这些步骤按最合适的顺序排序，以隔离问题并确定正确的解决方案。
请勿跳过任何步骤。
 
 

步骤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 能力。

提醒：显示的容量 status.dpn 命令和 UI 因预期设计而异。
 
 

第 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"
 
注意：虽然高作系统容量可能不是最大的问题，但这会妨碍进行故障处理 GSAN 如果容量超过 89%，则垃圾数据收集无法运行。下面对此进行了更详细的讨论，并在以下文章中提供了故障处理步骤：Avamar：作系统 （OS） 容量（解决方案路径）
 

仅当作系统容量低于 85% 时，才应 GSAN 容量故障处理继续。 

 

第 4步。有时可能被误解为容量的非容量问题：

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

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

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

如果必须恢复 GSAN 容量不高，请参阅以下文章：
 

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

提醒：有可能是 GSAN “Capacity”、“Metadata Capacity”和“DD Capacity”可能很高。在这些情况下，可以按任意顺序进行寻址，这与必须始终首先寻址作系统容量的情况不同。
 
 
 

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

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

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

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

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

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

提醒：虽然需要完美的条带平衡并且经常看到，但可能会出现问题并且“不完全”，但可以看到接近平衡。Avamar 工程团队已确认，条带余额之间 4% 的差异和容差在预期限制范围内。
 
 

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

如果在同一数据节点上，一个分区比同一节点的另一个分区大得多或小得多，则超出限制称为”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结果中的“MSG_ERR_TIMEOUT”混淆。该错误完全是另一回事，可以在 GC 错误解决路径一文中解决。在这里，超时意味着在 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，所有经过的时间输出都远低于此数字。）

  • 如果必须恢复 elapsed-time 小于 2/3 maxtime，很可能是 GC 提前完成，因为没有什么可收集的了，被赶上了。

  • 如果传递次数很高（14 次或更多），则很可能是 GC 删除了足够数量的数据。
    提醒：了解如果没有数据过期且没有需要清理的内容，则凭证的价值预计会很低，因此最好也了解整个情况和环境。不要以为很少通过就意味着存在问题。
 

各种问题可能会导致 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：容量故障处理、问题和疑问 — 所有容量（解决方案路径）

Additional Information

不建议手动或“主动”垃圾收集。
（这是对在计划的自动时间之外运行 GC 的引用。）
  • 此作本身可能会“掩盖”和隐藏真正的问题，只会使它们在几天或几周后再次出现，从而导致此手动作业浪费时间。
  • 此外，手动 GC 的运行效率可能不高，因为它超出了计划。
 
上述解决方案步骤未提及或建议更改特定于 GSAN 容量完全。
  • 通常不会执行此更改或作，默认情况下不应考虑此更改或作。此更改必须由 Avamar L2 工程师或主题专家 （SME） 批准。
  • 遗憾的是，此类作通常会以各种方式对 Avamar 网格造成永久性损坏，而这些损坏只能通过添加额外的存储节点或重新部署来解决。
 

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

Affected Products

Avamar

Products

Avamar, Avamar Server
Article Properties
Article Number: 000164132
Article Type: Solution
Last Modified: 07 Nov 2025
Version:  10
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.