Amazon Linux 2迁移Amazon Linux 2023，企业服务器如何制定备份、切换与回滚方案

Amazon Linux 2迁移Amazon Linux 2023，生产环境更稳妥的路径是：保留旧服务器，重新构建新系统，完成兼容验证与数据恢复演练后，再分批切换业务流量。备份不仅要覆盖系统盘，还要覆盖数据库、上传文件、配置、密钥和外部依赖；回滚也不能只理解为“把流量切回去”，必须回答新环境接收写入后，数据如何安全返回旧环境。

作为变更负责人，应把目标状态定义为“业务在Amazon Linux 2023上可持续运行，数据一致，监控完整，旧环境在约定窗口内仍可恢复服务”，而不是“新机器可以启动”。下面按现状核对、变更准备、分步实施、验证观察和回滚条件组织方案，默认采用新旧环境并行的迁移方式，避免在同一次变更中同时升级操作系统、数据库主版本和业务架构。

一、现状核对：先确定迁移边界与兼容风险

明确停服含义与迁移方式

根据Amazon Linux 2官方常见问题，Amazon Linux 2的支持结束日期为2026年6月30日。支持结束不等于运行中的实例当天自动关机，但继续使用会面临安全更新、技术支持和合规方面的风险。

Amazon Linux 2到Amazon Linux 2023不应按普通软件包更新处理。AWS不提供这两个版本之间的原地升级路径，应使用Amazon Linux 2023镜像建立新实例，再部署应用、迁移数据并切换入口。相关系统差异可参考AWS的Amazon Linux 2023与Amazon Linux 2对比文档。

迁移的基本边界是：更换操作系统运行环境，尽量不改变应用版本、业务接口和数据结构。 如果现有应用版本无法适配新系统，先在测试环境解决兼容问题，再进入生产切换，不把兼容修复留到停机窗口内。

建立资产清单，不只统计EC2实例

每个业务服务至少应形成一份可追踪清单：

在旧实例上，可通过以下只读命令核对基础信息。输出可能包含内部地址、包名和服务信息，应存放在受控的变更记录中：

cat /etc/os-release
uname -r
uname -m
lsblk -f
df -hT
rpm -qa | sort
systemctl list-unit-files --state=enabled
systemctl list-timers --all
ss -lntup

这些命令不能替代应用清单。还需要核对用户级定时任务、应用自带调度器、容器配置、人工修改过的服务单元，以及未纳入配置管理的脚本。

特别关注“机器上能找到，但部署仓库里没有”的文件。迁移时最容易遗漏的往往不是主程序，而是自定义CA证书、上传目录、报表模板、服务启动参数和临时修复脚本。

对兼容风险逐项给出处理结论

Amazon Linux 2023的软件包、系统组件和默认行为与Amazon Linux 2存在差异，不能直接把旧系统的软件目录整体复制过去。

在新实例上先确认实际状态，而不是根据旧文档猜测版本：

cat /etc/os-release
uname -r
dnf repolist
rpm -q glibc openssl systemd
stat -fc %T /sys/fs/cgroup
command -v getenforce >/dev/null 2>&1 && getenforce

包未安装、命令不存在或输出与预期不同，都应进入兼容性记录。不要通过手工替换系统共享库来让旧程序暂时启动，这会扩大后续更新和故障恢复风险。

如果原实例使用x86_64，本次迁移优先保持同一架构。改用Arm实例可以另行评估，但不宜与操作系统迁移同时实施，否则出现性能或依赖问题时难以定位原因。

二、变更准备：让备份、停机窗口和回滚方案彼此匹配

先约定RPO、RTO与业务影响范围

RPO表示允许丢失多少时间范围内的数据；RTO表示从故障发生到恢复可用服务的目标时间。两者应由业务负责人确认，不能由运维人员根据迁移方便程度自行决定。

例如，一项交易服务要求“已确认订单不丢失、异常后15分钟内恢复”，对应的方案就必须保护所有已确认写入，并把发现异常、停止写入、处理数据差异、切回入口和验证业务的时间全部计入恢复目标。

同时明确停机影响：

• 哪些接口在窗口内只读，哪些需要完全停止？
• 定时任务、队列消费者和后台管理是否同步暂停？
• 外部回调是否会重试，重试是否具备幂等性？
• 长连接、正在处理的请求和未提交事务如何结束？
• 谁可以批准延长窗口，谁可以下达回滚指令？

“前台页面可以访问”不代表业务没有停机。支付回调、库存扣减、文件上传和消息处理都应纳入同一个影响范围。

分层备份，并明确每层能恢复什么

合格的迁移备份必须同时满足三个条件：覆盖需要恢复的对象、具有明确的一致性边界、已经通过恢复验证。 仅看到“快照创建成功”，不足以证明数据库和应用能够恢复。

对于运行中的数据库，直接备份数据目录或在线创建卷快照，未必得到应用一致性备份。应使用数据库支持的在线备份机制，或在停止写入、完成检查点等必要操作后取得一致性快照。多卷数据库还要保证相关卷属于同一个一致性点。

