Обновление работающего сервера Ubuntu: подготовка, восстановление подключения и проверки после перезагрузки

При обновлении работающего сервера Ubuntu недостаточно обновить пакеты: нужно остановить службы и после перезагрузки вернуть систему в эксплуатацию. Такие проблемы, как потеря SSH-соединения, несовместимость настроек аутентификации с новой версией и невозможность извлечь резервную копию, могут возникнуть и после завершения команды обновления.

В этой статье опыт перехода с Ubuntu 24.04 на 26.04 LTS и обычных обновлений после миграции изложен в виде процедур, применимых и к другим серверам. Предполагается, что у вас есть права администратора и время на обслуживание с остановкой служб. Сначала описаны общие подготовка и порядок работ, а во второй части — диагностика проблем с подключением, аутентификацией и запуском.

Выбор перехода с 24.04 на 26.04 или обычного обновления

Определите, нужна ли новая версия ОС или достаточно исправлений текущей. Переход требует дополнительных проверок внешней аутентификации, VPN и БД; обычное обновление — планируемых пакетов и перезапусков. Не начинайте без консоли восстановления и проверенной процедуры восстановления данных.

Ubuntu Server：Условия и подготовка перехода LTS

1. Определите тип обновления и объём работ

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

Работа	Пример	Используемый механизм	Что проверить заранее
Обычное обновление	Исправления и обновление ядра в Ubuntu 26.04	APT	Планируемые обновления, добавления и удаления, влияние перезапуска служб
Обновление выпуска	Переход с Ubuntu 24.04 на 26.04	do-release-upgrade	Официальные условия перехода, совместимость, устаревшие и разделённые пакеты

apt-get dist-upgrade регулирует зависимости для настроенных источников пакетов. Несмотря на слово «dist» в названии, это не специальная команда для перехода на следующий выпуск Ubuntu LTS. Обновление выпуска выполняйте по официальным инструкциям Ubuntu. В рабочей среде не используйте -d, предназначенный для предварительных выпусков, и не меняйте вручную только источники APT. Переход с Debian на Ubuntu также не относится к обновлениям, которые можно выполнить по этой процедуре.

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

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

2. Обеспечьте доступ к управлению на случай разрыва SSH

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

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

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

3. Восстановите резервную копию в отдельное место

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

Например, если вы используете инструмент резервного копирования restic, проверку можно выполнить из административной оболочки с уже настроенными параметрами подключения. Замените snapshot_id на ID проверенной версии. Если зафиксировать ID, а не использовать latest, новая операция сохранения, запущенная во время проверки, не изменит выбранную версию.

# 既存のリポジトリ接続設定を使う。秘密値をコマンドに直書きしない。
snapshot_id='確認したスナップショットID'
umask 077
restore_dir=$(mktemp -d /var/tmp/restore-check.XXXXXX) || exit 1
restic restore "$snapshot_id" --target "$restore_dir" --verify

Не указывайте в качестве каталога восстановления рабочий каталог данных. restic может перезаписать существующие файлы, поэтому ознакомьтесь с официальным описанием восстановления и проводите проверку в изолированном пустом месте. Пример конфигурации с объектным хранилищем, например R2, приведён также в статье Как включить практическое восстановление резервной копии в процесс проверки.

После восстановления проверьте следующее — в зависимости от формата данных.

Данные	Что проверить	Что этим проверить нельзя
Архив, например ZIP	Распаковку и целостность, наличие нужных файлов	Запуск приложения и возможность использовать содержимое
Дамп SQL	Импорт в изолированную БД, схему и основные данные	Согласованность с вложениями и внешним хранилищем
SQLite	Наличие и размер восстановленного файла, целостность БД	Восстановление всего сервиса
Настройки, сертификаты, ключи	Нужные файлы, владельца, права и ссылки на них	Настройки и действительность данных на внешних сервисах

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

