Проверка диска в ALT Linux: SMART, ошибки файловой системы и GParted

Сообщение «ошибка диска» может означать повреждение файловой системы, неисправный накопитель, плохой кабель или просто заполненный раздел. GParted показывает разметку и умеет запускать часть операций с файловыми системами, но не ремонтирует контроллер SSD и не заменяет SMART-диагностику. Сначала нужно выяснить, на каком уровне проблема, затем выбрать проверку. Иначе исправление метаданных на умирающем диске только увеличит объём чтения и риск потери данных.

В статье используется ALT Linux с RPM-пакетами и APT-RPM. Команды диагностики ориентированы на современную систему с systemd; версии утилит и состав репозиториев проверьте на своём выпуске. Примеры устройств /dev/sdb и /dev/sdb2 условные: заменять их нужно по модели, серийному номеру и схеме разделов, а не по совпадению буквы после перезагрузки.

Определите накопитель, раздел и симптом

Начните с обзорных команд. Они не исправляют данные и позволяют выбрать правильный объект:

cat /etc/os-release
uname -r
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt /
df -hT
df -ih

lsblk показывает дерево устройств. Disk — накопитель, part — раздел, lvm — логический том. FSTYPE позволяет отличить ext4 от XFS, Btrfs, swap, LUKS-контейнера и физического тома LVM. findmnt / устанавливает, где находится корневая файловая система. Две команды df отвечают на разные вопросы: свободные байты и свободные inode. При исчерпании inode создание файлов невозможно даже с большим остатком гигабайтов.

Для более старой версии lsblk, которая не знает MOUNTPOINTS, используйте MOUNTPOINT и сверяйте результат с findmnt. На сервере с шифрованием проверяется файловая система внутри открытого mapper-устройства, а не внешний раздел crypto_LUKS. У LVM проверять /dev/sdb2 с типом LVM2_member как ext4 нельзя: нужно найти логический том и его FSTYPE.

Посмотрите сообщения ядра, сохранив временной интервал:

sudo journalctl -k -b --no-pager | \
  grep -Ei 'I/O error|ata[0-9]|nvme|reset|timeout|EXT4-fs|XFS|BTRFS'

Ошибки I/O говорят о проблеме чтения/записи ниже уровня обычных файлов. Reset и timeout могут относиться к кабелю, питанию, контроллеру или устройству. Сообщения EXT4-fs/XFS/BTRFS показывают реакцию файловой системы. Текст нужно читать вместе с именем устройства и временем события; один найденный timeout не определяет неисправный диск автоматически.

Если устройство исчезает, щёлкает, очень медленно читает или выдаёт повторные ошибки носителя, сначала сохраняйте данные. Не запускайте подряд long test, полный badblocks и fsck «для уверенности» — каждый проход нагружает тот же неисправный носитель.

Установите инструменты именно из репозитория ALT

ALT использует RPM, хотя команды установки похожи на Debian. Пакет .deb из инструкции Ubuntu сюда не подходит. Обновите индексы и проверьте наличие инструментов в своей ветке:

sudo apt-get update
apt-cache policy gparted smartmontools e2fsprogs
sudo apt-get install gparted smartmontools e2fsprogs
rpm -q gparted smartmontools e2fsprogs
smartctl --version

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

Для XFS потребуется xfsprogs, для Btrfs — btrfs-progs, для NVMe может пригодиться nvme-cli. Устанавливайте их по необходимости после определения FSTYPE и устройства. Названия и доступность сверяйте через apt-cache в своей системе. О работе с платформой и APT приведены примеры в документации ALT.

На рабочем столе GParted обычно запускается через меню приложений с запросом административной авторизации. Для Live-среды порядок зависит от образа. Не переносите в Wayland чужой универсальный sudo gparted, если приложение не открывается: используйте штатный запуск графической программы. Для серверной диагностики GUI вообще не обязателен.

Прочитайте SMART до ремонта файловой системы

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

sudo smartctl --scan-open
sudo smartctl -x /dev/sdb

Первый вызов помогает подобрать устройство и его тип. Второй запрашивает расширенный отчёт. Для диска через USB-мост или RAID-контроллер могут требоваться параметр -d и отдельный номер физического накопителя. Не считайте отсутствие SMART за RAID доказательством здоровья: запрос к логическому тому часто просто не показывает внутренние данные дисков.

