Как восстановить массив mdadm на NAS-устройстве Synology с диском в состоянии «E»?

12

Synology имеет настроенную версию наборов драйверов md и mdadm, которая добавляет флаг 'DriveError' в структуру флагов rdev-> в ядре.

Чистый эффект - если вам не повезло получить сбой массива (первый диск) в сочетании с ошибкой на втором диске - массив переходит в состояние, не позволяющее восстанавливать / восстанавливать массив, даже если чтение с диска работает хорошо.

На данный момент, я не очень беспокоюсь об этом вопросе с точки зрения ЭТОГО массива, так как я уже извлек контент и собираюсь его реконструировать, но больше из-за желания иметь путь разрешения для этого в будущем , так как это второй раз, когда меня это укусило, и я знаю, что видел, как другие задают подобные вопросы на форумах.

Поддержка Synology была менее чем полезной (и в основном не отвечающей) и не предоставит никакой информации ВСЕ о работе с наборами raidsets на коробке.

Содержимое / proc / mdstat:

ds1512-ent> cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]

md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
      2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
      2490176 blocks [5/5] [UUUUU]

unused devices: <none>

Статус из mdadm --detail / dev / md2:

/dev/md2:
        Version : 1.2
  Creation Time : Tue Aug  7 18:51:30 2012
     Raid Level : raid5
     Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
  Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Fri Jan 17 20:48:12 2014
          State : clean, degraded
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           Name : MyStorage:2
           UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
         Events : 427234

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       21        1      active sync   /dev/sdb5
       2       8       37        2      active sync   /dev/sdc5
       3       8       53        3      active sync   /dev/sdd5
       4       8       69        4      active sync   /dev/sde5

       5       8        5        -      spare   /dev/sda5

Как видите - / dev / sda5 был повторно добавлен в массив. (Это был диск, который сразу вышел из строя) - но даже если md рассматривает диск как запасной, он не будет восстановлен на нем. В этом случае / dev / sde5 является проблемным диском с состоянием (E) DiskError.

Я попытался остановить устройство md, запустить сборку силы, удаление / чтение sda5 из устройства / и т.д. Никаких изменений в поведении.

Я смог полностью воссоздать массив с помощью следующей команды:

mdadm --stop /dev/md2
mdadm --verbose \
   --create /dev/md2 --chunk=64 --level=5 \
   --raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5

который вернул массив в это состояние:

md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]

Затем я повторно добавил / dev / sda5:

mdadm --manage /dev/md2 --add /dev/sda5

после чего началось восстановление:

md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
      [>....................]  recovery =  0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec

Обратите внимание на положение «отсутствующего» диска, совпадающее с точным положением отсутствующего слота.

Как только это закончится, я думаю, что я, вероятно, вытащу сомнительный диск и сделаю его заново.

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

Натан Нойлингер
источник
Я нахожусь в похожей ситуации. Вы решили это успешно?
Дворжак
Да, я смог восстановить массив, выполнив следующие действия. Я продолжил с очищением и переключением с R5 на R6 - потому что на этом этапе я серьезно недоволен поведением Synology «заправить весь массив», которое я хотел удостовериться, что терпит неудачу более одного диска » ». В нашем случае второй диск с ошибкой «сбой» прошел расширенные интеллектуальные тесты без единой проблемы.
Натан Нойлингер
Спасибо за полезное руководство. Я не слишком уверен, возиться со всем этим, я не специалист по рейдам. Теперь я сталкиваюсь с той же проблемой, но в моем случае у меня есть один дисковый массив RAID 1 (/ dev / md3) с / dev / sde3, помеченным буквой [E]. Я предполагаю, что у меня должна быть возможность следовать тем же шагам, что и вы, но, поскольку это единственный диск массива, я не знаю, что он будет делать ;-). В любом случае команда mdadm --stop / dev / md3 не выполняется (устройство или ресурс заняты). Я думаю, я буду Google немного дольше .. =)
dSebastien
Если вы не можете остановить массив, звучит так, будто что-то его использует - то есть он смонтирован, или на этом устройстве выполняется какая-то другая задача.
Натан Нойлинджер
2
К счастью для меня, Synology помогла мне решить проблему. Они были достаточно любезны, чтобы предоставить мне команды, которые они выполняли. Я разместил информацию в своем блоге на случай, если кто-то еще столкнется с
dSebastien

Ответы:

3

Просто дополнение к решению, которое я нашел после того, как столкнулся с той же проблемой. Я следил за публикацией в блоге dSebastien о том, как заново создать массив:

Я обнаружил, что этот метод воссоздания массива работал лучше, чем этот метод выше. Однако после повторного создания массива том все еще не отображался в веб-интерфейсе. Ни одно из моих LUN не показывалось. В основном показывает новый массив без настроенного. Я связался со службой поддержки Synology, и они удалились, чтобы решить проблему. К сожалению, они удалились, пока я был далеко от консоли. Мне все-таки удалось запечатлеть сеанс и посмотреть, что они сделали. При попытке восстановить некоторые из моих данных диск снова вышел из строя, и я снова оказался в той же ситуации. Я воссоздал массив, как в блоге dSebastien, а затем просмотрел сеанс Synology, чтобы выполнить их обновление. После выполнения приведенных ниже команд мой массив и логические модули появились в веб-интерфейсе, и я смог с ними работать. У меня практически нет опыта работы с Linux, но это были команды, которые я выполнял в своей ситуации. Надеюсь, что это может помочь кому-то еще, но, пожалуйста, используйте это на свой страх и риск. Лучше всего обратиться в службу поддержки Synology и попросить их исправить это за вас, поскольку эта ситуация может отличаться от вашей.

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array

DiskStation> vgchange -ay
  # logical volume(s) in volume group "vg1" now active

DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out

DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict 

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 
Nirvaan
источник
1

Еще одно дополнение: я столкнулся с очень похожей проблемой с моим устройством с одним диском / RAID уровня 0.

Поддержка Synology была очень полезной и восстановила мое устройство. Вот что случилось, надеюсь, это поможет другим:

Мой диск имел ошибки чтения в одном конкретном блоке, сообщения в системном журнале ( dmesg) были:

[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772]          res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete

Через несколько секунд я получил ужасную Volume 1 has crashedпочту с моего устройства.

- Отказ от ответственности: Обязательно замените имя устройства на свое, а не просто копируйте и вставляйте эти команды, так как это может ухудшить ситуацию! -

После остановки smb я смог заново смонтировать раздел только для чтения и запустить e2fsk с badblocks check ( -c):

umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2

(можно также использовать e2fsck -C 0 -p -v -f -c /dev/md2для запуска как можно более автоматической, хотя в моем случае это не сработало, поскольку ошибки должны были быть исправлены вручную. Поэтому мне пришлось перезапустить e2fsck. Conclusio: -p не имеет большого смысла в случай ошибки диска)

Хотя e2fsck был в состоянии исправить ошибки, и smartctl также не показал больше увеличения Raw_Read_Error_Rate, том все равно не будет монтироваться устройством в режиме чтения-записи. DSM все еще показывал "громкость сбилась"

Поэтому я открыл билет с поддержкой. Сначала потребовалось немало времени, чтобы все заработало, но в итоге они исправили это, перестроив массив RAID с помощью:

synospace --stop-all-spaces
syno_poweroff_task -d 
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3

Не забудьте проверить имена устройств ( /dev/mdXи /dev/sdaX), прежде чем делать что-либо. cat /proc/mdstatпокажет соответствующую информацию.

GWu
источник