Debian 11 перестаёт получать LTS-обновления: как проверить сервер и безопасно обновиться

31 августа 2026 года заканчивается Long Term Support Debian 11 «Bullseye». Разбираем, как найти все серверы на этой версии, что проверить перед апгрейдом и как сократить риск и простой продакшена

Долгосрочная поддержка (LTS) Debian 11 «Bullseye» заканчивается 31 августа 2026 года [1][2]. После этой даты заканчивается стандартная LTS-поддержка безопасности Bullseye через инфраструктуру Debian; коммерческие сервисы расширенной поддержки могут продолжать выпуск обновлений для своего ограниченного набора пакетов [1][2][6]. Один из коммерческих способов выиграть время без миграции — Extended LTS (ELTS) от Freexian; Debian прямо указывает, что ELTS не является официальным проектом Debian и охватывает только согласованный набор пакетов [4][5][6]. Правильная последовательность действий: сначала — инвентаризация серверов и версий; затем — проверка совместимости PHP, БД, веб-сервера, Redis, Docker и панели управления с целевым релизом; затем — резервная копия и проверенное восстановление; и только потом — обновление, либо поэтапным dist-upgrade, либо переносом на новый сервер. После обновления обязательно проверяются cron, очереди задач, почта, SSL и фоновые службы, а до начала работ фиксируются критерии, при которых обновление откатывается.

В чём проблема и кому она касается

Если на сервере стоит Debian 11, 1 сентября он не перестанет работать: сайт может открываться, база отвечать, письма уходить. Однако после окончания LTS новые уязвимости могут остаться без исправлений в стандартных репозиториях поддержки Bullseye. Это изменение статуса риска, а не мгновенная поломка: безопасный вариант — миграция на поддерживаемый релиз либо временный договор на коммерческую расширенную поддержку нужных пакетов.

Проблема касается прежде всего:

• компаний с собственными VPS/VDS, где системный администратор один и апдейты идут по остаточному принципу;
• интернет-магазинов и сайтов на PHP, где стек годами не трогали, потому что «работает — не лезь»;
• внутренних сервисов (гит, таск-трекеры, файлхранилища, VPN), которые находятся вне зоны внимания out-of-the-box мониторинга уязвимостей;
• DevOps-команд, у которых Debian 11 «спрятан» внутри Docker-образов и CI-раннеров и не виден в стандартном учёте серверов [3].

Последний пункт — отдельная ловушка: образы debian:bullseye и debian:bullseye-slim используются как базовые слои в тысячах публичных Docker-образов, и команда может пользоваться устаревшим Debian внутри контейнера, даже не подозревая об этом, если явно не проверяла базовый слой [3].

Как устроен жизненный цикл Debian и что именно заканчивается

У каждого стабильного релиза Debian есть две фазы поддержки:

1. Полная поддержка (regular security support) — около трёх лет, её ведёт основная команда безопасности Debian.
2. Long Term Support (LTS) — ещё около двух лет, поддержку берёт на себя отдельная волонтёрская LTS-команда, но уже для более узкого набора архитектур и пакетов [1][6].

Для Bullseye это выглядело так: релиз вышел 14 августа 2021 года, обычная поддержка закончилась 14 августа 2024 года, после чего сопровождение перешло к LTS-команде, а сама LTS-фаза продлится до 31 августа 2026 года [1][2]. В этот момент поддерживаемых архитектур уже было меньше — только i386, amd64, armhf и arm64 [1].

Важный нюанс: часть источников в интернете ошибочно указывает другую дату окончания (например, 30 июня) — правильная дата зафиксирована прямо на официальной странице релиза Debian и в официальном анонсе LTS-команды: 31 августа 2026 года [2][7][8].

После окончания LTS для Bullseye доступны коммерческие варианты продления, включая Extended LTS (ELTS) от Freexian; это не официальный проект Debian. Freexian продлевает поддержку Debian 11 до 30 июня 2031 года, но: покрывает только пакеты, которые заказал клиент, требует платной подписки, и не гарантирует поддержку пакетов, уже исключённых обычной LTS-командой [4][9][5]. Это осознанный компромисс «выиграть время», а не полноценная замена миграции. Кроме Freexian, аналогичные платные сервисы продления патчей для уже неподдерживаемых версий Debian предлагают и другие независимые вендоры — например, TuxCare со своим сервисом Endless Lifecycle Support, который патчит пакеты через обычный apt без перехода на новую версию системы [10].