Для NVMe имя может быть /dev/nvme0 или /dev/nvme0n1, в зависимости от инструмента и доступного устройства. При наличии nvme-cli используйте дополнительную проверку:

sudo smartctl -x /dev/nvme0
sudo nvme smart-log /dev/nvme0

Не запускайте эти команды с выдуманным именем: оно должно присутствовать в выводе ваших средств обнаружения. Формат ATA и NVMe различается. В NVMe интересны Critical Warning, Available Spare, Percentage Used, Media and Data Integrity Errors, температура и журнал ошибок. Ненулевой накопительный счётчик оценивается по смыслу поля, истории и росту, а не по одному числу.

На аппаратно стабильном устройстве можно запустить short test, а при необходимости — long. Это внутренняя проверка накопителя, а не форматирование. Тем не менее она добавляет нагрузку и не подходит как первый шаг при признаках физического разрушения:

sudo smartctl -t short /dev/sdb
sudo smartctl -l selftest /dev/sdb
sudo smartctl -t long /dev/sdb

После -t устройство сообщает приблизительное время завершения. Чтение журнала сразу может показать незавершённый тест или предыдущий результат. Дождитесь указанного времени и повторите -l selftest. Вывод команды запуска не равен успешному завершению теста. Ключи и типы устройств описаны в руководстве smartctl; это руководство утилиты, не предложение установить Debian-пакет в ALT.

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

При стабильном носителе подготовьте файловую систему к проверке. Сначала проверьте тип и использование конкретного раздела:

sudo blkid /dev/sdb2
findmnt --source /dev/sdb2
lsblk -f /dev/sdb

Если раздел смонтирован как /srv/data, остановите использующие его приложения в согласованное окно, проверьте открытые процессы и размонтируйте обычным способом:

sudo fuser -vm /srv/data
sudo umount /srv/data
findmnt --source /dev/sdb2

Не используйте lazy unmount или force как доказательство, что запись действительно прекратилась. Если umount сообщает busy, выясните, какой процесс удерживает ресурс. Просмотр списка процессов может показать текущий каталог shell, открытый файл БД или фоновый backup. Не завершайте их случайным kill -9.

Для проверки системного раздела можно подготовить согласованный Live USB. На официальной странице GParted выберите стабильный образ для подходящей архитектуры и скачайте контрольные суммы. Современные образы GParted Live предназначены для x86-64; для ARM и других архитектур нужен подходящий rescue-носитель. Контрольная сумма проверяет целостность скачанного файла:

sha256sum gparted-live-*.iso

Сравните результат именно с SHA-256 опубликованного файла, а не с MD5 или суммой другой версии. Затем подключите отдельный USB-носитель, установите по lsblk его модель и размер и размонтируйте его разделы. Запись образа перезаписывает USB полностью. Только после проверки назначения пример команды для выбранной флешки /dev/sdc:

sudo dd if=./gparted-live-approved-amd64.iso of=/dev/sdc \
  bs=4M status=progress conv=fsync

Имя ISO замените скачанным файлом; /dev/sdc — учебный пример именно флешки, не проверяемого диска и не её раздела /dev/sdc1. Согласуйте перезагрузку, откройте Boot Menu локально или через консоль управления, загрузитесь с USB и выберите штатный запуск Live. На удалённом сервере одной SSH-сессии для этого недостаточно: требуется доступ к консоли. После загрузки вновь сопоставьте все устройства с моделями и UUID.

Корневую файловую систему работающей ALT так не проверяют. Загрузитесь с согласованного Live/Rescue-носителя, убедитесь, что он не примонтировал раздел автоматически, и заново идентифицируйте устройства. Номер /dev/sdb после такой загрузки может измениться. Сверяйте UUID, модель, размер и серийный номер. Сам факт загрузки Live ещё не гарантирует размонтирование всех дисков.

Для ext2/ext3/ext4 сначала выполните офлайн-проверку без исправления:

sudo e2fsck -f -n /dev/sdb2
check_status=$?
printf 'e2fsck exit=%s\n' "$check_status"

-f принуждает к полной проверке, даже если состояние помечено clean. -n открывает проверку без согласия на изменения. На смонтированной файловой системе даже диагностический вывод может быть недостоверным, поэтому исходное условие — размонтирована. Ограничения объяснены в e2fsck(8).

При подтверждённой резервной копии и исправном носителе запустите интерактивный ремонт:

