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

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

Пришлось и мне столкнуться с данной проблемой. Мой один товарищ, у которого установлена Убунту на старенький ноутбук ASUS, и который просто не хочет хоть иногда включать мозги, обратился ко мне с такой проблемой. На его ноуте установлена новая Убунту 12.10 и очень часто система просто не хочет грузиться, выбрасывая в черный экран, либо застывая на фиолетовом фоне. А вот в последнее время начало выскакивать такое вот сообщение, что-то типа «Операционная система не смогла загрузиться. Выберите для дальнейших действий нужную клавишу…» И дальше идет описание, что нужно нажать. Я уже точно не помню, какие клавиши предлагает нажать система, но смысл такой, что для автоматического исправления ошибок нажмите такую-то клавишу, для ручной отладки другую, и чтобы игнорировать это сообщение предлагается нажать третью кнопку. Автоматическое исправление ошибок ни к чему не приводило и загрузка операционной системы так и не доходила до логического завершения. Вот и решил я попробовать знаменитую команду fsck .

Для начала нужно загрузиться либо с загрузочной флешки с Ubuntu (Lubuntu, Xubuntu, Kubuntu и т.д.), либо с диска Ubuntu Live CD. Теперь нам нужно узнать, какой именно раздел с Убунту нам нужно просканировать для исправления файловой системы. Запускаем Терминал (Ctrl-Alt-T) и выполняем команду:

sudo fdisk -l

Данная команда покажет нам все диски, флешки, которые примонтированы к системе. Я приведу пример с моим личным компьютером, а не с ноутбуком приятеля. Вот, что вышло у меня:

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 640.1 GB , 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors

Disk identifier: 0x0009d6f7

/dev/sda1 * 2048 61442047 30720000 83 Linux
/dev/sda2 61442048 73730031 6143992 82 Linux swap / Solaris
/dev/sda3 73730048 1250263039 588266496 83 Linux

Disk /dev/sdb: 500.1 GB , 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xb9ff6f01

Device Boot Start End Blocks Id System
/dev/sdb1 * 16065 100197404 50090670 83 Linux
/dev/sdb2 105322201 976771071 435724435+ 5 Extended
/dev/sdb3 100197405 105322139 2562367+ 82 Linux swap / Solaris
/dev/sdb5 105322203 832110591 363394194+ 7 HPFS/NTFS/exFAT
/dev/sdb6 832112640 860755218 14321289+ 83 Linux
/dev/sdb7 860758016 862613503 927744 82 Linux swap / Solaris
/dev/sdb8 862615552 976771071 57077760 83 Linux

Partition table entries are not in disk order

Disk /dev/sdc: 8115 MB , 8115978240 bytes
250 heads, 62 sectors/track, 1022 cylinders, total 15851520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc3072e18

Device Boot Start End Blocks Id System
/dev/sdc1 * 32 15847625 7923797 b W95 FAT32

Как видно из вывода команды sudo fdisk -l , у меня имеются 2 жестких диска (sda)640 Гб и (sdb)500 Гб, а также флешка (sdc)8Гб, с которой я собственно и загружался. Я знаю, что моя основаня система с Убунту 12.04 находится на диске sda, а раздел с операционной системой соответственно называется sda1.

Теперь когда мы знаем раздел, который нужно сканировать, можно собственно приступить к его проверке. В Терминале:

sudo fsck -y -f -c /dev/sda1

если увидете ошибку, то скорее всего нужно отмонтировать данный раздел:

sudo umount /dev/sda1

Ключи и параметры команды fsck:

y - всегда отвечать yes на все вопросы (имеется альтернатива: ключ p - начинает проверку в полностью автоматическом режиме);

f - принудительная проверка файловой системы (даже если файловая система помечена как полностью работоспособная)

c - ищет битые блоки (bad blocks), а после отмечает их соответствующим образом

/dev/sda1 - устройство или раздел, которые нужно проверить. Хотя команда может иметь и другой вид. Например:

sudo fsck -p /dev/sda1

В данном случае добавлен только ключ -p. Вы просто почитайте о всех ключах команды fsck и добавляйте именно нужные вам ключи. Чтобы узнать о всех возможностях программы введите в Терминале:

man fsck

Вот, что выдал Терминал после проверки:

ubuntu@ubuntu:~$ sudo fsck -y -f -c /dev/sda1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Checking for bad blocks (read-only test): 0.00% done, 0:00 elapsed. (0/0/0 errdone
/dev/sda1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

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

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

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

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

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