Как я могу узнать, какие файлы были потеряны при попытке восстановления ddrescue?
Для sftp: если у вас есть доступ sudo к оболочке ssh, вы можете добавить свое имя пользователя в корневую группу пользователей в / etc / group и затем дать этой группе разрешения rx в папки, к которым вы хотите получить доступ.
Вам понадобятся номера всех обнаруженных сбойных блоков (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.
Самый простой способ, хотя и не обязательно самый быстрый или эффективный, состоял бы в том, чтобы:
- Запустите ddrescue в обычном режиме, чтобы спасти весь диск, и обязательно сохраните файл карты .
- ReRun
ddrescueв режиме заполнения -для маркировки поврежденных секторов уникальным шаблон. Они рекомендуют что-то вроде этого :
Чтобы избежать ложных срабатываний, вы хотите использовать шаблон, который обычно не существует ни в одном файле.ddrescue --fill-mode=- <(printf "BAD-SECTOR ") outfile mapfile - Смонтируйте восстановленный образ/диск со своей собственной операционной системой.
- Используйте соответствующую утилиту операционной системы, например
e2fsckв Linux, для проверки и, возможно, восстановления структуры каталогов файловой системы. Любые плохие сектора, которые попадают в структуры файловой системы, сначала должны быть разрешены, прежде чем вы сможете искать все повреждения файлов.Repairing directory structures is an art in and of it's self which is out of this answers scope.
- Используйте соответствующую утилиту, предоставляемую операционной системой, например
grep, чтобы просканировать все файлы в файловой системе и составить список тех, которые содержат уникальный шаблон, которым они заполнены в режиме -. - При необходимости вы можете просмотреть файлы в соответствующем редакторе чтобы найти положение фактической потери данных, выполнив поиск уникальный шаблон в файле (s ).
Это не зависит от операционной системы, поэтому я намеренно не привожу подробности, зависящие от конкретного типа файловой системы. Сначала мне пришлось сделать это в файловой системе NTFS с помощью утилит Windows, но та же идея и в ext3/4 и т. д.
NTFS, ext3, ext4
После копирования данных с неисправного диска с помощью ddrescueиспользуйте ddrutility, чтобы найти затронутые имена файлов.
Мне удалось получить список уязвимых файлов NTFS в разделе размером 1 ТБ с помощью файла карты ddrescueменее чем за 20 секунд.
Он записывает свой файл журнала в текущий каталог.
На связанной странице упоминается поддержка NTFS, ext3 и ext4.
бтрфс, зфс
Эти файловые системы имеют собственную встроенную -в scrubфункцию.
Я использовал Filezilla simple и решил свою проблему. Используйте обычную Filezilla для резервного копирования всех хороших данных. Я заметил, что один большой файл копировался неправильно (Остановка в середине и перезапуск передачи ). К счастью, у меня есть предыдущая резервная копия того же файла. Чтобы продублировать диск, мне нужно было найти плохие блоки на диске с помощью этой процедуры:
Сначала найдите проблемный диск, идентифицируя информацию HD, используя fdisk -l
2-й, если допустим, что ваш диск /dev/sdb , тогда вам нужно запустить команду badblocks -v /dev/sdb список всех ваших плохих блоков на диске. К счастью, их будет несколько. Если плохие блоки не обнаружены, значит, с блоками дисков все в порядке, и нужно что-то придумать. Размер моего блока 512, поэтому я использую этот номер по умолчанию для запуска DD
.3-й размер каждого блока 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=fullblock’ обслуживает короткие чтения, но поддерживает синхронизацию ваших данных до конца. Никакой порчи, он просто не копирует неисправные блоки и заполняет их пустыми NUL.
После того, как копирование с помощью DD было выполнено, я просто заменил этот плохой файл, вернув Filezilla из прошлой резервной копии, и все заработало нормально. Я надеюсь, что это будет полезно для других, пытающихся сделать резервную копию неисправных дисков.
ПРИМЕЧАНИЕ. :Плохие блоки были расположены довольно близко друг к другу. Около 4 блоков одновременно вместе в группах, где обнаружены плохие. Если ваши блоки разбросаны по всему диску, могут быть затронуты несколько файлов. К счастью, в моем случае был затронут только большой файл базы данных размером 4 ГБ.