详情

首页手游攻略 CentOS 7 生产迁移备份清单:数据一致性、切换点与回滚准备

CentOS 7 生产迁移备份清单:数据一致性、切换点与回滚准备

佚名 2026-10-30 16:50:01

迁移出现问题时,数据库备份不完整,或新机已经有旧机没有的新数据,都会让回退更难处理。这些问题应在正式切换前就有验证过的办法。

生产迁移前要同时准备三样东西:能恢复的备份、明确的切换点,以及切换后新增数据的处理办法。“已经做过快照”不能单独证明可以回滚。

先确定允许丢多少数据、停多久

业务应明确最大可接受数据损失和最大恢复时间,常写作 RPO、RTO。比如最多允许丢失五分钟数据、半小时内恢复服务,相应的备份频率、同步方式和操作流程都要支持这个目标。

如果要求不丢数据,就不能靠几小时前的快照解决所有问题。需要在停写、复制或增量日志中找到能对齐的恢复点。

写明谁批准切换、谁负责数据库、谁改入口、谁决定回退。多个团队同时操作而没有统一顺序,很容易形成两边都接收写入的状态。

清单一:系统和配置是否完整?

  • 保存磁盘布局、挂载、LVM、启动模式和网络配置。
  • 导出软件包、仓库、启用服务和计划任务清单。
  • 备份应用目录、服务配置、自定义脚本和环境变量配置。
  • 保存证书、密钥及恢复所需授权材料,按敏感数据限制访问。
  • 记录服务账号 UID/GID、目录权限、ACL 和 SELinux 标签要求。

CentOS 7 上可采集以下信息:

lsblk -f
findmnt
rpm -qa | sort
systemctl list-unit-files --state=enabled
ip addr
ip route

这些命令只是环境清单,不是备份。整机恢复还需要能够覆盖系统盘、启动信息和必要数据盘的方案,不能只复制 /etc。

清单二:数据库备份是否一致?

数据库要使用与产品、版本和表类型匹配的备份方式。逻辑导出、物理备份、复制和增量日志,不同组合有不同恢复步骤。

  • 备份包含应用需要的全部数据库和对象。
  • 存储过程、触发器、事件、用户及授权已纳入安排。
  • 已记录数据库版本、字符集、排序规则和必要插件。
  • 需要时间点恢复时,相关日志完整、位置明确且保留期足够。
  • 在独立环境完成过导入,并用业务读写验证。

运行中的数据库目录不能随意用文件复制代替一致性备份。多个数据库或文件共同组成一笔业务时,还要设计跨组件一致性点。

清单三:文件和外部依赖有没有遗漏?

上传文件、共享目录、对象存储、附件、搜索索引、消息队列和缓存,都应明确迁移办法。缓存是否可丢弃,要由业务确认;有些系统把关键状态放在缓存里,不能直接清空。

文件同步可以先预演,比如:

rsync -aHAXn --numeric-ids /srv/app/ admin@NEW_HOST:/srv/migration-stage/app/

目标地址、目录和权限需要替换并确认。-n 只显示预演结果;真正同步后还要检查返回状态、重要文件校验值和数量,并验证属主映射。不要随手添加 --delete,否则可能删除目标中需要保留的文件。

还要检查邮件、支付等外部业务接口、固定 IP 白名单、授权文件、DNS、证书续期和监控告警。应用页面能打开,不代表这些后台依赖都正常。

清单四:备份是否独立、可读、可恢复?

备份应存到与原机故障范围不同的位置,并确认目标存储空间和访问权限。加密备份的密钥必须能在原机损坏时取得,不能只留在被备份的系统内。

快照适合快速恢复磁盘状态,但不一定自动包含所有数据盘,也不一定满足数据库应用一致性。按备份工具要求停写、冻结或使用应用一致性机制。

实际恢复一次,记录耗时、缺失项目和业务结果。只有备份任务显示成功,没有恢复记录,仍不足以证明它符合迁移要求。

清单五:切换当天按什么顺序做?

  1. 宣布维护开始,暂停变更和计划任务。
  2. 停止业务写入,处理在途请求和后台消费者。
  3. 完成最终数据同步,记录数据库和文件的一致性点。
  4. 校验新机配置和数据,再切换流量入口。
  5. 测试业务读写,按顺序启用后台任务。
  6. 持续观察错误率、延迟、队列和数据完整性。

不能只改 DNS 就认为旧入口立即失效。客户端缓存、连接池和长连接都可能让请求继续到旧机,应通过明确的停写、转发或入口控制避免两边各写各的。

清单六:回滚条件和数据办法写清了吗?

阶段回退前需要确认
新机尚未接收写入旧机仍处于一致状态,旧入口可恢复
新机已经接收写入先停写,处理新数据反向同步或恢复,再回退入口
已升级数据库结构旧应用是否仍能读取;不兼容时按专门恢复方案处理
怀疑发生安全事件从可信备份重建并处理凭据,不能把异常状态直接带回

提前规定触发条件,比如核心功能失败、错误率持续超过约定阈值、关键数据校验不一致,或迁移超过维护窗口。阈值由项目设定,不能临场随意决定。

回滚步骤应包含负责人、命令或操作位置、预计耗时和验证项目,并在测试环境演练。旧内核能启动、yum history undo 能执行,都不能代替整套业务回滚。

最后,旧机什么时候可以下线?

确认新环境经过约定观察期,关键任务至少完成相应业务周期,备份与恢复正常,新写入数据没有一致性问题,回退需求也已经结束,再批准退役。

退役时处理旧机凭据、服务入口、监控、备份保留和磁盘数据。不要让一台已经不承担业务、但仍能访问生产系统的旧服务器长期挂在网络上。

可以用一次恢复演练检查准备是否完整:停用旧主机后,团队能否在约定时间内恢复业务?如果仍需临时查找口令、安装材料和数据文件,就应先补齐缺项。

点击查看更多
推荐专题
热门阅读