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

Зміст:

• Навіщо регулярно виконувати оновлення 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;

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

• час із мінімальним навантаженням на сайт;

• доступ до консолі після перезавантаження.

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

Приклад скороченого виводу:

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

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

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

Як перевірити доступні оновлення

Перед початком оновлення Ubuntu Server оновіть локальний список пакетів. Команда apt update перевіряє репозиторії Ubuntu, а перевірка джерел пакетів не встановлює нові версії. Так пакетний менеджер APT отримує актуальні дані про версії та залежності. Встановлені системні пакети залишаються без змін до запуску окремої команди встановлення. Системні пакети на цьому етапі лише перевіряються:

sudo apt update
apt list --upgradable

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

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

apt-cache policy nginx

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

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

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

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

Apt upgrade чи apt full-upgrade

Практичне оновлення Ubuntu Server зазвичай починається з такого сценарію:

sudo apt update
sudo apt upgrade

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

apt full-upgrade може встановити нові залежності або видалити пакети, якщо це потрібно для узгодження системи:

sudo apt full-upgrade

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

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

У цьому випадку симуляція показала лише пакети, які можна прибрати окремо:

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, якщо з’єднання нестабільне:

tmux new -s system-update

У цій сесії виконайте команди після перевірки списку змін. Повернутися до сесії можна командою tmux attach -t system-update. Якщо tmux недоступний, використовуйте screen як альтернативу. Не переривайте APT і не вимикайте сервер, поки dpkg розпаковує або налаштовує пакети.

Під час оновлення система може показати запит про змінений конфігураційний файл. Якщо ви не знаєте, які локальні параметри були змінені, не погоджуйтеся на автоматичну заміну. Збережіть поточний файл, перегляньте різницю та об’єднайте зміни після операції.

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

Останню команду запускайте лише за ознак незавершених залежностей і після збереження тексту помилки.

Які служби треба перезапустити після оновлення

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

sudo apt install needrestart
sudo needrestart
sudo needrestart -b

Звичайний режим зручніший для ручної перевірки. Параметр -b вмикає машиночитний вивід, який зручно використовувати в автоматизації та скриптах. Основні поля такого виводу:

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

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

• NEEDRESTART-KSTA — числовий статус needrestart щодо необхідності перезавантаження.

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

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

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

sudo systemctl reload nginx
sudo systemctl restart nginx

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

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

Коли потрібне перезавантаження сервера

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

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 показують стан сервера.

sudo reboot

SSH-з’єднання перерветься — це очікувано. Не запускайте sudo reboot усередині незавершеного оновлення. SSH-з'єднання після reboot має відновитися лише після завершення всіх операцій.

Що перевірити після reboot

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

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

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

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.

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 для моніторингу сервера.

Очищення непотрібних пакетів

Після перевірки сайту і служб можна подивитися непотрібні пакети:

sudo apt autoremove --simulate

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

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 запускайте тільки після перевірки списку та переконайтеся, що пакети не потрібні програмам або сценаріям резервного копіювання.

Ubuntu очікує reboot внаслідок ядра та системних компонентів; uptime, uname -r, systemctl --failed та df -h показують стан сервера

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

sudo apt clean

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

Не виконуйте autoremove і clean під час пошуку причини невдалого оновлення. Спочатку збережіть логи та відновіть стабільний стан.

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

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

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

<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

Журнали зазвичай знаходяться тут:

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