Проверка ФС и восстановление удалённых файлов в Linux.

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

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

Утилита fsck (F ile S ystem 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 [параметр] -- [параметры ФС] [<файловая система> . . .]

Основные параметры:

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

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

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

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

$ sudo fsck -y /dev/sdb2

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

$ sudo fsck -fy /dev/sdb2

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

$ sudo fsck -c /dev/sdb2

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

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

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

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

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

$ sudo fdisk -l $ sudo mkfs -t ext4 -n /dev/xvdb1 $ sudo fsck -b 163840 /dev/xvdb1

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

Заключение

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

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

Linux — одна из самых надёжных операционных систем, которую вы когда-либо видели, однако это вовсе не означает, что оборудование на котором работает Linux такое же надёжное. Жёсткие диски могут работать с ошибками и как следствие — вы получите ошибки на ваших файловых системах. Неважно насколько надёжна ваша операционная система, если вы случайно удалили нужные файлы или каталоги. Однако нее отчаивайтесь, если с вами произошло нечто подобное. Linux располагает всем необходимым, чтобы помочь вам восстановить потерянные файлы в результате удаления или сбоев в работе дисков и файловых систем. О каких инструментах идёт речь? Первым делом мы рассмотрим с вами утилиты e2fsck , scalpel и lsof . В сегодняшней заметке мы с вами посмотрим, как при помощи такого набора инструментов можно исправлять ошибки ФС и восстанавливать удалённые файлы.

Проверка ФС ext2/ext3/ext4 при помощи e2fsck

Утилита e2fsck является потомком известной UNIX-утилиты fsck , предназначенной для проверки файловых систем. При помощи e2fsck вы можете проверять на наличие ошибок и выполнять восстановительные работы в файловых системах ext2/ext3/ext4 .

Одним из наиболее важных моментов в работе с e2fsck является то, что при помощи неё работы можно проводить только на отмонтированной файловой системе, в противном случае вы можете получить себе ещё больше головной боли, о чём и предупреждает сама утилита при попытке запуска её для работы на смонтированной ФС. Если проверяемая ФС не является корневой, то вы можете завершить работу всех пользователей, переключиться в однопользовательский режим (init 1 ), отмонтировать ФС и работать с ней.

Однако автор всё же рекомендует воспользоваться каким-нибудь и, загрузившись с него, выполнять все работы. Используя этот метод вы получите в своё полное распоряжение несмонтированные ФС без необходимости выполнять какие-то дополнительные действия.

Если же вы по каким-то причинам выбираете первый вариант, то после того, как перейдёте в однопользовательский режим:

# init 1

отмонтируйте нужную для работы файловую систему:

# umount /dev/sdb1

и после успешного размонтирования запускайте e2fsck :

# e2fsck -y /dev/sdb1

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

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

Восстановление удалённых файлов при помощи /proc и lsof

Теперь давайте рассмотрим процесс восстановления удалённых файлов. Вообще, причиной тому что вы можете восстановить удалённый файл является тот факт, что «файл» — это лишь ссылка на индексный дескриптор файла (inode) . Именно в inode хранится информация о физическом размещении файла. Когда вы удаляете файл, фактически вы просто удаляете ссылку на inode , в то время как сам дескриптор ещё какое-то время будет существовать: до тех пор, пока процесс, ранее открывший этот файл не освободит соответствующий дескриптор для записи. Таким образом, есть какое-то время, пусть и короткое, в течение которого можно восстановить содержимое удалённого файла. Ключом в этом процессе является файловая система , содержащая среди всего прочего информацию обо всех выполняющихся в системе процессах и открытых ими файлах. Каждый процесс, работающий в системе имеет соответствующий его PID каталог в /proc . Зная PID процесса, всё ещё держащего открытым удалённый файл, мы всегда можем восстановить его содержимое из каталога /proc// открывшего его процесса. Давайте на простом примере посмотрим, как это делается.

Сперва давайте создадим какой-нибудь файл:

$ echo "Очень важные данные" > ~/myfile.txt

Теперь у нас есть файл myfile.txt с важными данными, расположенный в домашнем каталоге. Давайте попробуем удалить его и затем восстановить следующим образом. Сначала мы откроем файл для просмотра командой less , после чего приостановим её работу, оставив таким образом нужный нам файл открытым. Итак, пошагово.

Откройте файл командой less для просмотра

$ less ~/myfile.txt

После того, как файл будет открыт и вы увидите его содержимое, нажмите Ctrl+z , чтобы приостановить выполнение less .

Удалите файл:

$ rm ~/myfile.txt

Убедитесь в том, что файла больше нет

$ ls -l ~/myfile.txt

Поскольку работа ранее запущенной нами less ещё не завершена, то файл остаётся для неё открытым и фактически не удалён. Давайте восстановим его.

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

$ lsof | grep myfile.txt less 2675 ashep 4r REG 8,1 37 294478 /home/ashep/myfile.txt (deleted)

Во втором поле вывода lsof содержится PID — 2675, а в четвёртом номер дескриптора — 4. Теперь можно приступать к восстановлению:

$ cp /proc/2675/fd/4 ~/recovered.txt

Проверьте, то ли содержимое находится в файле, которое нам нужно:

$ cat ~/recovered.txt Очень важные данные

Как видим, всё прошло успешно и нам удалось восстановить удалённый файл.

Восстановление удалённых файлов при помощи Scalpel

После того как процесс, открывший файл, завершится, восстановление файла становится задачей потруднее, поскольку индексный дескриптор освобождается и всякая связь между данными в блоках на диске и файловой системой потеряна. До тех пор, пока данные физически не будут перезаписаны на диске, существует возможность их восстановления при помощи утилиты Scalpel . Этот инструмент последовательно, блока за блоком, обходит содержимое диска и анализирует его содержимое, пытаясь найти признаки существования там файлов. Для поиска Scalpel использует шаблоны из последовательности байт, присущих определённым типам файлов. Например, PNG-файлы содержат в заголовке последовательность байт \x50\x4e\x47 .

Scalpel вы найдёте в репозиториях большинства современных дистрибутивов. После установки утилиты первым делом нужно определиться с тем, какие файлы программа будет искать при работе. Определения шаблонов для поиска находятся в файле /etc/scalpel/scalpel.conf . По умолчанию содержимое файла целиком закомментировано и прежде чем начать работу вам необходимо раскомментировать нужные шаблоны и/или добавить свои. Формат описания шаблона довольно прост:

Extension case_sensitive size header

• extension определяет расширение файла, которое Scalpel будет дописывать при восстановлении;
• case_sensitive указывает утилите, имеет ли значение регистр символов в шаблоне поиска;
• при помощи size определяется максимальный размер восстанавливаемых файлов;
• в header и необязательном footer описываются последовательности заголовка файла и нижней его части соответственно.

Например, определение шаблона для JPG-файлов может выглядеть так:

Jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9

После того, как внесёте необходимые изменения в конфигурационный файл Scalpel и подготовите пустую (обязательно!) директорию для сохранения найденных файлов, можно запускать процесс поиска и восстановления:

# scalpel -o ~/recovered /dev/sdb1

где при помощи опции "-o" определяется путь к каталогу для сохранения найденных файлов. Процесс работы утилиты как правило очень долгий, поскольку она сканирует всё устройство целиком, поэтому воспользуйтесь моментом и сходите прогуляться на улицу, свежий воздух ещё никому не мешал;)

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