Если для проверки нужно запустить систему аутентификации или аналогичный сервис, изолируйте сеть, чтобы копия с теми же идентификаторами не могла связаться с рабочей системой. Если используете контейнеры или пространства имён, перед монтированием или запуском проверьте, что изоляция работает. Также убедитесь, что создание тестового /run не перекрывает /run рабочей системы.

4. Сохраните исходное состояние системы, а не только настройки

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

Что сохранить	Что сверить позднее
ОС и пакеты	Выпуск, работающее ядро, установленные пакеты, источники APT и пакеты на hold
Сеть и SSH	Netplan, настройки SSH и VPN, способ управления межсетевым экраном
Службы	Unit-файлы и drop-in-файлы, включены ли службы при загрузке и в каком они состоянии сейчас
Плановые задания	Включение и выключение timer, cron и резервного копирования, время следующего запуска
Приложения	Настройки, расположение данных, конфигурация контейнеров, внешние зависимости

Пример сохранения данных в Ubuntu с Netplan и systemd. Проверьте, что нужные каталоги существуют, затем войдите в оболочку root с помощью sudo -i и выполните команды. Каталог, созданный mktemp, будет новым и доступным только root; существующие записи не будут перезаписаны.

umask 077
record_dir=$(mktemp -d /root/ubuntu-upgrade.XXXXXX) || exit 1
cp -a /etc/netplan /etc/ssh /etc/systemd/system "$record_dir/" || exit 1
apt-mark showhold > "$record_dir/apt-hold.txt"
systemctl list-unit-files > "$record_dir/unit-files.txt"
systemctl list-units --type=service --all > "$record_dir/services.txt"
systemctl list-timers --all > "$record_dir/timers.txt"
cat /proc/sys/kernel/random/boot_id > "$record_dir/boot-id.txt"

Этот пример не включает настройки приложений и данные во внешних хранилищах. Добавьте объекты из таблицы выше и зафиксируйте в журнале работ расположение сохранённых данных.

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

cat /etc/os-release
uname -r
cat /proc/sys/kernel/random/boot_id
apt-mark showhold
systemctl list-timers --all
systemctl --failed
sudo sshd -t

sshd -t проверяет синтаксис настроек SSH. Успешная проверка не подтверждает, что к серверу можно подключиться извне. Так же и для Netplan: отдельно проверяйте синтаксис и результат генерации, а также фактическую связь.

Если для обновления остановили timer или временно изменили hold, запишите исходное состояние и причину. Если после работ без разбора включить всё, запустятся даже задания, которые намеренно были остановлены. При восстановлении настроек не заменяйте весь /etc старой версией, а сверяйте по различиям именно те файлы и строки, которые меняли.

5. Свяжите отсутствие пользователей с безопасной остановкой

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

Заранее составьте перечень объектов проверки и получите самые свежие значения для каждого из них. Если получение данных не удалось, значения отсутствуют или устарели либо какие-то серверы не охвачены мониторингом, остановку не разрешайте. Не преобразуйте отсутствие значения в 0: при сбое мониторинга это может привести к остановке службы.

Например, если мониторинг обычно обновляется каждые несколько секунд, можно задать условие: и время наблюдения, и время обновления исходных данных не старше 15 секунд. Эти 15 секунд — пример проектного решения. Выберите интервал с учётом фактической периодичности обновления и проверьте синхронизацию часов. Если для решения достаточно числа пользователей, собирать их имена или регулярно отправлять в консоль команды для вывода списка не нужно.

Непосредственно перед остановкой действуйте в таком порядке.

1. Убедитесь, что число пользователей и заданий на всех объектах равно 0 и не выполняется конкурирующее обслуживание.
2. Закройте приём новых запросов на уровне приложения или балансировщика нагрузки. Используйте способ, который позволяет текущим операциям штатно завершиться.
3. После закрытия приёма запросов повторно проверьте по новым данным, что на всех объектах значение равно 0.
4. Запросите штатное завершение и убедитесь, что процесс остановился и данные сохранены.
5. Возобновите приём запросов только после проверки работы после обновления и перезагрузки.

