web-dev-qa-db-ja.com

Synologyでmdadmアレイを回復する方法NASドライブが「E」状態の場合?

Synologyには、カーネルのrdev-> flags構造に「DriveError」フラグを追加するmdドライバーとmdadmツールセットのカスタマイズバージョンがあります。

正味の影響-アレイ障害(最初のドライブ)が発生し、2番目のドライブでエラーが発生した場合、アレイは、ドライブからの読み取りが機能しているにもかかわらず、アレイを修復または再構築できない状態になります。大丈夫。

この時点では、この配列の観点からはこの質問についてはあまり心配していません。既にコンテンツを引き出して再構築するつもりなので、将来的にはこの問題の解決方法を知りたくないからです。 、2回目なので、フォーラムで同様の質問をしている人を見たことがあります。

Synologyのサポートはあまり役に立たず(そしてほとんどの場合無反応)、ボックス上のRAIDセットの扱いに関する情報は共有されませんAT ALL。

/ 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デバイスをオフラインにする以外に強制的に再構築する方法を知っているかどうかに関する提案を探しています。アレイを最初から再作成します。

12

同じ問題が発生した後に見つけたソリューションへの追加。配列を再作成する方法について dSebastien のブログ投稿をフォローしました。

配列を再作成するその方法は、この上記の方法よりもうまく機能することがわかりました。ただし、アレイを再作成した後、ボリュームはまだWebインターフェイスに表示されませんでした。 LUNが表示されていませんでした。基本的に、何も設定されていない新しいアレイを示しています。 Synologyサポートに連絡したところ、問題を解決するために遠隔地に到着しました。あいにく、私がコンソールから離れている間、彼らは遠く離れていました。私はなんとかセッションをキャプチャして、彼らが何をしたかをじっくりと見ました。データの一部を回復しようとしたときに、ドライブが再びクラッシュし、同じ状況に戻りました。 dSebastienのブログのように配列を再作成してから、synologyセッションを調べて更新を実行しました。以下のコマンドを実行すると、アレイとLUNがWebインターフェイスに表示され、それらを操作することができました。私は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 
3
Nirvaan

もう1つの追加: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を停止した後、パーティションを読み取り専用で再マウントし、badblocksチェックを使用してe2fskを実行することができました(-c):

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

e2fsck -C 0 -p -v -f -c /dev/md2を使用して可能な限り無人で実行することもできますが、私の場合はエラーを手動で修正する必要があったため、うまくいきませんでした。そのため、e2fsckを再起動する必要がありました。結論:-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は関連情報を表示します。

1
GWu