CentOS 停止维护了，公司的服务器该怎么办？

不少公司的服务器跑的是 CentOS——Web、数据库、ERP、邮件、内网应用都可能架在它上面。忽然有一天，你发现 yum update 拉不到更新了，或者安全扫描开始报"系统已停止支持"，再或者想装个新软件，软件源已经失效。这时候才意识到：CentOS 已经停止维护了，服务器该往哪迁？

先说结论：CentOS 停更是事实，但不是世界末日——绝大多数场景可以平滑迁移到兼容系统，关键是别直接原地升级、别不备份就动手、别没有回滚预案。生产服务器迁移，业务不中断、数据不丢失是能做到的。

一、先把事实搞清楚：CentOS 到底停到哪了

很多人对"CentOS 停更"的理解是模糊的，先把时间线说清：

CentOS 8：早在 2021 年 12 月 31 日就结束了维护（EOL）。红帽在 2020 年底宣布把 CentOS 的重心转向 CentOS Stream，CentOS Linux 8 由此提前退役。

CentOS 7：2024 年 6 月 30 日正式 EOL，停止提供维护更新。

"停止维护"意味着什么？不再有安全补丁和缺陷修复。对新爆出的系统漏洞、openssl 这类基础组件的高危漏洞，官方不会再发补丁。对一台暴露在公网、或跑着业务数据的服务器，这等于把门敞着——不是"还能不能用"的问题，是"安不安全、合不合规"的问题。

需要澄清一点：停更不等于马上不能用。已有的 CentOS 系统不会某天突然开不了机，短期内业务照跑。如果这台机器是纯内网、不碰等保和客户审计、也没有新功能新硬件的需求，短期内继续用着、把迁移排进计划，是一个现实的选择。

但要注意：不更新不代表就没事。没有新补丁，意味着新爆出的漏洞在这台机器上永久裸奔，而"内网"并不是保险箱——U 盘、一台被攻破的边缘设备、一个弱口令的远程入口，都可能把风险带进来。更要留个心眼：停更后连软件源都会失效（下一节细说），哪天急着装个排障小工具，可能连包都拉不到；真到出事那天，救援本身也会被拖累。所以可以暂不迁，但要知道自己在承担什么、把迁移排进日程。

二、停更后最先撞上的实际问题：yum / dnf 装不了软件

很多公司第一次真切感到"停更"，不是收到通知，而是某天想装个软件，yum install 直接报错，拉不到任何包：

https://mirror.centos.org/centos/7/os/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
Error: Cannot find a valid baseurl for repo: base/7/x86_64

原因是：CentOS 的镜像服务不再为已 EOL 的版本返回可用镜像，这些旧版本被整体移进了官方的 vault 历史库——包都还在，只是不在"常用目录"了。对日常使用的直接影响有两个：

一是想装新软件装不上（包括排障工具、依赖组件）；二是 yum update 拉不到东西——这未必是坏事（本来也确实没有新补丁可拉），但它以"报错"的形式出现，很多人会被吓一跳；也有人反过来误以为"系统坏了"。

解法：把源改到 vault（以阿里云镜像为例）

国内阿里云等镜像站为停更的 CentOS 保留了 vault 目录，实测在线（2026 年 10 月核验：CentOS 7.9.2009 的 os / updates / extras、CentOS 8.5.2111 的 BaseOS / AppStream 均可访问）。以 CentOS 7 为例，分三步走：

第一步，备份原配置。把 /etc/yum.repos.d/ 下的 CentOS-*.repo 统一移到备份目录，别直接删——留着回退用。

第二步，写入 vault 源。新建 /etc/yum.repos.d/CentOS-vault.repo，配 base、updates、extras 三个源，地址分别指向 https://mirrors.aliyun.com/centos-vault/7.9.2009/os/、https://mirrors.aliyun.com/centos-vault/7.9.2009/updates/、https://mirrors.aliyun.com/centos-vault/7.9.2009/extras/（架构目录用 $basearch 变量），GPG 校验沿用原密钥 RPM-GPG-KEY-CentOS-7。

第三步，清缓存、重建索引。执行 yum clean all && yum makecache，索引能正常刷新，就能继续装软件了。

CentOS 8 同理，注意两点：包管理用 dnf；且 BaseOS 和 AppStream 两个源都要配，少一个就有一半包装不上。

但要把性质说清楚：改 vault 源是兜底，不是解药。它能让存量机器继续装软件、把该打的最后一批补丁补上，让"跑不动"的日子来得晚一些；它不会变出新补丁——EOL 之后新爆出的漏洞，依然没人修。所以它是迁移前的"止血"，不是"不用迁了"的理由。真到了要改源这一步，通常正是该把迁移正式排上日程的信号。

三、迁去哪儿：四个常见去向

迁移目标怎么选，取决于你现在的应用栈和团队熟悉度。常见四个去向：

Rocky Linux——与 RHEL 一比一兼容、二进制兼容，适合想"无感平移"、应用和配置改动最小的场景；注意点是社区驱动，需盯版本发布节奏。AlmaLinux——同样二进制兼容 RHEL，是另一个主流选择，注意点与 Rocky 相同。RHEL（红帽官方）——本尊，适合有预算、要官方支持与认证的场景，需要订阅费。Ubuntu LTS / Debian——不同血脉（deb 系），适合应用能跟着重建、愿意换生态的团队，软件包和配置差异大、改动多。