Если после закрытия приёма обнаружились пользователи, не переходите к остановке. Выполните заранее определённые действия — дождитесь их выхода или восстановите приём запросов. Не используйте повторно предыдущее значение 0.

Если управление выполняется через межсетевой экран, проверьте, как обрабатываются новые и уже установленные соединения, IPv4 и IPv6, TCP и UDP. Поведение UDP зависит от приложения, поэтому рассмотрите также режим обслуживания на его стороне. Сохраните доступ по SSH и VPN для управления, а также внутренний трафик, и убедитесь, что приём запросов остаётся закрытым и во время перезагрузки. Используйте отдельное временное правило, которое можно будет снять, не затрагивая остальные.

Разделяйте запрос на штатное завершение и подтверждение его завершения

Если используете systemctl stop, заранее проверьте ExecStop целевого unit-файла, время ожидания остановки и настройки принудительного завершения. Если ExecStop только отправляет запрос на завершение и сразу возвращает управление, systemd может принудительно завершить оставшийся процесс. В соответствии с описанием systemd предусмотрите ожидание штатного завершения.

Для службы, которой передают команду завершения через консоль, необходимо также обеспечить доставку правильной команды целевому процессу с символом перевода строки. В строках команд unit-файла конструкции оболочки $() и конвейеры не обязательно работают автоматически. Объедините нужные действия в небольшой скрипт, предусмотрев проверку того, что выбран правильный процесс, и ожидание его завершения. Если истёк тайм-аут, не продолжайте обновление с принудительным завершением — выясните, почему штатная остановка не удалась.

6. Разделяйте обычное обновление на получение индексов, проверку плана и установку

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

# この段階ではパッケージを更新しない
sudo apt-get update -o APT::Update::Error-Mode=any &&
  sudo apt-get -s --no-remove dist-upgrade

Проверьте код завершения имитации и планируемые обновления, добавления и удаления. --no-remove — условие остановки, если для обновления требуется удалить пакеты. Для некоторых обновлений, например ядра, могут понадобиться новые пакеты, поэтому не требуйте, чтобы число добавляемых пакетов всегда было равно 0. Согласно описанию APT, состояние во время имитации не фиксируется. Непосредственно перед запуском проверьте, что не выполняется другая операция APT и что план не изменился.

Если план приемлем и целевые службы остановлены, переходите к установке. В среде с needrestart можно, например, вывести дополнительные предложения о перезапуске в виде списка:

# 通常更新の予定を確認し、必要なサービスを正常停止した後に実行する
sudo env NEEDRESTART_MODE=l apt-get --no-remove dist-upgrade

NEEDRESTART_MODE=l задаёт режим вывода списка needrestart. Это не запрещает все перезапуски служб, которые выполняют собственные сценарии настройки пакетов. Учитывая влияние на SSH и VPN, проводите работы в окне обслуживания, когда доступен канал восстановления. Не добавляйте -y без проверки и не задавайте без разбора замену всех файлов конфигурации.

На случай разрыва SSH используйте административный сеанс, который продолжит работу после отключения, например tmux, и сохраните результат завершения команды. При автоматическом запуске непосредственно перед выполнением проверьте целевой хост, версию ОС, результат сверки настроек, проверку резервной копии и состояние остановки служб; сохраняйте и промежуточные этапы. Не запускайте то же обновление повторно только потому, что соединение прервалось.

Как обращаться с обновлениями, отложенными поэтапной доставкой

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

Однако подготовка к обновлению выпуска — отдельный случай. Согласно официальной процедуре Ubuntu, текущий выпуск следует обновить, в том числе установив пакеты, отложенные поэтапной доставкой. Перед do-release-upgrade выполните официальные требования, действующие на тот момент. Поскольку при таком обновлении может потребоваться замена или удаление пакетов, не используйте без изменений команду для обычного обновления, приведённую выше.

Перед запуском проверьте, какой целевой выпуск предлагается:

