Я занимаюсь восстановлением данных с вышедшего из строя диска объемом 1 ТБ (об этом спрашивали вПроцедура замены жесткого диска?). Я сделал это ddrescueс USB-накопителя для восстановления системы, в результате чего размер ошибки составил 557568 Б при 191 ошибке, вероятно, всего /home(я предполагаю, что то, что он называет «ошибками», — это не плохие сектора, а их последовательные последовательности).
Теперь, несколько руководств, которые я видел вокруг, предлагают сделать e2fsckна новом диске, и я ожидал, что это каким-то образом обнаружит, что некоторым файлам были назначены "пустые сектора/блоки", чтобы, по крайней мере, знать, какие файлы не могут быть сохранены целиком. Но никаких ошибок не было найдено вообще (я запустил его без , -yчтобы убедиться, что я ничего не пропустил). Теперь я снова запускаю его с -c, но на 95% ошибок пока не обнаружено; я предполагаю, что у меня есть новый диск с некоторыми нормально выглядящими файлами с нулевыми или случайными частями внутри, необнаруживаемыми, пока я не открою их соответствующим программным обеспечением, или пока они не понадобятся Linux Mint.
Могу ли я что-нибудь сделать со старыми/новыми дисками, чтобы получить список возможно поврежденных файлов? Я не знаю, сколько их может быть, так как эти 191 могут быть распределены по файлам, но, по крайней мере, общий размер невелик; меня больше всего беспокоит большая куча старых семейных фотографий и видео (по 1+ МБ каждое), остальное, вероятно, не имеет значения или было недавно скопировано.
Обновление: новый проход e2fsck дал что-то новое, в чем я ничего не понимаю:
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes
решение1
Вам понадобятся номера всех обнаруженных плохих блоков ( ddrescueя должен был предоставить вам список, надеюсь, вы его сохранили), а затем вам нужно будет выяснить, какие файлы используют эти блоки (см., например,здесь). Вы можете захотеть написать этот скрипт, если есть много плохих блоков.
e2fsckне помогает, он просто проверяет целостность самой файловой системы, поэтому будет действовать только в тех плохих блоках, которые содержат «административную» информацию файловой системы.
Поврежденные блоки в файлах будут просто пустыми.
Редактировать
Хорошо, давайте разберемся с размером блока. Давайте создадим пробную файловую систему с блоками устройств по 512 байт:
$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs
$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs
$ /sbin/tune2fs -l fs
...
Block count: 100
...
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Итак, размер блока файловой системы составляет 1024, и у нас есть 100 таких блоков файловой системы (и 200 блоков устройств по 512 байт). Спасаем его:
$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 102400 B, errsize: 0 B, current rate: 102 kB/s
ipos: 65536 B, errors: 0, average rate: 102 kB/s
opos: 65536 B, run time: 1 s, successful read: 0 s ago
Finished
$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time: 2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos current_status
0x00010000 +
# pos size status
0x00000000 0x00019000 +
$ printf "%i\n" 0x00019000
102400
Итак, шестнадцатеричные ddrescueединицы — это байты, а не блоки. Наконец, давайте посмотрим, что debugfsиспользует. Сначала создадим файл и найдем его содержимое:
$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp
$ hexdump -C fs
...
00005400 61 62 63 64 65 66 67 68 69 6a 6b 0a 00 00 00 00 |abcdefghijk.....|
00005410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Итак, адрес байта данных равен 0x5400. Преобразуем это в блоки файловой системы по 1024 байта:
$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21
и давайте также попробуем диапазон блока, пока мы этим занимаемся:
$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs: testb 0
testb: Invalid block number 0
debugfs: testb 1
Block 1 marked in use
debugfs: testb 99
Block 99 not in use
debugfs: testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs: testb 21
Block 21 marked in use
debugfs: icheck 21
Block Inode number
21 12
debugfs: ncheck 12
Inode Pathname
12 //foo
Итак, это работает так, как и ожидалось, за исключением того, что блок 0 недействителен, вероятно, потому, что там находятся метаданные файловой системы. Итак, для вашего байтового адреса 0x30F8A71000из ddrescue, предполагая, что вы работали со всем диском, а не с разделом, мы вычитаем байтовый адрес начала раздела
210330128384 - 7815168 * 512 = 206328762368
Разделите это на tune2fsразмер блока, чтобы получить блок файловой системы (обратите внимание, что поскольку несколько физических, возможно поврежденных, блоков составляют блок файловой системы, числа не обязательно должны быть кратными):
206328762368 / 4096 = 50373233.0
и это тот блок, который вам следует протестировать debugfs.
решение2
NTFS, ext3, ext4
После копирования данных с вашего вышедшего из строя диска с помощью ddrescue, используйтеddrutilityчтобы найти затронутые имена файлов.
Мне удалось успешно составить список затронутых файлов NTFS на разделе объемом 1 ТБ с использованием ddrescueфайла карты менее чем за 20 секунд.
Он записывает свой файл журнала в текущий каталог.
На связанной странице упоминается поддержка NTFS, ext3 и ext4.
btrfs, zfs
Эти файловые системы имеют собственную встроенную scrubфункцию.
решение3
Я бы рекомендовал уже реализованную утилиту под названием ddrutility. Это исключило бы ручные утомительные вычисления.
Вы должны запустить его на своем клонированномкопия(не оригинальное) приводное устройство, например:
ddru_findbad /dev/sdb /ddrescue-disk-copy.map
Использование файла карты (второй аргумент) здесь обязательно.
Утилита довольно умная, поддерживает разные файловые системы (даже NTFS), а также имеет функционал проверки еще не разделенных ошибочных секторов (отмечая их как плохие временные), поэтому вы должны быть в состоянии оценить, нужно ли вам ddrescueзавершать всю процедуру. Также обратите внимание, что /dev/sdbздесь используется целый диск (а не какой-то раздел типа /dev/sdb1), поскольку изначально был клонирован весь диск.
Утилита доступна в репозиториях Debian и может быть установлена с помощью:
sudo apt install ddrutility
Вики проекта:https://sourceforge.net/p/ddrutility/wiki/Главная
решение4
Я использовал Filezilla simple и исправил свою проблему. Используйте обычную Filezilla для резервного копирования всех хороших данных. Я заметил, что один большой файл не копировался правильно (останавливался на середине и перезапускал передачу). К счастью, у меня есть предыдущая резервная копия того же файла. Чтобы сделать дубликат диска, мне пришлось найти плохие блоки на диске, используя эту процедуру:
1-й найдите проблемный диск, идентифицируя информацию о HD с помощьюfdisk -l
2-й, если, скажем, ваш диск/dev/sdbто вам нужно выполнить команду плохие блоки -v /dev/sdbон выведет список всех плохих блоков на диске. К счастью, их будет несколько. Если плохих блоков не обнаружено, значит, с блоками вашего диска все в порядке и нужно что-то еще придумать. Мой размер блока — 512, поэтому я использую это значение по умолчанию для запуска DD
В-третьих, каждый блок имеет размер 512, поэтому я установил bs=512.
Каждый раз, когда я запускал DD регулярно, как я всегда делаю, мои данные после ошибок выходили поврежденными. Поэтому я затем использовал параметры, как описано на страницеhttps://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.htmlнайдите раздел «Для неисправных дисков».
dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock
Это заняло некоторое время. Каждый обнаруженный плохой блок издавал звук, похожий на стук по неисправному диску. Он копирует блок за блоком, и через все мои плохие блоки издавал тот же звук. Количество раз, когда издавал звук, было связано с тем, что он находил другой плохой блок и сообщал вам об ошибке на дисплее. Что'conv=noerror,sync'делает, это заполняет плохие чтения с помощью NUL, в то время как'iflag=полный_блок'обслуживает короткие чтения, но сохраняет синхронизацию ваших данных до конца. Никаких повреждений, просто не копирует неисправные блоки и заполняет их пустыми NUL.
После того, как копирование с помощью DD было сделано, я просто заменил этот плохой файл, вернув Filezilla из прошлой резервной копии, и все заработало нормально. Надеюсь, это будет полезно для других, пытающихся сделать резервную копию неисправных дисков.
ПРИМЕЧАНИЕ: Мои плохие блоки были довольно близко друг к другу. Около 4 блоков одновременно вместе в группах, где были обнаружены плохие. Если ваши блоки по всему диску, могут быть затронуты несколько файлов. К счастью, в моем случае был затронут только большой файл базы данных размером 4 ГБ.