# Hetzner GPU-сервер: Rescue System и восстановление SSH-доступа

Как восстановить доступ к выделенному GPU-серверу Hetzner через Robot и Rescue System: диагностика диска, SSH-конфигурации и безопасный порядок действий.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/hetzner-gex-root-rescue-access/
Language: ru

При потере SSH-доступа к выделенному GPU-серверу Hetzner используйте Robot и документированный Rescue System для диагностики. Это отдельная среда загрузки по сети, которая позволяет проверить установленную ОС. Перед восстановлением нужно определить причину, а не сразу переустанавливать сервер.

## Разделите Robot и доступ к ОС

Robot управляет сервером на уровне провайдера, а SSH обычно подключает вас к установленной операционной системе. Потеря ключа, ошибка firewall или неудачное обновление в ОС не обязательно означают потерю доступа к панели управления.

[Документация Rescue System](https://docs.hetzner.com/robot/dedicated-server/troubleshooting/hetzner-rescue-system/) описывает активацию режима в Robot и последующую загрузку. Сверяйте именно инструкцию dedicated server: похожие функции облачных виртуальных машин могут иметь другой порядок действий и другую панель.

## Сначала соберите симптомы

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

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

## Что проверить в Rescue

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

| Возможная причина | Что исследовать |
| --- | --- |
| Ошибка SSH-конфигурации | Изменённые параметры и журнал ОС |
| Неверный публичный ключ | Нужного пользователя и authorized_keys |
| Ограничение сети | Правила установленной системы |
| Заполненный диск | Свободное место и крупные журналы |
| Неудачная загрузка | Конфигурацию ОС и доступные журналы |

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

## Пример после изменения firewall

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

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

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

После успешного восстановления добавьте причину сбоя в рабочую инструкцию. Короткая запись о неверном правиле или ключе полезнее полного необработанного журнала.

## Подготовьте процедуру на будущее

[Руководство GPU-линейки](https://docs.hetzner.com/robot/dedicated-server/server-lines/gpu-server/) помогает сопоставить доступные административные средства с сервером. Сохраните инструкцию доступа к Robot, контакты ответственных и порядок проверки резервной копии. Эти материалы должны быть доступны вне самой машины.

Сопутствующие темы — [различие VPS и GEX](/ru/journal/hetzner-gpu-vps-vs-gex/) и [план выхода с GPU-ресурса](/ru/journal/gpu-exit-plan/). Доступ к диагностике и понятный ответственный за перезагрузку помогают обсудить эксплуатацию столь же предметно, как объём VRAM.