Переезд с CentOS 7, который давно без поддержки: план работ по шагам

MAATRIX

Если на вашем сервере до сих пор крутится CentOS 7 — вы не одни. Дистрибутив был настолько стабильным и предсказуемым, что тысячи серверов работают на нём годами без единого повода вмешаться. Проблема в том, что стандартный жизненный цикл CentOS 7 закончился ещё в середине 2024 года, и с тех пор система не получает обновлений безопасности из базовых репозиториев. Сервер продолжает работать так же, как вчера, — но каждый день без патчей увеличивает разрыв между тем, что установлено, и тем, что реально безопасно. Разберём по шагам, как переехать с CentOS 7 на новый сервер без хаоса и без потери данных.

Почему это не «когда-нибудь потом», а срочная задача

CentOS 7 достиг конца стандартной поддержки 30 июня 2024 года. Это значит, что для пакетов из базовых репозиториев (base, updates, extras) больше не выходят обновления — ни функциональные, ни, что важнее, обновления безопасности. Ядро, OpenSSL, glibc, sudo, systemd, SSH-демон — всё системное ПО, из которого состоит фундамент сервера, застыло на версиях 2024 года и раньше. Новые уязвимости в этих компонентах продолжают находить регулярно, просто патчей для CentOS 7 больше нет.

У Red Hat есть платная программа расширенной поддержки (Extended Life Cycle Support) для тех, кому нужно время на миграцию, но это отдельная коммерческая договорённость с ограниченным сроком действия, а не что-то происходящее автоматически. Если вы её не оформляли — обновлений у вас нет уже больше двух лет к моменту написания этой статьи.

Проверить, что перед вами именно CentOS 7 и на что он опирается:

cat /etc/centos-release
cat /etc/os-release
uname -r
rpm -q glibc systemd openssl

Второй момент — практический. CentOS как классический бесплатный клон RHEL больше не существует в прежнем виде: место занял CentOS Stream с другой философией жизненного цикла. Это значит, что переезд с CentOS 7 — это не «обновиться до CentOS 8», а осознанный выбор нового дистрибутива и полноценный перенос, а не патч поверх старого.

Шаг 1: инвентаризация — что именно держит вас на CentOS 7

Прежде чем куда-то переезжать, нужно честно понять, что стоит на сервере и, главное, что из этого специфично именно для CentOS 7 — то есть может повести себя иначе на новой системе.

Полный список установленных пакетов и их источник:

rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE} %{VENDOR}\n' | sort > /root/inventory-packages.txt
yum repolist all > /root/inventory-repos.txt

Отдельно выпишите репозитории, добавленные вручную — не только штатные base/updates, но и сторонние:

ls /etc/yum.repos.d/

На CentOS 7 почти всегда встречается EPEL и часто — Software Collections (SCL), которые устанавливают альтернативные версии Python, PHP, Ruby рядом со штатными, не мешая системным. Если приложение зависит от пакета вида rh-python38 или devtoolset, это отдельная зависимость, которую нужно будет пересобрать на новом сервере — сами каталоги /opt/rh/ при переносе файлов не заработают без переустановки SCL-репозитория и пакетов.

Проверьте, какие службы реально запущены и что слушает сеть:

systemctl list-units --type=service --state=running
ss -tulpn

Отдельно посмотрите на SELinux — на CentOS 7 он чаще всего включён по умолчанию (enforcing или permissive), и если для приложения когда-то настраивались собственные политики или контексты, это тоже часть инвентаризации:

getenforce
semanage fcontext -l | grep -v '^/opt\|^/usr\|^/var$' | head -50
semodule -l

И firewalld — правила, открытые порты, зоны:

firewall-cmd --list-all-zones

Отдельно проверьте версию Python, на которую завязаны системные утилиты и, возможно, часть вашей автоматизации — на CentOS 7 системный Python по умолчанию 2.x, и это один из самых частых источников проблем при переезде (подробнее — в шаге про совместимость). Все эти списки сведите в один документ: он станет вашей картой при настройке нового сервера и чек-листом «ничего не забыли».

Шаг 2: почему обновление на месте здесь не вариант

На CentOS 7 существовал официальный инструмент leapp для перехода на CentOS 8 (точнее — на актуальные на тот момент версии семейства RHEL 8). Но у него есть жёсткие ограничения, которые делают его непригодным для вашей ситуации сегодня:

