Сервер не перезагружали два года: как проверить, что он вообще поднимется

MAATRIX

Вы открываете uptime и видите цифру, от которой немного холодеет — что-то вроде «712 days». Сервер работает, сайты отвечают, все привыкли, что перезагружать его не нужно. Но именно поэтому перезагрузка теперь пугает: никто не знает, что случится, когда питание пройдёт полный цикл, а не просто «сервис перезапустили». За два года без ребута внутри накопилось непроверенное ядро, забытые вручную запущенные процессы и службы, чей автозапуск мог незаметно сломаться. Разберём, что именно рискует не пережить перезагрузку, как это проверить заранее, не выключая сервер, и как подготовить план так, чтобы даже неудачный ребут не превратился в аварию на весь день.

Почему долгий аптайм — это не показатель надёжности, а слепая зона

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

Разница принципиальная. Пока сервер не перезагружается, он живёт на состоянии, собранном в памяти при последнем старте, плюс всё, что применено «на лету» с тех пор: правила iptables/nft, добавленные командой без сохранения в конфиг, интерфейсы, поднятые вручную через ip link, процессы в screen или nohup, никогда не оформленные как systemd-юнит. Всё это работает прямо сейчас — и совсем не обязано подняться снова после reboot, потому что перезагрузка не «продолжает» текущее состояние, а собирает систему заново по тому, что реально записано на диск: юнит-файлы с флагом enabled, /etc/fstab, конфиги сетевых интерфейсов, скрипты автозапуска.

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

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

Что конкретно может не пережить перезагрузку

Прежде чем проверять и готовиться, стоит явно перечислить категории риска — иначе легко проверить одно и пропустить другое.

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

Забытые процессы вне автозапуска. Классика — тестовый скрипт через nohup python3 worker.py & или screen/tmux сессия «на пару часов проверить», ставшая частью прода. Его не видно в systemctl status, он не переживёт даже штатный reboot, а если сессию давно закрыли, о его существовании вспомнят только когда что-то перестанет работать после ребута.

Дрейф автозапуска служб. Служба когда-то запущена командой systemctl start без enable, или наоборот — enable есть, но юнит правлен руками и с тех пор не проходил daemon-reload. Разбираем подробно в следующем разделе.

Ручные сетевые и firewall-правила. Правило iptables, добавленное в терминале для теста и ни разу не сохранённое (iptables-save > /etc/iptables/rules.v4), исчезнет при перезагрузке молча — сеть поднимется, но часть портов внезапно снова закрыты или наоборот открыты.

Точки монтирования без правки /etc/fstab. Диск, примонтированный вручную через mount /dev/sdb1 /data, при перезагрузке просто не примонтируется — приложение либо упадёт, либо начнёт писать прямо в корневой раздел, постепенно забивая его.

Устаревшие записи fstab, которые раньше не мешали. Строка ссылается на диск, отключённый или переименованный два года назад, но система никогда не пыталась смонтировать её заново — до следующей загрузки. Некоторые дистрибутивы при ошибке монтирования уходят в emergency shell и ждут пароль root на консоли.

Снимите точный слепок текущего состояния, пока сервер ещё жив

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

# какое ядро реально загружено сейчас и что установлено на диске
uname -r
dpkg -l 'linux-image*' 2>/dev/null || rpm -qa 'kernel*'   # Debian/Ubuntu или RHEL/AlmaLinux

# все запущенные процессы — сверить после ребута, что ничего не потерялось
ps auxf > /root/pre-reboot-processes.txt

# что слушает порты прямо сейчас
ss -tlnp > /root/pre-reboot-listening.txt

# включённые и активные unit-файлы systemd
systemctl list-unit-files --state=enabled > /root/pre-reboot-enabled-units.txt
systemctl list-units --type=service --state=running > /root/pre-reboot-running-units.txt

# смонтированные файловые системы и место на диске
df -h > /root/pre-reboot-disks.txt
mount > /root/pre-reboot-mounts.txt

# сетевые интерфейсы и маршруты как они есть прямо сейчас
ip a > /root/pre-reboot-network.txt
ip route >> /root/pre-reboot-network.txt

# активные правила firewall в рантайме
iptables-save > /root/pre-reboot-iptables.txt 2>/dev/null || nft list ruleset > /root/pre-reboot-nftables.txt

Особое внимание — на ss -tlnp и systemctl list-units --state=running, сверенные друг с другом. Если порт слушает процесс без соответствующего systemd-юнита (например, голый python3-скрипт), это кандидат на «не переживёт перезагрузку» — оформите его как unit-файл с enable до ребута, а не полагайтесь на память о том, что «его кто-то когда-то руками запустил».

Также стоит проверить, что fstab не соврёт при следующей загрузке — без реального размонтирования это делается через findmnt --verify (проверка синтаксиса и логики файла) и mount -a --fake (имитация монтирования всех записей без реального выполнения — покажет ошибки, если запись ссылается на несуществующее устройство или UUID).

