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

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 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** 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
** Phase 1 - Check Blocks and Sizes

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

команда проверки файловой системы и интерактивного восстановления ее.

Синтаксис

fsck -p [-f] fsck [-l maxparallel ] [-q] [-y] [-n] [-d]

Описание

Утилита fsck в первом варианте вызова проверяет набор стандартных файловых систем, либо систем указанных в параметрах. Для этого она использует стандартный скрипт размещенный по адресу /etc/rc выполняя автоматическую перезагрузку. Используя вызов getfsent утилита считывает дескриптор файловой системы (filesystem descriptor) с целью определить какие файловые системы нуждаются в проверке. Будут проверены разделы имеющие параметры "rw", "rq", "ro" и те которые имеют ненулевой параметр прохождения. Файловые системы имеющие параметр прохождения 1 (стандартная корневая файловая система) будет проверена один раз.

Сейчас fsck представляет собой оболочку вызывающую в случае необходимости другие утилиты из группы fsck_XXX . Сейчас доступны fsck_hfs , fsck_msdos , fsck_exfat и fsck_udf . Если утилита столкнется с серьезными нарушениями файловой системы или формат проверяемого раздела не будет соответствовать одному из выше перечисленных fsck завершится с ошибкой и автоматическая перезагрузка будет завершена с ошибкой. Для каждой исправленной системы будет выведена одна или несколько строк с информацией описывающей систему, место и характер коррекции.

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

Без параметра -p fsck проверяет и интерактивно восстанавливает несовместимые условия для файловых систем. Некоторые из данных действий по восстановлению могут привести к потери части данных. Объем потерь можно увидеть в диагностическом выводе. Если у пользователя нет прав на запись в файловой системе утилита автоматически будет выполнение с параметром -n.

Параметры

-f	Форсировать проверку. Игнорировать флаг "clean"
-l	Ограничить число параллельных проверок количеством указанным после аргумента. По умолчанию fsck запускает по одному процессу на диск. Если лимит задан меньшим числом, то проверка происходит последовательно.
-p	Режим чистки
-q	Выполнить быструю проверку если том был размонтирован
-y	Отвечать на все задаваемые вопросы утвердительно. Использовать с крайней осторожностью.
-n	не запрашивать никаких подтверждений у оператора, за исключением "CONTINUE?" (продолжить). Не запускайте утилиту если файловая система вам доступна для записи.

На операционных системах Mac OS X начиная c dthcbb 10.3 необходимость применения данной утилиты практически отсутствует. И с большинством проблем справляется дисковая утилита diskutil.

Если у вас все-таки такая необходимость возникла, перезагрузите компьютер в однопользовательский режим, зажав во время загрузки клавиши Cmd+S . Наберите в командной строке

/sbin/fsck -fy

После проверки дисков будет выведено либо

Программа 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, а последний параметр - это корневая файловая система (/).

Неисправный жёсткий диск - одно из самых неприятных явлений в работе компьютера. Мало того что мы легко можем потерять очень много важной информации и файлов, так и замена HDD неслабо бьёт по бюджету. Прибавим к этому потраченное время и нервы, которые, как известно, не восстанавливаются. Чтобы не дать проблеме застать нас врасплох и заранее диагностировать её, стоит знать, как проверить жёсткий диск на ошибки в ОС Ubuntu. Программных средств, предоставляющих такие услуги, предостаточно.

Как в Ubuntu протестировать жесткий диск на ошибки.

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

Открываем терминал и вводим:

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

После этого вводим:

sudo badblocks -sv /dev/sda

Команда служит уже для поиска повреждённых секторов. Вместо /dev/sda вводим имя своего накопителя. Ключи -s и -v служат для того, чтобы отображать в правильном порядке ход проверки блоков (s) и чтобы выдавать отчёт обо всех действиях (v).

Нажатием клавиш Ctrl + C мы останавливаем проверку жёсткого диска.

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

Для того чтобы размонтировать файловую систему, вводим:

Для проверки и исправления ошибок:

sudo fsck -f -c /dev/sda

• «-f» делает процесс принудительным, то есть проводит его, даже если HDD помечен как работоспособный;
• «-c» находит и помечает бэд-блоки;
• «-y» - дополнительный вводимый аргумент, который сразу же отвечает Yes на все вопросы системы. Вместо него можно ввести «-p», он проведёт проверку в автоматическом режиме.

Программы

Дополнительное программное обеспечение также отлично справляется с этой функцией. А иногда даже лучше. Тем более что некоторым пользователям проще работать с графическим интерфейсом.

GParted как раз для тех, кому текстовый интерфейс не по душе. Утилита выполняет большое количество задач, связанных с работой HDD на Убунту. В их число входит и проверка диска на ошибки.

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

sudo apt-get install gparted

1. Открываем приложение. На главном экране сразу же выводятся все носители. Если какой-то из них помечен восклицательным знаком, значит, с ним уже что-то не так.
2. Щёлкаем по тому диску, который хотим проверить.
3. Жмём на кнопку «Раздел», расположенную сверху.
4. Выбираем «Проверка на ошибки».

Программа отсканирует диск. В зависимости от его объёма процесс может идти дольше или меньше. После сканирования мы будем оповещены о его результатах.

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

Качаем программу:

aptitude install smartmontools

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

ls -l /dev | grep -E ‘sd|hd’

Вбиваем команду для выведения подробной информации о носителе. Стоит посмотреть на параметр ATA. Дело в том, что при замене родного диска, лучше ставить устройство с тем же либо большим ATA. Так можно максимально раскрыть его возможности. А также посмотрите и запомните параметры SMART.

smartctl —info /dev/sde

Запускаем проверку. Если SMART поддерживается, то добавляем «-s». Если он не поддерживается или уже включён, то этот аргумент можно убрать.

smartctl -s on -a /dev/sde

После этого смотрим информацию под READ SMART DATA. Результат может принимать два значения: PASSED или FAILED. Если выпало последнее, можно начинать делать резервные копии и искать замену винчестеру.

Этим возможности программы не исчерпываются. Но для однократной проверки HDD этого будет вполне достаточно.

Safecopy

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

Устанавливаем Safecopy:

sudo apt install safecopy

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

sudo safecopy /dev/sda /home/

Бэд-блоки

У некоторых могут возникнуть вопросы: «что такое эти битые блоки и откуда они, вообще, взялись на моём HDD, если я его ни разу не трогал?» Bad blocks, или бэд-секторы - разделы HDD, которые больше не читаются. Во всяком случае так они по объективным причинам были помечены файловой системой. И скорее всего, с диском в этих местах действительно что-то не так. «Бэды» встречаются как на старых винчестерах, так и на самых современных, поскольку работают они практически по тем же самым технологиям.

Появляются же сбойные секторы по разным причинам.

• Прерывание записи из-за отключения питания. Вся информация, поступающая на жёсткий диск, разбивается в виде единиц и нулей на самые разные его части. Сбить этот процесс - значит сильно запутать винчестер.
• Некачественная сборка. Тут и говорить нечего. У дешёвого китайского устройства полететь может что угодно.

Теперь вы знаете, как сканировать HDD на ошибки. Проверка диска как на Ubuntu, так и на других системах довольно важная операция, которую стоит проводить хотя бы раз в год.