Обновление ОС на VDS закрывает известные уязвимости, но неудачное обновление на удалённом сервере может оставить вас без доступа. Разница между apt upgrade и do-release-upgrade — это разница между рутинной операцией и событием, которое стоит планировать заранее.
Обновление пакетов (Ubuntu/Debian)
# Обновить список пакетов из репозиториев
apt update
# Обновить все пакеты без удаления существующих
apt upgrade -y
# Обновить с заменой конфигов и возможным удалением пакетов
apt full-upgrade -y
# Очистить пакеты, которые больше не нужны как зависимости
apt autoremove -yРазница между upgrade и full-upgrade принципиальна: первый никогда не удаляет установленные пакеты, даже если для новой версии зависимости требуют иначе, и в таком случае просто не обновит пакет с конфликтом. Второй разрешает удаление ради разрешения зависимостей — поэтому его нужно запускать осознанно, глядя на список действий перед подтверждением.
Обновление дистрибутива
# Ubuntu 20.04 → 22.04, самая свежая LTS на момент перехода
do-release-upgrade
# Debian: аккуратный путь через смену источников
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
apt update && apt full-upgrade -yВ Ubuntu do-release-upgrade сам проверяет доступность новой LTS, скачивает пакеты и переносит конфиги известных сервисов. В Debian отдельной утилиты нет: переход на новый релиз — это замена кодового имени в источниках пакетов и полный full-upgrade, поэтому риск конфликтов конфигурации выше и проверять их нужно вручную.
Разбор типичных ошибок при обновлении
Ошибка E: Unable to correct problems, you have held broken packages означает, что часть пакетов зафиксирована (apt-mark hold) или конфликтует по версиям зависимостей. Проверьте список зафиксированных пакетов командой apt-mark showhold и снимите фиксацию перед обновлением, если она не нужна намеренно.
dpkg: dependency problems prevent configuration of package-name:
package-name depends on libssl3 (>= 3.0.0); however:
Version of libssl3 on system is 1.1.1.Такая ошибка чаще всего возникает при смешивании репозиториев разных релизов — например, если в sources.list остались строки от старой версии дистрибутива рядом с новыми. Решение — проверить /etc/apt/sources.list и файлы в /etc/apt/sources.list.d/ на предмет старого кодового имени релиза.
Прерванное соединение SSH во время do-release-upgrade раньше означало обрыв процесса обновления. Начиная с современных версий утилита сама поднимает резервный SSH-демон на альтернативном порту (обычно 1022) на время апгрейда — но полагаться на это не стоит: безопаснее выполнять обновление в screen или tmux, чтобы сессия пережила разрыв канала.
Сравнение способов обновления
| Способ | Что меняет | Риск простоя | Когда применять |
|---|---|---|---|
| apt upgrade | Минорные версии пакетов | Низкий | Регулярно, раз в 1–2 недели |
| apt full-upgrade | Пакеты с изменением зависимостей | Средний | После security-бюллетеня, перед крупным релизом |
| do-release-upgrade | Целый дистрибутив (Ubuntu) | Высокий | Переход на новую LTS раз в 1–2 года |
| Смена кодового имени (Debian) | Целый дистрибутив (Debian) | Высокий | Переход на новый стабильный релиз |
Важно перед обновлением
- Создайте снимок (snapshot) сервера в панели управления — это единственный быстрый путь назад, если обновление дистрибутива сломает загрузку.
- Обновляйте в период низкой нагрузки и предупредите пользователей сервиса заранее, если апгрейд дистрибутива — не рутинный
apt upgrade. - Проверьте версии критичных сервисов (PHP, MySQL, Nginx) до обновления — мажорный апгрейд ОС часто тянет за собой мажорный апгрейд и этих пакетов, а это отдельная миграция конфигов.
- После обновления перезагрузите сервер и проверьте, что все нужные сервисы стартуют автоматически, а не только текущий, не перезапущенный процесс.
Когда обновление лучше отложить или делать иначе
Мажорный апгрейд дистрибутива не стоит запускать вслепую в следующих случаях:
- Сервер держит продакшн-нагрузку без резервного узла — лучше сначала прогнать апгрейд на клоне (снимке, поднятом как отдельный VDS), а уже потом на боевом.
- Используются пакеты из сторонних PPA или репозиториев, собранные под конкретную версию дистрибутива, — после апгрейда они могут перестать разрешать зависимости или просто исчезнуть из списка доступных.
- Нет актуального бэкапа базы данных — миграция MySQL или PostgreSQL на новую мажорную версию в рамках апгрейда ОС может потребовать отдельного экспорта и импорта дампа.
Проверка результата
- Проверьте версию релиза:
lsb_release -aилиcat /etc/os-releaseдолжны показывать ожидаемую версию. - Проверьте статус ключевых сервисов:
systemctl status nginx mysql php8.2-fpm— все должны бытьactive (running), а не просто установлены. - Проверьте журнал ядра на ошибки после перезагрузки:
dmesg | grep -i error. - Откройте сайт или приложение снаружи и убедитесь, что оно отвечает так же, как до обновления, — версия PHP или MySQL могла измениться и повлиять на поведение кода.
Если обновление затрагивает ядро и после перезагрузки хочется убедиться, что загрузилось именно новое ядро, — команда uname -r покажет версию, а детали пересборки модулей разобраны в статье про обновление ядра Linux. Firewall после смены релиза стоит перепроверить отдельно — иногда пакет UFW обновляется с изменением дефолтов, это описано в статье про настройку UFW на VDS.
Частые вопросы
Обязательна ли перезагрузка после каждого apt upgrade или только когда обновилось ядро?
После обычного обновления пакетов перезагрузка не обязательна — большинству сервисов достаточно перезапустить собственный процесс, и пакетный менеджер нередко делает это сам. Перезагрузка становится нужной, только когда меняется ядро, systemd или некоторые базовые библиотеки: они остаются загруженными в память до перезапуска всей системы, а не отдельного сервиса.
Если full-upgrade хочет удалить пакет, который на самом деле ещё нужен, что безопаснее сделать вместо простого подтверждения?
Остановитесь и прочитайте список запланированных удалений, прежде чем что-либо подтверждать, а потом проверьте, не закреплён ли пакет и от чего зависит замена. Часто безопаснее напрямую разрешить конфликт зависимостей или отложить именно этот шаг обновления, чем позволить инструменту удалить пакет, на который сервер по-прежнему опирается в повседневной работе.
Откатывает ли восстановление снимка сервера, снятого до крупного обновления, и изменения в базе данных, сделанные позже?
Да, полный снимок сервера фиксирует состояние всего диска в тот момент, включая базы данных, поэтому восстановление откатывает всё разом, а не только файлы операционной системы. Любые данные, записанные после снимка, включая новые строки в базе, исчезают вместе с откатом обновления — именно поэтому для всего, что пишется в это окно, важен отдельный, более свежий бэкап базы.
Означает ли регулярное обновление пакетов, что патчи безопасности применяются сами собой, или запускать обновление вручную всё равно нужно каждый раз?
Регулярные обновления пакетов всё равно нужно запускать осознанно, а не ждать, что всё произойдёт само собой — ничего не патчит сервер автоматически только потому, что новая версия появилась в репозитории. Именно превращение этого в рутинную задачу по предсказуемому расписанию закрывает известные уязвимости вовремя, ведь обновление, лежащее неприменённым в репозитории, вообще не защищает работающий сервер.