Запуск системы спасения Hetzner - пошаговое руководство для администраторов серверов

Я покажу вам, как запустить систему спасения Гетцнера всего за несколько минут, как SSH войдите в систему и введите свой Сервер целенаправленное восстановление. В этом руководстве вы шаг за шагом пройдете весь путь от активации до восстановления, включая проверку файловой системы, резервное копирование и переустановку.

Центральные пункты

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

• Начало спасательной операцииАктивация в Роботе или Облаке, затем перезагрузка.
• SSH-доступВойдите в систему с ключом или паролем и правами root.
• Анализ ошибокПроверьте fsck, журналы, разделы.
• Резервное копирование данных: rsync, tar, scp для быстрого резервного копирования.
• Новая установкаinstallimage для свежих систем.

Что делает система спасения

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

Что практично, так это то, что среда спасения заведомо нестабильна: изменения исчезают после перезагрузки, а значит, я могу безопасно тестировать. При необходимости я устанавливаю временные инструменты (например, smartmontools, mdadm, lvm2, btrfs-progs или xfsprogs) без изменения продуктивной системы. Версия ядра современная и поддерживает новейшее оборудование, включая NVMe, UEFI, GPT, программный RAID (mdraid), LVM и шифрование LUKS. Это позволяет мне охватывать даже сложные системы хранения данных и выявлять даже редкие ошибки воспроизводимым способом.

Требования и доступ

Чтобы начать, мне нужен доступ к интерфейсу клиента и мой SSH-ключи или временный пароль. Я удобно управляю выделенными системами через Робот Хетцнерв то время как я управляю экземплярами в облаке через консоль. Оба интерфейса предлагают четкую опцию для активации режима спасения. Я заранее проверяю правильность IP-адреса сервера, доступность IPv6 и, если необходимо, внеполосные функции для перезагрузки. Такая подготовка значительно сокращает время простоя.

При первом входе в SSH я сознательно подтверждаю новый отпечаток пальца и при необходимости обновляю запись в Known Hosts, чтобы последующие соединения не завершились неудачей из-за предупреждений. Для команд я храню дополнительные ключи специально для спасательной операции и удаляю их после завершения. Если доступен только временный пароль, я меняю его сразу после входа в систему, а затем заменяю на Key-Auth - я последовательно деактивирую парольные логины по окончании работы.

Активация системы спасения - шаг за шагом

Я открываю окно подробной информации о сервере, выбираю опцию "Rescue" и устанавливаю архитектуру на linux64 для текущих систем, затем я вношу свой SSH-ключ. В зависимости от ситуации я запускаю только режим спасения и запускаю перезагрузку отдельно или использую "Activate Rescue & Power Cycle" для прямого перезапуска. Если машина зависает, я выполняю жесткий сброс через интерфейс. После загрузки интерфейс показывает временный пароль root, если я не ввел ключ. Как только сервер загрузится, он ответит на SSH, и я смогу приступить к работе.

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

Подключение по SSH и первые проверки

Я подключаюсь через SSH с ssh root@ и сначала проверьте сеть, носители данных и журналы, чтобы получить быстрый обзор Статус. С ip a и пинг Я проверяю наличие; journalctl --no-pager -xb или в файлах журнала на смонтированных дисках отображаются последние сообщения об ошибках. Команды lsblk, blkid и fdisk -l обеспечивают ясность в отношении компоновки и файловых систем. Для RAID я использую cat /proc/mdstat и mdadm --detail для определения состояния. Для исходных аппаратных показателей smartctl -a и короткий hdparm -Tt-тест.

LVM, RAID, LUKS и специальные файловые системы

Многие серверы используют LVM, программный RAID или шифрование. Сначала я активирую все соответствующие уровни:

• mdraid: mdadm --assemble --scan выводит существующие массивы; я проверяю состояние с помощью cat /proc/mdstat.
• LUKS: Я открываю зашифрованные тома с помощью cryptsetup luksOpen /dev/.
• LVMС vgscan и vgchange -ay Я активирую группы томов и вижу их через lvs/vgs/pvs.

В Btrfs я обращаю внимание на субтома и монтирую их специально с помощью -o subvol=@ соответственно -o subvolid=5 для верхнего уровня. Я проверяю XFS с помощью xfs_repair (никогда на смонтированных томах), в то время как Ext4 обычно используется с fsck.ext4 -f реорганизована. Я ориентируюсь на GUID/UUID из blkidпотому что имена устройств для NVMe (/dev/nvme0n1p1) и может меняться при изменении заказа. Я буду корректировать /etc/fstab.

