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

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

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

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

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

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

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