Avamar v7 及更高版本 — 当数据正在使用时，由于“哈希引用位映射”而无法清理的垃圾数据收集报告“skipped-hashes”

哈希引用位映射功能是 Avamar v7.x 功能引入的一项功能，可在垃圾数据收集 （GC） 维护活动期间进行备份。

在此功能之前，由于存在数据冲突的可能性，垃圾数据收集无法同时运行。

在垃圾数据收集阶段，新功能在内存中维护有关添加或更改的数据的信息（“引用的哈希图”）。垃圾数据收集会检查此信息，以了解不应删除哪些哈希（以及它们引用的数据）。  

此功能的要求是，这些“映射”需要至少 5 分钟的“安静”时间，在此期间不会进行任何备份，以便可以重置备份。进行此重置后，可在后续垃圾数据收集周期中扫描锁定在其中的数据，只要它们继续保持不变。

在设计每日 Avamar 备份和维护计划时，应考虑此安静时间。
无法重置映射可能会阻止垃圾数据收集清理过期的数据。
如果哈希引用的映射未获得重置机会，则不应处理应符合垃圾数据删除条件的数据，并且容量使用率可能会增加。如果映射无法在较长时间内重置，垃圾数据收集日志可能会显示越来越多的“跳过哈希”。

备份已过期，但垃圾数据收集未恢复所有符合删除条件的数据，因为一些数据当时正在使用中。

要检查此项，请运行以下命令：
命令转储垃圾数据收集维护日志 7 天，并将其解析为显示。

• 跳过了多少个哈希，
• 删除的数据量
• 发生了多少次垃圾数据收集
• 垃圾数据收集的运行时间

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

分析：

输出显示在 2014 年 2 月 16 日重置哈希引用映射之前跳过的哈希数量随时间推移而增加。
我们还可以看到，在哈希释放后清理的“MB-recovered”数据量正在跳动，垃圾数据收集可以处理过期数据。

即时解决方案

1.确保映射可以重置并允许重新运行垃圾数据收集。
2.确保没有正在运行的 avtar 会话将数据添加到系统（备份或传入复制数据）。使用 GUI 活动监视器并检查仅使用“avmaint sessions --full”命令看到的挂起会话。
3.停止所有备份和传入复制会话。
4.等待至少五分钟，以允许哈希引用的位映射有足够的时间重置。  
5.当 GC 再次运行时，检查 GC 维护日志以确认 跳过的哈希=0

如果跳过的哈希未重置为零，请与支持人员一起仔细检查上述步骤。如果垃圾数据收集报告 MSG_ERR_TRYAGAINLATER，支持人员可以确认这是否是由于索引条带拆分活动造成的。 
 

长期解决方案

设计备份和维护计划，以便定期“空闲”可用于重置哈希引用的位映射。

换言之，备份计划不应全天候运行。构建一个计划，在不向系统写入任何备份或传入复制数据时提供较短的时间。 

提醒： 

• 哈希引用的位映射检查是否可以重置的唯一时间是在 avtar 会话终止之后。如果没有正在进行 avtar 会话，映射只会在以下情况下重置：

• 跳过的哈希计数可能暂时高的一个原因是索引条带拆分。发生这种情况是因为移至拆分目标的哈希受到保护。索引条带拆分发生在仍在增长或正在填充数据的系统上。 
• 当索引条带拆分时，垃圾数据收集也可能会失败 ，并MSG_ERR_TRYAGAINLATER ：  
• MCS 可能不一定知道 Avamar Server 上发生的所有 avtar 会话。