Устаревшая ОС на сервере: обновлять или переносить

Если на сервере старая операционная система, сначала установите её версию, фактическое покрытие обновлениями и зависимости приложения. Номер выпуска сам по себе не описывает всю ситуацию: стандартный период может закончиться, а дополнительные условия поддержки требуют отдельной проверки. Решение об обновлении на месте или переносе принимают после этой инвентаризации, а не по обещанию «запустим одну команду, и всё станет новым».

Ниже — порядок подготовки работы со стороны владельца проекта. Отдельные факты показаны на примере Ubuntu Server по официальной документации, проверенной в октябре 2026 года. Это не универсальная инструкция для всех ОС и не список команд для рабочего сервера. Сроки и допустимый маршрут проверяют заново для конкретного выпуска, а действия выполняют специалисты в согласованном окне.

Что именно устарело

Разделите операционную систему, язык или среду выполнения приложения, базу данных и сам код проекта. Поддерживаемая ОС не доказывает актуальность каждого из этих компонентов. Обратная ситуация тоже возможна: приложение обновили, но окружение осталось прежним. Одна строка «сервер актуален» не объясняет, какой слой проверен и что ещё требует решения.

Запишите источник установленных компонентов. Пакет из стандартного репозитория, сторонний источник и файл, установленный вручную, могут иметь разные пути обновления. Не определяйте возможность перехода только по названию программы. Команде нужно знать фактическую версию, способ установки и зависимость рабочих сценариев от неё. Непонятный компонент сначала исследуют, а не удаляют ради чистого списка.

Если проблема относится только к языку сайта, есть отдельный материал об устаревшем PHP на хостинге. Здесь речь о более широком изменении окружения. Не подменяйте перенос всего сервера обновлением одной программы и не обещайте исправить несовместимость приложения только новой версией ОС.

Проверьте покрытие, а не только название LTS

Официальная таблица Ubuntu различает стандартное и расширенное сопровождение. Например, для 20.04 LTS стандартное обслуживание указано до мая 2025 года, а для 22.04 LTS — до мая 2027 года. Наличие на странице других сроков не доказывает, что нужное дополнительное покрытие подключено именно у вашей машины и распространяется на интересующий компонент.

Попросите специалиста подтвердить состояние реальной системы и применимые условия. Не делайте вывод «все обновления закончились» или «всё защищено ещё несколько лет» по одной колонке таблицы. В записи должны быть выпуск, вид покрытия, проверенный компонент и открытые вопросы. Это позволяет выбрать приоритет работы без ложного успокоения и без неподтверждённой аварийной срочности.

Проверка покрытия не заменяет анализ приложения и восстановление доступа к сопровождению. Даже если для части окружения есть приемлемый временный вариант, назначьте ответственного и дальнейший план. Не превращайте промежуточное решение в бессрочное объяснение, почему никто больше не знает состав сервера и не проверяет возможность его восстановления.

Два маршрута перехода имеют разные ограничения

Первый вариант — изменение установленной системы. Второй — подготовка нового окружения и перенос приложения с данными. Нет общего победителя без сведений о проекте. Для небольшого воспроизводимого сервиса новый стенд может быть понятным способом проверки, а сложное окружение требует отдельной оценки каждого маршрута. Нельзя обещать одинаковую трудоёмкость всем серверам.

В руководстве Ubuntu для перехода между LTS описан последовательный маршрут, а не произвольный скачок через несколько выпусков. Поэтому обещание обновить сильно отставшую систему сразу до выбранной версии требует объяснения метода. Новая установка и обновление существующей системы являются разными действиями, даже если в конце отображается одинаковый номер ОС.

Составьте карту зависимостей приложения

В перечень включите не только веб-страницу. На сервере могут находиться обработчики очереди, плановые задания, почтовый транспорт, файловое хранилище и интеграции с внешними системами. Для каждого компонента определите назначение, способ запуска и признаки успешной работы. Не копируйте неизвестные службы на новый стенд только по привычке, но и не объявляйте их ненужными без разбора.