Автозапуск служб: разница между «работает» и «включено»

Самая частая ошибка при подготовке к перезагрузке — проверить, что служба сейчас active (running), и на этом успокоиться. systemctl status показывает текущее состояние, но не отвечает на вопрос, поднимется ли служба сама после ребута — за это отвечает отдельный флаг:

systemctl is-enabled nginx
systemctl is-enabled postgresql
systemctl is-enabled ваш-сервис

Возможные ответы и что они значат:

• enabled — служба стартует сама при загрузке. Это то, что нужно для всего, что должно работать без ручного вмешательства.
• disabled — служба может быть active, потому что её когда-то запустили вручную, но при перезагрузке она не поднимется. Ровно тот случай, когда «работает уже год» создаёт ложное ощущение, что всё настроено правильно.
• static — юнит запускается как зависимость другого юнита; само по себе не ошибка, но стоит проверить, что тот, кто его тянет, действительно enabled.
• masked — служба принудительно заблокирована, даже если что-то попытается стартовать её как зависимость. Если видите masked у того, что должно работать, — это почти всегда след чьей-то отладки, о которой все забыли.

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

comm -23 \
  <(systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort) \
  <(systemctl list-unit-files --state=enabled --no-legend | awk '{print $1}' | sort)

Всё, что попадёт в этот список, — службы, которые сейчас работают, но не подтверждены как автозапускаемые. По каждой нужно решить: включить (systemctl enable имя) или осознанно оставить как есть, если это разово запущенная задача, которая после перезагрузки действительно не нужна.

Отдельно стоит перепроверить юниты с Restart= и зависимостями (After=, Requires=) — если сервис зависит от сети, а конфигурация была написана до того, как сервер перешёл на другую схему именования интерфейсов, After=network-online.target может не сработать так, как задумано, и сервис попытается стартовать раньше, чем сеть реально готова.

Снапшот и бэкап перед перезагрузкой — это не одно и то же

Снапшот диска или всей виртуальной машины на уровне гипервизора (Proxmox, ESXi, панель хостера) — самый быстрый способ подготовиться к рискованной операции: если после перезагрузки что-то пошло не так, откат к снапшоту возвращает состояние диска буквально за минуты, без разбора, что именно сломалось.

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

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

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

Для баз данных отдельно убедитесь, что снапшот делается консистентно: если СУБД пишет на диск в момент снятия снапшота без паузы записи, файлы данных могут зафиксироваться в промежуточном состоянии. Для большинства СУБД с журналированием транзакций (WAL/binlog) это не катастрофа — восстановление проходит через replay журнала, но лучше сверить с документацией конкретной базы.

Выбор окна и план отката

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

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

Доступ к консоли хостера — проверьте его до, а не во время. Если сеть после ребута не поднимется, единственный путь внутрь — веб-KVM, IPMI/iDRAC/iLO или serial console панели хостера. Многие администраторы годами не заходят в эту консоль и не помнят логин или второй фактор от неё. Зайдите в неё заранее, чтобы не тратить критичные первые минуты на восстановление доступа к самому инструменту восстановления.

Явный план отката. Запишите заранее, а не придумывайте на ходу: как загрузиться со старым проверенным ядром через меню GRUB, если новое не поднимет сеть; как быстро откатить снапшот, если восстановление руками займёт больше времени, чем окно; кто ещё в команде в курсе перезагрузки и может подстраховать, если вы недоступны.

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

Сама перезагрузка: чек-лист первых минут

Когда подготовка закончена — снимок состояния сделан, автозапуск сверен, снапшот и бэкап свежие, консоль хостера проверена, — сама перезагрузка проходит по плану:

1. Откройте консоль хостера (KVM/IPMI/serial) в отдельном окне ещё до команды перезагрузки — так вы увидите загрузку живьём, а не будете гадать по недоступности ping.
2. Выполните sync перед reboot, чтобы гарантированно сбросить буферы файловой системы на диск.
3. Наблюдайте загрузку через консоль: какое ядро реально стартовало (сверьте с записанным заранее uname -r), нет ли ошибок монтирования fstab, не завис ли процесс на initramfs.
4. Как только сеть отвечает — зайдите по SSH и сразу проверьте systemctl --failed: команда покажет все юниты, которые попытались стартовать и не смогли.
5. Сверьте ss -tlnp с сохранённым до перезагрузки списком портов — любое расхождение означает, что сервис не поднялся или поднялся не на том порту.
6. Проверьте df -h и mount на совпадение с записанным состоянием — особенно ручные точки монтирования.
7. Прогоните функциональную проверку приложения (реальный HTTP-запрос, подключение к базе, ответ очереди задач) — процесс может быть active, но не отвечать по существу.

Если что-то из списка не сошлось — не пытайтесь чинить всё сразу вручную под давлением времени. Откатитесь на снапшот или на предыдущее ядро через GRUB, разберитесь в спокойном режиме, задокументируйте причину и повторите попытку в следующем окне уже с исправленной причиной.

Частые вопросы