• leapp умеет только один шаг вперёд — с 7-й версии на 8-ю той же линейки RHEL/CentOS/AlmaLinux. Перепрыгнуть сразу на актуальную мажорную версию (9-ю и выше) он не может — потребовался бы промежуточный апгрейд через 8-ю, с тем же риском на каждом шаге.
• CentOS 8 сам давно вне поддержки (его цикл закончился ещё раньше, в конце 2021 года), поэтому промежуточная остановка на нём бессмысленна — вы просто переедете с одной неподдерживаемой системы на другую.
• leapp не умеет менять дистрибутив. Если вы хотите переехать на AlmaLinux, Rocky Linux или тем более на Ubuntu/Debian — это не апгрейд, а смена системы, и штатных инструментов апгрейда на месте для такого перехода не существует в принципе.
• Даже там, где leapp формально применим, на сервере с накопленными за годы кастомными репозиториями, SCL-пакетами и правками конфигов он регулярно упирается в конфликты зависимостей и требует ручного разбора отчёта о блокерах перед стартом.

Итог простой: для CentOS 7 в 2026 году реалистичный путь — не апгрейд на месте, а перенос на новый сервер с актуальным дистрибутивом. Старый сервер при этом продолжает работать как есть, пока вы готовите новый, — это даёт путь назад на любом этапе, вплоть до момента переключения трафика.

Шаг 3: выбор целевого дистрибутива

CentOS 7 был RHEL-совместимым дистрибутивом, и первый естественный вопрос — оставаться ли в этом семействе.

Если ваше приложение или инфраструктура завязаны на RPM-пакеты, SELinux-политики, панели управления с RHEL-специфичной интеграцией или корпоративный софт, сертифицированный именно под RHEL/CentOS — логичный выбор AlmaLinux 9 (или Rocky Linux 9): это тот же уклад, что и раньше, только на актуальной поддерживаемой базе. Он бинарно совместим с RHEL и следует за его стабильным циклом, а не опережает его, как CentOS Stream — детальное сравнение вариантов есть в статье CentOS или AlmaLinux: что выбрать для сервера.

Если же привязки к RPM-экосистеме нет, а важнее свежесть пакетов и более широкая база гайдов в интернете — стоит рассмотреть Ubuntu LTS. Но учтите: это не просто смена дистрибутива, а смена всей парадигмы администрирования сервера, и переносить конфиги буквально не получится ни в одном из двух случаев — их придётся пересобирать заново под новую систему.

Шаг 4: полный бэкап и подготовка нового сервера

Прежде чем что-либо переносить — снимите полный бэкап старого сервера, причём не «на будущее», а с проверкой, что он реально восстанавливается.

# Дампы баз данных, а не просто копия файлов БД
mysqldump --all-databases --single-transaction > /backup/all-databases-$(date +%F).sql
# или
pg_dumpall > /backup/postgres-all-$(date +%F).sql

# Конфиги, вебданные, домашние директории
tar -czvf /backup/etc-$(date +%F).tar.gz /etc
tar -czvf /backup/var-www-$(date +%F).tar.gz /var/www
tar -czvf /backup/home-$(date +%F).tar.gz /home

# Списки из инвентаризации — тоже часть бэкапа
cp /root/inventory-*.txt /backup/

Бэкап должен уехать за пределы самого сервера — если он лежит на том же диске, при аварии вы рискуете потерять и оригинал, и копию разом.

Дальше — новый сервер. Разверните VPS на выбранном дистрибутиве и настройте его с нуля по актуальным гайдам, а не копированием конфигов со старого CentOS 7 — форматы за годы разошлись. Если выбор пал на AlmaLinux 9, порядок действий по базовой настройке, firewalld, SSH-доступу и типовому веб-стеку подробно расписан в статье первичная настройка и безопасность AlmaLinux 9 с нуля.

Ставьте нужные сервисы штатной установкой под новую систему, а старый конфиг используйте как справочник «что должно получиться в итоге»: какие директивы кастомизированы, какие лимиты и модули включены — и переносите только это, в новом синтаксисе. Данные при этом переносятся напрямую, без пересборки:

# Перенос дампа БД
scp /backup/all-databases-*.sql user@new-server:/tmp/
ssh user@new-server "mysql < /tmp/all-databases-*.sql"

