Статья также доступна на украинском (перейти к просмотру).

Содержание:

• Зачем регулярно выполнять обновление Ubuntu Server

• Что проверить перед обновлением сервера

• Как проверить доступные обновления

• Apt upgrade чи apt full-upgrade

• Безопасная установка пакетов

• Какие службы нужно перезапустить после обновления

• Когда требуется перезагрузка сервера

• Что проверить после reboot

• Очистка ненужных пакетов

• Автоматические обновления Ubuntu и безопасность

• Типичные ошибки новичков

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

Если сайт работает на VPS, обновление не стоит откладывать. Старые системные пакеты могут содержать известные уязвимости безопасности, ошибки в библиотеках и проблемы совместимости. Регулярное обновление Ubuntu Server помогает поддерживать стабильность сервера и получать исправления для ядра Linux и серверных служб.

Рассмотрим регулярные обновления пакетов в пределах уже установленной версии Ubuntu. Это не то же самое, что переход с Ubuntu 24.04 на Ubuntu 26.04. Такую миграцию выполняют отдельно. Примеры подходят для актуальных версий Ubuntu LTS на серверном хостинге Freehost и специальных инсталляций Ubuntu.

Зачем регулярно выполнять обновление Ubuntu Server

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

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

Регулярное обновление пакетов Ubuntu позволяет:

• закрывать известные уязвимости безопасности;

• исправлять ошибки в системных пакетах;

• поддерживать стабильность сервера и совместимость программ;

• получать новые версии ядра Linux;

• своевременно обновлять веб-сервер, PHP, MySQL, Docker и другие компоненты.

APT обновляет только программы, установленные как пакеты из подключенных репозиториев. Обновление пакета Docker Engine не обновляет Docker-образы и программы внутри контейнеров. Сервер без обновлений может работать месяцами, но это не означает, что он остается безопасным. Для production-сервера важно иметь регламент: проверять доступные обновления, выполнять их в согласованное время и фиксировать результат. Если нужно обновить Ubuntu, начинайте с проверки состояния, а не с безусловного запуска установки.

Что проверить перед обновлением сервера

Перед началом убедитесь, что работает SSH-соединение, и проверьте доступ к аварийной веб-консоли VPS в панели управления. Консоль нужна как запасной способ входа, если SSH-соединение прервется или после обновления изменится сетевая служба.

Создайте резервную копию VPS и, если это предусмотрено тарифом, snapshot VPS. Snapshot помогает быстро вернуть предыдущее состояние диска, но не заменяет независимую резервную копию, которая хранится вне VPS. Внешняя резервная копия защищает данные в случае повреждения или утраты самого VPS. Регулярное резервное копирование снижает риск потери данных во время обновления.

Кстати: на VPS хостинге FREEhost.UA резервные копии VPS-сервера создаются автоматически и хранятся до 10 дней.

Также проверьте:

• До начала обновления основные серверные службы должны быть проверены и работать штатно.

• свободное место на диске и inode;

• состояние веб-сервера, PHP-FPM, MySQL/MariaDB и Docker;

• отсутствие активного резервного копирования, миграций и тяжелых операций базы данных;

• время с минимальной нагрузкой на сайт;

• доступ к консоли после перезагрузки.

Bash
lsb_release -ds
uname -r
if test -f /run/reboot-required; then
    echo "reboot-required=yes"
    cat /run/reboot-required.pkgs
else
    echo "reboot-required=no"
fi

Пример сокращенного вывода:

Plaintext
Ubuntu 24.04.4 LTS
6.8.0-134-generic
/dev/vda2        24G  21G  2.8G  89% /
reboot-required=yes
linux-image-6.8.0-136-generic
linux-base
apparmor

Не игнорируйте свободное место. Заполнение диска на 89% само по себе не определяет, можно ли запускать обновление. Важно учитывать фактический объем свободного места, размер загружаемых пакетов и дополнительное пространство, требуемое во время их распаковки и установки. В данном примере запас составляет всего 2,8 ГБ, поэтому перед обновлением стоит освободить место.

