Jak odzyskać macierz mdadm na Synology NAS z dyskiem w stanie „E”?

Synology ma dostosowaną wersję sterownika md i zestawów narzędzi mdadm, które dodają flagę „DriveError” do struktury flag rdev-> w jądrze.

Efekt netto - jeśli nie masz wystarczająco dużo szczęścia, aby uzyskać awarię tablicy (pierwszy dysk) w połączeniu z błędem na drugim dysku - tablica przechodzi w stan uniemożliwiający naprawę / rekonstrukcję tablicy, nawet jeśli odczyty z dysku działają w porządku.

W tym momencie tak naprawdę nie martwię się tym pytaniem z punktu widzenia TEGO zestawu, ponieważ już ściągnąłem zawartość i zamierzam ją zrekonstruować, ale bardziej z tego, że chcę mieć ścieżkę rozwiązania tego w przyszłości , ponieważ po raz drugi mnie to ugryzło i wiem, że widziałem innych zadających podobne pytania na forach.

Obsługa Synology była mniej niż pomocna (i przeważnie nie reaguje) i w ogóle nie udostępnia żadnych informacji na temat radzenia sobie z zestawami raidów na pudełku.

Zawartość / 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>

Status z 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

Jak widać - / dev / sda5 został ponownie dodany do tablicy. (To był dysk, który całkowicie zawiódł) - ale chociaż md widzi dysk jako zapasowy, nie będzie go odbudowywać. / dev / sde5 w tym przypadku jest dyskiem problemowym ze stanem (E) DiskError.

Próbowałem zatrzymać urządzenie md, ponownie uruchomić siły działające, usunąć / odczytać sda5 z urządzenia / etc. Bez zmian w zachowaniu.

Byłem w stanie całkowicie odtworzyć tablicę za pomocą następującego polecenia:

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

co przywróciło tablicę do tego stanu:

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]

Następnie ponownie dodałem / dev / sda5:

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

po czym rozpoczął przebudowę:

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

Zwróć uwagę na położenie „brakującego” napędu pasującego do dokładnego położenia brakującego gniazda.

Kiedy to się skończy, myślę, że prawdopodobnie wyciągnę wątpliwy dysk i ponownie go odbuduję.

Szukam sugestii, czy istnieje jakiś „mniej przerażający” sposób wykonania tej naprawy - lub jeśli ktoś przeszedł przez to doświadczenie z macierzą Synology i wie, jak zmusić ją do przebudowy, inną niż przełączenie urządzenia MD w tryb offline i odtworzenie tablicy od zera.

To tylko dodatek do rozwiązania, które znalazłem po tym samym problemie. Śledziłem dSebastien „s blogu o tym, jak ponownie utworzyć tablicę:

Odkryłem, że ta metoda odtwarzania tablicy działała lepiej niż powyższa metoda. Jednak po ponownym utworzeniu tablicy wolumin nadal nie był wyświetlany w interfejsie internetowym. Żadna z moich jednostek LUN nie była wyświetlana. Zasadniczo pokazuje nową tablicę bez niczego skonfigurowanego. Skontaktowałem się z pomocą techniczną Synology, która przesłała wiadomość, aby rozwiązać problem. Niestety zdalnie dotarli, gdy nie było mnie przy konsoli. Udało mi się jednak uchwycić sesję i przejrzałem to, co zrobili. Podczas próby odzyskania niektórych danych dysk ponownie się zawiesił i wróciłem do tej samej sytuacji. Odtworzyłem tablicę jak na blogu dSebastien, a następnie przejrzałem sesję synology, aby wykonać ich aktualizację. Po uruchomieniu poniższych poleceń moja tablica i jednostki LUN pojawiły się w interfejsie internetowym i mogłem z nimi pracować. Mam praktycznie zerowe doświadczenie w Linuksie, ale były to polecenia, które wykonałem w mojej sytuacji. Mam nadzieję, że może to pomóc komuś innemu, ale proszę, użyj tego na własne ryzyko. Najlepiej byłoby skontaktować się z pomocą techniczną Synology i poprosić o naprawienie tego problemu, ponieważ sytuacja może być inna niż Twoja

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 

Kolejny dodatek: trafiłem na bardzo podobny problem z moim urządzeniem z jednym dyskiem / RAID poziomu 0.

Obsługa Synology była bardzo pomocna i przywróciła moje urządzenie. Oto, co się stało, mam nadzieję, że pomoże to innym:

Mój dysk odczytał błędy w jednym konkretnym bloku, komunikaty w dzienniku systemowym ( dmesg) to:

[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

Kilka sekund później otrzymałem okropną Volume 1 has crashedwiadomość z mojego urządzenia.

- Oświadczenie: pamiętaj o zastąpieniu nazwy urządzenia swoją nazwą i nie kopiuj i wklejaj tych poleceń, ponieważ może to pogorszyć sytuację! -

Po zatrzymaniu smb mogłem ponownie zamontować partycję tylko do odczytu i uruchomić e2fsk z badblocks check ( -c):

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

(można również użyć e2fsck -C 0 -p -v -f -c /dev/md2do uruchomienia tak nienadzorowanego, jak to możliwe, chociaż w moim przypadku to nie zadziałało, ponieważ błędy musiały zostać naprawione ręcznie. Musiałem więc zrestartować e2fsck. Wniosek: -p nie ma większego sensu w błąd dysku)

Chociaż e2fsck był w stanie naprawić błędy, a smartctl również nie wykazywał dalszego wzrostu Raw_Read_Error_Rate, wolumin nadal nie montowałby się w trybie odczytu-zapisu przez urządzenie. DSM nadal pokazywał „zawieszony wolumin”

Więc otworzyłem bilet ze wsparciem. Najpierw zajęło sporo czasu, ale ostatecznie naprawili to, przebudowując macierz RAID za pomocą:

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

Przed wykonaniem jakichkolwiek czynności sprawdź nazwy swoich urządzeń ( /dev/mdXi /dev/sdaX). cat /proc/mdstatpokaże odpowiednie informacje.