Российская специфика: на что обратить внимание отдельно

Технически Debian — интернациональный проект, и юридических требований именно к Debian в России нет. Но у практики есть нюансы, которые стоит учитывать:

• Доступность репозиториев. Перед апгрейдом проверьте, что настроены доступные официальные зеркала или CDN deb.debian.org и они отдают целевой релиз. archive.debian.org предназначен для старых выпусков и не является региональным зеркалом актуального репозитория.
• Типичный стек рунета. Значительная часть российских сайтов и внутренних сервисов работает на связке 1С-Битрикс + PHP + MySQL/MariaDB под управлением панелей вроде ISPmanager, BILLmanager или их аналогов. Такие панели часто сами диктуют, какие версии ОС и PHP они официально поддерживают, — это нужно свериться с документацией панели до апгрейда, а не после.
• Хостинг-провайдеры. Если сервер арендован у хостера с собственным образом Debian, у него может быть собственный график миграции и собственные ограничения на dist-upgrade «в лоб» — стоит уточнить это у провайдера до начала работ.
• ELTS как временная мера. Для организаций, которые не могут завершить миграцию в срок из-за внутренних регламентов согласования изменений, ELTS от Freexian (или аналогичные сервисы других вендоров) — реалистичный мост на несколько месяцев, но не постоянное решение: часть пакетов там не покрывается вовсе [5][9].

Шаг 1. Определить версию Debian на сервере

Первый шаг — не поверить памяти («вроде бы там Debian 11»), а точно проверить:

cat /etc/os-release

Строки VERSION_ID="11" и VERSION_CODENAME=bullseye однозначно покажут релиз. Дополнительно полезно:

lsb_release -a
uname -mrs

Первая команда покажет кодовое имя и релиз через утилиту lsb-release, вторая — версию ядра, которая тоже понадобится при оценке совместимости.

Шаг 2. Составить полный список серверов на Debian 11

Локальная проверка одного сервера ничего не говорит о масштабе проблемы в компании. Дальше нужна инвентаризация:

• Физические и виртуальные серверы. Если есть система управления конфигурацией (Ansible, Salt, Puppet) или CMDB — самый быстрый способ получить список: прогнать по всем хостам команду проверки версии и собрать отчёт централизованно.
• Облачные VPS/VDS у разных провайдеров. Часто у компании несколько аккаунтов и провайдеров — стоит явно пройтись по каждому, а не полагаться на «список из головы».
• Docker-образы и CI/CD. Отдельно нужно проверить базовые образы в Dockerfile (FROM debian:bullseye, FROM debian:bullseye-slim, а также образы других приложений, которые незаметно тянут Bullseye как базовый слой) и образы, используемые раннерами CI [3].
• Забытые внутренние сервисы. VPN-шлюзы, внутренние Git/Wiki/мониторинг, старые тестовые стенды — именно они чаще всего оказываются «случайно найденным» Debian 11 при полной инвентаризации.

Результат этого шага — таблица: хост, роль сервера, версия ОС, критичность для бизнеса, ответственный. Она же станет основой плана миграции по приоритету.

Шаг 3. Проверить совместимость стека с целевой версией

Главная ошибка при подготовке к обновлению — считать, что «система обновится, а софт как-нибудь адаптируется». На практике переход на новый релиз Debian означает одновременный мажорный скачок версий у всего стека, и это нужно сверять заранее, компонент за компонентом.

PHP. Debian 11 поставляет по умолчанию PHP 7.4, Debian 12 — PHP 8.2, Debian 13 — уже PHP 8.4 [11]. Это не просто «новее» — между 7.4 и 8.x есть изменения, ломающие обратную совместимость (типизация, устаревшие функции, поведение ошибок), поэтому обязательно нужно тестировать код приложения (особенно самописный PHP и старые плагины CMS) на целевой версии PHP до переключения продакшена, а не после.

