Восстановление файловой системы linux fsck

Проверка и восстановление файловых систем в Linux- команда fsck

Иногда по разным причинам (в результате сбоя, некорректного завершения работы) файловые системы накапливают ошибки. Сами ошибки представляют собой «рассогласованные» структуры данных. Естественно, при возникновении такой ситуации необходимо как можно скорее привести повреждённую файловую систему в порядок. С этой задачей отлично справляется утилита fsck. Она действительно очень эффективна и системные администраторы очень часто в первую очередь используют именно ее для восстановления или починки файловых систем.

Как работает fsck?

Утилита fsck (File System Consistency Check) изначально глубоко проверяла все структуры данных подряд, т. е. целиком всю файловую систему. Для поиска ошибок она задействовала методы эвристического анализа для ускорения и оптимизации процесса поиска ошибок. Однако, даже в этом случае для больших по объёму файловых систем эта процедура могла занимать много часов.

Позднее была реализована схема оценки состояния файловой системы, в основе которой лежит признак «чистого бита файловой системы». Если происходил сбой и файловая система (ФС) некорректно демонтировалась, то в суперблоке ФС устанавливался этот бит. По-умолчанию в Linux-системах на одном из этапов загрузки системы происходит проверка файловых систем, которые зарегистрированы в файлах /etc/fstab, /etc/vfstab, а также в /etc/filesystems. Таким образом, анализируя «чистый бит» ФС во время загрузки системы утилита определяет, стоит ли проводить проверку.

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

Некоторые особенности использования fsck в Linux

Для Linux-систем довольно часто (в особенности с использованием ФС ext) проверка ФС может быть организована таким образом, что она будет проводиться при прошествии некоторого числа демонтирований, даже если ФС полностью исправны. Это особенно актуально для настольных компьютеров, которые могут выключаться/включаться каждые сутки, перезагружаться в связи с особенностью их работы и применения, а также из-за свободного к ним доступа для подключения внешних устройств. В таких случаях проверка ФС (хоть и является полезной и благоприятной процедурой), оказывается слишком частой, а потому бессмысленной.

По-умолчанию в Linux проверка ФС проводится по прошествии 20 демонтирований. Для того, чтобы изменить количество демонтирований, после которых нужна проверка ФС нужно воспользоваться командой tune2fs:

$ sudo tune2fs -с 50 /dev/sda1 tune2fs 1.44.1 (24-Mar-2018) Setting maximal mount count to 50

Синтаксис и основные опции fsck

У команды fsck следующий синтаксис:

fsck [параметр] -- [параметры ФС] [ . . .]

Опция	Описание
-A	Проверяет все ФС
-С []	Показывает статус выполнения. Здесь fd – дескриптор файла при отображении через графический интерфейс
-l	Блокирует устройство для исключительного доступа
-M	Запрещает проверять примонтированные ФС
-N	Показывает имитацию выполнения, без запуска реальной проверки
-P	Проверять вместе с корневой ФС
-R	Пропускает проверку корневой ФС. Может использоваться только совместно с опцией -A
-r []	Выводит статистику для каждого проверенного устройства
-T	Не показывать заголовок при запуске
-t	Задаёт ФС для проверки. Можно задавать несколько ФС, перечисляя через запятую
-V	Выводит подробное описание выполняемых действий

Кроме основных опций для fsck существуют и специфические, зависящие от выполняемой задачи и/или ФС. Об этом более подробно можно прочитать в соответствующих страницах интерактивного руководства, используя команду man fsck. В содержании основного руководства для утилиты (в разделе «SEE ALSO») есть ссылки на другие страницы, например fstab(5), mkfs(8), fsck.ext2(8), fsck.ext3(8) и т. д. Информацию по этим ссылкам можно просматривать выполняя команду man с соответствующими параметрами, например man fsck.ext3.

В следующей таблице приводятся дополнительные (специальные), а также наиболее часто используемые опции, позволяющие использовать команду с максимальной гибкостью и эффективностью:

