|

В некоторых ситуациях файлы сервера повреждаются, и тогда файловая система нуждается в восстановлении. Такое бывает, если VPS внезапно отключился или произошел какой-либо программный или аппаратный сбой.

Существуют методы восстановления файлов VPS; по крайней мере, вы можете спасти самые важные из них.

Важные замечания и риски

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

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

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

1: Восстановление с помощью ядра fsck

Примечание: Новые дистрибутивы (FreeBSD, CoreOS, Debian 8 и Ubuntu 15.04) не могут использовать ядро восстановления. Если вы пользуетесь одним из этих дистрибутивов, переходите к разделу «Восстановление с помощью ISO».

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

Запуск fsck

Сначала отключите сервер. Для этого введите в командную строку:

Также это можно сделать с помощью панели управления. Нажмите Power Off или аналогичный вариант.

Отключив сервер, перейдите в настройки и откройте раздел восстановления. Запишите, какое ядро использует сервер, чтобы вернуть все на места после восстановления. Затем смонтируйте ядро восстановления (кнопка Mount Recovery Kernel или подобная).

Изменив ядро, запустите сервер.

Затем подключитесь к серверу через консоль. На данный момент SSH-доступ к серверу, скорее всего, отсутствует, поскольку сервер использует ядро восстановления.

В текущем окне откроется сессия терминала, и вы получите доступ к среде Linux.

Теперь нужно запустить fsck, чтобы найти и исправить ошибки в файловой системе.

Способ вызова этой команды будет зависеть от того, поддерживает ли сервер VirtIO. Если да, то жесткий диск сервера, скорее всего — /dev/vda или /dev/vda1 (в зависимости от системы). Вы можете уточнить это, набрав:

Если сервер не поддерживает VirtIO, жесткий диск находится в /dev/sda.

Итак, вам нужно запустить команду:

fsck -yf /dev/vda

fsck -yf /dev/vda1

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

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

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

Изменив ядро, запустите сервер и подключитесь к нему через консоль.

Если сервер раньше не запускался, а теперь запустился – это хороший знак.

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

Также важно проверить каталог /lost+found. В него fsck помещает частично восстановленные файлы.

Иногда fsck может восстановить данные файла, но не может найти ссылку на файл в файловой системе. По сути, это файл без имени. В такой ситуации fsck помещает файлы в каталог /lost+found, чтобы вы могли попытаться вручную определить, что это за файл.

Просмотрите содержимое каталога /lost+found:

cd /lost+found
ls

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

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

2: Восстановление с помощью ISO

Если ядро и fsck не помогли восстановить систему, попробуйте использовать ISO восстановления.

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

Отключите сервер. Если у вас остался доступ к командной строке, введите:

Если доступа к командной строке нет, отключите сервер через панель управления.

Затем с помощью панели управления обратитесь за помощью в техподдержку. При этом следует перечислить предпринятые вами действия по восстановлению.

Команда техподдержки должна предоставить вам ISO для восстановления. После этого запустите сервер и подключитесь к нему через консоль.

Вы увидите главное меню среды восстановления.

Настройка сети в среде восстановления

Стандартный ISO восстановления, как правило, автоматически настраивает сетевое взаимодействие с серверами в регионах, которые поддерживают метаданные. В других регионах вам придется вводить данные сети вручную.

Используйте в настройке параметры общей сети.

Запуск fsck в ISO восстановления

Чтобы запустить проверку и восстановление файловой системы fsck, выберите в меню Check Filesystem (или аналогичный вариант) и нажмите Enter. Среда восстановления обнаружит образ диска и попытается запустить на нем fsck. Утилита сообщит о любых ошибках и проблемах, возникших на сервере.

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

Данная среда Linux запущена с образа ISO, а не с сервера, потому вам нужно смонтировать файловую систему в среде, чтобы получить доступ к файлам. Выберите в меню Mount your Disk Image и нажмите Enter. Образ диска будет обнаружен и смонтирован в /mnt в среде восстановления.

