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

MAATRIX

Вам достался сервер — по наследству от уволившегося админа, вместе с купленным проектом или просто как новая зона ответственности — и рано или поздно встаёт вопрос: а что будет, если его перезагрузить. Не потому что вы точно знаете, что он давно не перезагружался — вы вообще не знаете его историю. Может, ребутили месяц назад, может, три года. Документации нет, спросить не у кого, а перезагрузка нужна: обновление ядра, зависшая служба, миграция, или просто вы хотите убедиться, что сервер переживёт внезапное отключение питания в дата-центре. Разберём, как подготовиться к первой перезагрузке любого унаследованного сервера — независимо от того, сколько он уже работает без ребута.

Чем этот случай отличается от «сервер два года не перезагружали»

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

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

Почему для чужого сервера риск перезагрузки выше, чем для своего

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

Три конкретных отличия от «перезагрузить свой привычный сервер»:

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

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

Шаг 1: полная опись того, что должно подняться

Прежде чем нажимать reboot, нужно точно знать, что на сервере вообще есть и что из этого обязано пережить перезагрузку. Полный разбор механизмов автозапуска — systemd, cron @reboot, rc.local, SysV init-скрипты — выходит за рамки этой статьи: подробная методика с командами по каждому источнику разобрана в статье полная опись автозапуска: что поднимется при следующей загрузке. Прочитайте её и пройдите по ней перед тем, как продолжать здесь — без этого шага остальная подготовка теряет смысл, потому что вы будете готовиться к перезагрузке того, что, как вам кажется, есть на сервере, а не того, что там есть на самом деле.

Здесь — минимальный набор команд, чтобы зафиксировать текущее состояние и свериться после ребута:

# что сейчас реально запущено
ps auxf > /root/pre-reboot-processes.txt

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

# что enabled и что running — и расхождение между ними
systemctl list-unit-files --state=enabled > /root/pre-reboot-enabled.txt
systemctl list-units --type=service --state=running > /root/pre-reboot-running.txt

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 имя, если она должна работать всегда, или осознанно оставить как есть, если это разовый процесс. Скопируйте эти файлы не только на сам сервер, но и себе на компьютер — если сервер не поднимется, файлы на его же диске будут недоступны.

Шаг 2: снапшот и бэкап — сделайте оба, это не одно и то же

Для первой перезагрузки чужого сервера снапшот на уровне гипервизора (Proxmox, ESXi, панель хостера) — это самая быстрая страховка: если что-то не поднимется, откат занимает минуты, а не часы разбора. Но снапшот не заменяет бэкап данных — они решают разные задачи, и это разобрано отдельно в статье миф: снапшот виртуалки заменяет бэкап. Коротко: снапшот обычно живёт на том же хранилище, что и сервер, и не спасёт, если откажет само хранилище или диск.

Перед перезагрузкой унаследованного сервера сделайте оба:

1. Снапшот всей виртуальной машины или диска — как кнопку отмены на случай проблем с загрузкой.
2. Бэкап данных в отдельное хранилище — базы данных, конфиги, пользовательские файлы, не зависящие от того же диска или той же виртуалки.

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

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

Шаг 3: проверьте доступ к консоли хостинга до, а не во время

Это тот шаг, который чаще всего пропускают именно на унаследованном сервере — потому что предыдущий администратор мог настраивать доступ к панели хостинга сам, а вам передали только SSH-ключ или пароль от самой операционной системы. Если после перезагрузки сеть не поднимется, единственный путь внутрь — веб-консоль хостера: KVM-over-IP, IPMI/iDRAC/iLO для выделенных серверов или serial console в панели VPS-провайдера. Как это работает и зачем нужно — в статье KVM-доступ к серверу: зачем и как.

Проверьте заранее, до самой перезагрузки:

• Есть ли у вас логин в панель хостинга (не только доступ к самой машине по SSH) — это часто отдельная учётная запись, которую забывают передать вместе с сервером.
• Работает ли второй фактор для входа в панель, если он настроен, и есть ли у вас к нему доступ.
• Открывается ли консоль реально — зайдите в неё один раз заранее, посмотрите на экран сервера прямо сейчас, пока всё работает штатно. Это тренировка, которая экономит критичные первые минуты, если сеть после ребута не ответит.
• Если сервер у стороннего хостера, а не в вашей же инфраструктуре — узнайте телефон или чат поддержки на случай, если понадобится физическое вмешательство (например, сервер завис на уровне BIOS).

Без этого шага любая другая подготовка теряет часть смысла: снапшот и опись автозапуска не помогут, если вы физически не можете попасть внутрь сервера, чтобы применить откат или посмотреть, что происходит на экране загрузки.

Шаг 4: выберите окно и явно запишите план отката

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

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

Явный план отката, записанный заранее, а не придуманный на ходу:

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

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

Сама перезагрузка и проверка после неё

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

# сброс буферов файловой системы перед ребутом
sync

# сама перезагрузка
reboot

Порядок действий:

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

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

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