Обновление сервера без простоя
Сервер нельзя оставлять без обновлений, но каждое обновление — риск остановить сайт. Риск снимают процессом: мелкие исправления безопасности ставятся автоматически, крупные изменения идут по плану со снимком, проверкой и готовым откатом, а перезагрузки собираются в окно обслуживания. Разберём, как устроить это на одном VPS.
Обновления сервера бывают двух видов, и обращаться с ними нужно по-разному. Исправления безопасности выходят часто, меняют мало и почти никогда ничего не ломают — их лучше ставить автоматически в тот же день. Плановые обновления — новая версия системы, PHP, базы данных или панели — меняют поведение программ, поэтому их готовят и проверяют. Простой сайта чаще всего случается не из-за обновления как такового, а из-за того, что крупное изменение поставили как мелкое.
Автоматические обновления безопасности
В Ubuntu Server пакет unattended-upgrades установлен и включён по умолчанию: раз в сутки он ставит только обновления безопасности, а остальные источники в файле /etc/apt/apt.conf.d/50unattended-upgrades закомментированы. Частота задаётся в 20auto-upgrades, журнал пишется в /var/log/unattended-upgrades/. В Debian используется тот же пакет, но на минимальной установке его может не быть — как включить, описано на странице Debian Wiki.
В AlmaLinux и других RHEL-совместимых системах ту же задачу решает dnf-automatic. По умолчанию он обновления не устанавливает: в /etc/dnf/automatic.conf задают upgrade_type = security и apply_updates = yes, а затем включают таймер dnf-automatic.timer.
Перезагрузку оба инструмента по умолчанию не делают. Это правильно: сервер не должен перезагружаться в час пик. Но и забывать о ней нельзя — обновлённое ядро и библиотеки начинают работать только после перезапуска. В Ubuntu и Debian о том, что нужна перезагрузка, сообщает файл /run/reboot-required, в AlmaLinux — команда dnf needs-restarting -r. Проверку стоит добавить в мониторинг сервера, а саму перезагрузку проводить в окно обслуживания.
Снимок перед плановым обновлением
Перед любым крупным изменением делают снимок диска (snapshot) в панели хостера. Он возвращает сервер в исходное состояние за минуты, если обновление пошло не так. По каталогу accsly.io на ноябрь 2026 года условия резервного копирования описаны у 1 644 из 2 247 хостеров VPS, и снимки в них прямо названы у 318. Если хостер снимков не делает, перед обновлением нужна полная резервная копия, которую вы уже проверяли восстановлением.
Две оговорки. Снимок обычно хранится там же, где диск сервера, и резервную копию не заменяет: при сбое хранилища пропадут оба. Кроме того, снимок работающей базы данных может оказаться несогласованным, поэтому перед ним делают дамп базы или ненадолго останавливают запись. Как построить резервное копирование целиком, рассказано в статье Резервные копии VPS, тарифы с местом под копии — на странице VPS для бэкапов.
Blue-green и поочерёдное обновление на одном VPS
Схемы без простоя пришли из больших систем, где за балансировщиком стоят несколько серверов: blue-green держит две полные копии и переключает трафик с одной на другую, поочерёдное (rolling) обновление выводит серверы из работы по одному. На одном VPS те же идеи применимы к приложению, хотя не к самой системе.
- Каталоги релизов. Каждая версия сайта выкладывается в отдельный каталог, например
releases/2026-11-07, а веб-сервер смотрит на символическую ссылкуcurrent. Новую версию готовят рядом — зависимости, сборка, кэш, — затем переключают ссылку одной командой. Откат — вернуть ссылку на предыдущий каталог. - Два экземпляра приложения. Новая версия запускается на другом порту или в другом контейнере, проходит проверку, затем nginx переключают на неё. Перезагрузка конфигурации nginx не обрывает соединения: по документации nginx главный процесс сначала проверяет конфигурацию и при ошибке продолжает работать со старой, а старые рабочие процессы дообслуживают своих клиентов. Перед этим всё равно запускают
nginx -t. Как запускать приложения в контейнерах, описано в статье Docker на VPS. - Совместимые миграции базы. Пока работают обе версии, база должна подходить обеим. Поэтому изменения схемы делят на шаги: сначала добавляют новые столбцы и таблицы, выкладывают код, который ими пользуется, и только в следующем релизе удаляют старое.
Обновление самой системы на новую основную версию без простоя на одном сервере не провести. Надёжнее поднять второй VPS с новой системой, перенести на него сайт, проверить и переключить DNS, заранее уменьшив время жизни записей, — как это сделать, рассказано в статье Домены и DNS для владельца сервера. Второй сервер на время переезда удобно брать с почасовой оплатой. Как выбрать версию системы, чтобы такие переезды случались реже, — в статье Linux-дистрибутивы для сервера.
Обновление ядра без перезагрузки
Живое исправление ядра (live patching) закрывает критические уязвимости в работающем ядре, не перезагружая сервер. В Ubuntu это Livepatch из подписки Ubuntu Pro: для личного использования он бесплатен на пяти машинах. Для RHEL-совместимых систем существуют свои механизмы, в том числе коммерческие сервисы.
У технологии есть пределы. Исправить можно только функции, которые ядро умеет трассировать, — это ограничение описано в документации ядра Linux, поэтому часть исправлений приходит только с новым ядром. Canonical прямо пишет, что Livepatch не отменяет плановые перезагрузки, а лишь позволяет отложить их до окна обслуживания. И главное для VPS: собственное ядро есть только у виртуализации KVM. На OpenVZ и LXC ядро общее и обновляет его хостер, подробнее — в статье KVM или OpenVZ.
Окно обслуживания и откат
Окно обслуживания — заранее выбранное время с наименьшей посещаемостью, обычно ночь по времени основной аудитории, когда разрешены перезагрузки и плановые изменения. Время берут из статистики сайта, а не наугад. Если сайтом пользуются клиенты или сотрудники, их предупреждают заранее. Окно нужно не только вам: хостер тоже проводит работы, и как он о них сообщает, разобрано в статье SLA и аптайм.
План отката составляют до начала работ, а не после того, как что-то сломалось:
- заранее определите признаки отказа — ошибки в журналах, рост времени ответа, проваленная проверка ключевых страниц — и срок, после которого откатываетесь без дальнейших попыток починить;
- для кода — переключите ссылку или nginx на предыдущий релиз;
- для пакетов в AlmaLinux есть
dnf history undo, который отменяет последнюю транзакцию; в Ubuntu и Debian штатного отката пакетов нет, поэтому там опираются на снимок; - снимок возвращает весь диск, и всё, что было записано после него — заказы, сообщения, регистрации, — пропадёт. Поэтому на время рискованного обновления сайт переводят в режим обслуживания или только для чтения.
После обновления проверьте ключевые страницы и журналы ошибок и сравните время ответа с обычным. Если перед запуском вы проводили нагрузочное тестирование, тот же сценарий после крупного обновления быстро покажет, не стал ли сайт медленнее.