Назад | Перейти на главную страницу

Восстановление раздела mdadm + lvm + ext4 с ошибкой чтения

Один из дисков в моем NAS вышел из строя. NAS работает под управлением Linux и использует технологию mdadm + LVM для своих файловых систем.

У меня есть резервная копия большей части содержимого, но не самых последних изменений, и, если возможно, я хотел бы восстановить ее с этого неисправного диска.

Диск («зеленый диск» WD10EARS размером 1 ТБ) выдает следующие ошибки:

Oct  3 12:00:41 kernel: [ 3625.620000] ata5.00: read unc at 9453282
Oct  3 12:00:41 kernel: [ 3625.620000] lba 9453282 start 9453280 end 1953511007 
Oct  3 12:00:41 kernel: [ 3625.620000] sde5 auto_remap 0
Oct  3 12:00:41 kernel: [ 3625.630000] ata5.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6
Oct  3 12:00:41 kernel: [ 3625.630000] ata5.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
Oct  3 12:00:41 kernel: [ 3625.640000] ata5.00: failed command: READ FPDMA QUEUED
Oct  3 12:00:41 kernel: [ 3625.650000] ata5.00: cmd 60/40:00:e0:3e:90/00:00:00:00:00/40 tag 0 ncq 32768 in
Oct  3 12:00:41 kernel: [ 3625.650000]          res 41/40:00:e2:3e:90/12:00:00:00:00/40 Emask 0x409 (media error) <F>
Oct  3 12:00:41 kernel: [ 3625.660000] ata5.00: status: { DRDY ERR }

Однако во время тестирования с dd я заметил, что если я пропущу первые 4 КБ, чтение будет нормальным, т.е. команда вроде. dd if = / dev / sde5 of = dev / null bs = 4k count = 1000 skip = 1 не возвращает ошибок чтения.

Предположим, что на остальной части диска нет других сбоев чтения, смогу ли я восстановить этот раздел размером 900 ГБ (как я уже упоминал ранее, это раздел «linux raid autodetect», содержащий том LVM2, содержащий файловую систему ext4 ) если я скопирую-клонирую раздел в другом месте, кроме первых 4кБ?

... В противном случае (т.е. если у вас уже есть деградированный массив) вы все равно сможете это сделать.

Если ваш mdadm, который создал массив, имеет размер <v.3.0, то полезная нагрузка начинается со смещения 0x22000 (и далее вверх, если это v.3.0 или новее), что также предшествует удаленному первому 4 КБ.

Таким образом, был поврежден только суперблок linux-raid, но это не так уж сложно восстановить (особенно если у вас есть другие устройства в этом массиве).

Учитывая, что это был относительно простой случай, когда устройство md работало как одно физическое устройство для тома LVM, линейно выделенного, и которое обертывает одну файловую систему ext4, моим решением было пойти сразу после ext4 fs и смонтировать его как файловую систему цикла для время, необходимое для восстановления.

Мои шаги:

  • Как упоминалось выше, с дд Я скопировал весь поврежденный раздел в раздел такого же размера на исправном диске (здесь ниже назван / dev / sdd5)
  • Я скопировал первый МБ / dev / sdd5 в файл и импортирован на мой настольный компьютер Ubuntu, где я открыл его с помощью шестнадцатеричного редактора гекс
  • Я видел из ext wiki https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block этот суперблок EXT4 имеет по смещению 0x38 магическое число 0xEF53, и из моего шестнадцатеричного дампа я смог найти эту подпись.
  • Повторив то же самое с другой исправной файловой системой ext4, я обнаружил, что начало суперблока составляет 1024 байта после начала раздела, поэтому я вычислил, каким будет смещение от начала раздела. sdd5 в начало раздела ext4, который я искал.
  • Я создал раздел цикла с помощью losetup -o <offset> /dev/loop0 /dev/sdd5
  • Проверено fsck -n /dev/loop0 это смещение было правильным, поскольку я действительно получил действительный ext fs и что файловая система была, по крайней мере, в согласованном состоянии.
  • Я смонтировал цикл fs в режиме только для чтения во временный каталог: mount -o ro /dev/loop0 /tmp/recovery

На этом этапе я мог начать получать доступ к контенту, из которого хотел восстановить / tmp / recovery /.