培训平台部署备份与容灾：从三服务交付到可恢复运行
培训平台一旦承载了学习记录、考试成绩和证书信息，就不能只关注"服务能不能启动"，还要回答：数据丢失后能恢复到什么时间点，课件和配置能否找回，恢复需要多久，谁负责执行切换和验证。
织码在线教育系统交付了 Docker 编排、服务脚本和前端部署脚本，可作为标准化部署的基础。MySQL、Redis、对象存储和 Nacos 等中间件的高可用与备份，取决于部署方的选型和运维方案。本文按部署拓扑、备份清单、恢复演练和可用性建设梳理一套可落地的连续性方案。
一 先看清平台的部署边界
后端由网关、基础服务和资源服务组成，通过 docker-compose.yml 统一编排：
| 服务 | 容器名 | 端口 | 主要职责 |
|---|---|---|---|
wcs-edu-gateway |
gateway | 9500 | 统一鉴权与路由 |
wcs-edu-server-base |
base | 9510 / 9512 | 用户、组织、权限、订单与配置 |
wcs-edu-server-resource |
resource | 9530 / 9532 | 课程、任务、考试、证书与直播 |
典型编排配置会为服务设置 restart: always，并把日志挂载到宿主机，例如 ./logs/base:/root/logs/base。这能在进程异常退出时尝试自动拉起，也能避免容器删除后日志随容器消失，但它不等同于服务高可用，更不能替代数据备份。
部署交付物通常包括：
text
wcs-edu-backend/
├── docker-compose.yml 三服务编排
├── .env TAG 与运行环境变量
├── wcs-edu-gateway/Dockerfile
├── wcs-edu-server/*/Dockerfile
├── distribution/bin/ 服务启停与 systemd 脚本
│ └── service/ 等待依赖、安装与卸载服务
└── docs/sh/ admin / web / h5 / 后端部署脚本配置通过 Nacos 外部化管理，例如 spring.config.import=nacos:application.properties。wait-service-ready.sh 用于依赖等待，install-systemd.sh 可以把服务注册为系统服务。前端 admin、web、h5 由 docs/sh/ 下的脚本部署。具体环境变量、镜像版本和端口应在上线前形成环境清单，不能只依赖操作人员记忆。
MySQL、Redis 和对象存储可以独立部署或使用云托管。它们的备份、主从、集群和恢复权限，属于部署方的基础设施责任，需要在交付边界中写清楚。
二 按恢复价值建立备份清单
备份优先级应按"丢失后能否重建"和"业务影响有多大"判断：
| 对象 | 主要内容 | 丢失影响 | 建议策略 |
|---|---|---|---|
| MySQL | 用户、课程、学习、考试、证书 | 业务事实难以重建 | 每日全量 + binlog 增量 |
| Redis | Token、缓存、部分考试状态 | 会话失效，体验受影响 | 按实际用途配置 RDB/AOF |
| 对象存储 | 视频、文档、图片等课件 | 课程无法播放，重建成本高 | 备份桶、版本控制或跨区域复制 |
| Nacos | 应用配置、存储和消息参数 | 服务可能无法正确启动 | 变更前导出并归档 |
| 部署产物 | 镜像 TAG、.env、compose、前端包 |
重建环境速度变慢 | 随版本打包并保存 |
| 日志 | 操作、错误、任务和访问日志 | 排查与审计证据减少 | 按制度保留并做容量管理 |
MySQL 通常是最难重建的业务事实；Redis 的数据是否需要恢复，取决于其中保存的是临时缓存还是不可丢失的业务状态。不能用一套固定策略覆盖所有系统，备份范围应结合实际数据用途确认。
三 把备份变成可验证的恢复方案
备份文件存在不代表能够恢复。运维侧可以按下面的顺序建立恢复流程：
text
确定故障范围与恢复目标
↓
在隔离环境恢复 MySQL 全量并追平 binlog
↓
恢复对象存储、Nacos 配置和指定版本部署产物
↓
启动 gateway / base / resource 并检查依赖状态
↓
抽检登录、课程播放、考试记录和证书记录
↓
记录 RTO、RPO、缺失数据与改进项建议至少按季度做一次只恢复不切换的演练，避免第一次真正故障时才发现备份账号无权限、对象存储路径不一致、配置密钥缺失或镜像版本找不到。演练环境应与生产隔离，恢复后的测试数据要标记清楚，避免误发通知或污染正式业务。
RTO 表示恢复到可用状态所需时间，RPO 表示最多能接受的数据丢失窗口。它们不是系统默认值，需要结合企业对考试和合规记录的要求确定。全量备份频率、binlog 保留时长、对象存储版本策略和恢复人员值班安排，都应围绕这两个目标制定。
四 用务实方式提升可用性
| 目标 | 可执行做法 | 边界 |
|---|---|---|
| 进程自愈 | 服务设置 restart: always，配合健康检查和告警 |
只能处理部分进程级故障 |
| 消除单点 | 网关前置负载，服务多实例部署 | 需要处理会话、配置和依赖一致性 |
| 数据连续性 | MySQL 主从或托管高可用，Redis 哨兵/集群 | 由部署方结合成本和 RPO 选择 |
| 快速重建 | 镜像 TAG、.env、compose 和前端构建产物纳入版本管理 |
密钥不能明文散落在代码仓库 |
| 配置回滚 | Nacos 变更前导出，保留版本和审批记录 | 配置回滚需配合服务重启或刷新策略 |
| 故障排查 | 使用 sys_log 的 status、errorMessage、durationMs |
日志留存仍需规划容量和权限 |
高可用、备份和容灾解决的是不同问题：高可用减少服务中断，备份帮助找回数据，容灾方案保证在环境不可用时恢复业务。三者要分别设定目标，再通过演练验证组合起来是否满足业务要求。
五 上线前的检查清单
| 阶段 | 检查项 | 交付记录 |
|---|---|---|
| 部署前 | 镜像版本、端口、环境变量、Nacos 命名空间 | 环境配置清单 |
| 上线时 | 三服务依赖、前后端访问、日志挂载和告警 | 上线检查表 |
| 备份时 | 全量、增量、对象存储、配置和部署产物 | 备份任务记录 |
| 演练时 | 恢复权限、数据抽检、RTO/RPO、缺失项 | 恢复演练报告 |
| 变更后 | compose、镜像、配置和前端包是否同步归档 | 版本归档记录 |
六 总结
培训平台的连续性保障，先要明确交付边界，再把业务数据、课件素材、配置、部署产物和日志纳入清单。docker-compose.yml、服务脚本和 Nacos 外部化配置帮助环境标准化；MySQL、Redis 和对象存储的高可用与备份，则需要部署方结合业务目标落地。
真正可靠的方案必须经过恢复演练。只有能在隔离环境恢复服务、抽检关键业务，并记录 RTO 和 RPO，备份才从"文件存在"变成"业务可恢复"。
edis 和对象存储的高可用与备份，则需要部署方结合业务目标落地。
真正可靠的方案必须经过恢复演练。只有能在隔离环境恢复服务、抽检关键业务，并记录 RTO 和 RPO，备份才从"文件存在"变成"业务可恢复"。