sudo e2fsck -f /dev/sdb2

Программа спрашивает о конкретных исправлениях. Не отвечайте автоматически yes на всё только потому, что название команды знакомо. Исправление метаданных может удалить недостижимые ссылки и переместить найденные объекты в lost+found. Для критичных данных сначала сохраняют образ или копию и разбирают диагностический отчёт.

Коды могут комбинироваться побитовыми признаками; это не всегда одно число из таблицы. fsck — оболочка над специализированными проверяющими программами. Не запускайте один и тот же fsck -y на всех неизвестных типах.

Что меняется для XFS, Btrfs, NTFS и зашифрованных томов

Для XFS диагностический проход по размонтированному тому выполняется другим инструментом:

sudo xfs_repair -n /dev/mapper/vgdata-lvdata

Путь условный, тип должен быть XFS. -n означает просмотр без ремонта. При dirty log штатный путь может требовать корректного воспроизведения журнала; решение зависит от состояния носителя и копии. Не используйте xfs_repair -L как универсальную кнопку: потеря журнала может привести к потере данных. Для XFS применяются его собственные правила, описанные в xfs_repair(8).

Для Btrfs базовая офлайн-проверка:

sudo btrfs check --readonly /dev/mapper/vgdata-lvdata

Если раздел Btrfs смонтирован, для анализа целостности данных в подходящем сценарии используется scrub, а не произвольный check --repair. Scrub может создавать серьёзную нагрузку; способность исправить ошибку зависит от наличия исправной избыточной копии и конфигурации. Документация btrfs check отдельно предупреждает о применении repair без квалифицированного разбора.

NTFS после гибернации Windows и Fast Startup может быть недоступен для безопасной записи. ntfsfix не заменяет полноценную Windows-проверку chkdsk. Если данные предназначены для Windows, завершите её штатно и выполняйте требуемое восстановление по её процедуре. Не форматируйте раздел только потому, что ALT отказалась монтировать его.

Для LUKS сначала открывается нужный контейнер штатным способом, затем выбирается файловая система внутри /dev/mapper/.... Для mdraid и LVM нужно проверить нижележащую сборку и идентифицировать логический том. Здесь особенно полезно дерево lsblk: утилита файловой системы должна получать устройство того слоя, где эта файловая система действительно находится.

Как выполнить проверку в GParted и не запустить лишние операции

Откройте GParted в подходящей установленной или Live-среде. В правом верхнем переключателе выберите нужный накопитель по размеру и устройству. Сопоставьте его с заранее сохранёнными данными lsblk. Если ожидается диск с несколькими разделами, а отображается пустая область, остановитесь: проверьте, не выбран ли другой носитель и не повреждена ли таблица разделов.

Выберите раздел с известной файловой системой. Если он смонтирован, в контекстном меню доступна операция размонтирования; выполнять её нужно после остановки приложения. Замок рядом с разделом может указывать на его использование. Корневой раздел текущей системы проверяется из Live-среды.

Откройте меню раздела и выберите «Проверить» / Check, если операция поддерживается для этого типа и установлены необходимые инструменты. Затем посмотрите очередь действий. До нажатия «Применить все операции» убедитесь, что там находится только запланированная проверка — не Create Partition Table, Format, Delete, Move или Resize от прежнего эксперимента.

GParted откладывает операции в очередь. Сам выбор Check ещё не означает, что проверка выполнена. После Apply дождитесь окончания и откройте подробности: посмотрите вызванную утилиту, сообщения и результат. Операция Check может проверять и пытаться исправлять файловую систему, а для некоторых типов затрагивать её соответствие размеру раздела. Это не обязательно диагностический read-only проход. Если нужен именно просмотр без записи, используйте описанную выше подходящую команду и её -n/readonly-режим.

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

Проверьте не только clean, но и работу данных

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

findmnt /srv/data
df -hT /srv/data
sudo journalctl -k --since '15 minutes ago' --no-pager

Команды для /srv/data заменяются вашим mount point. Если проверялся корень, используйте /. Для базы данных нужен её собственный контроль и тест приложения; clean у ext4 не доказывает логическую целостность таблиц. Для файлового архива полезны контрольные суммы известных файлов и чтение выборки. Проверку записи проводите через штатный прикладной сценарий или согласованный тестовый файл, не меняя произвольные бизнес-данные.

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