sudo do-release-upgrade -c

Убедитесь, что предлагается нужный выпуск LTS, а обновление и перезагрузка текущего выпуска, проверка восстановления и совместимости уже завершены. После этого выполните sudo do-release-upgrade в окно обслуживания. Если целевой выпуск не предлагается, проверяйте условия его доступности. Не продолжайте, указывая предварительный выпуск. Если появится запрос на изменение файла конфигурации, изучите различия и оцените влияние на настройки подключения и аутентификации.

7. Если SSH не восстанавливается, последовательно проверьте сеть и запуск

Если подключиться по SSH не удаётся, через консоль восстановления проверьте следующее.

Этап проверки	Примеры проверки	Что исследовать дальше
Запущена ли ОС	Консоль, systemctl --failed	Аварийный режим, сбойные unit-файлы, прерванная настройка пакетов
Есть ли IP-адрес и маршрут	ip address, ip route	Источник конфигурации Netplan, имя интерфейса, изменение маршрутов
Ожидает ли SSH подключения	sshd -t, служба или socket SSH	Ошибка конфигурации, фактический порт прослушивания
Доступен ли сервер извне	Подключение с другого хоста	Межсетевой экран, VPN, правила сетевого доступа в облаке

Проверяйте journal для текущей загрузки. Выясните причину сбоя или отмены команды с помощью journalctl -b -u 対象unit, а зависимости проверьте командой systemctl show 対象unit -p After -p Before -p Requires -p Wants.

Если запуск VPN для подключения отменяется, проверьте не только настройки сети, но и порядок запуска. Например, старый socket unit может ожидать запуска VPN, а VPN — другого этапа загрузки, образуя цикл. Сначала проверьте, какие службы фактически ожидают подключения и обмениваются данными, а затем измените только те unit-файлы, назначение которых утратило актуальность. При активации через socket служба, ожидающая подключений, может оставаться в состоянии inactive — это нормально. Не считайте её ненужной только на основании отображаемого состояния.

Если cloud-init повторно генерирует настройки сети

cloud-init — механизм первоначальной настройки облачной среды и других параметров. Если в вашей конфигурации администратор самостоятельно поддерживает существующие настройки Netplan, проверьте, не изменятся ли они после обновления при повторной генерации. Отключение генерации сетевых настроек задаётся в управляемом файле в /etc/cloud/cloud.cfg.d/ следующим образом.

network:
  config: disabled

Эта настройка отключает только генерацию сетевой конфигурации в cloud-init. Не применяйте её без разбора в средах, где сеть настраивается из метаданных облака. Проверьте, кто управляет настройками, сохраните существующий Netplan и сравните его хеш, изучите результат генерации и убедитесь, что после обычной перезагрузки связь работает.

8. Проверяйте совместимость аутентификации и запуска только для используемых компонентов

Ниже приведены проверки для сред, где используется соответствующее ПО. Устанавливать его на серверы, где оно не применяется, не нужно.

Если Samba обеспечивает аутентификацию в домене Windows

Samba AD/DC — конфигурация, обеспечивающая аутентификацию и работу каталога домена Windows. При переходе на Ubuntu 26.04 следуйте официальным примечаниям к обновлению и проверьте наличие пакета samba-ad-dc в старой ОС.

dpkg-query -W -f='${Status}\n' samba-ad-dc
apt-cache policy samba-ad-dc

Убедитесь, что пакет имеет статус install ok installed. Если он не установлен, проверьте официальные источники пакетов и планируемые добавления, а затем установите его в старой ОС. Не смешивайте установку недостающих пакетов с пересозданием домена или изменением его функционального уровня.

Для резервного копирования используйте подходящий режим samba-tool domain backup, а не простое копирование файлов базы данных. При проверке восстановления проверяйте не только базу, но и ответы каталога в изолированной среде. При проверке с Samba 4.23 встречались случаи, когда запуск не удавался из-за отсутствия /run/samba/nmbd — внутреннего каталога для socket, даже если расположение БД и PID было изменено. Раздельная проверка постоянных данных и каталогов времени выполнения помогает отличить повреждение резервной копии от нехватки компонентов тестовой среды.

