У меня есть 3 жестких диска, в следующих параграфах с именами /dev /sda, /dev /sdb и /dev /sdc сначала появились новейшие. Примечание: /dev /sdc имеет один основной раздел /dev /sdc1, один расширенный раздел /dev /sd2 и 3 логических раздела /dev /sdc5, /dev /sdc6 и /dev /sda7.
Я создал деградированное устройство RAID 5 /dev /md0 с /dev /sda5 и /dev /sdb5 (планировалось добавить /dev /sdc5 к RAID, чтобы перевести его в нормальное состояние), затем использовал /dev /md0 в качестве единственного pv LVM и создал lv с файловой системой ext4 /dev /mapper /vg0-lv0.
К сожалению, при изучении и игре с LVM я запускаю dd if=/dev/zero of=/dev/sdc1 bs=64M count=10 после удаления /dev /sdc1. Таким образом, на самом деле нули были записаны в /dev /sdc2, а поврежденная часть таблицы разделов хранится в /dev /sdc2 и в начальной части /dev /sdc5.
Когда я понял это, я сразу же сделал образ /dev /sdc через dd, например: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img .
Несколько дней спустя у меня наконец-то есть время попытаться восстановить данные в /dev /sdc, фактически только в /dev /sdc7, так как это единственный раздел без резервного копирования. Я запустил testdisk с файлом образа sdc.img, воспользовался функцией быстрого поиска, чтобы перестроить таблицу разделов, потеряв ее в /dev /loop0. /dev /loop0p7 (который является образом /dev /sdc7) вернулся и был смонтирован, и все файлы выглядят нормально. Затем я запустил find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum для создания списка контрольных сумм MD5 для всех файлов в /dev /loop0p7.
При работе с физическим /dev /sdc устройством быстрый поиск testdisk не находит все разделы, а Deep Search делает это. Затем я построил список контрольных сумм MD5 sdc7.md5sum для всех файлов на физическом /dev /sdc7 с помощью аналогичной команды. При сравнении с sdc7_image.md5sum я обнаружил, что 4 файла отличаются. После сравнения их вручную я заметил, что каждый файл имеет разницу только в 1 байт. И поскольку в одном файле указано имя CRC32, я могу подтвердить, что файл из физического /dev /sdc7 является правильным.
Итак, мой вопрос: почему произошла эта странная вещь? Я уже запустил fsck.ext4 -c -c /dev/mapper/vg0-lv0 чтобы убедиться, что у него нет плохих блоков. Разница в 4 байта в данных объемом 1,2 ТБ составляет такой небольшой процент, но это не позволяет мне уверенно сохранять данные в /dev /mapper /vg0-lv0 в будущем.
Обновление: я должен отметить, что все операции были выполнены в последней версии ArchLinux, работающей в VirtualBox 4.1.16, которая работает в Windows 7. /dev /sda, /dev /sdb и /dev /sdc связаны с физическими жесткими дисками, через VBoxManage internalcommands createrawvmdk . VirtualBox только сообщил об ошибке VERR_ACCESS_DENIED при сделанных md5sums для физического / DEV /sdc7, после форума физического диска с помощью diskpart из Win7, никаких дальнейших ошибок не подняли.