第 11 章 · 巡检与代理健康
适用对象：运维工程师、值班人员 · 阅读约 14 分钟 · 对应产品界面版本 v1.2.0
备份系统坏掉的方式，大多不是"某天突然报错"，而是"某台主机的代理离线了两周没人发现"。这一章讲的就是怎么用固定节奏把这类静默故障捞出来：日检、周检、月检各看什么，代理健康怎么判定，以及资源紧张时哪些东西可以清、哪些绝对不能碰。
读完这一章你会做：
- 分清 Agent、数据获取器（Backup Proxy）和数据存储库三个对象，知道"代理离线"说的是哪一个
- 按日检、周检、月检三张表执行巡检，并用判定标准而不是感觉来判断正常与否
- 记录一次代理离线事件，并判断它是否影响了还原点覆盖
- 区分"从配置删除""从磁盘中删除""卸载代理"三个操作的后果
- 在容量紧张时清理可再生内容，同时避开所有禁止手工删除的目录
本章依据的源文档 DRC-013 大量使用「本系统技术说明…」「本系统技术要求…」句式给出具体行为和取值。经比对已确认：源文档中的「本系统」是多份第三方产品资料做品牌替换后的残留，并不指 SupDRC——同一批文档里「本系统」同时指向四份版本号互不相同的外部手册，另有小节把「本系统」与独立的「SupDRC 状态」并列成两列。
因此本章凡涉及删除是否需要二次密码、WORM 或保留锁定机制、完备点合并能力、重删库清理周期、缓存与日志的具体路径、服务名与内核模块名的内容，一律按"来源指代不明、SupDRC 行为待实测"对待：可以拿它当变更审批时的风险清单，不能拿它当 SupDRC 的产品承诺。每处都附有对应的 TODO。
先分清三个对象
巡检最容易出错的地方，是把不同角色的状态混为一体。下面三个对象的"离线"含义完全不同：
| 对象 | 英文 / 界面名 | 装在哪里 | 归谁管 | 它不可用会怎样 |
|---|---|---|---|---|
| 代理 | Agent / 备份代理 | 被保护主机上 | 主机责任人 + 备份管理员 | 该主机不再产生新的备份点，已有还原点不受影响 |
| 数据获取器 | Backup Proxy（数据获取器） | 基础设施侧的服务器 | 备份管理员 | 依赖它的一批作业全部受影响 |
| 数据存储库 | Repository（数据存储库） | 基础设施侧的存储 | 存储管理员 + 备份管理员 | 备份写不进去，恢复任务也读不出来 |
本章标题里的"代理健康"指的是装在被保护主机上的 Agent——它的在线状态、版本、卷快照驱动是否正常。而告警规则里的"数据获取器（Backup Proxy）不可用"说的是基础设施侧的服务组件，两者的排查路径、责任人和影响范围都不一样。看到"离线"先问一句：是哪一个离线了。
三个对象对应三个巡检入口：
| 入口 | 控制台位置 | 看什么 |
|---|---|---|
| 被保护资源 | 基础备份设施 → 被保护资源 | 主机地址、类型、状态、备份代理状态 |
| 主机保护组 | 基础备份设施 → 主机保护组 | 成员清单、代理安装与在线情况、扫描与备份时间 |
| 数据服务组件 | 基础备份设施 → 数据获取器 / 数据存储库 + 报表中心 → 存储报表 | 服务器、类型、可用状态、剩余容量与空间风险 |
代理状态是瞬时值。一台主机此刻显示在线，不保证它在今晚的备份窗口里仍然在线。判断保护是否有效，要把"代理状态"和"最近一次成功备份时间"放在一起看。任务异常还需结合日志定位，单一容量百分比不足以判断原因。
巡检节奏与判定口径
日检关注作业结果、代理在线状态、告警和容量；周检关注失败趋势、存储增长和日志；月检关注恢复演练、许可有效期和容量预测。
先给出与代理健康和资源清理直接相关的判定口径，执行时套用后面的对应表格填写：
| 检查维度 | 判定口径（什么算正常 / 什么算异常） | 异常处置方向 | 对应表格 |
|---|---|---|---|
| Agent 在线状态 | 正常：全部在线。异常：出现计划外离线；或同一主机一周离线 ≥ 2 次 | 先确认是否维护窗口；非计划离线按第 17 章排查网络、服务与凭证；重复离线升级为问题记录 | 日检第 3 项、周检第 4 项 |
| 保护组与代理版本 | 正常：成员齐全、代理版本与平台匹配。异常：成员缺失或版本落后 | 补齐成员；按第 16 章分批升级代理 | 日检第 2 项 |
| 作业结果 | 正常：计划作业全部触发且成功。异常：未运行、排队超时或连续失败 | 按第 10 章的失败分级处置；连续失败立即升级 | 日检第 4、5 项 |
| 存储容量 | 健康：剩余 > 20%；紧张：10%–20%；风险：< 10%（需扩容） | 紧张时启动清理评估；风险时立即扩容或调整保留策略（见第 8 章） | 日检第 8 项、月检第 3 项 |
| 日志与磁盘占用 | 正常：日志分区占用未接近总量上限（参数见第 10 章） | 接近上限时先归档再按策略清理；禁止手工删除当前日志文件 | 日检第 10 项 |
| 缓存与临时目录 | 正常：占用稳定、无异常增长。异常：缓存目录持续增长或存在残留临时文件 | 按本章「可以清理什么」与「禁止手动删除的目录」处置；清理前先停作业 | 周检第 5 项 |
| 清理后验证 | 正常：服务与 Agent 状态正常、权限未放宽、还原点无缺失、小范围备份成功 | 出现还原点缺失或服务异常时立即停止后续清理并保全证据 | 周检第 7 项 |
| 许可与合同 | 正常：剩余有效期 > 30 天（日检）或 ≥ 90 天（月检）。异常：临近到期 | 启动续期流程 | 日检第 11 项、月检第 6 项 |
日检表
日检为每工作日一次，建议在上午 9:30 前完成，覆盖前一夜的备份窗口。检查人在"实际值 / 证据编号"列填入观测值或截图编号；不符判定标准即开异常编号。
| 序号 | 检查项 | 判定标准（什么算正常） | 填写示例 |
|---|---|---|---|
| 1 | 管理平台可访问 | 登录页正常打开并成功登录，无证书阻断告警 | 正常，09:20 登录成功 |
| 2 | 数据获取器与存储库状态 | 全部在线，存储库容量正常可写 | Proxy-01 在线；存储库剩余 68% |
| 3 | Agent 在线状态 | 无计划外离线主机；离线主机已确认原因 | 在线 118/120；2 台离线为计划停机（工单 CHG-2026-0912） |
| 4 | 昨夜计划作业执行情况 | 全部按计划触发，成功；无"未运行"或"排队超时" | 计划 42 个，执行 42 个，成功 41，失败 1 |
| 5 | 失败与警告任务 | 失败任务已登记原因、责任人与处理时限 | 失败 1：主机 db-03 快照失败，原因内核模块未加载，责任人张三，09-18 前修复 |
| 6 | 最近可用还原点 | 每台核心主机存在 24 小时内的可用还原点 | 核心 25 台，最近还原点均在 24 小时内 |
| 7 | 备份窗口占用 | 未超出批准窗口，未与业务高峰重叠 | 最后作业结束 03:12，窗口内 |
| 8 | 存储剩余空间 | 剩余比例 > 20%（10%–20% 为紧张，< 10% 为风险） | 剩余 68%（健康） |
| 9 | 告警与通知 | 无未处理的严重告警；邮件/通知可送达 | 严重 0，警告 2（容量提醒），已处理 |
| 10 | 日志与磁盘占用 | 日志分区占用未接近总量上限 | 日志分区占用 12% |
| 11 | 许可证状态 | 有效期剩余 > 30 天，授权项无异常 | 永久授权，正常 |
| 12 | 异常编号与闭环 | 每个异常有唯一编号并指定责任人、时限 | 异常 EX-20260917-01 已登记 |
异常编号采用 EX-YYYYMMDD-NN（如 EX-20260917-01）。同一异常跨日未关闭时沿用原编号并在备注追加日期，不新开编号——否则一个长期问题会被拆成十几条看起来各不相干的记录。检查人当日签署，值班负责人复核。
周检表
周检为每周一次，建议周五下午执行，覆盖本周全部作业。周成功率建议以 98% 为合格线，连续两周低于该值即升级为整改项。
| 序号 | 检查项 | 判定标准 | 填写示例 |
|---|---|---|---|
| 1 | 周次与范围 | 明确本周统计区间与覆盖主机数 | 2026-W38（09-14~09-18），120 台 |
| 2 | 作业成功率趋势 | 周成功率 ≥ 98%，且无连续 3 天失败主机 | 本周 295/300，成功率 98.3% |
| 3 | 重复故障识别 | 同类故障出现 ≥ 2 次时已建问题记录 | 快照失败出现 3 次，问题 PRB-2026-014 |
| 4 | 代理频繁离线 | 单主机一周离线 ≥ 2 次已排查 | win-app-07 离线 3 次，原因网络抖动，已加交换机端口监控 |
| 5 | 容量变化与增长趋势 | 记录本周净增长，推算可支撑天数 | 本周净增 1.2 TB，可支撑 142 天 |
| 6 | 保留策略复核 | 实际保留点数与策略一致，无异常清理 | 策略保留 30 个，实际 30 个 |
| 7 | 抽测还原点（含抽样恢复） | 抽取 ≥ 2 台主机做文件级恢复验证，结果成功 | 抽测 db-01、app-05，各恢复 1 个目录，校验一致 |
| 8 | 日志归档与通知投递 | 归档文件已校验；通知无投递失败 | 归档 7 份，校验通过；通知失败 0 |
| 9 | 配置变更记录 | 本周变更均有工单与审批 | 变更 2 项，工单 CHG-2026-0908/0911 |
| 10 | 遗留问题及责任人 | 上周遗留项状态更新（进行中/已关闭） | 遗留 1 项：许可续期询价，李四，09-25 前 |
前六项都只能证明系统在跑。抽样恢复是唯一能验证保护目标是否达成的检查，不要因为耗时就跳过或改成"看还原点存在即通过"。恢复方法见第 12 章。
月检表
月检为每月一次，建议在次月 5 个工作日内完成。月检结论需提交运维负责人与业务方确认；恢复演练结论与演练记录共用同一份证据。
| 序号 | 检查项 | 判定标准 | 填写示例 |
|---|---|---|---|
| 1 | 月份与统计区间 | 明确统计月份与数据来源 | 2026-09（09-01~09-30） |
| 2 | 业务覆盖与保护等级复核 | 覆盖率 100%；新增业务已纳入保护 | 覆盖 120/120；新增 2 台已纳入 |
| 3 | 月度作业与容量指标 | 月成功率 ≥ 98%；容量预测更新 | 月成功率 98.6%；可支撑 138 天 |
| 4 | 恢复演练执行情况 | 按计划完成演练，记录 RTO/RPO 与校验结果 | 文件级演练 1 次，RTO 22 分钟，校验通过 |
| 5 | 账号与权限复核 | 离职账号已停用；权限符合最小权限 | 停用 2 个离职账号；无越权 |
| 6 | 许可与合同期限 | 剩余有效期 ≥ 90 天或续期流程已启动 | 永久授权；维保 2027-03 到期，已询价 |
| 7 | 版本与补丁计划 | 已知缺陷的修复版本已评估；补丁计划已确认 | 计划 10 月升级至 v1.2.1，含缺陷 PRB-2026-014 修复 |
| 8 | 日志留存与合规 | 留存天数满足组织要求；归档可检索 | 留存 90 天，满足；抽查归档可检索 |
| 9 | 配置与元数据独立备份 | 配置/元数据备份存在且可恢复 | 配置备份 09-28 生成，已校验，独立存放 |
| 10 | 整改项与责任人 | 上月整改项有结论；新整改项有责任人与日期 | 上月 3 项已关闭 2，1 项延期至 10-15（王五） |
责任人须填具体岗位或姓名，不得填写"运维组""相关人员"；计划完成日须为具体日期（YYYY-MM-DD），不得填写"尽快""本周内"。延期须在原计划完成日前提交延期申请并记录新的完成日与原因。未指定责任人与日期的条目不得进入正式交付清单。
代理离线事件
代理离线是最高频的运维事件，需要可累计的记录以识别重复故障与网络问题。
处置顺序：
- 先确认是否在维护窗口内。计划内停机附工单号即可，不进异常流程。
- 检查主机是否运行、网络是否连通、凭证是否失效、代理服务状态是否正常。
- 关联最近一次扫描时间与最后一次备份时间，评估是否影响还原点覆盖。
- 恢复在线后检查这段时间遗漏的备份，必要时补跑。
- 登记离线持续时间及处理结果。
记录表：
| 序号 | 记录项 | 判定标准 / 填写示例 |
|---|---|---|
| 1 | 事件编号 | EX-20260917-02 |
| 2 | 主机名与所属保护组 | win-app-07 / PRD-APP |
| 3 | 离线发生时间 | 2026-09-17 02:14 |
| 4 | 恢复在线时间 | 2026-09-17 02:41（共 27 分钟） |
| 5 | 是否落在备份窗口内 | 落在窗口内须评估是否影响备份。示例：是，影响 02:00 增量作业 |
| 6 | 是否计划内 | 计划内停机须附工单号。示例：否（计划外） |
| 7 | 根因判断 | 网络 / 主机电源 / 服务异常 / 凭证过期 / 其他。示例：网络，接入交换机端口 CRC 增长 |
| 8 | 是否影响还原点 | 是否导致当日无成功备份。示例：否，02:41 后补跑成功 |
| 9 | 处置措施 | 更换跳线并监控端口；已提交网络工单 NET-2026-1180 |
| 10 | 同主机一周内发生次数 | ≥ 2 次须升级为问题记录。示例：3 次，已升级问题 PRB-2026-015 |
| 11 | 责任人与完成日期 | 李四 / 2026-09-22 |
三个删除操作的区别
控制台上有三个看起来相近、后果完全不同的按钮：「从配置删除」「从磁盘中删除」「卸载代理」。它们位于不同层级——从配置删除在备份作业层，从磁盘中删除在展开的主机数据层，卸载代理在被保护资源。
| 操作名称 | 作用对象 | 是否释放空间 | 是否可恢复 | 对备份链影响 |
|---|---|---|---|---|
| 从配置删除 | 作业定义、资源登记或保护组关系等控制台侧对象 | 通常不释放（数据仍在存储） | 可通过重建配置重新关联；个别作业类型会连带删除数据，须逐项确认 | 链结构一般保留，但不再新增备份点 |
| 从磁盘中删除 | 存储库中的还原点 / 备份数据本体（按时间点或整链） | 是（释放可能有延迟） | 否，永久删除不可恢复 | 直接影响链结构；删除完备点会破坏依赖关系 |
| 卸载代理 | 目标主机上的 Agent 程序、服务、驱动与残留 | 基本不释放（仅移除主机侧组件） | 可通过重新安装恢复纳管；主机侧缓存数据不保证可恢复 | 已产生的服务端备份链不受影响，但该主机不再产生新备份点 |
各自的防护措施：
- 从配置删除：删除前停止运行中作业；确认该作业是否属于会连带删除数据的特殊类型；删除后核对还原点数量。
- 从磁盘中删除：需二次密码确认与审批；禁止手工
rm存储目录；核对保留期与恢复需求；先确认无挂载或瞬时恢复引用；WORM 保护期内不可删。 - 卸载代理：先停作业并在平台侧解除关联；确认卸载顺序（先平台后主机）；卸载后检查服务单元、服务、注册表项、内核模块与配置残留。
参考资料对这个操作的警示是：删除前需输入用户密码，且备份数据删除为永久删除、不可恢复；删除以备份链为单位而不是以单个时间点为单位——备份链是指完备点以及依赖于此完备点的所有增量备份点、差异备份点、归档日志备份点组成的备份数据集合。
这段描述来自指代不明的「本系统」资料，SupDRC 是否同样要求二次密码、删除粒度是不是备份链，都还没有实测。 在实测之前按最坏情况处理：当成永久、整链、不可撤销的操作走审批。
备份任务在运行时不可直接修改或删除，必须先停止任务再执行删除。参考资料另有一条提示：瞬时恢复任务和数据库 CDP 备份任务被删除后，恢复数据和备份数据会被一并删除——如果这条对 SupDRC 也成立，那么"从配置删除"在不同作业类型下的后果并不一致。删除任何一类特殊作业前，先向产品侧确认该类型是否连带删数据。
参考资料还把主机管理区分为「删除」（仅移除登记）与「删除并卸载」（同时卸载客户端插件），并称两者所需条件相同——Windows 仅支持 administrator、Linux 仅支持 root，且网络与传输端口可达——后者会触发目标主机上的插件卸载。SupDRC 控制台上这两个入口是否同名、条件是否一致，同样待实测。
备份链的删除规则
| 序号 | 规则 | 原因 |
|---|---|---|
| 1 | 禁止在存储目录中以文件删除方式删掉链中某个增量点 | 元数据仍记录该点存在，后续备份与恢复会因找不到数据而失败 |
| 2 | 删除完备点必须走产品流程（先合并或整链删除） | 链路结构完整性由完备点维系，直接删除会产生"无完备点"的残链 |
| 3 | 存在运行中作业或挂载 / 瞬时恢复引用时不得删除 | 删除正在被读写的链路会造成作业失败甚至数据损坏 |
| 4 | 处于 WORM / 永久保留或未到期保护期的数据不得删除 | 参考资料称 WORM 备份点在到期前无法修改、删除，保留期限只能延长；SupDRC 是否具备该机制待确认 |
| 5 | 删除前必须核对引用该还原点的恢复需求与保留期限 | 永久删除不可恢复，事后无法补做 |
| 6 | 删除后空间释放可能延迟，不得因此反复重启或手工清目录 | "删除后存储空间未释放，或释放空间较慢"属正常现象 |
保留策略需要移除旧完备点时，系统先把紧随其后的增量点合并生成新的完备点，再删除原完备点及其之前的数据，从而在保留策略执行后仍得到一条结构完整的链。增量点不能脱离其依赖的完备点单独存在。
"删除时间点失败""备份链无完备点""恢复失败"被归为同一类备份数据故障，处置方向是检查备份存储空间是否足够、存储连接状态是否正常。一旦备份链缺失完备点，恢复能力会直接受损，单纯重试删除解决不了问题。
资源清理
清理的原则是只清理可再生内容、不触碰备份数据本体，并配套验收记录：清理对象、清理前后容量、关键任务回归、抽样恢复结果，四项缺一不可。
可以清理什么
| 目录类别 | 内容 | 清理档位 | 前置条件 |
|---|---|---|---|
| 挂载 / 恢复缓存 | 挂载浏览与缓存恢复产生的临时数据 | 可清理（可再生） | 必须先确认挂载点已全部解除、无恢复作业运行 |
系统临时目录 /tmp、/var/tmp（排除其中的挂载点目录） | 进程临时文件 | 可清理 | 停止相关服务后清理，避免删除仍被打开的文件句柄 |
| 瞬时恢复 / 接管临时目录 | 瞬时恢复期间产生的缓存数据 | 有条件清理 | 禁止在瞬时恢复任务运行期间清理；停止任务会删除瞬时恢复虚拟机并丢失缓存数据 |
| 升级包上传暂存目录 | 升级包上传与解压中间文件 | 有条件清理 | 无升级任务运行；保留最近一次可用升级包及其校验值 |
| ISO / WinPE / LiveCD 制作输出目录 | 引导介质制作产物 | 有条件清理 | 成品已归档至受控位置并记录校验值 |
| 日志目录 | 系统、任务与组件运行日志 | 按轮转策略清理，不手工 rm | 先归档需留存区间 |
| 崩溃 / 转储文件 | 进程崩溃现场文件，单个体积可能很大 | 确认已提交分析后可清理 | 保留至问题闭环；先打包归档 |
| 客户端插件 / 程序目录 | 程序与插件本体 | 禁止清理 | 仅能通过官方卸载 / 升级流程处理 |
| 备份存储目录 | 备份数据本体与元数据 | 禁止清理 | 只能经产品删除流程操作 |
数据库挂载方式备份会在 <挂载缓存目录> 下产生缓存（Windows 在系统临时目录的 mountpoint 子目录、Linux 在 /tmp 的 mountpoint 子目录）。这类目录在解除挂载后属于可再生内容，但仍需先确认挂载已解除。
清理操作纪律：
- 先停止或确认无相关作业运行，再执行清理；清理期间不得同时进行备份、恢复或升级。
- 优先使用产品自带的清理功能或清理命令；无官方入口时，仅清理上表中明确标记「可清理」的目录。
- 清理前记录目录大小与文件数量，便于对比清理效果。
- 禁止用
rm -rf递归清理未经确认的父目录，避免误删备份存储或程序目录。
禁止手动删除的目录
| 目录类别 | 禁止手工删除的原因 |
|---|---|
| 备份数据存储目录 | 直接破坏备份链，导致"备份链无完备点"与恢复失败，且不可恢复 |
| 重删库 / 元数据库目录 | 元数据与数据块映射失配，整库还原点不可读，只能由产品侧后台处理 |
| 程序与二进制目录 | 服务无法启动；应通过官方卸载 / 升级流程处理 |
| 配置目录与服务单元目录 | 丢失账号、存储、网络等关键配置，恢复成本高 |
| 产品内置数据库的数据文件与事务日志目录 | 控制台数据与作业记录损坏 |
| 正在被挂载的目录本身 | 影响正在进行的恢复与浏览，且可能残留孤儿挂载 |
这一条无论产品是哪一家都成立：不要在备份系统后台的备份数据存放目录下手动删除数据。绕过产品的文件级删除既不可恢复，也会破坏保留锁定一类的保护机制，还会让元数据与实际数据失配。该要求适用于所有备份数据存放位置，不限于数据库场景。
如确需手工清理，必须同时满足四个条件：已在维护窗口、已停止全部作业、已确认该内容可再生、已有书面审批与回退方案。清理前后各记录一次目录大小与文件数，出现异常立即停止并保全现场。任何涉及备份数据与元数据库的手工删除，均不得由现场人员自行实施。
容量回收机制
删除之后空间不立刻变多，是正常的。参考资料描述的回收链路有两条：保留策略到期后以备份链为单位删除数据；以及完备点合并——需要移除旧完备点时，先把紧随其后的增量点合并为新完备点，再删除原完备点及其之前的数据。SupDRC 是否具备完备点合并能力尚未确认，下表用于判断"空间为什么还没回来"，不作为产品机制的描述。
| 回收机制 | 触发条件 | 常见延迟 | 风险与注意 |
|---|---|---|---|
| 保留策略到期删除 | 还原点超出按个数或按天数的保留范围 | 在后续作业运行时被触发清理，非实时 | 按天数保留时，中间停止备份的天数也计入周期，可能提前删除可用数据 |
| 完备点合并 | 保留策略需要移除旧完备点但需维持链完整性 | 合并过程本身耗时，期间空间可能先增后减 | 合并期间 I/O 与临时空间占用上升，应避开业务高峰 |
| 重删库垃圾回收 | 按计划周期执行 | 回收后空间可能延迟数小时至次日才反映 | 同一介质服务器上的重删库清理不应存在重叠时间段；参考资料称可按星期间隔配置，SupDRC 的配置形式待确认 |
| 归档 / 副本数据清理 | 归档或副本链超过保留个数 / 天数 | 随归档 / 副本作业执行时触发 | 副本链保留策略独立于本地备份链，需分别核查 |
| 人工后台释放 | 删除后长时间未释放、或出现异常占用 | 存在处理时延 | 必须经产品侧介入，现场不得自行清理存储目录 |
不会自动回收的常见情形：处于 WORM 或永久保留标记的数据；保留期限未到的数据；仍被作业或恢复需求引用的数据；因作业失败产生的孤立临时数据。容量告警时应先判断属于哪一类，再决定是调整保留策略、排除故障还是申请扩容，禁止以删除未知备份链的方式释放空间。
日志保留与轮转
日志保留应按类别分别设定，而不是全局一个值。
| 日志类别 | 记录内容 | 建议保留方式 | 说明 |
|---|---|---|---|
| 历史任务 | 每次作业的执行记录与结果 | 按个数或按天数；建议不少于一个完整保留周期 + 1 | 排障时用于判断"计划未触发"与"执行失败" |
| 任务操作日志 | 对作业的新建、修改、启停、删除记录 | 按天数保留，不低于审计留存要求 | 变更追溯与责任界定依据 |
| 系统操作日志 / 审计日志 | 登录、配置变更、用户与权限调整 | 按天数保留，通常要求 90 天以上或按等保要求 | 异常登录需与账号变更、维护窗口关联排查 |
| 任务告警 / 系统告警 | 作业失败、容量与组件异常告警 | 按个数或按天数 | 告警删除为永久删除、不可恢复，关闭前确认已有外部归档 |
| 组件运行日志 | 服务、节点、代理运行与传输日志 | 按大小轮转 + 按天数上限 | 具体取值见第 10 章 |
自动清理应开启，但保留期不得短于审计与故障追溯所需的最短周期。日志清理属于批量不可逆操作，删除前应确认已归档。 调整保留策略后需在下一次检测周期内复核实际生效情况。
源文档在数据库备份风险中提示"若不进行日志限制，则会导致日志撑满磁盘空间"，并指出该结论同样适用于产品自身的运行日志：必须设置上限与写满动作，否则日志会成为存储耗尽的原因。实施时把日志目录放在独立分区或设置总量上限，避免日志写满系统盘影响控制台与数据库。
Agent 卸载与残留清理
主机退役或需要重新纳管时，要把代理干净地卸掉。顺序错了会留下孤儿服务和驱动。
通用步骤：
- 停止该主机上的备份、恢复与实时复制作业，确认无任务运行；在平台侧解除该主机的作业关联。
- 按需在平台侧执行「删除并卸载」，或先「删除」再在主机上手工卸载。顺序不可颠倒。
- Linux 执行官方卸载脚本；Windows 通过「控制面板 → 程序 → 程序和功能」搜索插件名称后右键卸载，或执行官方 MSI 卸载命令。
- 卸载后检查并清理残留（见下表）。卸载内核模块前先确认没有其他依赖该模块的作业；涉及实时 / 快照驱动时按官方要求重启主机。
- 重启后确认服务、驱动与目录均已消失，并在平台侧确认主机状态不再上线。
- 记录卸载时间、执行人、残留清理清单与验证结果。如主机将被重新纳管，先清洗残留再重新安装，避免版本与驱动冲突。
| 平台 | 残留物类别 | 检查方法 | 清理要点 |
|---|---|---|---|
| Linux | systemd 服务单元 | systemctl list-units | grep <代理服务名> | 先 systemctl disable --now <代理服务名>，再删除单元文件并 systemctl daemon-reload |
| Linux | 程序目录 | <Agent 安装目录> | 确认无进程占用后删除；保留需归档的日志副本 |
| Linux | 内核模块 / 快照驱动 | lsmod | grep <快照驱动模块名>；查看 /lib/modules/$(uname -r)/ 下的产品模块 | 按官方方式卸载模块，禁止强删正在被引用的模块；必要时重启 |
| Linux | 配置与日志 | /etc 下的配置与环境文件、<Agent 日志目录> | 删除前确认不含仍需保留的审计信息 |
| Windows | 系统服务 | sc query <代理服务名>，或用服务管理器查找 | 停止并删除服务，确认驱动未处于运行状态 |
| Windows | 注册表项 | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<代理服务名> 与 HKEY_LOCAL_MACHINE\SOFTWARE\<产品项> | 仅在确认服务已删除后清理，操作前导出注册表备份 |
| Windows | 驱动与筛选器 | fltmc filters 查看文件系统筛选器；设备管理器中查看存储筛选器 / 卷影副本组件 | 筛选器未卸载会影响磁盘性能，需按官方指引处理并重启 |
| Windows | 程序目录与缓存 | <Agent 安装目录>、<挂载缓存目录> | 确认无挂载点占用后清理 |
上表里 <代理服务名>、<快照驱动模块名>、<Agent 安装目录>、<Agent 日志目录>、<挂载缓存目录> 是占位符。源文档在这几个位置给的取值（服务单元名、模块名、安装路径、日志路径、卸载脚本名）都出自指代不明的第三方资料，照抄会把你引到一个不存在的路径上，或者更糟——删掉同名的别的东西。拿到产品侧的确切名称后再执行。
源文档提示：代理客户端需与备份系统版本同步升级；若重复安装插件，安装程序会自动删除之前的插件，并导致正在备份的任务失败。所以"再装一遍试试"不是一个安全的排障动作，升级请走第 16 章的流程。
清理后的验证
清理后的验收覆盖四个方面：服务可用、作业可跑、数据可恢复、容量符合预期。逐项留存证据。
| 序号 | 验证项 | 验证方法 | 期望结果 |
|---|---|---|---|
| 1 | 服务与 Agent 状态 | 控制台查看服务状态、数据获取器与代理在线情况 | 全部组件恢复为正常状态，无新增告警 |
| 2 | 关键目录权限 | 核对程序目录、日志目录、存储挂载点属主与权限 | 与清理前一致，无权限被放宽 |
| 3 | 容量回收 | 清理前后对比 df -h 与存储报表 | 空间释放，且允许存在释放延迟 |
| 4 | 还原点完整性 | 核对保留期内还原点数量与时间点列表 | 保留期内还原点无缺失，链结构完整 |
| 5 | 小范围备份验证 | 选择 1–2 个非核心作业执行一次手动备份 | 作业成功，新增还原点可见 |
| 6 | 抽样恢复验证 | 抽取 1 个文件级与 1 个目录级还原点恢复到临时路径 | 恢复成功且文件数量、最近修改时间与源端基本一致 |
| 7 | 异常处置 | 出现还原点缺失或服务异常时的处置与关闭 | 立即停止后续清理，保全证据并升级 |
记录清理对象清单、清理前容量、清理后容量、验证时间、执行人与复核人；对未通过项登记责任人与处理时限。
这七项在本环境尚未取得实测结果，交付时须据实填写。
源文档在这一节里的表述自相矛盾：小节开头写"本次已取得实测数据、单元格按已实测处理"，小节末尾又写"本节的取值范围为行业通用要求，不得作为本系统验收结论；实测数据须在实施阶段取得"；而表格「本次结果」一列填的是「已明确」这种既非观测值也非结论的字样。按全书统一口径，凡实测与否存在冲突的，一律按未实测处理。
不可恢复操作的审批
涉及永久删除、卸载、密钥与权限的操作，走统一流程：申请—审批—执行—核对—留痕。
申请时应列明：删除对象、数据归属、保留期限、依赖关系、业务影响、替代副本与验证证据。由数据责任人及运维负责人审批后在维护窗口执行，确认弹窗中的对象必须与申请一致，执行人和复核人分别签认，保留操作日志。
变更前后建议记录的字段：变更编号与申请日期、变更对象、变更内容、保护空档风险、备份链完整性影响、容量影响、恢复能力影响（RTO/RPO 是否仍满足业务等级）、加密与密钥影响、窗口与带宽影响、回退方案、审批与责任人。
对删除、恢复、升级、权限和密钥相关操作实施双人复核。这一类操作的共同特征是"执行完就没有回头路"，复核人存在的意义是在点确定之前把对象核一遍。
常见问题
代理显示在线，但这台主机好几天没有新还原点了。
在线只是瞬时状态。到历史任务里查这台主机关联的作业：是没触发（看策略上有没有 <禁用任务计划> 标记），还是触发了但失败。判定口径见本章"巡检节奏"一节的"作业结果"行。
一台主机一周离线三次，每次几分钟，要不要处理？ 要。判定标准是同一主机一周离线 ≥ 2 次即须排查，≥ 2 次升级为问题记录。短时反复离线通常是网络侧问题，按代理离线事件记录表逐项填写，把根因落到具体端口或链路上。
存储快满了，能不能先删点旧备份腾地方？ 先判断属于哪一类：保留期未到、被引用、WORM 保护、还是孤立临时数据。禁止以删除未知备份链的方式释放空间。可以先清理挂载缓存、系统临时目录和崩溃转储这类可再生内容，再考虑调整保留策略或扩容。
删除了一批还原点，但 df 看着没变。
"删除后存储空间未释放，或释放空间较慢"属正常现象。重删场景下的回收依赖定期垃圾回收任务，可能延迟数小时到次日。不要因此反复重启或手工清目录。
主机要重装系统，直接格式化就行了吧？ 平台侧还留着这台主机的登记和作业关联。正确顺序是先停作业、在平台侧解除关联或执行「删除并卸载」，再处理主机。否则平台上会留下一台永远离线的资源，还会污染巡检的在线率统计。
卸载完代理，lsmod 里还有模块没走。
卸载内核模块前要先确认没有其他依赖该模块的作业；涉及实时或快照驱动时按官方要求重启主机。重启后再确认服务、驱动与目录是否都已消失。SupDRC 的具体模块名与卸载方式尚待产品侧提供，不要凭名字相近就强行 rmmod。