Если SSSD взаимодействует с внешней системой аутентификации

SSSD позволяет подключить Linux к системам пользовательских данных и аутентификации, например AD или LDAP. В SSSD 2.10 параметр config_file_version устарел. Если в настройках осталась старая запись, перед её исправлением сохраните владельца и права исходного файла, а затем выполните проверку командой sudo sssctl config-check.

Также проверьте способ запуска. Возможен конфликт между responder, запускаемым monitor самого SSSD, и тем же responder, запускаемым через socket systemd. Responder — процесс, который обслуживает запросы пользовательской информации и аутентификации. Сверьте настройки с описанием конфигурации установленной версии и журналом; меняйте только конфликтующие параметры.

После исправления проверьте получение пользовательской информации, необходимую аутентификацию и состояние домена Online. При подключении к AD проверьте также adcli testjoin с существующим machine key. Прежде чем перевыпускать ключ или повторно присоединять систему к домену, выясните, не вызвана ли проблема настройками или способом запуска.

Если обновление прервалось и пакеты или файлы запуска остались в неполном состоянии

Сначала проверьте не настроенные пакеты и зависимости командами sudo dpkg --audit и sudo apt-get check. Если выполняется другая операция APT или dpkg, не запускайте ещё одну параллельно. Не удаляйте файлы блокировки и не пытайтесь обойти их принудительно.

Если процесс уже завершился и подтверждено, что нужно продолжить настройку не настроенных пакетов, возобновите её командой sudo dpkg --configure -a. Проверьте результат, прежде чем переходить дальше. Если остались проблемы с источниками пакетов или зависимостями, сначала устраните их.

Даже если новое ядро установлено, система не запустится нормально, если отсутствует необходимый для загрузки initrd. Проверьте объём свободного места в /boot, установленные ядра и соответствующие им файлы запуска. Команда update-initramfs -c -k 対象バージョン создаёт initrd, а -u обновляет существующий — это разные задачи. Описание update-initramfs

Выбирайте ядро для восстановления из списка установленных версий. uname -r показывает работающее сейчас ядро, поэтому это может быть старая версия, использовавшаяся до обновления.

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

9. Сверьте условия завершения после перезагрузки

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

Условие завершения	Что подтверждает выполнение
Система загрузилась обычным образом	Boot ID изменился; система не осталась в консоли восстановления или аварийном режиме
Работают запланированные ОС и ядро	/etc/os-release и uname -r. Не определяйте это только по списку установленных версий
Пакеты находятся в согласованном состоянии	Результаты dpkg --audit и apt-get check
Нужные службы запустились автоматически	Состояние служб, socket и контейнеров, сбойные unit-файлы, ответы извне
Подключение и аутентификация работают	SSH, VPN и нужные маршруты аутентификации проверены с другого хоста
Временные изменения отменены	Приём запросов, межсетевой экран, timer, hold, различия unit-файлов и настроек
Состояние после обновления можно восстановить	Результат восстановления новой резервной копии и сведения о проверке

Проверяйте работу не только из обновлённого хоста, но и с другого хоста, подключённого как можно ближе к реальному пути пользователя. Для API убедитесь, что корректный запрос завершается успешно, а на маршрутах, где нужна аутентификация, запрос без неё отклоняется в соответствии с требованиями. Ответ HTTP 200 сам по себе не подтверждает работу границы аутентификации или основных функций приложения.

После возобновления приёма запросов убедитесь, что временные unit-файлы и правила обслуживания удалены. Если для объекта предусмотрено резервное копирование, сохраните его состояние после завершения работ и восстановите для проверки новую версию резервной копии. Не используйте успешное восстановление копии, сделанной до обновления, как доказательство пригодности новой. Если резервное копирование намеренно было остановлено, сохраните исходное состояние остановки.

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