对绝大多数"只想把 CentOS 平稳换掉、应用不动"的厂子，Rocky Linux 或 AlmaLinux 是改动最小的一档——它们和 RHEL 二进制兼容，你原来用 yum 装的 Nginx、MySQL、PostgreSQL、Docker，以及自研业务系统，基本能原样搬过去，不用重写。要官方背书和订阅支持，就上 RHEL；应用愿意借机重构、团队熟 deb 系，再考虑 Ubuntu / Debian。

一个必须挡住的误区：不要升级到 CentOS Stream

聊迁移时有个坑必须单独点出来：别把 CentOS Stream 当成 CentOS 的"升级路径"。

CentOS Stream 不是 CentOS Linux 的新版本，它是红帽 RHEL 的上游滚动预览版——变更先进 Stream 验证，再流向下游的 RHEL。这带来两个生产环境扛不动的特性：

一是没有稳定的支持周期，滚动更新，随时可能引入未经充分验证的变更；二是它天然是"变化"的，而生产服务器要的是"稳"。

2020 年底红帽宣布 CentOS 战略转向后，不少文章和教程把"CentOS 8 → CentOS Stream 8"说成继续获得更新的正道，误导了大量用户——对生产服务器，这是条错路。想要长期稳定，就迁 Rocky Linux / AlmaLinux / RHEL；只有想提前验证 RHEL 新特性的开发、测试环境，才适合碰 Stream。如果已经误升上去了，回退的路还是那六步：备份、新装目标、迁应用数据、并行验证、切换、旧机兜底。

四、迁移的核心：业务不断、数据不丢、能回滚

生产服务器迁移，最怕"迁到一半业务停了、数据丢了、回不去了"。一套稳妥的路数是这样的：

1. 先备份，再谈迁。不管迁移方案多熟，动手前先把现有系统整个备份下来（系统盘 + 数据 + 配置），留一份能随时回退的兜底盘。这是铁律，没有备份不动手。

2. 搭目标系统，别原地升级。新装一台 Rocky / AlmaLinux，而不是在老 CentOS 上"升级转换"。原地升级看着快，实则最容易把现场搞乱、出了岔子回不去。

3. 装应用、迁数据，逐项对。按清单把应用服务、数据库、配置文件、定时任务一项项在新环境重建 / 迁移，每迁一项验证一项。

4. 并行验证。新环境搭好后，和旧系统并行跑一段，用真实流量 / 真实数据核对，确认业务在新系统上正常，再切。

5. 选窗口切换。挑业务低峰切流量 / 换入口，切换后密切盯一段时间。

6. 旧机兜底，别急着下线。切完旧系统先别拆，保留成回滚预案——新环境真出问题，能立刻切回旧机，把停机压到最短。

这套路子的核心就一句：每一步都有退路，业务不中断、数据不丢、随时能回滚。迁移不是"赌一把换成功"，是"有备份、有并行、有回滚地换"。

五、几个最常见的坑

直接原地升级转换。图快，却最容易把现有环境搞乱、出了岔子回不去。生产环境别这么干。

不备份就动手。迁移前不备份，等于没系安全带就上高速。

忽视软件源和依赖。CentOS 的 yum 源、epel、第三方源在停更后可能失效或漂移，迁移时要逐项确认新系统的源和依赖版本。

没有回滚预案。只想着"迁成功怎么办"，没想"迁失败怎么退"，一旦卡住只能看着业务停。

赶在半夜硬切、没并行验证。不并行跑一段就切流量，等于拿生产业务当试验田。

把 CentOS Stream 当"升级路径"。Stream 是 RHEL 的上游滚动预览版，没有稳定支持周期，生产环境别拿它当 CentOS 的续版（详见第三节的误区说明）。

以为改了 vault 源就等于"有补丁了"。vault 源只是让存量机器还能装软件、补上最后一批旧补丁，EOL 后新出的漏洞依然没人修。源能装 ≠ 安全了。

六、这事可以交给专业的人做

CentOS 迁移是典型的一次性短期工程——评估、搭目标、迁数据、并行验证、切换、兜底，一个项目有明确的起点和终点。但它吃经验：哪些源会失效、哪些配置藏着坑、切换窗口怎么选，踩过的和没踩过的，差别就在业务停不停。

我们摩杰斯自己的核心业务系统（生产管理软件 PMS9、PMS5）从第一天起就整台跑在 Linux 上，CentOS、Rocky、RedHat、Ubuntu、Debian 这些系统的安装、配置、迁移、故障处理，十四年里在几百家制造客户的现场一台台做过。迁 CentOS 这种活，我们一贯按"先备份、搭目标、并行验证、旧机兜底"的路子来——每一步都有退路，业务不中断、数据不丢。

想了解生产系统为什么值得建在 Linux 上，可以看《系统为什么从第一天就跑在 Linux 上》；迁移后系统越跑越慢怎么查，可以看《服务器负载飙高按什么顺序查》；担心半夜再出状况，可以看《产线系统半夜宕机怎么分钟级拉起》。Linux 服务器的应急处理、CentOS 迁移、安全加固、备份搭建这类短期项目的服务范围，见Linux 服务器服务介绍。

结语

CentOS 停更是既定事实，但对绝大多数跑在它上面的业务，这不是"塌方"，是"该换地基了"。迁去 Rocky / AlmaLinux 这类兼容系统，按"先备份、搭目标、并行验证、旧机兜底"的路子走，业务不中断、数据不丢、随时能回滚是能做到的。真正危险的从来不是迁移本身，而是不备份就动手、原地硬升级、误升 CentOS Stream、没有回滚预案。