第 2 章 · 架构、组件与数据流
适用对象：架构师、交付工程师 · 阅读约 15 分钟 · 对应产品界面版本 v1.2.0
上一章把对象认全了，这一章回答它们怎么连起来：哪些进程跑在管理平台上、一次备份的数据从哪走到哪、出问题该去哪个组件取证。这一章也是划网络区域、提放行需求前必须看完的一章。
读完这一章你会做：
- 说出管理平台部署域里各组件的分工，并用实际容器名而不是示例名定位它们
- 区分数据获取器、存储库、挂载服务器与被保护主机上的 Agent 四个对象各自的位置
- 按 T1–T7 和 R1–R7 两条时序定位一次作业卡在哪一段、该去哪里取证
- 按管理区 / 数据服务区 / 生产区划分网络，并知道跨区放行要逐条登记哪六项
- 分清「端口在监听」和「这次作业真的走了这条路」是两件事
系统边界
管理控制台是操作入口；被保护主机及其 Agent 是保护对象；数据获取器、存储库、挂载服务器等承担不同的基础设施角色。保护组负责组织计算机成员及发现、分发设置。平台通过浏览器管理资源、策略、备份数据、用户和日志。
这张图说明的是「有哪些组件、归属哪个部署域」，不说明它们之间的调用关系——连线和顺序要等厂商确认矩阵。
核查环境中，平台主机运行管理容器，同时还有数据获取器和存储库进程；架构清单里另有一台标记为 Mount Server 的服务器。该布局只表示当前这一个实例，源文档判定现有材料不足以把它当作官方标准拓扑。做方案时按第 3 章的规模档位决定合设还是分离。
管理平台里的组件
管理服务以 Docker 容器运行，界面把功能组织为资源、策略、数据、监控和配置五类。
| 组件 | 角色 | 说明 |
|---|---|---|
| Nginx | Web 入口 | 控制台访问入口 |
| SupDRC | 管理服务 | 核查环境容器镜像标签 supdrc:1.0 |
| Backup Server | 任务与备份服务 | 界面写作 SupMirror Backup Server；核查环境镜像标签 supmirror-backupserver:2.0 |
| MySQL | 元数据 | 还原点、备份链依赖、容量与统计的落库位置 |
| Redis | 缓存 | 观察到的容器 |
| RabbitMQ | 消息服务 | 观察到的容器 |
| InfluxDB | 指标数据 | 观察到的容器 |
核查环境里镜像标签是 1.0 和 2.0，而「关于」里的界面版本是 v1.2.0。页面版本与应用镜像标签分开记录，不要从名称推导版本兼容性。 查询运行状态时以实际容器名称定位，不要把示例名当作所有部署的固定名称。
MySQL、Redis、RabbitMQ、InfluxDB 只作为该实例中的数据库、缓存、消息和指标类组件记录，它们的数据模型、调用关系和高可用机制未经产品技术资料核对证实。规划时把 Web 入口与数据库、消息端口分开处理，不要求所有业务客户端直接连接中间件。
已观察到的关联关系
配置面上可以确认的关联有四条，排障时按这四条倒推配置错在哪：
- 主机保护策略：选择保护组或计算机，并选择存储库
- 数据获取器：与所属服务器关联
- 存储库：与服务器及存储路径关联
- 恢复向导：选择还原点、恢复目标或介质制作主机
端口与监听
数据获取器监听 35000/35001，存储库监听 36000/36001。源文档记录的组件端口如下：
| 组件或对象 | 端口 | 用途 | 证据边界 |
|---|---|---|---|
| 被保护主机 | 37000 | 服务通信 | 页面或手册中的配置值 |
| 被保护主机 | 37001 | 数据传输 | 页面或手册中的配置值 |
| 数据获取器（Proxy） | 35000 | 应用服务 | 页面配置与监听记录 |
| 数据获取器（Proxy） | 35001 | 通信 | 页面配置与监听记录 |
| 数据存储库 | 36000 | 存储库服务 | 页面配置与监听记录 |
| 数据存储库 | 36001 | 数据传输 | 页面配置与监听记录 |
| Linux 服务器 | 22（SSH 默认，现场可改） | SSH 连接 | 端口字段可见，实际值按现场配置 |
| 元数据库 | 3306 | 元数据写入（本机或容器网络内） | 时序记录 |
端口存在只证明相应服务正在运行，不能单独证明某一次 Agent 作业的数据经过了哪些组件。要证明完整路径，需要一次成功作业的连接记录或抓包结果。
源文档两篇对同一组端口的归属写法不一致，本手册不替你选一种：
- 架构篇把 37000/37001 记为被保护主机的监听端口（37000 服务、37001 数据）；
- 产品篇的通信方向矩阵把 37000/37001 写成 Agent 到数据获取器方向上的目标端端口，同一张表的恢复回写行又把 37000/37001 写成恢复目标主机侧的端口；
- 35000/35001 同样有两种写法：架构篇记为都由数据获取器监听，产品篇记为 35000 在数据获取器侧、35001 在管理平台侧。
正式放行前必须由产品方确认源、目的、协议、方向与必要性，再写进附录 B。上表不是完整放行规范。
一次备份经过哪七段
有代理的主机保护作业分为七段。这张表的用法是：作业失败时先判断停在哪一段，再决定去哪个组件看日志。
| 阶段 | 触发方 / 执行组件 | 动作 | 涉及端口 | 证据边界 |
|---|---|---|---|---|
| T1 策略触发 | 管理平台调度器 | 到点或手动触发作业，生成作业实例并下发作业定义与凭证引用 | 浏览器→管理平台 443/TCP；管理平台→被保护主机 37000/TCP | 页面配置与监听记录 |
| T2 Agent 准备 | 被保护主机 Agent | 校验作业定义、凭证、卷与文件范围，加载快照/过滤驱动，建立数据通道并回报就绪 | 被保护主机 37000（服务）、37001（数据） | 端口字段可见，实际值按现场配置 |
| T3 快照 / CBT | Agent + 操作系统快照接口 | 创建一致性时间点，读取 CBT 变化块位图；全备时读取全量数据 | 本机调用，不占用网络端口 | 手册中的快照与 CBT 说明 |
| T4 数据传输 | Agent → 数据获取器或存储库 | 按块传出数据，可压缩、加密、限速 | Agent 37001→Proxy 35001，或→存储库 36001 | 监听记录；未被单次作业证明完整路径 |
| T5 写入存储库 | 数据存储库 | 落盘前做重删、压缩、加密，组织分片与目录 | 存储库 36000/36001 | 页面配置与监听记录 |
| T6 元数据更新 | Backup Server + 元数据库 | 登记还原点、链依赖、容量与统计，刷新索引，作业状态转为成功或失败 | 元数据库 3306/TCP | 时序记录 |
| T7 通知与归档 | 通知与保留模块 | 产出任务结果与告警，打长期保留标记，按策略触发副本或归档 | 邮件 / SNMP Trap / Syslog / Webhook（出站） | 时序记录 |
源文档对 T1–T7 的写法是「骨架」，并明确「不把未确认值写成已核实事实」。尤其是 T4 —— 数据是否必须经过数据获取器、还是可以由 Agent 直接写存储库，源文档给的是「或」，没有定论。 交付前要用一次成功作业的连接记录把这一段坐实。
一次恢复经过哪七步
恢复是备份的逆向流程：
| 步骤 | 动作 | 组件 | 端口 |
|---|---|---|---|
| R1 选择还原点 | 在「主机保护数据」中按时间点或类型选定还原点，确认目标主机与路径 | 管理平台 | 443/TCP |
| R2 目标准备 | 整机恢复时准备目标主机与恢复介质（ISO 或共享路径），或由平台直接连接目标 Agent | 管理平台、挂载服务器、目标主机 | 管理平台→目标 37000/TCP |
| R3 校验与解密 | 读取还原点元数据，校验完整性；启用加密时需要加密密码或密钥 | Backup Server、存储库 | 36000/36001 |
| R4 数据读取与传输 | 存储库组织数据流，经数据获取器或直连发送到目标 | 存储库、数据获取器、目标 Agent | 36001→35001→37001 |
| R5 写入目标 | 按卷或文件写入目标；整机恢复时按需重建分区 | 目标主机 Agent | 37001 |
| R6 引导与驱动 | 整机恢复后注入存储与网络驱动、修复引导，改回与原机一致的引导模式 | 恢复介质、目标主机 | 按介质网络设置 |
| R7 验收归档 | 核对任务结果、文件数量与内容、业务可用性，登记证据编号并归档 | 管理平台 | 443/TCP |
整机恢复时重建分区会清除目标磁盘的原有数据。操作细节和确认关口见第 14 章。
失败了先查哪里
| 停在哪一段 | 先查什么 |
|---|---|
| T2 / T3 | Agent 状态、凭证、快照空间 |
| T4 | 端口连通、限速与重连参数 |
| T5 | 存储库容量与权限 |
| T6 | 元数据库可用性。这一段失败时数据可能已经落盘但还原点不可见，需人工核对后再决定重试或清理 |
网络区域怎么划
部署前先定区域，再谈放行。
区域划分是能定的，跨区连线的协议和方向要等正式矩阵——图里那两段连线画成虚线就是这个意思。
| 区域 | 放什么 |
|---|---|
| 管理区 | 管理员访问与编排：管理终端（浏览器）、管理平台 |
| 数据服务区 | 数据获取器、存储库等组件 |
| 生产区 | 被保护主机及其 Agent |
跨区放行按源角色、目的角色、协议、端口、方向、用途六项逐条登记，结合最小权限限制访问。备份流量与生产高峰错开；跨站链路另行评估带宽与中断重试。
四个信任边界
| 边界 | 源→目的 | 数据形态 | 控制点 |
|---|---|---|---|
| 管理边界 | 浏览器→管理平台 | 账号口令、会话令牌、配置与日志（HTTPS/TLS） | 强口令与多因素、会话超时、来源 IP 限制、操作审计 |
| 控制边界 | 管理平台→Agent / 数据获取器 / 存储库 | 作业定义、凭证引用、控制指令 | 证书或令牌校验、端口最小放行、双向确认 |
| 数据边界 | 数据获取器 / 存储库→存储介质 | 备份数据块（可压缩、加密）、索引与元数据 | 存储侧权限收敛、静态加密、WORM 或不可变选项、容量与完整性校验 |
| 运维边界 | 运维终端→平台后台或主机 | SSH / RDP 会话、底层命令、日志文件 | 堡垒机、专用账号、命令白名单、留痕与双人复核 |
密钥怎么流转
密钥按生成、存储、备份、轮换、销毁五个环节闭环管理：
| 环节 | 做法 | 注意点 |
|---|---|---|
| 生成 | 启用存储加密时生成数据加密密钥；传输通道使用 TLS 会话密钥 | 算法与密钥长度见下方提示 |
| 存储 | 密钥与密文分离保管，平台内以受保护形式存放 | 含解密密钥的恢复介质按敏感介质管理 |
| 备份 | 配置与数据库备份单独加密，密钥材料存入独立故障域 | 不要把密钥与备份数据放在同一故障域 |
| 轮换 | 新旧密钥并存，覆盖全部存量还原点后再下线旧密钥 | 旧还原点仍依赖旧密钥，销毁前必须核对 |
| 销毁 | 双人审批并登记销毁时间、范围与无依赖确认 | 密钥丢失不可恢复，密文数据不可逆 |
源文档对算法的口径不一致：架构篇一处写作「本系统支持 AES-256 与国密 SM4」，同篇另一处写作「静态加密参考 AES-256 与国密 SM4」（即行业参考值），产品篇写作行业通用值，兼容性篇则把加密列为「仅见配置入口、效果未验证」。本手册不选其中任何一种作为结论。 策略高级配置里确实有备份文件加密入口，但入口存在不等于已验证加密算法与密钥机制。
高可用与平台自身容灾
备份与容灾平台的可用性设计通常分三档。下表是核对框架，用来问清楚产品支持到哪一档，不是 SupDRC 的实际能力声明：
| 档位 | 监控与切换判定 | 切换时间参考 | 数据一致性 | 关键前置条件 |
|---|---|---|---|---|
| 主备（冷备 / 温备） | 人工或外部监控发现故障后手动切换 | 30 分钟–数小时 | 以最近一次同步为准，可能回退 | 备机同版本同配置；配置与元数据定期同步；切换脚本与审批 |
| 双机热备 | 进程级或心跳探活，达到阈值自动切换 | 1–5 分钟 | 需元数据同步；备份数据置于共享或副本存储 | 心跳使用独立链路；防脑裂仲裁；虚拟 IP 或域名切换 |
| 共享存储集群 | 集群投票与仲裁，节点故障自动摘除 | 秒级–2 分钟 | 单一数据副本，一致性最高 | 仲裁节点；集群文件系统；存储双活或多路径 |
上表的切换时间是行业参考区间，不是产品承诺值。不要把 1–5 分钟这类数字写进验收指标。
切换完成后至少核对六项：管理界面可登录；被保护主机与 Agent 在线状态恢复；元数据中还原点可检索；存储库可读且容量统计正确；调度器继续按计划触发作业；未完成作业的重试或补偿策略生效。建议每年至少一次切换演练，关键业务每半年一次，演练记录纳入恢复演练档案（见第 15 章）。
平台自身容灾要同时覆盖配置、数据库与元数据、许可材料、恢复所需密钥以及备份数据五类对象。
把经批准的配置备份保存在独立故障域，记录版本、生成时间、校验值和恢复依赖，并定期验证能否恢复管理能力与还原点检索能力。
Agent 装完之后长什么样
Agent 可以按「管理服务 + 传输服务 + 看门狗」三件套理解，命名一般遵循「产品前缀 + 模块 + 角色」的规律，日志收敛到平台专属目录并按模块分子目录。核对方法：
| 平台 | 怎么核对 |
|---|---|
| Linux（systemd） | systemctl list-units 配合 grep 定位；EL6 用 service 命令 |
| Linux（进程） | ps -ef 配合 grep，一次列出管理、传输与看门狗进程；三者应同时处于运行状态 |
| Linux（驱动） | lsmod 配合 grep 查看卷过滤模块 |
| Windows（服务） | services.msc 或 sc query；每个模块一对「管理 + 传输」服务，另有看门狗服务，服务名与显示名可能不同 |
| Windows（驱动） | sc query <驱动名>；驱动日志并入操作系统事件日志 |
源文档在这一节给出的服务名与日志路径标注为「参考实例」，属于通用规律而非 SupDRC 的确认取值，本手册不照抄。现场先用上表的命令定位，再用产品方出具的清单固化。巡检口径见第 11 章。
常见问题
数据一定要经过数据获取器吗？ 源文档没有定论，写的是「经数据获取器转发或直接写入存储库」。这一条要用一次成功作业的连接记录或抓包坐实，不要在方案里先写死。
为什么容器镜像标签是 1.0、2.0，界面却是 v1.2.0？ 它们是不同维度的版本号。界面版本从页面左上角和「关于」取，镜像标签从后台容器清单取，两者分别登记，谁也不能代替谁。
端口表能直接交给网络组去放行吗？ 不能。源文档两篇对 37000/37001、35000/35001 的归属写法不一致，且明确标注这些方向不得直接作为防火墙开通依据。要等产品方确认后的正式矩阵。
挂载服务器一定要单独一台吗？ 核查环境的架构清单里有一台标记为 Mount Server 的服务器，但这只是该实例的布局。它的部署规模和高可用方式源文档判定材料不足，规划时按第 3 章的规模档位和实际恢复需求决定。
备份作业一直排队不执行，先看哪一段？ 先看 T1：作业实例有没有生成。生成了但 Agent 不动，看 T2 的凭证与 Agent 在线状态；Agent 就绪但数据不走，看 T4 的端口连通与限速。