Avamar：作系统 （OS） 容量（解决方案路径）

Summary: 此解决方案路径文章用于处理 Avamar 上的作系统 （OS） 容量问题或对其进行故障处理。

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

如何处理 Avamar 上的作系统容量问题或对其进行故障处理。

此解决方案路径文章旨在解决 Avamar 上的作系统容量问题或对其进行故障处理。


有关初始概念并了解作系统容量，请参阅培训文章 Avamar：容量管理概念和培训

如培训文章中所述，应合理了解以下主题，才能继续阅读本文的其余部分：

  • 基本了解检查点 （cp）、检查点验证 （hfscheck)和垃圾数据收集 （GC），以及每个
  • 两者的区别 GSAN （又称“用户容量”和作系统容量）
  • 检查点开销数据
  • 如果任何数据分区超过总物理作系统容量空间的 89%，则垃圾收集无法运行。
  • Avamar 网格越接近 100% 用户容量，可用于检查点开销的作系统容量就越少。
  • 影响检查点开销的因素，包括异步处理、存储的检查点数量、 HFSCheck 和检查点验证重要性等。
  • 如何查找作系统容量级别
  • 缓解作系统容量问题的基本措施

 

通常最简单的方法是将作系统容量视为 GSAN 数据（更具体地说，为此数据分配的空间）以及 Avamar 检查点产生的开销。检查点数量越多，更改率越高，检查点开销就越高。


高作系统容量的影响可能包括：

  • 垃圾数据收集失败：GC 失败并显示MSG_ERR_DISKFULL 如果作系统容量上升到 89% 以上
  • 备份或复制失败： 如果作系统容量上升到 90% 以上，备份或传入复制可能会失败并显示MSG_ERR_STRIPECREATE。（仅当必须创建新的数据条带时才这样做。如果不需要新的条带，备份和复制仍可能成功运行。）
  • 检查点故障：如果作系统容量上升到 96% 以上，则检查点将失败并显示MSG_ERR_DISKFULL


如上所述，当其他 Avamar 容量也很高时，作系统容量通常是第一种需要解决的 Avamar 容量类型。至少，当作系统容量达到特定级别时，即使 GSAN 或者用户容量也很高。

通常，当 GC 失败且 OS 容量超过 89% 时，MSG_ERR_DISKFULL 将 OS 容量视为较高。如果作系统容量完全低于 89%，则不会影响任何维护作业。 

 
提醒：预计作系统容量全天都在波动。验证日常维护作业是否顺利运行非常重要，通常是尽可能避免作系统容量问题的最佳解决方案。
 
提醒：虽然以上内容被视为 Avamar作系统容量，但可能存在与备份分区或检查点不直接相关的作系统容量问题。这些是安装了 Linux作系统的磁盘和分区。虽然这些问题不太常见，但它们可能会产生其他影响，下面将对此进行讨论。

Cause

由于以下原因的任意组合，Avamar作系统容量可能会增加：

  • 备份数据更改率高，添加“太多太快”
  • 高 GSAN 或“用户容量”，它为作系统容量留出的空间较小，有时甚至会导致更高的更改率
  • 检查点未能成功完成，这会导致输出中显示的“MSG_ERR_DISKFULL”状态。
  • 检查点验证 （hfscheck) 失败或最近未运行，因此最旧的检查点无法滚出或删除
  • 由于其他原因（包括检查点保留设置过高），检查点未滚存
 

其他磁盘分区上的高作系统容量可能由多种原因引起，包括数据放置不正确、日志文件变得过大等。

 
将短语“太多太快”作为高作系统容量的原因的快速解释可按如下方式解释：
  • 简单介绍一下背景信息，Avamar 检查点是只读快照和实时数据链接。由于这是使用链接创建的，因此检查点在创建后会立即使用零额外的磁盘空间。如果实时数据没有更改，则检查点不会使用额外的空间。
  • 当修改实时数据而检查点保持不变时，这种情况会发生变化。此时，检查点中有数据的原始副本和已修改数据的更新实时副本。这完全是故意的。这就是保留作系统容量空间的原因。
  • 但是，如果更改数据的数量或速率突然大幅增加，这可能会导致作系统容量大小出现罕见的峰值，并被视为“太多太快”
  • 而 capacity.sh 在比较几天的输出时，工具会将此显示为原因。

Resolution

如果维护作业（包括垃圾数据收集）因 Avamar OS 容量高而失败，请执行以下步骤：

1.收集所有 Avamar 容量信息以描绘情况：Avamar：如何收集对容量问题进行故障处理所需的信息。


2.接下来，查看作系统容量有多高以及可能需要执行哪些作。在数据收集文章中，可以使用以下命令找到此信息： 

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

Avamar 的工作原理是，显示的 fs-percent-full 的最高值是当前作系统容量的限制因素。根据节点类型代系和大小，存储备份和检查点数据的数据分区数量可能会有所不同。从 Linux作系统可以看出，这些可能是磁盘或分区，例如“/data0*”，其中“*”可以是一个数字。数据分区的数量取决于节点类型、硬件代系和大小（并且无法更改）。


3.查看找到的检查点数量以及最近通过命令验证这些检查点的时间：

cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980
 
提醒： 一些检查点必须完全保留。
 
 

4.通过运行以下命令，验证检查点作是否从“MSG_ERR_DISKFULL”失败：

dumpmaintlogs --types=cp --days=4 | grep "\<430"


如果检查点成功完成，则会看到类似于以下内容的输出：

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance


如果由于MSG_ERR_DISKFULL而失败，则会看到以下输出：

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
 
如果检查点作失败并出现MSG_ERR_DISKFULL错误，请向 Dell Technologies Avamar 支持团队 提出服务请求 ，否则从步骤 5 继续。
 
 
5.检查是否存在其他检查点问题：
 
而 cplist c奥曼德 显示找到的检查点数量以及检查点的验证时间。如数据收集一文中所示，请使用 《Avamar — 如何理解 cplist 命令生成的输出》以了解 cplist 输出。

应该有两个或三个检查点，并且过去 24 小时内的检查点中至少有一个显示为已验证 hfscheck。这将是所有成功运行的作业的正常行为和输出，以及正常的检查点保留设置。

如果存在三个以上的检查点，或者在过去 24 小时内没有经过验证的检查点，则必须先解决此问题，因为这可能是减少作系统容量的唯一方法。如果遇到这种情况，请向 Dell Technologies 提出服务请求 ，否则从步骤 6 继续。
 
 

6.确定更改率：

capacity.sh

 

示例输出：

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

 


有时，如果高变化率或“太多太快”的情况再次出现，可以通过降低整体变化率来缓解这种情况 GSAN 或用户容量。使用较低的 GSAN 容量，则作系统容量开销的空间更大一些，同时还会导致数据存储容器更改更少。要获得此情况的帮助，请向 Dell Technologies Avamar 支持团队 提出服务请求 ，否则从步骤 7 继续。

 

7.其他磁盘分区上的高作系统容量问题有多种原因，但这些解决方案需要技术支持。向 Dell Technologies Avamar 支持团队创建服务请求，否则从步骤 7 继续。

 
 

解决作系统容量问题后， GSAN 可以查看容量或其他 Avamar 容量。请参阅 Avamar 容量故障处理、问题和疑问 — 所有容量（解决方案路径）

 

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000169014
Article Type: Solution
Last Modified: 12 Mar 2025
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.