MariaDB/MySQL. Debian 11 по умолчанию поставляет MariaDB 10.5, Debian 12 — MariaDB 10.11, Debian 13 — уже ветку MariaDB 11.8 [12]. Здесь тоже стоит заранее свериться со списком изменений между этими ветками, особенно если в проекте используются нестандартные настройки репликации, специфичные SQL-режимы или сторонние расширения СУБД.

Nginx/Apache. Обычно апгрейд ветки веб-сервера переносится менее болезненно, чем PHP или БД, но стоит явно проверить: изменения синтаксиса конфигурации, изменившиеся модули (например, поведение mod_php против PHP-FPM), а также совместимость используемых модулей безопасности (mod_security и аналогов) с новой версией.

Redis. Проверяется отдельно: версия Redis в целевом релизе, изменения в конфигурационных директивах, а также совместимость клиентских библиотек приложения с новой версией сервера.

Docker. Если приложение работает в контейнерах, а не напрямую на хосте, апгрейд хостовой ОС и апгрейд базового образа контейнера — это два разных, не связанных напрямую действия. Нужно отдельно спланировать пересборку образов на новом базовом слое (debian:bookworm вместо debian:bullseye) и протестировать приложение в контейнере на новом базовом образе.

Панель управления. Если сервер администрируется через панель (ISPmanager, BILLmanager, cPanel/Plesk и аналоги), нужно свериться именно с документацией панели: часто у панелей есть собственный список поддерживаемых версий ОС, и апгрейд системы «в обход» панели может сломать её работу или потребовать отдельного скрипта миграции самой панели.

Почему нельзя делать dist-upgrade вслепую на боевом сервере

Официальный путь обновления Debian поддерживает переход только на один релиз вперёд: с 11 на 12, затем отдельным шагом с 12 на 13 — «перепрыгнуть» напрямую с 11 на 13 штатно не получится [13]. Это уже само по себе означает, что «обновление» — это не одна команда, а спланированная последовательность.

Кроме версии самой ОС, apt dist-upgrade одновременно меняет версии PHP, СУБД, веб-сервера и десятков системных библиотек — то есть весь стек приложения меняется разом, без возможности откатить только один компонент. Именно поэтому запуск dist-upgrade на проде без предварительной проверки — это не «быстрый способ обновиться», а быстрый способ получить одновременный отказ нескольких частей системы, причины которого придётся выяснять уже во время инцидента.

Дополнительный риск — сторонние (не-Debian) репозитории и пакеты. Перед апгрейдом стоит явно проверить, какие пакеты установлены не из официальных репозиториев Debian (например, через apt list '?narrow(?installed, ?not(?origin(Debian)))' или аналогичные инструменты для поиска пакетов не из архива Debian) — такие пакеты чаще всего являются причиной прерванного или незавершённого upgrade [14].

Резервная копия, snapshot и тестовое восстановление — обязательный этап, а не формальность

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

1. Snapshot виртуальной машины или диска (если сервер виртуальный — снимок на уровне гипервизора/облака; если физический — LVM-snapshot или иной механизм на уровне ОС). Snapshot может ускорить откат, но фактическое время и консистентность зависят от платформы и состояния приложений; он не заменяет отдельный проверенный бэкап данных.
2. Резервная копия данных отдельно от snapshot: дамп баз данных, файлы приложения, конфигурации веб-сервера, cron-задачи, содержимое очередей — всё, что нельзя восстановить простым откатом диска, если, например, snapshot был сделан раньше последних транзакций.
3. Тестовое восстановление — обязательный шаг, который часто пропускают. Резервная копия, которую ни разу не разворачивали заново, с практической точки зрения не является резервной копией: единственный способ убедиться, что восстановление реально работает и укладывается в приемлемое время простоя, — сделать это один раз заранее, на отдельном тестовом сервере, до начала работ на проде.

Только после того, как snapshot сделан, бэкап проверен и тестовое восстановление прошло успешно, имеет смысл переходить к самому обновлению.

Как обновлять: поэтапно на месте или миграция на новый сервер

