Выделенный сервер не загружается, SSH недоступен: план действий через KVM

MAATRIX · Выделенные серверы · Статья 48 из 48

После перезагрузки проходит минута, затем ещё одна. SSH молчит. Страница приложения не открывается. В такие моменты кнопка Reset выглядит удивительно убедительно: большая, понятная, обещает хоть какое-то действие.

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

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

Шаг 1. Убедитесь, что пропал сервер, а не путь к нему

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

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

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

Одновременно зафиксируйте начало инцидента и последние изменения. Было обновление ядра? Менялись правила firewall, сеть, диски или /etc/fstab? Сервер перезагрузили планово либо он исчез сам? Это не поиск виноватого. Это способ сузить количество версий, пока их ещё можно удержать в голове.

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

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

Шаг 2. Откройте консоль и сначала посмотрите

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

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

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

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

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

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

Шаг 3. Выберите ветку восстановления по экрану

Не проходит проверка оборудования или не видны диски

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

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

Ошибка появилась после обновления ядра

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

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

Система не находит корневой раздел

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

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

Загрузка остановилась на монтировании или службе

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

Нельзя лечить всякий emergency mode массовым отключением проверок. Одна неверная запись в /etc/fstab требует одного понятного исправления с сохранением прежнего состояния. А сообщение об ошибках файловой системы требует оценки её состояния, не косметического обхода.

Для ext2/ext3/ext4 утилита e2fsck отдельно предупреждает об опасности работы со смонтированной файловой системой. У других файловых систем свои средства и правила восстановления. Руководство e2fsck — хороший пример того, почему команда с автоматическим ответом «да» не должна становиться универсальным первым шагом.

Шаг 4. Если удалось войти локально, отделите ОС от сети

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

systemctl --failed
journalctl -b -p warning --no-pager
ip -br address
ip route
ss -lntp

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

Параметр -b ограничивает журнал выбранной загрузкой. Предыдущая загрузка доступна через journalctl -b -1, если её записи сохранились; при хранении журнала только в памяти после перезапуска они могут отсутствовать. Подробности выбора загрузки приведены в документации journalctl.

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

Проверьте, имеет ли интерфейс правильный адрес, существует ли ожидаемый маршрут и слушает ли SSH нужный порт. Название службы зависит от дистрибутива: встречаются ssh.service и sshd.service. Сначала выясните правильное имя, затем смотрите её состояние и журнал. Поведение команд проверки состояния описывает руководство systemctl.

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

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

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

Шаг 5. Перед записью на диски остановитесь и проверьте план

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

Ответьте на четыре вопроса. Что конкретно считаем причиной? Какое одно действие её проверит или устранит? Какие данные оно может изменить? Как вернуться назад, если гипотеза неверна? Эти ответы экономят время даже при сильном давлении со стороны бизнеса.

Если необходим rescue-образ, проверьте его источник и убедитесь, что выбран режим восстановления, а не автоматической установки. Посмотрите, какие накопители видит среда, прежде чем их монтировать. При работе с копией данных способ монтирования и поведение журналируемой файловой системы тоже имеют значение: простое слово read-only не во всех сценариях достаточно для гарантии отсутствия любых записей на исходный носитель.

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

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

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

Шаг 6. Верните приложение и завершите инцидент

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

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

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

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

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

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

Все материалы о выделенных серверах