Fsck: полное руководство по проверке и исправлению файловых систем Linux

Введение / Зачем это нужно

Файловая система — это основа хранения данных на диске. Со временем из-за сбоев питания, аппаратных ошибок или программных багов в ней могут накапливаться inconsistencies: потерянные блоки, некорректные ссылки, поврежденные inode. Утилита fsck (file system check) — стандартный инструмент Linux для проверки и исправления таких проблем. Регулярная проверка помогает предотвратить потерю данных и обеспечивает стабильность системы. Этот гайд подробно объяснит, как безопасно использовать fsck на различных типах файловых систем.

Требования / Подготовка

Перед началом убедитесь, что:

1. У вас есть права root (или используйте sudo).
2. Файловая система размонтирована. Запуск fsck на смонтированном разделе (особенно в режиме чтения-записи) опасен и может усугубить повреждения. Для корневого раздела (/) потребуется загрузка с Live USB/CD.
3. Установлены соответствующие утилиты. Обычно fsck входит в пакет util-linux, но для специфичных файловых систем могут потребоваться дополнительные пакеты:
   • ext2/3/4: e2fsprogs (часто установлен по умолчанию)
   • XFS: xfsprogs
   • Btrfs: btrfs-progs
   • NTFS: ntfs-3g
4. Сделана резервная копия важных данных, если это возможно. Хотя fsck обычно безопасен, при серьёзных повреждениях есть риск потери файлов.

Шаг 1: Определите файловую систему и устройство

Сначала узнайте, какой тип файловой системы используется на целевом разделе и какое устройство ему соответствует.

lsblk -f

Пример вывода:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
├─sda1 vfat   BOOT  ABCD-1234                            /boot/efi
├─sda2 ext4   ROOT  a1b2c3d4-e5f6-7890-abcd-ef1234567890 /
├─sda3 swap        abcdef12-3456-7890-abcd-ef1234567890 [SWAP]
└─sda4 xfs   HOME  9876fedc-ba54-3210-fedc-ba9876543210 /home

Или используйте blkid:

blkid /dev/sda2

Вывод: /dev/sda2: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Запишите устройство (например, /dev/sda2) и тип файловой системы (ext4, xfs и т.д.).

Шаг 2: Размонтируйте раздел

Проверьте, смонтирован ли раздел:

mount | grep /dev/sda2

Если раздел смонтирован (например, в /home), размонтируйте его:

umount /dev/sda2

Если раздел используется (например, текущий рабочий каталог), закройте все приложения, которые его используют, или перейдите в другой каталог. Для корневого раздела (/) простой umount не сработает — необходимо загрузиться с Live-носителя (например, Ubuntu Live USB) и запустить проверку оттуда.

Шаг 3: Запустите fsck для вашего типа файловой системы

fsck — это frontend, который вызывает конкретные утилиты в зависимости от типа файловой системы. Рекомендуется вызывать их напрямую для большей надёжности.

Для ext2/ext3/ext4:

fsck.ext4 -f /dev/sdX1

Опция -f принудительно запускает проверку даже если файловая система выглядит чистой.

Для XFS:

XFS требует, чтобы файловая система была размонтирована. Используйте xfs_repair (это аналог fsck для XFS):

xfs_repair /dev/sdX1

⚠️ Важно: xfs_repair не имеет опции «только проверка». Он сразу исправляет найденные ошибки. Убедитесь в резервной копии.

Для Btrfs:

Btrfs поддерживает проверку онлайн (на смонтированной ФС) через btrfs check, но для серьёзных повреждений лучше размонтировать:

btrfs check /dev/sdX1

Используйте опцию --repair для исправления, но будьте осторожны — она потенциально опасна.

Для NTFS (через ntfs-3g):

ntfsfix /dev/sdX1

ntfsfix — это упрощённый аналог fsck для NTFS. Он исправляет основные ошибки и очищает журнал транзакций. Для сложных случаев используйте Windows-утилиту chkdsk.

Шаг 4: Примите решение об исправлении ошибок

После сканирования fsck (или соответствующей утилиты) выведет список найденных проблем и спросит, исправлять ли их.

Пример для ext4:

/dev/sda2: 1234/4567890 files (0.0% non-contiguous), 5678/9112345 blocks

Если есть ошибки, вы увидите вопросы вроде:

/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
            (i.e., without -a or -p options)

Варианты действий:

1. Автоматическое исправление: запустите с опцией -y (или -p для автоматического исправления только безопасных ошибок), чтобы ответить «да» на все вопросы:

   fsck.ext4 -y /dev/sdX1
   

   
   Используйте осторожно: если есть серьёзные повреждения, лучше анализировать каждую ошибку.
