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、沒有回滾預案。