Переезд с Ubuntu 20.04: план для тех, кто затянул

MAATRIX

Если вы читаете эту статью — скорее всего, у вас есть сервер на Ubuntu 20.04, который «просто работает», и вы точно не помните, что на нём вообще накручено за эти годы. Стандартный цикл поддержки этой версии подошёл к концу или вот-вот закончится, вы это понимаете, но откладываете: страшно, что после обновления что-то отвалится, а разбираться будет некому. Это нормальный страх, и у него есть решение — не «обновлять на месте и надеяться», а пройти по конкретному плану, который снижает риск на каждом шаге.

Почему откладывать стало опаснее, чем действовать

Окончание стандартного цикла поддержки версии (то, что называют End of Life) не означает, что сервер в одну секунду перестанет работать. Он продолжит крутиться ровно так же, как крутился вчера. Проблема в другом: перестают выходить обновления безопасности для пакетов из основных репозиториев. Новые уязвимости в ядре, OpenSSL, sudo, пакетах веб-серверов и прочем системном ПО продолжают находить — просто патчей для вашей версии больше нет (либо они выходят платно через расширенную поддержку, если вендор её предлагает, и это отдельная договорённость, а не то, что происходит само собой).

Дальше работает эффект снежного кома. Ubuntu Pro / ESM может закрыть часть дыр в ядре и базовых библиотеках, но не покрывает весь стек: PHP, Node.js, базы данных, докер-образы на устаревших тегах — всё это продолжает стареть без присмотра. Чем дольше сервер живёт без обновлений, тем больше расхождение между тем, что установлено, и тем, что считается актуальным и поддерживаемым. А значит — тем сложнее и рискованнее будет апгрейд, если отложить его ещё на полгода-год. Технический долг не стоит на месте, он растёт.

Второй момент, который стоит проговорить честно: если на сервере есть что-то, торчащее наружу (веб-приложение, панель администратора, API, VPN) — риск не абстрактный. Автоматизированное сканирование интернета на уязвимые версии сервисов происходит постоянно, и «нас никто не найдёт» — это не стратегия безопасности, а надежда.

Шаг 1: инвентаризация — что вообще стоит на сервере

Прежде чем что-то трогать, нужно честно ответить на вопрос «что здесь работает». На сервере, который годами не трогали руками, почти гарантированно накопилось забытое ПО: тестовый сервис, который забыли выключить, старая версия чего-то, поднятая «на попробовать», cron-задача, о которой все забыли.

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

dpkg -l > /root/inventory-packages.txt
dpkg -l | wc -l

Список активных и работающих служб — то, что реально запущено прямо сейчас:

systemctl list-units --type=service --state=running > /root/inventory-services-running.txt
systemctl list-unit-files --type=service --state=enabled > /root/inventory-services-enabled.txt

Что слушает сеть — часто самый информативный список, потому что показывает, что реально доступно снаружи:

ss -tulpn > /root/inventory-listening.txt

Полезно также посмотреть на docker, если он используется — контейнеры любят жить своей жизнью отдельно от systemd:

docker ps -a
docker images

Иcron/systemd-таймеры — забытые задачи резервного копирования, ротации логов, синхронизации с чем-то внешним:

crontab -l
for u in $(cut -f1 -d: /etc/passwd); do crontab -u "$u" -l 2>/dev/null && echo "^-- $u"; done
systemctl list-timers --all

Сведите это всё в один документ (можно прямо в текстовый файл рядом) — этот список станет вашей картой при разборе конфигурации на новом сервере. Не пытайтесь запомнить — записывайте.

Шаг 2: почему не `do-release-upgrade`

Соблазн большой: команда do-release-upgrade существует именно для перехода между версиями Ubuntu, и на свежем, аккуратно обслуживаемом сервере она часто отрабатывает предсказуемо. Но если сервер несколько лет не обновлялся стандартным apt upgrade, накопил сторонние PPA-репозитории, ручные правки конфигов, версии пакетов «застрявшие» из-за конфликтов зависимостей — ситуация другая.

Что конкретно может пойти не так при апгрейде на месте старой запущенной системы:

• Конфликты зависимостей. Пакет из стороннего PPA, добавленного пять лет назад, может не иметь сборки под новый релиз — апгрейд встанет на середине с частично настроенной системой.
• Смена дефолтных версий. PHP, Python, Node.js между релизами Ubuntu меняют версии по умолчанию — приложение, написанное под старый интерпретатор, может не запуститься после апгрейда без правок кода.
• Изменение формата конфигов. Некоторые демоны (systemd, nginx, PHP-FPM, базы данных) между мажорными версиями меняют синтаксис или расположение конфигурационных файлов — старый конфиг может быть частично или полностью несовместим.
• Долгий downtime без отката. Апгрейд идёт на «живом» продакшн-сервере — если что-то ломается на середине, откатиться некуда, а сервис в это время недоступен.
• Накопленный мусор. Забытые пакеты из инвентаризации на шаге 1 могут заблокировать апгрейд или обновиться до версии, ломающей что-то, о существовании чего вы уже не помните.

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

Шаг 3: полный бэкап данных до любых действий

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

Минимальный набор для бэкапа перед миграцией:

