Когда сервер перестаёт загружаться, тратить время на запись очередной флешки через dd поздно. Набор инструментов должен лежать готовый. Универсальная загрузочная флешка на связке Ventoy и SystemRescue решает задачу элегантно: вместо "одна флешка равно один образ" получается меню загрузки с десятком ISO одновременно, а live окружение SystemRescue содержит весь нужный инструментарий для диагностики дисков, спасения данных, ремонта файловых систем и пересборки начального окружения. Разберём, из чего состоит такой набор, как его собрать и где он окупается в реальной практике.
Ventoy заменяет разовую запись образов простым копированием ISO файлов на флешку
Ventoy это открытый загрузчик, который устанавливается на флешку один раз. После этого работа строится по принципу "закинул файл и готово": в каталог флешки копируются ISO образ целиком, меню загрузки строится автоматически, остаётся выбрать нужный объект в GRUB меню при старте. Поддерживаются Linux дистрибутивы, установщики Windows, образы тебяющих сборщиков и гибридные live окружения.
Установка на Linux занимает пару команд:
wget https://example.com/ventoy-1.0.99-linux.tar.gz
tar xzf ventoy-1.0.99-linux.tar.gz
cd ventoy-1.0.99
sudo ./Ventoy2Disk.sh -i /dev/sdXФлаг -i применяет стандартную разметку GPT, ключ -g включает совместимость с UEFI, -s активирует поддержку Secure Boot. После установки Ventoy создаёт два раздела: основной в exFAT (при желании можно переформатировать в NTFS или ext4) для хранения ISO и скрытый системный. Досуг пополнения простой: скачали свежий выпуск SystemRescue, немедленно скопировав его в корень флешки.
Стоит упомянуть версионную аккуратность: проект Ventoy активно обновляется, и обновить его на уже записанной флешке можно без перезаписи данных через тот же скрипт с ключом -u. Старые образы и E2B подобные конструкции давно устарели, Ventoy давно вытеснил их за счёт простоты.
Отдельный плюс это плагины. Через ventoy.json можно настроить постоянное хранилище persistence, файловую загрузку драйверов, применение автоустановочных ответов для поддерживаемых дистрибутивов, а также проверку контрольных сумм при загрузке. Для задач восстановления это уже избыточно, но для инсталляторов пригождается.
Минимальный рабочий набор на флешке выглядит так:
- SystemRescue ISO как универсальное окружение первичной помощи;
- образ установщика нужного дистрибутива для пересборки ядра и загрузчика в chroot;
- Memtest86+ для проверки ОЗУ при подозрении на железо;
- GParted Live для разметки дисков в графической среде;
- свежий точный дубликат текущего продакшн дистрибутива с той же версией ядра, что и на сервере.
Последний пункт решает часто забываемую проблему: пересборка initramfs в chroot потребует исходных пакетов ядра, и наличие ISO образа с тем же дистрибутивом заметно упрощает задачу.
SystemRescue собирает инструменты диагностики дисков и разделов в одном live окружении
SystemRescue это специализированный дистрибутив на базе Arch Linux, собранный именно под сценарии спасения и ремонта систем. Сам загружаемый образ умеет работать с readonly оригинальными разделами, и поднимает на борту большой список утилит. Среди них smartmontools, lvm2, mdadm, архиваторы, сетевые клиенты, файловые системные сервисы и достаточно драйверов чтобы узнать железо от старого сервера до современного NVMe.
Запуск простой: флешка стартует, Ventoy показывает список ISO, загружается SystemRescue, и система поднимается полностью в памяти. Жесткий диск сервера при этом остаётся в покое: никакие данные не трогаются до явного монтирования.
Диагностика начинается с таблиц разделов и дисков:
lsblk -f
fdisk -l
smartctl -a /dev/sda
nvme smart-log /dev/nvme0Утилита smartctl показывает атрибуты S.M.A.R.T.: счётчики переназначенных секторов, температура, время наработки, текущие отложенные ошибки. При высоком значении Current_Pending_Sectors или Reallocated_Sector_Ct надежнее сразу перейти к спасению данных, а не экспериментировать с дальнейшей записью.
Проверить диск на чтение позволяет команда badblocks в безопасном режиме:
badblocks -sv /dev/sdaДля старых вращающихся дисков это полноценный тест на час, но он надёжно выявляет деградацию магнитных поверхностей. Для NVMe достаточно smart логов и журнала ошибок фирмваре.
Восстановление данных с повреждённого диска через ddrescue и TestDisk
Когда диск читается с ошибками, главное правило - сначала поблочная копия, потом любые попытки ремонта. Работать с деградирующим накопителем через обычную файловую операцию равносильно лотерее: каждая перезагрузка и каждая fsck нагружают слабые сектора.
GNU ddrescue это стандартный инструмент аккуратного копирования. Он читает диск сначала быстрыми здоровыми участками, пропуская сбойные, и только потом проходит недочитанные блоки повторно:
ddrescue -d -f -n /dev/sda /dev/sdb rescuelog.map
ddrescue -d -f -r3 /dev/sda /dev/sdb rescuelog.mapПервая строка копирует без повторов попыток, вторая приводит три захода на проблемные сектора. Файл карты rescuelog.map позволяет прерывать и возобновлять процесс.
После спасения содержимого на здоровый диск можно поднимать разделы. Если повреждена сама таблица разделов, TestDisk анализирует диск, находит удалённые разделы и пересоздаёт таблицу без потери данных. Режим photorec, уже входящий в комплект, вытаскивает файлы из умершей структуры, распознавая сигнатуры в сыром потоке.
Проверка и ремонт файловых систем из live окружения
Типичный сценарий после некорректного выключения сервера: сбойная сбрасывание журнала, загрузчик выпадает в initramfs или в аварийную консоль, и дальше система не стартует без ручного вмешательства.
В SystemRescue доступны все стандартные программы проверки:
fsck -y /dev/sda1
xfs_repair /dev/sda2
btrfs check --readonly /dev/sda2fsck из пакета util-linux автоматически трактует семейство ext2, ext3, ext4 и вызывает соответствующий модуль. Параметр -y отвечает утвердительно на запросы на исправления. Для XFS вместо fsck на самом деле используется xfs_repair, набор XFS прочно защищает журнал без ручных вмешательств. Для btrfs команда check с флагом readonly обычно достаточна для диагностики, а починка часто делается через scrub и замену сбойных устройств.
Команды выполняются строго на отмонтированных разделах, иначе данные гарантированно пострадают. Перед стартом проверки убеждаются через mount и lsblk, что раздел нигде не используется, а swap остановлен swapoff -a, если виртуальная память поднята была вручную. Полезна привычка делать снапшот LVM перед ремонтом: если корень лежит на логическом томе, команда lvcreate -s -n snap /dev/vg0/root мгновенно фиксирует точку возврата.
После корректного закрытия файловых систем стоит проверить загрузчик. Часто причина проблемы в повреждённом ядре или неудачной сборке initramfs, и об этом отдельно говорится дальше в статье.
Сброс паролей и правка конфигурации через chroot в корневой раздел
Работа в chroot это техника подмены корневого каталога из live окружения. Понадобится смонтировать разделы проблемной системы и системные виртуальные файловые системы из текущего запуска:
mount /dev/sda2 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mntВнутри chroot доступны все родные утилиты дистрибутива. Отсюда выполняется смена пароля через passwd, правка конфигурации загрузчика, пересборка initramfs через dracut или update-initramfs, откат неудачных пакетов. Перезагрузка после выхода из chroot запускает сервер уже на "своих" пакетах, но в отремонтированном окружении.
Особая хитрость UEFI систем: корректно описать раздел /boot/efi. При его монтировании в chroot инструменты efibootmgr смогут править загрузочные записи NVRAM материнской платы:
mount /dev/sda1 /mnt/boot/efiПроверка памяти и железа плюс сетевые инструменты окружения
Не каждый отказ загрузки это проблема софта. Нестабильная оперативная память вызывает битые пакеты ядра, случайные паники и фантомную порчу файловых систем: Любые нестабильности проверяют Memtest86+ или встроенным memtest в составе SystemRescue.
Запускается из меню Ventoy, проходит четыре прохода для надёжного результата. Одиночная ошибка на всю серию иногда встречается на граничных конфигурациях XMP, но повторяющиеся ошибки на любых адресах означают замену модуля.
Параллельно смотрят логи железа: edac-util для серверов с ECC, sensors для температур, dmesg на последних строках перед падением. В live консоли удобно заглянуть в журнал предыдущих запусков проблемной системы через:
mount /dev/sda2 /mnt
journalctl -D /mnt/var/log/journal -p err -b -1Эта команда выводит ошибки последней загрузки повреждённой системы без полного chroot и лишних движений.
Live окружение поднимает полноценную сеть. Интерфейсы настраиваются через NetworkManager привычной командой nmtui или nmcli, а дальше открывается простор для эвакуации данных через rsync или scp на соседний сервер:
nmcli dev status
rsync -aHAXS --numeric-ids /mnt/data/ Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. :/backup/rescue/Флаги латинские: a это архивный режим с сохранением прав, H держит жёсткие ссылки, X и A сохраняют расширенные атрибуты и списки контроля доступа. При подозрении на целостность корневой системы выгрузка пользовательских данных подобным способом обязательна, и только после неё логично запускать агрессивные процедуры ремонта.
Для массового клонирования дисков в наборе хорошо показывает себя Clonezilla, ещё один ISO в копилке Ventoy. Она поднимает Partclone внутри, умеет снимать образы компрессированными в SSHFS или NFS точку и разворачивать их обратно на аналогичное железо. На тех же ресурсах удобно подключить сетевую шару через mount -t nfs и просто скопировать в нужный каталог.
Практические советы по сборке флешки и проверке её перед настоящей аварией, а не в её напряжённом разгаре
Надёжный набор собирают не в момент паники, а заранее, и проверяют. Полезные наблюдения из практики.
Флешку берут качественную, от бренда с реальным USB 3.x контроллером. Дешёвые "ёмкие" модели нередко являются подделками с виртуальной памятью, и перезаписанные блоки начинают умирать через пару месяцев. На флешке резервируют 32 гигабайта минимум: этого хватит на десяток ISO и постоянное хранилище persistence для рабочей среды.
Раз в квартал проверяют чтение всех ISO через встроенную вентойскую проверку контрольной суммы, а саму флешку гоняют тестовой загрузкой на свежем железе. Прошлые аварии показывают, что исправная и проверенная флешка сокращает время простоя сервера с часов до минут, и стоит она в пересчёте на время ничто.
Среди хранящихся инструментов полезно оставить текстовые заметки о специфике конкретной инфраструктуры: какие именно разделы у корня, на каком устройстве лежит EFI раздел, какая файловая система внутри. В стрессовый момент эта шпаргалка экономит драгоценное время на вспоминание разметки.
Отдельный пункт касается обновления набора. Дистрибутивы вроде SystemRescue обновляются регулярно, и раз в полгода стоит заменять ISO на свежий, чтобы в наборе были актуальные ядра и драйверы, способные увидеть новые чипсеты. Одновременно обновляют и сам Ventoy.
Небольшая деталь, которую забывают: макеты клавиатуры и раскладки в консоли. Для работы по SSH это неважно, а с KVM консоли физически набор паролей с русской раскладкой иногда становится невозможным. Закидывают на флешку чек-лист по смене пароля, и в новых выпусках SystemRescue конфигурация ограничивается простым setkmap.
И финальный принцип: набор восстановления должен быть доступен физически. Если сервер в удалённом датацентре и доступ туда только через KVM консоль, стоит иметь аналогичный набор ISO рядом с рабочим ноутбуком, чтобы тот же самый SystemRescue можно было пробросить в виртуальный дисковод и повторять уже отработанные сценарии.