Avamar：NDMP 备份失败，并显示致命信号 11 卷内存使用分段错误

备份失败指示

当 Avamar NDMP 备份遇到分段故障（信号 11）时，会观察到以下症状：

• 备份作业中止，并显示类似以下内容的致命错误消息：

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

• 日志条目显示正在处理的异常大的数据集，例如：

avtar Info <8688>: Status 2017-10-13 19:32:37, 3,050,352 files, 2,419,299 directories, 5,119 GB (3,050,352 files, 1.913 GB, 41.42% new) 15049MB 60% CPU (1 open files)

• 据报告内存消耗高，单个备份流通常超过 15 GB 的 RAM/交换。
• 大量 NDMP 流处于活动状态（每个客户端最多 8 个），每个流可能使用 2 GB 或更多内存。
• 多个大型备份可能会并发运行，从而增加整体系统负载。
• 受影响的卷包含数百万个文件和目录（例如，240 万个目录中的 300 万个文件，涵盖 5.1 TB 数据）。
• 即使只更改了少量数据（例如 1.9 GB），备份过程也会尝试从 NAS 发送每个文件进行处理。

触发致命信号的潜在因素 11.

当进程访问未分配给它的内存时，会生成信号 11（分段错误）。在 Avamar NDMP 备份期间，以下情况直接导致此事件发生：

• 多个大型 NDMP 备份并发运行。
• 一个备份处理了 3,050,352 个文件和 2,419,299 个目录， 总计 5.1 TB 的数据，但其中只有 1.9 GB 的数据发生了更改。
• 每个 NDMP 流可以消耗≥ 2 GB 内存。客户端最多允许 8 个流， 并且多个客户端同时处于活动状态，从而导致高聚合内存需求。
• 在崩溃之前，备份过程使用了大约 15 GB 的 RAM/交换空间。
• Avamar 限制每个客户端的流数量，但不对流总数强制实施全局限制。这使合并的内存使用量超过可用资源。

这些内存密集型情况导致 avtar 进程遇到分段错误，在日志中记录为：

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

修复由信号 11（分段错误）导致的 Avamar NDMP 备份失败

步骤 1 — 评估当前备份负载。

使用 Avamar Administrator 控制台或 CLI 识别生成大型 NDMP 备份的卷。

列出活动 NDMP 作业及其资源使用情况：

$ avtar -listjobs -type ndmp

 步骤 2 - 减少同步卷备份。

• 限制同时备份的卷数量，以避免过度消耗 RAM/交换。
• 在 Avamar Administrator 中，编辑备份计划并取消选择重叠窗口。

步骤 3 — 将大型卷拆分为较小的子卷

• 确定具有超过 300 万个文件或超过 5 TB 数据的卷（如示例中所示）。
• 在目录树中低一级创建逻辑子卷。
• 在 Avamar 中将每个子卷配置为单独的 NDMP 客户端。
  •  示例：为子目录创建新 NDMP 客户端

$ avtar -addclient -name subvol1 -path /data/level2/subvol1

 步骤 4 - 调整 NDMP 流设置。

• 如果 NAS 支持，请增加每个客户端的最大 NDMP 流数量。
• 在 NAS NDMP 配置中，尽可能将流限制从默认的 4 提高到 8。

步骤 5 — 限制每个流的文件数

• 创建备份策略时，请设置较低的“每个流的文件数”阈值，以将每个流的内存占用空间保持在 2 GB 以下。
• 使用 Avamar Administrator→策略→高级设置 调整此值。

步骤 6 — 在备份期间监视内存使用情况

• 在备份运行时监视 Avamar Server 上的 RAM 和交换消耗情况。
• 确保使用量远低于可用内存总量（例如，15 GB 的作业小于 12 GB）。
  • 实时内存监控

$ top -b -n 1 | grep avtar

 步骤 7 — 验证修复

• 再次运行以前失败的备份。
• 确认日志不再包含 Fatal signal 11 消息的典型原因。
• 验证备份是否成功完成，以及报告的数据大小是否符合预期。
  •  检查最新的备份日志中是否有错误

$ tail -n 50 /var/log/avtar/backup.log