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

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

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

mdadm --assemble --scan --force

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

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 }

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

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

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

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

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

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

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

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

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