Заключение

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

Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».

1) fsck при загрузке ОС

Когда случается сбой питания в работу вступает fsck: file system consistency check and interactive repair или если на русском, то «проверка целосности файловой системы и интерактивное восстановление» . По умолчанию проверка дисков отключена. Что бы её включить при загрузке системы, добавим такую строчку

fsck_y_enable="YES"

в файл /etc/rc.conf . В этом случае, при некорректном завершении работы сервера, будет автоматически запускаться проверка всех файловых систем.

Сама проверка состоит из 5-ти этапов:

** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames


** Phase 5 - Check Cyl groups

На самом деле, Phase 1 ещё подразделяется на 1a и 1b . Это можно заметить только тогда, когда случился серъёзный крах.

Всё это хорошо, но есть одно НО! Когда происходит проверка файловой системы, то пока раздел не провериться, он не смонтируется и станет доступным, соответственно, увеличивается время загрузки сервера. Разработчики и это предусмотрели и сделали возможным запуск проверки в «фоне». Хотя на самом деле это только попытка, но всё же лучше, чем ничего. по умолчанию она включена. Правда по этому поводу точаться дискуссии на тему «нужно ли включать проверку в фоне или нет». Решать вам.

Есть один неприятный момент в процессе проверки ФС при загрузке. Если раздел достаточно большой, то его проверка может занять длительное время, при этом, fsck как бы зависает на каждом из этапов. Иными словами визуально непонятно, то ли идёт проверка, то ли сервер завис. Ну и при всём при этом непонятно, сколько уже проверено и сколько будет проверяться. Что бы немного облегчить жизнь системным администраторам, разработчики внедрили недокументированую возмножность. нажатие комбинации Ctrl+T показывает текущее состояние проверки: сколько уже проверено, в процентах. Если через пару минут захотите узнать опять состояние — нужно снова нажать Ctrl+T и так каждый раз (либо просто зажать и держать, тогда получите динамически обновляемые данные).