备份记录至少写清生成时间、业务数据边界、加密密钥、保存位置、恢复权限和保留期限。新实例使用的IAM角色能否访问备份、能否调用KMS解密，也要在演练中验证。

恢复演练必须在隔离环境进行，避免恢复后的数据库、定时任务或消费者自动连接生产服务。演练应验证服务启动、核心查询、文件读取和指定备份点的数据，不能只检查文件是否解压成功。

根据有效传输速率估算停机窗口

停机时间由最后一次数据同步、校验、启动、切流和业务验证共同构成，不等于数据复制时间。

以十进制口径计算，300 GB数据通过有效吞吐200 Mbps的链路传输：

• 300 GB × 8 × 1000 = 2,400,000 Mb；
• 2,400,000 Mb ÷ 200 Mbps = 12,000秒；
• 即约3小时20分钟，尚未计入校验、重试和启动时间。

因此，大量基础数据应提前同步。如果窗口内剩余20 GB，按相同吞吐计算仍需要800秒，即13分20秒，几乎占满一个15分钟窗口；若剩余5 GB，理论传输时间约为3分20秒，才有空间完成其他操作。

这里的200 Mbps指有效传输吞吐，不是实例标称带宽。大量小文件、压缩、数据库日志重放和磁盘性能都可能改变耗时，应以预演结果修正窗口。

正式变更前还要确定“最晚放弃点”：剩余时间不足以完成校验和安全回退时，停止推进，而不是继续赌迁移能在最后一分钟完成。

冻结版本，保留可恢复的旧环境

Amazon Linux 2023采用版本化软件仓库机制。准备阶段应记录使用的AMI、仓库发布版本、软件包版本和应用制品，测试与生产使用同一批构建结果。相关机制可参考AWS确定性升级文档。

不建议在切换当天临时更新到未经测试的软件组合。基础镜像、安全更新和应用部署应先完成验证，再进入变更窗口。

旧实例、旧数据卷、原入口配置和原证书权限需保留到观察窗口结束。禁止刚切换就删除旧卷、释放关键地址或撤销恢复所需的访问权限。

三、分步实施：先构建新环境，再控制数据和流量

第一步：建立不接收生产流量的新环境

从适合实例架构的Amazon Linux 2023镜像创建新实例，部署与预演一致的软件和应用版本。网络访问采用最小必要范围，管理入口、数据库连接和监控上报先行验证。

不要直接覆盖复制旧系统的整个/etc目录。只迁移经过审查的业务配置，并按新系统格式处理服务单元、网络设置和权限。

初次启动应用前，默认关闭定时任务、消费者和主动推送功能；写权限和外部回调按测试需求受控开放。否则，新旧环境可能同时扣库存、重复发通知或消费同一批消息。

新环境要达到“应用可以运行，但不会意外产生生产副作用”的状态，再进行健康检查和业务测试。

第二步：恢复基础数据并进行预同步

不同数据位置对应不同迁移路径：

• 数据库使用RDS等独立服务：通常保留数据库，只迁移应用服务器，但仍需验证驱动、TLS、连接池、权限和连接数。
• 数据库位于旧实例本地：建立经过验证的备份恢复或复制链路，记录复制位置与延迟，切换前执行明确的写入交接。
• 应用包含本地持久化文件：先同步基础文件，再同步增量，并保证文件与数据库记录属于可解释的一致性边界。
• 无状态应用：重点验证配置、缓存、会话、外部接口和入口切换，不必制造不必要的数据搬迁。

文件同步方案不能只处理新增文件，还要考虑修改、删除、重命名、权限和符号链接。任何带删除语义的同步操作都应先预览差异，并保留目标目录备份。

此阶段完成关键业务预验证：登录、权限、查询、测试写入、文件访问、消息处理和外部服务调用。可能产生真实副作用的测试必须使用隔离数据或已批准的测试流程。

第三步：进入窗口，冻结写入并完成最终校验

切换负责人应按既定顺序执行：

1. 通知业务进入维护或只读状态，停止可能产生写入的后台任务。
2. 排空进行中的请求、事务和队列处理，确认没有持续写入。
3. 记录数据库事务位置、文件同步边界和切换时间。
4. 完成最后一次增量同步，验证复制追平及关键数据一致性。
5. 确认旧环境写入已被隔离，再开放新环境所需权限。
6. 完成入口切换，并通过真实业务路径验证。

停止Web写接口，并不代表写入已经停止。管理后台、批处理、回调、消费者和其他服务也可能修改同一数据库。

数据校验应围绕业务对象，而不是只比较文件总大小。例如核对最后一批订单、对应附件、关键状态记录和数据库复制位置。校验范围与抽样规则应在变更前确定，不能出现异常后临时降低标准。

第四步：按服务状态选择切流方式

