Обновление Debian и Ubuntu на VPS: безопасный порядок действий

Регулярное обновление сервера закрывает известные уязвимости и исправляет ошибки, но без подготовки даже обычный запуск apt upgrade может закончиться недоступным SSH, переполненным диском или остановленным приложением. Ниже приведён безопасный порядок для Debian и Ubuntu на VPS. Он подходит для текущего стабильного выпуска Debian и поддерживаемых выпусков Ubuntu Server.

Обновление пакетов и обновление версии ОС — не одно и то же

Команды apt update и apt upgrade обновляют пакеты в пределах уже установленного выпуска. Переход с одной версии Debian на следующую или с одного выпуска Ubuntu на другой — отдельная операция. Для неё нужны официальные примечания к выпуску, полноценная резервная копия и отдельное окно обслуживания.

В обычной еженедельной процедуре мы обновляем индекс репозиториев, просматриваем список пакетов и устанавливаем доступные исправления. Не меняйте кодовое имя дистрибутива в файлах APT ради «быстрого обновления»: это уже переход между выпусками и он требует другого плана.

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

Сначала зафиксируйте текущее состояние. Команды не меняют систему:

cat /etc/os-release
uname -r
uptime
free -h
df -hT /
systemctl --failed
apt-mark showhold

Обратите внимание на четыре вещи:

• На корневом разделе должно оставаться достаточно места. Для небольшого VPS разумно иметь не менее 1–2 ГБ свободного пространства перед крупным обновлением.
• Не должно быть необъяснимых упавших служб.
• Пакеты в состоянии hold должны быть вам известны.
• Нужен доступ к консоли VPS в панели провайдера. Она спасёт, если после обновления перестанет работать сеть или SSH.

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

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

Для MariaDB перед файловой копией создайте логический дамп:

sudo mariadb-dump --all-databases \
  --single-transaction --routines --events --triggers \
  > /root/all-databases-before-upgrade.sql

Для PostgreSQL:

sudo -u postgres pg_dumpall \
  > /root/postgresql-before-upgrade.sql

После копирования дампов во внешнее хранилище ограничьте доступ к ним или удалите временные файлы: они могут содержать учётные данные и персональные данные.

Обновите индекс пакетов и изучите изменения

sudo apt update
apt list --upgradable

apt update ничего не устанавливает: он получает актуальные метаданные репозиториев. Если команда сообщает об ошибке подписи, недоступном репозитории или неправильном кодовом имени, не продолжайте обновление. Сначала устраните проблему с источником пакетов.

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

sudo apt -s upgrade
sudo apt -s full-upgrade

Ключ -s запускает симуляцию. Обычный upgrade консервативнее. full-upgrade умеет добавлять и удалять пакеты для разрешения зависимостей, поэтому его вывод нужно читать особенно внимательно.

Установите обновления

Для штатного обслуживания начните с:

sudo apt upgrade

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

sudo apt full-upgrade

Не добавляйте -y при первом обновлении незнакомого сервера. Интерактивный режим позволяет увидеть список изменений и запросы о конфигурационных файлах.

Что отвечать на вопрос о конфигурационном файле

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

• Для SSH, Nginx, PHP-FPM, базы данных и firewall чаще безопаснее сохранить действующий файл.
• Новый вариант можно изучить позже: пакет обычно сохраняет его рядом с расширением вроде .dpkg-dist.
• Не заменяйте рабочую конфигурацию вслепую, особенно при удалённом подключении.

Найдите оставленные варианты после обновления:

sudo find /etc -type f \( -name '*.dpkg-dist' -o -name '*.dpkg-old' \)

Проверьте службы и необходимость перезагрузки

systemctl --failed
sudo journalctl -p err -b --no-pager
test -f /var/run/reboot-required && cat /var/run/reboot-required

На Debian файл /var/run/reboot-required может отсутствовать даже при обновлении ядра, поэтому дополнительно сравните запущенное и установленное ядро:

uname -r
dpkg -l 'linux-image*' | awk '/^ii/{print $2, $3}'

Если обновлены ядро, libc, systemd или другие базовые компоненты, запланированная перезагрузка обычно безопаснее выборочного перезапуска множества служб.

Перезагрузка без потери контроля

До команды reboot убедитесь, что открыта консоль провайдера и конфигурация SSH проходит проверку:

sudo sshd -t
sudo systemctl status ssh --no-pager
sudo reboot

После возвращения сервера:

uptime
uname -r
systemctl --failed
ss -lntup
sudo journalctl -b -p warning --no-pager

Проверьте сайт или API не только локально, но и снаружи: DNS, TLS, HTTP-код и основные пользовательские действия.

Безопасная очистка старых пакетов

Сначала посмотрите, что будет удалено:

sudo apt -s autoremove
sudo apt autoremove
sudo apt clean

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

Типовые ошибки и восстановление

dpkg был прерван

sudo dpkg --configure -a
sudo apt --fix-broken install

APT сообщает о блокировке

Сначала найдите активный процесс, а не удаляйте lock-файлы:

ps aux | grep -E '[a]pt|[d]pkg'
systemctl status apt-daily.service apt-daily-upgrade.service

Дождитесь штатного завершения фоновой задачи. Удаление файлов блокировки при работающем dpkg может повредить базу пакетов.

Закончился диск

df -hT
sudo du -xhd1 /var | sort -h
sudo journalctl --disk-usage
sudo apt clean

Не удаляйте содержимое /var/lib/dpkg или /var/lib/apt вручную.

Рекомендуемый график

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

Итоговый чек-лист

1. Есть консоль провайдера и проверенная резервная копия.
2. Диск, память и службы находятся в нормальном состоянии.
3. apt update завершился без ошибок.
4. Список обновлений и возможных удалений просмотрен.
5. После установки проверены SSH, systemd, журналы и приложение.
6. При необходимости выполнена контролируемая перезагрузка.
7. Результат и время обслуживания зафиксированы.

Журнал изменений

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