Как вы можете заставить Linux Linux Raid не отключать диск для восстановления?

Я пытаюсь восстановить данные из массива RAID5. 2 из 4 моих дисков неожиданно вышли из строя одновременно. Я могу запустить массив, заставив его.

mdadm --assemble --scan --force

Массив запускается ckean, но ухудшается

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Apr 18 22:03:46 2012
     Raid Level : raid5
     Array Size : 8790795264 (8383.56 GiB 9001.77 GB)
  Used Dev Size : 2930265088 (2794.52 GiB 3000.59 GB)
   Raid Devices : 4
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Mon Aug 25 23:50:44 2014
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 157604ce:9206dd99:c8d249be
         Events : 21524

    Number   Major   Minor   RaidDevice State
       4       8       16        0      active sync   /dev/sdb
       1       0        0        1      removed
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd

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

[  190.250032] end_request: I/O error, dev sdc, sector 1234525616
[  190.250082] raid5:md0: read error not correctable (sector 1234525616 on sdc).
[  190.250086] raid5: Disk failure on sdc, disabling device.
[  190.250088] raid5: Operation continuing on 2 devices.
[  190.250195] ata5: EH complete
[  190.366679] Buffer I/O error on device md0, logical block 462946358
[  190.366723] lost page write due to I/O error on md0
[  192.873263] ata5.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0
[  192.873308] ata5.00: irq_stat 0x40000008
[  192.873348] ata5.00: failed command: READ FPDMA QUEUED
[  192.873392] ata5.00: cmd 60/10:00:00:dc:3c/00:00:57:00:00/40 tag 0 ncq 8192 in
[  192.873394]          res 41/40:10:00:dc:3c/00:00:57:00:00/00 Emask 0x409 (media error) <F>
[  192.873476] ata5.00: status: { DRDY ERR }
[  192.873514] ata5.00: error: { UNC }
Источник

2 ответа

Вы должны сделать образы всех дисков-участников RAID с помощью такого инструмента, как dd_rescueи затем соберите том RAID с этими образами.

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

Источник

Проблема в том, что файловая система ext2/3/4 ничего не знает от базового устройства. Если на некоторых устройствах raid обнаружен сбойный блок, это приведет к двум независимым результатам:

  1. подсистема raid отключит весь диск и переведет массив в деградированный режим
  2. файловая система будет подписывать ошибку чтения (в случае зеркала это не всегда так).

У меня есть мнение, которое в кругах "профессионального системного администратора" считается в основном еретическим. По этому мнению,

  1. диск с некоторыми плохими блоками не исходит от дьявола,
  2. если у вас есть хороший сектор 45634563563456 на жестком диске, возможно, вы сможете справиться с 3 плохими между ними.

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

Если у вас есть рейд, самым простым решением было получить новый жесткий диск. Этот можно использовать и для других задач, но не для рейда. Файловая система Ext2/3/4 имеет очень хорошую обработку плохих блоков.

Если вы хотите использовать устройство в качестве участника рейда, это возможно, хотя и не так просто. В этом случае вы можете сделать несколько хитрых решений на основе lvm- некоторые из них могут обрабатывать тома и управлять ими даже на диске с поврежденными блоками. Я предлагаю вам попробовать с плохим модулем перемещения блока устройства отображения.

Источник
Другие вопросы по тегам