Есть два принципиально разных подхода, и выбор между ними — это не вопрос личных предпочтений, а вопрос состояния конкретного сервера.

Поэтапный in-place upgrade (11 → 12 → 13) подходит, когда:

• сервер собран близко к «ванильному» Debian, без большого количества сторонних репозиториев и нестандартных патчей [14];
• есть подтверждённый снапшот и проверенное восстановление;
• стек приложения уже протестирован на целевых версиях PHP/БД на отдельном стенде;
• допустимо окно обслуживания на время апгрейда и перезагрузки.

Процедура на официальном уровне выглядит как: обновление до последней точечной версии текущего релиза → замена записей в списках источников APT с текущего кодового имени на следующее → выполнение обновления в два шага (сначала минимальный upgrade, затем полный dist-upgrade) → перезагрузка и проверка [13][15]. Здесь принципиально не пропускать «минимальный» шаг перед полным dist-upgrade — именно на нём Debian отлавливает конфликты пакетов до того, как они превратятся в сломанную систему.

Миграция на новый сервер предпочтительнее, когда:

• на сервере годами копились ручные правки, забытые cron-задачи и нестандартные конфигурации, которые никто не документировал;
• используется много сторонних репозиториев и самосборных пакетов;
• нужен переход сразу через два релиза (11 → 13), а не один;
• бизнес не может себе позволить длительное окно обслуживания на одном сервере, и проще поднять новый сервер параллельно, перенести на него данные и переключить трафик.

Миграция дороже по трудозатратам на старте, но при плохо документированном или сильно кастомизированном сервере она предсказуемее: вместо «а что сломает upgrade именно на этом сервере» получаем чистую установку с явным переносом только того, что действительно нужно.

Что проверить после обновления

Обновление ОС и стека — это половина работы; вторая половина — подтвердить, что всё, что должно работать в фоне, действительно работает:

• Cron. Проверить, что задачи cron не исчезли и не изменили расписание (иногда меняется пакет cron/anacron, и поведение по умолчанию слегка отличается между релизами), и что скрипты в cron не завязаны на путь к бинарнику PHP или другого интерпретатора старой версии.
• Очереди задач (например, очереди CMS, очереди рассылок, воркеры фоновой обработки) — убедиться, что процессы-обработчики запущены после апгрейда и не завершились молча из-за несовместимости с новой версией PHP или библиотек.
• Почта. Проверить, что почтовый сервер (если он есть на этом хосте) поднялся, слушает нужные порты и что исходящие письма от приложения (уведомления, чеки, восстановление пароля) реально доставляются, а не теряются из-за изменившейся конфигурации.
• SSL/TLS. Проверить, что сертификаты на месте, автопродление (certbot/acme.sh и аналоги) работает после обновления системных пакетов, и что версия OpenSSL в новом релизе не изменила требования к протоколам/шифрам для существующих интеграций.
• Интеграции. Отдельно протестировать все внешние API-интеграции (платёжные системы, службы доставки, банковские API, внешние CRM) — иногда причина сбоя не в самом приложении, а в изменившейся версии библиотек TLS/HTTP-клиента.
• Фоновые службы. Проверить статус всех systemd-юнитов (systemctl --failed покажет упавшие сервисы одним списком) — это самый быстрый способ увидеть, что не поднялось после перезагрузки.

Как заранее определить критерии отката

Критерии отката нужно фиксировать письменно до начала работ, а не придумывать по ходу инцидента:

• максимально допустимое время простоя, после превышения которого принимается решение откатываться, а не «пробовать ещё немного»;
• список критичных проверок (сайт отвечает 200 OK на ключевых страницах, оформление заказа проходит целиком, письма уходят, платежи проходят) — если хотя бы одна из них не проходит в установленный срок, это триггер отката;
• ответственный, который принимает решение об откате — заранее, а не «кто первый увидит проблему»;
• сам механизм отката — то есть заранее подтверждённый snapshot и понятная процедура его применения, а не «будем разбираться на месте».

Рекомендации по выбору решения