Есть несколько параметров, которые прописываются в /etc/rc.conf и касаются fsck . Ниже приведены их дефолтные значения:

fsck_y_enable="NO" # Включить проверку при запуске, если работа была завершена некорректно.
fsck_y_flags="" # Дополнительные флаги для fsck -y
background_fsck="YES" # Попытка запустить проверку в фоне
background_fsck_delay="60" # Время задержки перед запуском fsck в фоне.

fsck_y_enable="YES"

И так, вот примеры работы fsck :

— если сервер выключался корректно, то при загрузке мы увидим такое сообщение:

Nov 10 14:36:33 mail kernel: Starting file system checks:
Nov 10 14:36:33 mail kernel: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1a: clean, 942456 free (2944 frags, 117439 blocks, 0.3% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1d: clean, 503428 free (60 frags, 62921 blocks, 0.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1e: clean, 2301104 free (50872 frags, 281279 blocks, 1.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1f: clean, 162210122 free (2260506 frags, 19993702 blocks, 0.5% fragmentation)
Nov 10 14:36:33 mail kernel: Mounting local file systems:

Наличие ключевой фразы FILE SYSTEM CLEAN; SKIPPING CHECKS свидетельствует о предыдущем корректном завершении.

— если некорректно, то такое

Starting background file system checks in 60 seconds.
Jan 26 18:39:19 mail kernel: Starting file system checks:
Jan 26 18:39:19 mail kernel: /dev/da0s1a: 56013 files, 201857 used, 3349718 free (1702 frags, 418502 blocks, 0.0% fragmentation)
Jan 26 18:39:19 mail kernel: /dev/da0s1d: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1f: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1e: DEFER FOR BACKGROUND CHECKING

Но такое происходит не всегда. Если попытка не увенчалась успехом, то мы увидим такое:

** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var

INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT? yes
INCORRECT BLOCK COUNT I=446045 (4 should be 0)
CORRECT? yes

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts

UNREF FILE I=89148 OWNER=root MODE=100600
SIZE=376 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
UNREF FILE I=89152 OWNER=root MODE=100600
SIZE=755 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes

** Phase 5 - Check Cyl groups

FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
2242 files, 1607116 used, 973436 free (2196 frags, 121405 blocks, 0.1% fragmentation)

2) Ручной запуск fsck

Сразу замечу, что проверка делается ТОЛЬКО НА НЕ СМОНТИРОВАННОМ РАЗДЕЛЕ! Иначе можете потерять все данные.
И так, рассмотрим только те параметры, которые часто используются. А именно

-y|-n : этот параметр будет отвечать соответственно YES|NO на все вопросы при возникновении несоответствий.
-B|-F : соответственно фоновый и нефоновый режимы
-f : проверить раздел, даже если он был отключён корректно.

fsck -y -f /dev/ad2s1g

Если запустить без параметра -y , то при проверке и нахождении несоответствий будет выдаваться вопрос, на что можно ответить Y или N . обычно отвечают Y . Не очень удобно каждый раз отвечать Y , поэтому лучше запускать с параметром Y

** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes

INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT?

Есть хорошая новость: комбинация CTRL+T работает и в ручном режиме.

Файловая система UNIX на удивление надежна и выполняет значительную работу, справляясь с неожиданными сбоями системы и частыми отказами аппаратных средств. Тем не менее, существует ряд причин, вызывающих повреждение файловых систем и нарушение их целостности.

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

Имеются различные подходы к устранению этой проблемы. Небольшие повреждения обычно поддаются устранению с помощью команды fsck (сокращение от "filesystem consistency check" — проверка целостности файловой системы). С архитектурной точки зрения это не очень элегантный подход, но он себя оправдывает в большинстве распространенных ситуаций.

Файловые системы, в которых ведется журнал событий, записывают метаданные в последовательный журнальный файл, сохраняемый на диске перед завершением каждой команды. Впоследствии метаданные переносятся из журнального файла в соответствующее место файловой системы. Если происходит сбой системы, журнальный файл просматривается в обратном порядке и находится точка, когда система последний раз находилась в согласованном состоянии. Полная проверка файловой системы не требуется. Это очень полезно, если размер файловой системы очень велик.

Ведение журнала событий поддерживается в файловой системе UFS в Solaris и в файловой системе VXFS в HP-UX. Просмотрите описание процедуры инсталляции жесткого диска в HP-UX, где объясняется, как включить журнальный режим.

Если журнал событий не поддерживается, остается надеяться на программу fsck . Вот пять наиболее часто встречающихся видов повреждений:

наличие индексных дескрипторов, на которые нет ссылок;

неоправданно большие значения счетчиков ссылок;

неиспользуемые блоки данных, не отраженные в таблицах блоков;

блоки данных, указанные как свободные, но используемые в файле;

неверная статистическая информация в суперблоке.

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

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

Команду fsck -р можно выполнить и для отдельной файловой системы например:

# fsck -р /dev/rsd 0 g

Программа fsck обрабатывает файлы и блок-ориентированных, и байт-ориентированных устройств, но с последними она работает быстрее.

Когда программа fsck читает файл fstab , чтобы узнать, какие файловые системы проверять, она придерживается последовательности, обозначение, в последнем поле каждой записи. Файловые системы проверяются в порядке возрастания номеров. Если две файловые системы размещены на разны; дисках, им может быть присвоен один порядковый номер. Это заставит программу fsck проверить их одновременно; при этом минимизируется время затрачиваемое на ожидание дискового ввода-вывода. Первым всегда следует проверять корневой раздел.

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

блоки, принадлежащие более чем одному файлу;

блоки, находящиеся вне диапазона файловой системы;

слишком маленькие счетчики ссылок;

неучтенные блоки;

различные ошибки формата файлов.

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

Во многих операционных системах имеется отладчик файловых систем (часто называемый fsdb ), который позволяет проверять и модифицировать данные на низком уровне, но для эффективного его использования нужно очень хорошо понимать, что он делает. Если ограничиться чтением файловой системы и не пытаться ее модифицировать, то можно избежать усугубления проблем.

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

Если поврежденная файловая система содержит ценные данные, а программа fsck не смогла автоматически ее восстановить, не экспериментируйте с ней, не создав предварительно резервной копии. Можно попробовать применить к диску команду dump , но она предполагает наличие неповрежденной файловой системы, поэтому в результате могут быть потеряны данные (или команда завершится выдачей сообщения об ошибке). Лучше всего перестраховаться и выполнить для всего диска команду dd , чтобы создать резервный диск.

Если программа fsck знает только номер индексного дескриптора файла, то для выяснения его путевого имени в некоторых системах можно использовать команду ncheck . Для очистки дефектного индексного дескриптора, который программа fsck не может восстановить, можно воспользоваться командой clri (данные, естественно, будут потеряны).

Когда программа fsck обнаруживает файл, родительский каталог которого определить невозможно, она помещает такой файл в каталог lost+found , находящийся на верхнем уровне файловой системы. Поскольку имя, присвоенное файлу, регистрируется только в его родительском каталоге, имена файлов-сирот определить нельзя, и файлам, помещаемым в каталог lost+found , присваиваются имена, совпадающие с номерами их индексных дескрипторов.

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

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.

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

Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.

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

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

Основы работы с fsck

В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.

А теперь давайте рассмотрим сам синтаксис утилиты:

$ fsck [опции] [опции_файловой_системы] [раздел_диска]

Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.

А теперь давайте рассмотрим самые полезные опции fsck:

• -l - не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
• -t - задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
• -A - проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
• -C - показать прогресс проверки файловой системы;
• -M - не проверять, если файловая система смонтирована;
• -N - ничего не выполнять, показать, что проверка завершена успешно;
• -R - не проверять корневую файловую систему;
• -T - не показывать информацию об утилите;
• -V - максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

• -a - во время проверки исправить все обнаруженные ошибки, без каких-либо вопросов. Опция устаревшая и ее использовать не рекомендуется;
• -n - выполнить только проверку файловой системы, ничего не исправлять;
• -r - спрашивать перед исправлением каждой ошибки, используется по умолчанию для файловых систем ext;
• -y - отвечает на все вопросы об исправлении ошибок утвердительно, можно сказать, что это эквивалент a.
• -c - найти и занести в черный список все битые блоки на жестком диске. Доступно только для ext3 и ext4;
• -f - принудительная проверка файловой системы, даже если по журналу она чистая;
• -b - задать адрес суперблока, если основной был поврежден;
• -p - еще один современный аналог опции -a, выполняет проверку и исправление автоматически. По сути, для этой цели можно использовать одну из трех опций: p, a, y.

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

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

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

sudo fsck -y /dev/sda1

Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.

Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:

sudo mkfs -t ext4 -n /dev/sda1

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

Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:

sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

sudo fsck -c /dev/sda1

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

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

sudo fsck -AR -y

Или исключить все примонтированные файловые системы:

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

sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

sudo fsck -A -t opts=ro

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

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

sudo mount -o remount,ro /dev/sdb1

А теперь проверка файловой системы fsck в принудительном режиме:

sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n.