Проверка файловой системы linux. Программа fsck — проверка файловых систем в ubuntu. Перемещение файлов с помощью SFTP

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

Синтаксис

Описание

Утилита 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.

Параметры

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

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

/sbin/fsck -fy

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

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

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

Файловая система 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 , присваиваются имена, совпадающие с номерами их индексных дескрипторов.

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