Опция	Описание
-a	Устаревшая опция. Указывает исправлять все найденные ошибки без одобрения пользователя.
-r	Применяется для файловых систем ext. Указывает fsck спрашивать пользователя перед исправлением каждой ошибки
-n	Выполняет только проверку ФС, без исправления ошибок. Используется также для получения информации о ФС
-c	Применяется для файловых систем ext3/4. Помечает все повреждённые блоки для исключения последующей записи в них
-f	Принудительно проверяет ФС, даже если ФС исправна
-y	Автоматически подтверждает запросы к пользователю
-b	Задаёт адрес суперблока
-p	Автоматически исправлять найденные ошибки. Заменяет устаревшую опцию -a

Примеры использования fsck

Для самой типичной ситуации, характерной для случаев, когда нужно восстановить (а точнее «починить») ФС, например на устройстве /dev/sdb2, следует воспользоваться командой:

Здесь опция -y необходима, т. к. при её отсутствии придётся слишком часто давать подтверждение. Следующая команда позволит произвести принудительную проверку ФС, даже в том случае, если она исправна:

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

Работу файловыми системами нужно проводить, когда они отмонтированны от разделов. Однако, если возникает ситуация, когда нужно всё же произвести проверку на примонтированных ФС, то перед тем как использовать команду fsck с соответствующей опцией, нужно сначала перемонтировать нужную ФС в режиме «только для чтения»:

$ sudo mount remount,ro /dev/sdb2 $ sudo fsck -fy /dev/sdb2

Для указания, какую ФС использовать для раздела:

$ sudo fsck -t ext4 -y /dev/sdb2

Если fsck не справляется с исправлением/починкой ФС (что случается очень редко), то это может быть из-за повреждённого суперблока ФС. Его также можно восстановить, поскольку для суперблоков создаются их резервные копии. Но сначала нужно узнать, по каким адресам эти копии записывались, а затем попытаться восстановить суперблок из одной их резервных копий:

$ sudo mkfs -t ext4 -n /dev/xvdb1

$ sudo fsck -b 163840 /dev/xvdb1

Команда fdisk -l упомянута в данном примере для наглядности того, что сначала нужно представлять, с каким устройством работать, т. к. она выводит список (в данном выводе опущен) доступных разделов. Команда mkfs предназначена для создания ФС, но с опцией -n её можно использовать для получения информации о ФС, в том числе и о расположении суперблоков. Следует следить за тем, чтобы ключом -t для mkfs задавалась соответствующая фактическому состоянию файловая система, в данном случае ext4.

Заключение

В данной статье мы рассмотрели работу и использование утилиты fsck. Как видно из статьи использование утилиты не предоставляет большой сложности. А возможности по проверки и восстановлению файловых систем в Linux у нее довольно большие, поэтому знание этой утилиты системному администратору просто необходимы.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Похожие записи:

Источник

fsck (Русский)

Состояние перевода: На этой странице представлен перевод статьи fsck. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

fsck (file system check) — утилита для проверки и восстановления файловых систем Linux. Проверка файловых систем разных физических дисков выполняется параллельно, что позволяет значительно её ускорить (см. fsck(8) ).

Процесс загрузки Arch включает в себя процедуру fsck, поэтому проверка файловых систем на всех носителях выполняется автоматически при каждой загрузке. По этой причине обычно нет необходимости выполнять её через командную строку.

Проверка при загрузке

Механизм

Существует два возможных варианта:

1. mkinitcpio предоставляет хук fsck для проверки корневой файловой системы перед монтированием. Корневой раздел должен быть смонтирован на запись и чтение (параметр ядра rw ) [1].
2. systemd проверяет все файловые системы, которым задано значение fsck больше 0 (либо параметром fstab, либо в пользовательском файле юнита). Корневая файловая система изначально должна быть смонтирована только на чтение (параметр ядра ro ), и лишь позже перемонтирована на чтение-запись в fstab. Имейте в виду, что опция монтирования defaults подразумевает rw .