Восстановление файловой системы и резервное копирование данных

Перед ремонтом я создаю резервную копию важных Данные с rsync, scp или tar на внешнюю или локальную цель Резервное копирование-директория. Для проверки я использую fsck только на немонтированных разделах, например fsck -f /dev/sda2чтобы исправить несоответствия. Затем я монтирую систему под /mntнапример, с mount /dev/sda2 /mntи присоединить подпути, такие как /proc, /sys и /dev когда я хочу использовать chroot. Отдельные файлы конфигурации, такие как /etc/fstab или сетевые настройки непосредственно в смонтированной системе. Осторожные действия позволят избежать последующего ущерба и минимизировать время простоя.

Для надежного резервного копирования я полагаюсь на повторяющиеся команды: rsync -aHAX --info=progress2 получает права, жесткие ссылки, ACL и xattrs. Если линия слабая, я дросселирую с помощью --bwlimit и распараллелить сжатие с помощью tar -I pigz. При необходимости я создаю изображение критических, неисправных носителей данных в блоках с ddrescue чтобы перенести логическую работу на образ. Я тщательно проверяю системы Btrfs с btrfs check --readonly и использовать btrfs scrubдля обнаружения тихих ошибок. XFS часто требует восстановления вне монтирования в случае несоответствий (xfs_repair) - Я всегда сначала создаю резервную копию раздела.

Восстановление UEFI/BIOS, GPT/MBR и загрузчика

Многие проблемы с загрузкой вызваны взаимодействием прошивки, схемы разделов и загрузчика. Сначала я уточняю, запускается ли сервер в режиме UEFI или в режиме устаревшего BIOS (ls /sys/firmware/efi). В UEFI я монтирую раздел EFI (типичный /dev/sdX1 или /dev/nvme0n1p1) до /mnt/boot/efi. Затем я запустил систему:

mount /dev/ /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Я переустановил загрузчик соответствующим образом (grub-install на нужное устройство) и перегенерировать конфигурацию и initramfs: update-grub и update-initramfs -u -k all (для систем на базе Дракут dracut -f). Если порядок расположения устройств неправильный, я использую /etc/default/grub UUID и проверка /etc/fstab для правильных записей. При смене GPT/MBR я проверяю, существует ли загрузочный раздел BIOS (для GRUB/BIOS) или действительный системный раздел EFI.

Сетевые ловушки при спасении