картинка 1

SSH-терминал: Ubuntu 24.04.4 LTS, активное ядро, df -h, df -i и состояние reboot-required.

Как проверить доступные обновления

Перед началом обновления Ubuntu Server обновите локальный список пакетов. Команда apt update проверяет репозитории Ubuntu, а проверка источников пакетов не устанавливает новые версии. Так пакетный менеджер APT получает актуальные данные о версиях и зависимостях. Установленные системные пакеты остаются без изменений до запуска отдельной команды установки. Системные пакеты на этом этапе только проверяются:

Bash
udo apt update
apt list --upgradable

Первая команда загружает актуальные индексы, вторая показывает доступные обновления. Если после обновления индексов вы видите All packages are up to date, новые пакеты для текущих источников не найдены. Это не проверка всех конфигураций и не гарантия того, что reboot не требуется.

Для конкретного пакета используйте:

Bash
apt-cache policy nginx

Ключевой результат проверки:

Plaintext
All packages are up to date.
Listing... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
nginx:
  Installed: 1.24.0-2ubuntu7.13
  Candidate: 1.24.0-2ubuntu7.13

В результате видна установленная версия, кандидат на обновление и репозиторий. На проверенном сервере версии пакета совпадали, поэтому устанавливать его не потребовалось.

картинка 2

Результат apt update, список доступных обновлений, apt-get -s upgrade и apt-cache policy nginx на сервере.

Apt upgrade или apt full-upgrade

Практическое обновление Ubuntu Server обычно начинается со следующего сценария:

Bash
sudo apt update
sudo apt upgrade

apt upgrade может устанавливать новые пакеты, если они требуются как зависимости, но не удаляет уже установленные пакеты. Если для обновления требуется удаление пакета, такое обновление будет отложено. Перед подтверждением внимательно прочитайте итоговый вывод: количество изменений, удалений и требуемое место. На production-сервере не добавляйте -y автоматически.

apt full-upgrade может установить новые зависимости или удалить пакеты, если это необходимо для согласования системы:

Bash
sudo apt full-upgrade

Это команда с более широкими полномочиями, а не «улучшенная версия» обычного обновления. Если APT предлагает удалить важную библиотеку, веб-сервер или пакет, остановитесь и разберитесь с зависимостями. Сначала выполните симуляцию. Если список безопасный, запускайте sudo apt upgrade в согласованное окно обслуживания:

Bash
sudo apt --simulate upgrade
sudo apt --simulate full-upgrade 

В данном случае симуляция показала только пакеты, которые можно удалить отдельно:

Plaintext
The following packages were automatically installed and are no longer required: libfwupd2 libgusb2 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Если симуляция не предполагает нежелательного удаления пакетов, выполните соответствующую команду без параметра --simulate.

Иногда Ubuntu применяет phased updates — поэтапное распространение обновления. В этом случае пакет может временно оставаться неустановленным, хотя он уже присутствует в репозитории. Это не обязательно ошибка APT: phased updates разворачиваются постепенно после проверки стабильности. Обновления безопасности Ubuntu не задерживаются механизмом phased updates.

Безопасная установка пакетов

Во время обновления Ubuntu Server лучше работать в tmux, если соединение нестабильно:

Bash
tmux new -s system-updat 

В этой сессии выполните команды после проверки списка изменений. Вернуться к сессии можно командой tmux attach -t system-update. Если tmux недоступен, используйте screen в качестве альтернативы. Не прерывайте APT и не выключайте сервер, пока dpkg распаковывает или настраивает пакеты.

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

Bash
sudo dpkg --audit
sudo apt --fix-broken install

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

Какие службы нужно перезапустить после обновления

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

Bash
sudo apt install needrestart
sudo needrestart
sudo needrestart -b

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

• NEEDRESTART-KCUR — ядро Linux, которое запущенно сейчас;