Рекомендуется по умолчанию использовать первый вариант. Если вы устанавливали систему в соответствии с руководством, то использоваться будет именно он. Если вы хотите вместо этого использовать вариант 2, то удалите хук fsck из mkinitcpio.conf и задайте параметр ядра ro . Кроме того, параметром ядра fsck.mode=skip можно полностью отключить fsck для обоих вариантов.

Принудительная проверка

Если вы используете base -хук mkinitcpio, то можно принудительно выполнять fsck во время загрузки, задав параметр ядра fsck.mode=force . Проверена будет каждая файловая система на машине.

В качестве альтернативы можно воспользоваться службой systemd systemd-fsck@.service(8) , которая проверит все настроенные файловые системы, которые не были проверены в initramfs. Тем не менее, проверка корневой файловой системы этим способом может стать причиной задержки в время загрузки, поскольку файловая система будет перемонтироваться.

Примечание: Если вы используете другие дистрибутивы GNU/Linux, то учтите, что старые методы проверки вроде файлов forcefsck для каждой файловой системы или команды shutdown с флагом -F будут работать только с SysVinit и ранними версиями Upstart; работать с systemd они не будут. Решение, предложенное выше, является единственным рабочим для Arch Linux.

Советы и рекомандации

Восстановление повреждённых блоков

Следующая команда позволяет восстановить повреждённые участки файловых систем ext2/ext3/ext4 и FAT:

Важно: Разрешение на восстановление запрошено не будет. Подразумевается, что вы уже ответили «Да», запустив команду на выполнение.

Интерактивное восстановление повреждённых блоков

Полезно в том случае, если файлы на загрузочном разделе были изменены, а журнал не обновился соответствующим образом. В этом случае размонтируйте загрузочный раздел и выполните:

Изменение частоты проверки

Примечание: Команды tune2fs и dumpe2fs работают только с файловыми системами ext2/ext3/ext4.

По умолчанию fsck проверяет файловую систему каждые 30 загрузок (вычисляется отдельно для каждого раздела). Чтобы изменить частотку проверок, выполните:

Здесь 20 — число загрузок между проверками. Если задать значение 1 , то проверка будет выполняться при каждой загрузке, а значение 0 отключит сканирование.

Текущую частоту проверок и опции монтирования конкретного раздела можно узнать командой:

# dumpe2fs -h /dev/sda1 | grep -i 'mount count'

Параметры fstab

fstab — файл системных настроек, который используется для передачи ядру Linux информации о том, какие разделы (файловые системы) монтировать и в какие точки дерева файловой системы.

Записи в /etc/fstab выглядят примерно следующим образом.

/dev/sda1 / ext4 defaults 0 1 /dev/sda2 /other ext4 defaults 0 2 /dev/sda3 /win ntfs-3g defaults 0 0 

Шестое поле каждой строки (выделено) — опция fsck:

• 0 — не проверять.
• 1 — файловая система (раздел), которая должна быть проверена первой; для корневого раздела ( / ) должно использоваться именно это значение.
• 2 — прочие файловые системы, которые должны быть проверены.

Решение проблем

Не запускается fsck для отдельного раздела /usr

1. Убедитесь, что используются соответствующие хуки в /etc/mkinitcpio.conf , а также что вы не забыли пересоздать initramfs после последнего редактирования этого файла.
2. Проверьте fstab! Только корневому разделу должен быть задан параметр 1 в последнем поле, все остальные разделы должны иметь либо 2 , либо 0 . Также проверьте файл на наличие иных опечаток.

ext2fs: no external journal

Иногда (например, из-за внезапного отключения питания) файловые системы ext(3/4) могут повредиться так сильно, что восстановить их обычным способом не удастся. Как правило, при этом fsck выводит сообщение о том, что не удалось найти журнал (no external journal). В этом случае выполните команды ниже.

Отмонтируйте раздел от соответствующего каталога:

Запишите на раздел новый журнал:

Запустите fsck, чтобы восстановить раздел:

Источник