Если сервер один, стек простой и предсказуемый, а окно обслуживания доступно — поэтапный in-place upgrade с полным набором проверок из этой статьи обычно самый быстрый и дешёвый путь. Если серверов много, а конфигурации сильно различаются и слабо задокументированы, разумнее закладывать время на миграцию хотя бы части хостов на новые серверы — это дороже по часам работы, но предсказуемее по рискам. Если ни то ни другое не укладывается в срок до конца LTS, временный мост — подписка на Freexian ELTS (или аналогичный сервис другого вендора) для конкретных серверов с самым высоким риском, при этом миграция всё равно должна оставаться в плане, а не откладываться на неопределённый срок [4][5].

Для организаций с большим количеством разнородных серверов имеет смысл провести технический аудит инфраструктуры до начала массового обновления: собрать реальную картину версий, конфигураций и зависимостей, а не полагаться на предположения о том, что где установлено. Команда «Пятого фактора» может изучить существующую инфраструктуру, помочь с инвентаризацией серверов и стека, а также с самой технической реализацией — от подготовки резервного копирования и тестового восстановления до последовательного обновления или переноса сервисов на новые серверы.

Вывод

Окончание LTS Debian 11 — конкретная дата с конкретными последствиями: 31 августа 2026 года заканчивается стандартная LTS-поддержка безопасности Bullseye [1][2]. Это не повод для паники, но повод для плана: точно определить, где используется Debian 11, проверить совместимость всего стека с целевым релизом, обязательно подготовить и проверить резервную копию, выбрать между поэтапным апгрейдом и миграцией на новый сервер исходя из реального состояния конкретной системы, и заранее решить, при каких условиях обновление будет отменено. Технически ничего из этого не сложно по отдельности — сложность в том, чтобы сделать всё по порядку и не срезать углы там, где потом придётся чинить продакшен вручную.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] debian.org — Debian «bullseye» Release Information — https://www.debian.org/releases/bullseye/

[2] debian.org — Security support for Bullseye handed over to the LTS team — https://www.debian.org/News/2024/20240814

[3] eolradar.com — Debian 11 End of Life: August 31, 2026 — Hidden in Docker Images — https://eolradar.com/debian-11-end-of-life-bullseye-2026/

[4] freexian.com — About Debian 11 Bullseye (ELTS support period) — https://www.freexian.com/lts/extended/docs/debian-11-support/

[5] freexian.com — Frequently Asked Questions (LTS vs Extended LTS) — https://www.freexian.com/lts/extended/faq/

[6] wiki.debian.org — LTS/Extended — https://wiki.debian.org/LTS/Extended

[7] linuxcompatible.org — Debian 11 Bullseye Reaches EOL: August 2026 Deadline and Migration Options — https://www.linuxcompatible.org/story/debian-11-bullseye-reaches-eol-august-2026-deadline-and-migration-options/

[8] thelastpatch.io — Debian 11 End of Life: LTS Ends This Summer. Here's Your Checklist — https://thelastpatch.io/debian-11-end-of-life/

[9] freexian.com — Debian Extended LTS by Freexian — https://www.freexian.com/lts/extended/

[10] tuxcare.com — Debian 11 "Bullseye" Hits End of Life on August 31, 2026 — https://tuxcare.com/blog/debian-11-bullseye-hits-end-of-life/

[11] wiki.debian.org — AdditionalPHPVersions — https://wiki.debian.org/AdditionalPHPVersions

[12] mariadb.com — Distributions Including MariaDB — https://mariadb.com/docs/general-resources/distributions-including-mariadb

[13] debian.org — Release Notes for Debian 12 (bookworm), Chapter 4: Upgrades from Debian 11 — https://www.debian.org/releases/bookworm/armel/release-notes/ch-upgrading.en.html

[14] cyberciti.biz (nixCraft) — How to upgrade Debian 11 to Debian 12 bookworm using CLI — https://www.cyberciti.biz/faq/update-upgrade-debian-11-to-debian-12-bookworm/

[15] linuxcapable.com — Upgrade from Debian 11 Bullseye to Debian 12 Bookworm — https://linuxcapable.com/how-to-upgrade-from-debian-11-bullseye-to-debian-12-bookworm/