Условия приложения проверяют на целевом окружении. Если проект зависит от конкретной среды выполнения или стороннего пакета, наличие свежего установочного образа не решает несовместимость автоматически. Попросите разработчика назвать поддерживаемый состав и испытать его на копии. Не устанавливайте случайный старый пакет из неподтверждённого источника ради исчезновения ошибки первого запуска: так можно получить новое окружение со старой непонятной зависимостью.

Резервная копия должна соответствовать задаче возврата

Определите, какие данные и настройки нужны для восстановления сервиса. Архив сайта без базы или база без загруженных файлов могут быть неполным комплектом. Отдельно установите, где хранятся необходимые секреты и кто имеет к ним доступ. Их не включают в публичный отчёт или открытый тикет. Для учебной проверки используйте безопасные реквизиты вместо реальных платёжных и отправляющих подключений.

Проверьте восстановление выбранного комплекта в изолированной среде. Результатом должен быть понятный рабочий сценарий, а не только отсутствие ошибки распаковки. Если часть данных намеренно исключена, запишите последствия и способ получить недостающее. Официальное руководство Ubuntu подчёркивает необходимость резервного сохранения перед обновлением; конкретный состав и проверку вашего проекта всё равно нужно определить отдельно.

Не теряйте изменения между копией и переключением

За время подготовки работающий сервис может принять новые данные. Поэтому нужны точка исходной копии, способ учёта последующих изменений и момент окончательной сверки. Не объявляйте тестовую базу окончательной только потому, что приложение с ней запускается. Состояние, достаточное для проверки интерфейса, не обязательно подходит для рабочего переключения.

В учебном примере копия сделана до двух новых операций. Команда должна определить их судьбу до перехода: они уже перенесены, будут учтены отдельно либо попадут в предусмотренный заключительный перенос. Конкретный механизм зависит от системы. Универсальная ручная правка пары строк здесь не предлагается. Важно, чтобы план давал объяснимое состояние данных и возможность проверить, что нужные события не исчезли и не выполнились повторно.

Сторонние источники требуют отдельного решения

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

Для каждого такого компонента нужен выбор: поддерживаемый путь обновления, проверенная замена или отдельное решение с владельцем проекта. Запишите основание и результат испытания. Список пакетов полезен, но сам по себе не показывает, на какой рабочий сценарий влияет конкретный модуль. Поэтому обсуждение источников ведут вместе с картой приложения, а не отдельно от команды, которая отвечает за его работу.

Проверьте сценарии, а не только старт процесса

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

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

Назначьте окно работы и условия остановки

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

Проверьте запас памяти и диска, доступность предусмотренного управления и влияние параллельных работ. Если на машине несколько проектов, их владельцы должны понимать границы изменения. Не запускайте дополнительные тяжёлые проверки в тот же момент без необходимости. После каждого существенного шага сохраняйте результат, чтобы следующий специалист видел фактическую стадию, а не пытался определить её по давнему сообщению «обновляемся».

Закройте работу по фактическому результату

После перехода повторите согласованные сценарии в рабочем окружении, сохраняя безопасный способ проверки. Зафиксируйте версии, источники компонентов, точку данных и оставшиеся ограничения. Не объявляйте весь сервер исправленным, если проверено только приложение, и не закрывайте несовместимость приложения отметкой о новой ОС. Итог должен показывать, что действительно изменено и подтверждено.

Старое окружение удаляют или выводят из работы по принятому плану после необходимых сверок. Сам факт сохранённой машины не заменяет поддерживаемую резервную копию, а случайно забытая активная очередь может продолжать нежелательную работу. Проверьте её назначение, доступы и состояние отдельно. Полезный результат обслуживания — не новый номер в отчёте, а воспроизводимое окружение с понятным способом сопровождения и восстановления.