如果应用无状态、新旧版本可共用同一数据库且接口兼容，可以通过负载均衡分批放量，例如按5%、25%、50%、100%逐步推进。每档是否晋级由错误率、延迟和业务结果决定，不单纯按时间决定。

如果本地数据库或文件写入必须进行主从角色交接，应先完成写入切换，再放量，不适合让两个独立数据副本同时接收生产写入。

优先使用已有负载均衡入口完成目标组切换，并检查健康检查、会话保持和连接排空配置。DNS切换需要提前降低TTL，但客户端缓存和已有连接仍可能造成新旧环境并存，不能把“DNS记录已修改”视为流量全部迁移。

无论采用哪种入口，旧环境在切流后都应退出生产写入角色，避免残留流量造成数据分叉。

四、验证观察：从“进程启动”推进到“业务可持续运行”

设置逐层验证门槛

切流后按以下顺序验证：

1. 系统层：磁盘、内存、时间同步、挂载、服务启动状态和异常重启。
2. 连接层：入口到应用、应用到数据库、对象存储及外部接口的连通性。
3. 应用层：日志异常、线程或连接池、超时、依赖调用和资源限制。
4. 业务层：完整交易链路、数据写入结果、文件访问和重复处理情况。
5. 运维层：日志、告警、备份任务和远程管理是否正常。

可在新实例检查启动失败的服务和当前启动周期内的高优先级日志：

systemctl --failed
journalctl -b -p err --no-pager

查询应用日志时，应使用资产清单中确认的真实服务单元名称；不要只看系统日志就判断应用健康。

健康接口返回成功，通常只能证明部分组件可用。至少应完成一个经过批准的业务闭环，并确认结果实际写入正确的数据存储。

用相同口径比较迁移前后指标

变更前保存一个具有代表性的业务基线，切换后保持相同统计周期和流量口径进行比较。

表中数值是示例，应按现有业务SLO、低流量噪声和历史基线调整。数据错误的优先级通常高于资源指标；发现CPU升高可以先评估，发现订单重复不能等观察窗口结束。

常见异常应从低风险检查开始

新环境无法访问数据库时，先检查解析、路由、安全组、身份权限和证书，再检查驱动与连接池。不要一开始就扩大网络开放范围或关闭TLS验证。

应用启动后崩溃时，先比较日志、运行时版本、环境变量、文件权限和动态库依赖。需要调整配置的，应保存原配置并执行应用支持的语法检查；涉及TLS、认证或核心依赖的兼容修改，不宜在生产窗口内反复试错。

文件丢失、权限错误或校验不一致时，立即停止放量，并定位数据边界。源端仍在写入时重复同步，可能掩盖问题而不是解决问题。

五、回滚条件：区分流量退回与数据退回

新环境是否接收写入，决定回滚难度

回滚方案必须以“新环境是否产生有效业务写入”为分界线。 有备份只能证明存在恢复材料，不代表能够在RTO内完成无损回退。

如果旧数据库已经落后，直接把流量切回旧实例可能丢失新订单，或者让重复回调产生二次扣减。此时“立即回滚”首先意味着停止扩大影响和保护数据，不是立即恢复到旧数据副本。

因此，使用本地数据库的迁移应提前选择：保持旧库为权威数据源、建立可验证的反向同步能力，或采用明确的写入冻结窗口。无法证明数据能够返回旧环境，就不能承诺无损回滚。

写清触发条件、执行顺序和停止条件

出现以下情况，应停止继续放量，并由指定负责人决定回退：

• 核心交易不可用，预计修复时间超过剩余窗口。
• 发现数据缺失、重复写入或新旧数据持续分叉。
• 错误率、延迟或积压持续超过已批准的阈值。
• 新环境频繁重启，或者关键监控失联到无法判断运行状态。
• 迁移进入最晚放弃点，剩余时间不足以安全完成验证。

回滚执行顺序同样需要控制写入：

1. 冻结新环境入口和后台写入，保留日志、事务位置及差异证据。
2. 确认权威数据源，处理新环境已确认的业务写入。
3. 验证旧环境配置、权限、数据和外部连接。
4. 恢复旧环境入口，确认新环境不再处理生产请求。
5. 按顺序恢复消费者和定时任务，防止双重执行。
6. 验证核心业务，记录回滚后的数据边界和未完成事项。

若数据回同步失败、旧环境无法通过业务验证，或无法排除双写，不应继续机械执行切流，而应保持受控维护状态并升级处置。

切换完成后的观察窗口可按业务节奏安排：前30至60分钟保持集中值守，随后覆盖一个完整业务高峰和关键定时任务周期；例如继续观察24至72小时，存在周任务的业务还应覆盖对应周期。旧环境和备份的保留期应同时满足这一观察窗口及企业的数据恢复要求。

只有在核心业务、后台任务、监控告警和新环境备份恢复都通过验证后，才退出可回滚状态。观察期间一旦达到预设的错误率、延迟或一致性触发条件，停止放量；涉及数据安全时先冻结写入，再按已经演练的路径恢复服务。