Если вы ранее запускали проверку файловой системы из ядра восстановления или из ISO-образа, теперь вы можете проверить наличие частично восстановленных файлов в каталоге /mnt/lost+found.

Перейдите в каталог /mnt, и вы увидите свою файловую систему:

cd /mnt
ls
bin/ etc/ lib/ media/ proc/ sbin/ sys/ var/
boot/ home/ lib64/ mnt/ root/ selinux/ tmp/ vmlinuz@
dev/ initrd.img@ lost+found/ opt/ run/ srv/ usr/

Откройте lost+found и просмотрите частично восстановленные файлы.

cd lost+found
ls

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

Если файлы в lost+found не поддаются восстановлению (или если вы хотите только сохранить некоторые данные), вы можете попытаться разгрузить свои файлы на удаленную машину (другой сервер или другую физическую машину).

Перемещение файлов с помощью SFTP

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

Убедитесь, что главное меню показывает смонтированную файловую систему, и включите SSH-сервер.

Будет предложено создать временный root пароль для доступа к серверу.

Примечание: Это никак не повлияет на постоянный root-пароль сервера.

Дважды введите временный пароль. После этого среда восстановления установит и настроит сервер SSH.

Теперь вы можете получить доступ к серверу с помощью клиента SSH или SFTP. SFTP-клиент Filezilla позволяет создавать новые соединения, требуя для этого следующие данные:

Host: your_ server_IP
Port: 22
Protocol: SFTP - SSH File Transfer Protocol
Login Type: Normal
User: root
Password: TEMPORARY_PASSWORD

После подключения вы попадёте в каталог /root. Файловая система будет в /mnt. Перейдите в этот каталог, выберите необходимые файлы и переместите их на локальную машину.

Программа fsck используется для проверки файловых систем и для коррекции ошибок файловой системы, если таковые найдутся. Основное требование для проверки файловой системы: файловая система должна быть размонтирована. Запуск f век для уже смонтированной файловой системы может привести к ее разрушению - тогда уже даже и fsck не поможет. Программа fsck может использоваться для проверки файловых систем, которые поддерживаются ядром Linux.
Формат вызова программы следующий:
sudo fsck [параметры] [файловая_система]

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

Последовательность проверки файловой системы должна быть следующая:
1. Размонтировать файловую систему.
2. Запустить f sck для ее проверки.

Например, для проверки файловой системы раздела /dev/hda5 сначала размонтируем его, а потом запустим f sck:
sudo -i
# umount /dev/hda5
# fsck /dev/hda5

Но иногда мы не можем размонтировать файловую систему, например, когда нам нужно проверить корневую файловую систему. В этом случае нужно выполнить следующие действия:
1. Перезагрузиться в однопользовательском режиме.
2. Перемонтировать корневую файловую систему в режиме «только чтение».
3. Произвести проверку файловой системы.

Для перезагрузки в однопользовательском режиме перезагрузите систему (команда reboot), а при загрузке передайте ядру параметр single.
В однопользовательском режиме, как и следовало ожидать, может работать только один пользователь - root.
Все сервисы выключены, так что проверке файловой системы ничто не должно помешать. Для перемонтирования файловой системы введите команду:
# mount -о remount го -t ext3 /
Параметр -о команды mount позволяет указать различные опции. В данном случае мы указываем опции remount и го, что означает перемонтировать в режиме «только чтение». Параметр -t указывает тип файловой системы - ext3, а последний параметр - это корневая файловая система (/).

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

Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему 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.

Иногда по разным причинам (в результате сбоя, некорректного завершения работы) файловые системы накапливают ошибки. Сами ошибки представляют собой «рассогласованные» структуры данных. Естественно, при возникновении такой ситуации необходимо как можно скорее привести повреждённую в порядок. С этой задачей отлично справляется утилита 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 [параметр] -- [параметры ФС] [<файловая система> . . .]

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

Опция Описание
-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, следует воспользоваться командой:

$ 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 .

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

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 работает и в ручном режиме.