# Базы данных — дамп, а не просто копия файлов
mysqldump --all-databases --single-transaction > /backup/all-databases-$(date +%F).sql
# или для PostgreSQL
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

# Список пакетов и служб из шага 1 — тоже часть бэкапа
cp /root/inventory-*.txt /backup/

Бэкап обязательно должен уехать за пределы самого сервера — если он лежит на том же диске, при серьёзной проблеме вы потеряете и оригинал, и копию одновременно. Подробно про то, как выстроить автоматические бэкапы правильно, разобрано в статье про автоматические бэкапы на Ubuntu 24.04 с нуля — те же принципы применимы и здесь, только в разовом, а не автоматическом режиме.

После снятия бэкапа — проверьте его. Разверните дамп базы в тестовую БД, распакуйте архив в отдельную папку и сверьте, что файлы на месте и не битые. Бэкап, который ни разу не проверяли на восстановление, для целей миграции считайте несуществующим.

Шаг 4: новый сервер и пересборка конфигурации с нуля

Разверните новый VPS на актуальной LTS-версии Ubuntu. Дальше — ключевой момент, который часто делают неправильно: не копируйте конфиги со старого сервера вслепую. Используйте старый сервер как справочник — «что должно получиться в итоге», а не как источник файлов для прямого копирования.

Причина проста: между версиями Ubuntu и версиями пакетов внутри неё меняется формат конфигов. Например:

• В nginx между версиями менялись рекомендуемые директивы SSL/TLS — старый конфиг с устаревшими параметрами шифрования может работать, но с предупреждениями или сниженной безопасностью на новом сервере.
• PHP-FPM пул-конфиги (www.conf) между версиями PHP имеют разные пути к сокетам по умолчанию — слепое копирование ломает связку nginx + PHP-FPM.
• systemd unit-файлы для кастомных служб могут ссылаться на пути или пользователей, которые на новом сервере ещё не созданы.

Правильный порядок: разверните нужные сервисы на новом сервере через штатную установку (по официальным гайдам для актуальной версии, включая настройки для вашего дистрибутива), затем сверяйте параметры со старым конфигом — какие директивы были кастомизированы, какие лимиты выставлены, какие модули подключены — и переносите только то, что реально нужно, в новом синтаксисе. Если у вас типовой стек (веб-сервер, PHP, база данных), можно опереться на пошаговые гайды установки под актуальную LTS — например, установка веб-сервера LEMP на Ubuntu 24.04 с нуля или установка LAMP на Ubuntu 24.04 с нуля — и уже поверх накладывать специфику своего проекта.

То же самое касается firewall, SSH-доступа и прочей базовой обвязки — их разумнее настроить заново по актуальным гайдам, а не переносить старые правила механически: настройка файервола на Ubuntu 24.04 с нуля и подключение по SSH-ключу на Ubuntu 24.04 с нуля.

Данные — базы, файлы пользователей, медиа — переносятся напрямую (это не конфиги, формат которых мог смениться):

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

# Перенос файлов приложения (rsync экономит трафик и время при повторных запусках)
rsync -avz --progress /var/www/ user@new-server:/var/www/

Шаг 5: параллельное тестирование перед переключением

Не выключайте старый сервер, пока не убедились, что новый работает полноценно. Правильная последовательность:

1. Новый сервер настроен, данные перенесены, сервисы запущены — но домен/DNS всё ещё указывает на старый сервер.
2. Тестируете новый сервер напрямую по IP или через временную запись в /etc/hosts на своей машине — проверяете, что сайт/приложение открывается, формы отправляются, база данных отвечает корректными данными.
3. Проверяете конкретно то, что чаще всего ломается при смене окружения: кодировки в базе данных, права доступа на файлы (особенно если переносили как root, а сервис работает от отдельного пользователя), пути в конфигах приложения, cron-задачи и таймеры из вашей инвентаризации на шаге 1 — все они должны быть воссозданы на новом сервере, а не потеряны.
4. Только после того, как всё проверено — переключаете DNS или прокси на новый сервер. TTL записей стоит заранее снизить за сутки-двое, чтобы переключение прошло быстро.
5. Старый сервер держите ещё какое-то время (неделю-две) в режиме «на паузе», не удаляя — как страховку на случай, если что-то всплывёт уже после переключения.

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

Что делать сразу после переезда

Как только новый сервер стал основным, задача не заканчивается — стоит закрыть несколько практических хвостов:

• Настроить автоматические бэкапы на новом сервере с нуля — старая схема бэкапов (если она вообще была) осталась на старом сервере.
• Пройтись по базовому чек-листу безопасности нового сервера, чтобы не унести на новую систему старые небезопасные привычки: чек-лист безопасности нового сервера и первый день на новом VPS: чек-лист.
• Задокументировать сам сервер — тот список пакетов и служб, что вы собрали на шаге 1, плюс что из этого реально перенесли, а что осознанно выбросили как ненужное. Это экономит недели работы при следующем переезде — а он случится, потому что через несколько лет актуальная сейчас LTS тоже подойдёт к концу поддержки.
• Удалить старый сервер только когда полностью уверены, что он больше не нужен — не раньше.

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