# Перенос файлов приложения
rsync -avz --progress /var/www/ user@new-server:/var/www/

Общий таймлайн переезда — что делать за 1-2 недели, за пару дней и в день переключения — расписан подробнее в статье как составить план миграции на новый сервер; принципы применимы и к переезду с CentOS 7, поверх них накладывается специфика ниже.

Шаг 5: тестирование совместимости приложений — где чаще всего рвётся

Это ключевой шаг именно для CentOS 7, потому что разрыв в версиях компонентов между ним и актуальной системой — не косметический, а один из самых больших среди типовых миграций.

Python 2 → Python 3. Системный Python на CentOS 7 по умолчанию — ветки 2.x. Если у вас есть скрипты, cron-задачи или части приложения, написанные под Python 2 (даже неявно, через системные утилиты вроде старых версий yum), на новом сервере их нужно либо портировать под Python 3, либо явно ставить и вызывать нужную версию интерпретатора отдельно. Молча «сработает то же самое» здесь не будет — синтаксис и стандартная библиотека между ветками местами несовместимы.

PHP, Node.js и другие рантаймы. Штатные версии в базовых репозиториях CentOS 7 сильно устарели (например, PHP из base-репозитория — линейка 5.x), и если приложение писалось под них через SCL-пакеты, на новом сервере штатная версия из репозитория будет заметно новее. Проверьте код на устаревший синтаксис и функции, которые могли быть удалены или изменили поведение между мажорными версиями — это стоит сделать до переключения, а не после.

glibc и бинарная совместимость. Если на сервере есть скомпилированные вручную бинарники или проприетарное ПО без исходников, собранное под старую версию glibc, они могут не запуститься на новой системе с более новой библиотекой (или наоборот — потребовать более старую, которой уже нет). Проверьте зависимости бинарника заранее:

ldd /path/to/binary
file /path/to/binary

СУБД. Версии MySQL/MariaDB/PostgreSQL в базовых репозиториях CentOS 7 тоже сильно отстают от актуальных. Перед переносом дампа на новую версию СУБД проверьте список breaking changes между версиями — форматы дампов обычно переносятся штатно, но нюансы (устаревшие типы данных, изменившееся поведение по умолчанию, sql_mode) стоит проверить на тестовой базе, а не сразу на боевой.

SELinux-контексты и права. Если приложение зависело от специфичных SELinux-политик на старом сервере, на новом их нужно настраивать заново — контексты файлов не переносятся при простом копировании через rsync/scp и требуют восстановления:

restorecon -Rv /var/www

Тестируйте всё это на новом сервере до переключения трафика — через временную запись в /etc/hosts на своей машине или тестовый поддомен, не трогая DNS боевого домена. После переключения дополнительно пройдитесь по общему чек-листу — что именно проверять на новом сервере, разобрано в статье как проверить, что миграция прошла успешно.

Шаг 6: переключение, откат и жизнь после переезда

Переключайтесь только после того, как новый сервер полностью протестирован — параллельно со старым, который продолжает обслуживать трафик:

1. Снизьте TTL DNS-записей за сутки-двое до переключения — 300 секунд вместо стандартных 3600-86400.
2. Выполните финальную синхронизацию данных (дельта, а не полный перенос заново) и сверьте контрольные суммы или количество записей.
3. Переключите DNS или прокси на новый сервер.
4. Мониторьте логи и метрики первые час-два — ошибки 5xx, соединения с БД, работу cron-задач и фоновых служб из вашей инвентаризации.
5. Старый сервер на CentOS 7 держите ещё неделю-две в режиме «на паузе», не удаляя, — это ваш путь назад, если что-то всплывёт уже после переключения.

После стабилизации закройте практические хвосты: настройте резервное копирование на новом сервере с нуля (старая схема бэкапов, если она вообще была, осталась на CentOS 7), верните TTL к обычному значению, задокументируйте, что из инвентаризации шага 1 реально перенесли, а что осознанно выбросили. И только после этого — выводите из эксплуатации старый сервер.

Отдельно стоит сказать честно: если на сервере годами копился технический долг сверх того, что перечислено выше (самописные патчи ядра, древние версии специфичного корпоративного ПО без актуальных сборок), процесс может растянуться дольше типового переезда — закладывайте на это время в оценке, а не рассчитывайте на выходные.

Частые вопросы