• NEEDRESTART-KEXP — ожидаемое ядро, установленное обновлением и доступное после перезагрузки;

• NEEDRESTART-KSTA — числовой статус needrestart относительно необходимости перезагрузки.

Пример фрагмента машиночитаемого вывода:

Plaintext
NEEDRESTART-KCUR: 6.8.0-134-generic
NEEDRESTART-KEXP: 6.8.0-136-generic
NEEDRESTART-KSTA: 3

Не перезапускайте все службы без анализа. Для веб-сервера:

Bash
sudo systemctl reload nginx
sudo systemctl restart nginx

reload перечитывает конфигурационный файл без полной остановки процесса, если служба поддерживает эту операцию. restart полностью перезапускает службу, поэтому активные соединения могут прерваться. Если меняли конфигурацию веб-сервера, сначала проверьте ее с помощью sudo nginx -t.

Активное и ожидаемое ядро, PHP-FPM, база данных и Docker имеют статус active.

Когда требуется перезагрузка сервера

Некоторые системные пакеты Ubuntu создают файл /run/reboot-required, когда для полного применения обновления рекомендована перезагрузка:

Bash
if test -f /run/reboot-required; then
    echo "Требуется перезагрузка"
    cat /run/reboot-required.pkgs
else
    echo "Перезагрузка не требуется"
fi

После установки нового ядра Linux сервер работает на старой версии до reboot. В примере активным было ядро 6.8.0-134-generic, а новое установленное — 6.8.0-136-generic. Важна версия ядра: команда uname -r показывает ее текущее значение. Отсутствие файла не является универсальной гарантией того, что перезагрузка не требуется для программ, установленных вручную или из сторонних источников.

Перед перезагрузкой VPS убедитесь, что APT завершил работу, база данных не выполняет критическую операцию, а у вас есть доступ к консоли. Если требуется безопасная перезагрузка, выполняйте sudo reboot только после завершения APT.

Проверка перед перезагрузкой: Ubuntu ожидает reboot из-за ядра и системных компонентов; uptime, uname -r, systemctl --failed и df -h показывают состояние сервера.

Bash
sudo reboot

SSH-соединение прервется — это ожидаемо. Не запускайте sudo reboot внутри незавершенного обновления. SSH-соединение после reboot должно восстановиться только после завершения всех операций.

Что проверить после reboot

После восстановления SSH выполните базовый post-check. Проверка после reboot показывает фактическую версию ядра. Так вы подтверждаете, что новое ядро Linux стало активным. После этого проверьте основные серверные службы и службы systemd, от которых зависит сайт:

Bash
uptime
uname -r
systemctl --failed
df -h
journalctl -p err - 

Основные строки результата:

Plaintext
12:06:05 up 4 min, 1 user, load average: 0.21, 0.16, 0.07
6.8.0-136-generic
0 loaded units listed.
/dev/vda2        24G  21G  2.8G  89% /

uptime подтверждает недавнюю перезагрузку, uname -r показывает активное ядро, а systemctl --failed — службы, которые не запустились. Состояние служб systemd проверяйте отдельно. Журнал системы проверяют через journalctl, чтобы увидеть ошибки текущей загрузки. Состояние журнала системы помогает выявить ошибки после reboot. Для анализа журналов используйте материал про journalctl, grep, awk и sed.

Bash
systemctl is-active nginx
systemctl is-active php8.3-fpm
systemctl is-active mysql
systemctl is-active docker
ss -lnt

ss -lnt показывает, на каких TCP-портах локально слушают службы. Внешнюю доступность сайта и портов нужно проверять с другого устройства или через внешний мониторинг. Если используется Apache, замените веб-сервер в проверке на apache2; для MariaDB — mariadb. Откройте сайт, проверьте PHP-FPM, MySQL или MariaDB, необходимые порты и Docker-контейнеры. Для контроля нагрузки после reboot можно воспользоваться Netdata для мониторинга сервера.

Очистка ненужных пакетов