Проблемы с сетью часто являются причиной того, что службы "пропадают". В Rescue я проверяю состояние соединения (ip-ссылка), маршруты (ip r) и разрешение DNS (статус resolvectl соответственно cat /etc/resolv.conf). Я тестирую IPv4 и IPv6 отдельно (пинг -4/пинг -6). Для серверов с мостами или связью порядок интерфейсов в продуктивной системе может отличаться от среды спасения. Я записываю MAC-адреса и правильно их сопоставляю. Если производственная система использует Netplan, я проверяю /etc/netplan/*.yaml и переключитесь после создания chroot netplan generate и применять netplan на. Для классики /etc/network/interfaces-установки, я обращаю внимание на согласованность имен интерфейсов (предсказуемые имена по сравнению с eth0).

Переустановите операционную систему

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

Я намеренно использую монтирование на основе UUID для новых установок, чтобы исключить проблемы с порядком устройств в дальнейшем. При установке RAID-массивов я создаю массивы с самого начала и проверяю состояние пересборки перед восстановлением данных. Если вы развертываете подобные системы на регулярной основе, вы работаете с предопределенными шаблонами установочных образов и четкой логикой разметки (корневой раздел, отдельный раздел данных, раздел подкачки, EFI при необходимости). После первой загрузки я обновляю источники пакетов и ядра, активирую автообновление системы безопасности и выполняю базовые шаги по укреплению системы.

Безопасность, временное окно и рецидив

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

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

Пример: Спасение сервера WordPress

Я загружаюсь в режим спасения, монтирую системный раздел и создаю резервную копию База данных за mysqldump и wp-content-каталог с tar или rsync. Затем я проверяю файловую систему, перезагружаю загрузчик и исправляю неправильные конфигурации PHP или NGINX. Если пакеты повреждены, я использую chroot и переустанавливаю зависимости. Если этого недостаточно, я перезагружаю машину с помощью installimage и восстановите резервную копию и конфигурации. Наконец, я проверяю фронтенд, логин и cronjobs.

На практике я обращаю внимание на согласованность InnoDB (MySQL/MariaDB): Fails mysqld в самом начале, я закрепляю /var/lib/mysql и запустите дамп из свежего экземпляра. Я выборочно очищаю кэши (объектный кэш, кэш страниц, OPCache), последовательно устанавливаю разрешения на файлы (найти . -type d -exec chmod 755 {} ;, найти . -type f -exec chmod 644 {} ;) и проверьте open_basedir и директории загрузки. В качестве теста я деактивирую критические плагины, переименовав каталог плагинов. Затем я проверяю пулы PHP FPM, таймауты FastCGI, лимиты памяти и NGINX/Apache includes. Короткий wp cron event run --due-now (если доступен WP-CLI) помогает обрабатывать отставания.

Лучшие практики для администраторов

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

У меня также есть готовый контрольный список runbook, в котором указаны обязанности и пути эскалации. Запланированные "игровые дни" (целевые симуляции отказов) готовят команду к чрезвычайным ситуациям. Я регулярно тестирую резервные копии в качестве образца для восстановления - непроверенная резервная копия считается несуществующей. И я версифицирую свои системные конфигурации, чтобы быстро распознавать различия между "хорошим" и "неисправным" состоянием.

Облако и выделенная среда: различия в процессе

В облаке я часто меняю режим загрузки прямо в диалоге экземпляра и использую последовательную консоль для быстрой проверки, в то время как на выделенных серверах требуется цикл питания и, возможно, внеполосный доступ. Облачные тома можно удобно подключать к другим экземплярам - это эффективный способ резервного копирования данных без простоя на затронутом хосте. На "голом" металле я уделяю больше внимания физическому порядку расположения дисков, особенно при покупке дополнительных SSD/NVMe-модулей. В обоих мирах: Rescue является временным инструментом - я планирую возврат к нормальной загрузке в нужное время.

Сравнение: провайдеры с системой спасения

Помимо хорошего качества работы, быстрого восстановления Оборудование а также чисто интегрированный Спасатель-функция. В следующей таблице представлен компактный обзор набора функций и способов их использования. Я основывался на доступности, простоте доступа и типичных рабочих процессах администратора. Оценка "Рекомендовано" отражает мое практическое использование для решения типичных задач. Разумеется, весовые коэффициенты могут меняться в зависимости от целей использования.

Поставщик	Спасательная система в наличии	Простота использования	Производительность	Рекомендация
веб-сайт webhoster.de	Да	Очень хорошо	Очень высокий	Победитель испытаний
Hetzner	Да	Очень хорошо	Высокий
Страто	Частично	Хорошо	Средний
IONOS	Нет	Средний	Средний

Контрольный список: Последовательность действий в чрезвычайной ситуации

• Активируйте Rescue, запустите перезагрузку/цикл питания, протестируйте SSH.
• Просмотр аппаратного обеспечения/хранилища: smartctl, lsblk, blkid, mdstat, lvm.
• Активируйте массивы/LUKS/LVM, проверяйте файловые системы только для чтения.
• Создайте резервную копию (rsync/tar), затем fsck/Ремонт.
• Система под /mnt mount, bind mounts, chroot.
• Восстановите загрузчик/initramfs, проверьте конфигурацию сети.
• Тестовая загрузка, проверка служб, проверка мониторинга/сигналов тревоги.
• Деактивируйте Rescue, удалите временные ключи, обновите документацию.

Вопросы и ответы Спасательная система Hetzner

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

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

Работает ли это для облачных и выделенных серверов? Да, я запускаю режим как для выделенных машин, так и для облачных экземпляров в Облако Хетцнера.

Что делать, если загрузчик поврежден? Я монтирую root и, возможно, EFI, делаю chroot в системе, выполняю grub-install, update-grub и перестроить initramf, затем протестировать перезагрузку.

Как работать с LVM/RAID? Сначала я собираю mdraid, активирую LVM с помощью vgchange -ay а затем смонтируйте логические тома. Восстановление выполняется только после резервного копирования.

Можно ли сохранять только отдельные файлы? Да, я монтирую только для чтения и выборочно копирую конфигурации, базы данных (через дамп) или каталоги - минимально инвазивно и быстро.

Основная идея

С Hetzner Rescue System, у меня есть быстрый инструмент, который надежно определяет проблемы загрузки, ошибки файловой системы и поврежденные конфигурации. Я активирую режим, вхожу в систему по SSH, создаю резервную копию данных, а затем принимаю решение о восстановлении или переустановке. Это позволяет сэкономить Время в экстренных ситуациях и сокращает время простоя до минимума. Если вы усвоите эти несколько шагов, то сможете спокойно справляться даже со сложными авариями. Это означает, что работу сервера можно планировать, а перезапуск - контролировать.