2. Ручное подтверждение: запустите без -y и внимательно читайте каждый вопрос. Типичные действия:
   • Fix? — исправить ошибку.
   • Clear? — очистить блок.
   • Abort? — прервать проверку (не рекомендуется, если уже началось исправление).
   
   Если не уверены, можно выбрать «no» для спорных случаев и изучить логи после.
3. Только проверка: для тестирования без изменений используйте -n (no modify).

Шаг 5: Проверьте результат и смонтируйте раздел

После завершения fsck вернёт код завершения:

• 0 — ошибок не найдено.
• 1 — ошибки исправлены.
• 4 — ошибки остались (неисправимые) или файловая система было изменена и требует перезагрузки (для корневого раздела).
• 8 — операционная ошибка (например, раздел смонтирован).

Просмотрите вывод на наличие предупреждений о неисправленных ошибках.

Затем смонтируйте раздел:

mount /dev/sdX1 /mnt

Если монтирование прошло успешно (без ошибок в консоли), проверьте, доступны ли файлы:

ls /mnt

Шаг 6: Проверьте системные логи на наличие ошибок

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

dmesg | tail -20

Или посмотрите журнал systemd:

journalctl -xe | grep -i "error\|fail" | tail -20

Если в логах есть упоминания о проблемах с диском (например, I/O error, medium error), это может указывать на аппаратные неполадки. В таком случае выполните проверку SMART (см. связанный гайд по smartctl).

Проверка результата

Главный признак успеха — возможность смонтировать файловую систему и читать/писать файлы без ошибок. Дополнительно:

1. Убедитесь, что fsck вернул код 0 или 1.
2. Проверьте, что нет ошибок в dmesg после монтирования.
3. Для ext-файловых систем можно выполнить дополнительную проверку:

   e2fsck -n /dev/sdX1  # только проверка, без изменений
   

   
   Она должна сообщить «Filesystem is clean».

Возможные проблемы

1. «Filesystem is mounted» — раздел смонтирован

Fsck откажется работать на смонтированной файловой системе. Решение:

• Размонтируйте раздел (см. Шаг 2).
• Для корневого раздела загрузитесь с Live-носителя.
• В крайнем случае для ext4 можно использовать опцию -f даже на смонтированной, но это опасно и может привести к потере данных. Не делайте этого без резервной копии.

2. «Bad magic number» или «Invalid argument» — повреждён суперблок

Суперблок — это метаданные файловой системы. Если он повреждён, fsck не может распознать ФС. Для ext2/3/4 можно попробовать использовать резервную копию суперблока:

fsck.ext4 -b 32768 /dev/sdX1

Номер резервного блока зависит от размера блока файловой системы. Обычные значения:

• 8192 (для блоков 1K)
• 32768 (для блоков 2K)
• 32768 (для блоков 4K)

Узнать расположение резервных суперблоков можно командой:

dumpe2fs -h /dev/sdX1 | grep -i "backup"

3. Fsck зависает или работает очень долго

Это может указывать на:

• Физические повреждения диска (битые сектора). Проверьте SMART:

  smartctl -a /dev/sdX
  

  
  Ищите ошибки Reallocated_Sector_Ct, Current_Pending_Sector, UDMA_CRC_Error_Count.
• Очень большое количество ошибок — fsck может долго исправлять. Дайте ему время.
• Раздел огромного размера (несколько ТБ) — нормально, что проверка занимает часы.

Если диск failing, срочно скопируйте данные (например, с помощью ddrescue) и замените диск.

4. После исправления система не загружается

Если fsck исправлял корневой раздел, но система не загружается:

• Проверьте, не повреждён ли загрузчик (GRUB). Переустановите его с Live-носителя.
• Посмотрите логи загрузки через journalctl -b -1 (предыдущая загрузка).
• Убедитесь, что в /etc/fstab указаны правильные UUID для разделов (после исправления UUID мог измениться? Обычно нет, но бывает при создании новых inode).

5. Ошибка «No such file or directory» при вызове fsck для конкретного типа

Убедитесь, что пакет с поддержкой этой файловой системы установлен. Например, для XFS:

sudo apt install xfsprogs   # Debian/Ubuntu
sudo yum install xfsprogs   # RHEL/CentOS

6. Потеря данных после fsck

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

• Для ext4: инструменты вроде extundelete или testdisk (работают на размонтированном разделе).
• Для XFS: xfs_repair может перемещать повреждённые inode в каталог lost+found. Проверьте его после монтирования.
• Для NTFS: ntfs undelete (из пакета ntfs-3g) или Windows-утилиты.

Профилактика: всегда делайте регулярные бэкапы и используйте журналируемые файловые системы (ext4, XFS, btrfs), которые лучше переносят сбои.