После проверки сайта и служб можно посмотреть ненужные пакеты:

Bash

sudo apt autoremove --simulate

 

Результат симуляции:

Plaintext
The following packages will be REMOVED:
  libfwupd2 libgusb2

0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

Перед подтверждением прочитайте список. На проверенном сервере симуляция показала два пакета, которые больше не нужны: libfwupd2 и libgusb2. Параметр --simulate лишь показывает будущие изменения. Фактический sudo apt autoremove запускайте только после проверки списка и убедившись, что пакеты не нужны программам или сценариям резервного копирования.

SSH-терминал: sudo apt autoremove --simulate показывает два пакета к удалению, но не меняет систему.

Bash
sudo apt clean

apt clean удаляет загруженные файлы пакетов из кэша /var/cache/apt/archives/, но не удаляет журналы APT или systemd. Во время диагностики неудачного обновления не спешите выполнять apt clean, так как загруженные пакеты могут понадобиться для повторной установки. Журналы обновления эта команда не удаляет.

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

Автоматические обновления Ubuntu и безопасность

На стандартной инсталляции Ubuntu Server пакет unattended-upgrades часто уже установлен и активен. Сначала проверьте его состояние:

Bash
dpkg -l unattended-upgrades
systemctl status apt-daily-upgrade.timer

Если пакет отсутствует или автоматические обновления отключены, его можно установить и настроить:

Bash
<pку>sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Основные конфигурационные файлы:

• /etc/apt/apt.conf.d/20auto-upgrades

• /etc/apt/apt.conf.d/50unattended-upgrades

Журналы обычно находятся здесь:

Bash
ls -la /var/log/unattended-upgrades/

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

Автоматические обновления Ubuntu полезны для обычного сервера: критические исправления не ждут ручного запуска. Они могут устанавливать исправления безопасности без ручного вмешательства. Для сложной production-системы лучше определить тестовую среду, окно обслуживания и процедуру отката. Не включайте автоматическую перезагрузку без четкой причины: она может прервать работу сайта, базы данных или длительную операцию. Даже при активном механизме необходимы мониторинг, журналы и контроль reboot-required. Так автоматические обновления Ubuntu работают без потери контроля.

Типичные ошибки новичков

• запускать обновление без резервной копии или snapshot;

• не проверять свободное место на диске;

• использовать -y, не читая список изменений;

• перезагружать сервер до завершения работы APT;

• автоматически заменять измененный конфигурационный файл;

• перезапускать все службы без понимания последствий;

• не проверять сайт, PHP-FPM, базу данных и Docker после reboot;

• игнорировать /run/reboot-required месяцами.

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

• Проверка доступа: проверьте SSH-соединение и аварийную консоль VPS.

• Проверка ресурсов: проверьте свободное место на диске и inode (df -h, df -i).

• Резервное копирование: создайте резервную копию или snapshot VPS.

• Планирование: выберите время с минимальной нагрузкой на сайт.

• Обновление индексов: обновите список пакетов (sudo apt update).

• Проверка обновлений: просмотрите доступные пакеты (apt list --upgradable).

• Симуляция: проверьте список изменений с помощью симуляции (--simulate).

• Установка: запустите обновление пакетов.

• Контроль служб: проверьте состояние и при необходимости перезапустите нужные службы.

• Перезагрузка: при необходимости (если изменилось ядро или системные библиотеки) согласуйте и выполните reboot.

• Post-check: после перезагрузки проверьте версию ядра, доступность сайта, открытые порты, логи и состояние диска.

Такой порядок делает обновление Ubuntu Server предсказуемой и безопасной процедурой. Результат зависит от подготовки, наличия резервной копии, контроля изменений и тщательной проверки после перезагрузки.

Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал YouTube на https://www.youtube.com/freehostua.

Мы в чем-то ошиблись или что-то пропустили?

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

Дата: 22.07.2026 Автор: Илья Пигович #backup#linux#security#ubuntu

Голосование 1 2 3 4 5