QNAP TS-859U + RAID5ボリュームがマウント解除され、e2fsck_64がハングする
このQNAPTS-859U +とファームウェアバージョン3.8.1ビルド20121205をデータセンターで入手しました。 Intel（R）Atom（TM）CPU D525 @ 1.80GHzプロセッサと1GBRAM、8台の3TB（Seagate ST33000651AS CC44）ドライブを搭載し、7ドライブのRAID5アレイを形成します。もう一方のディスクはグローバルスペアです。
私の意図は、できるだけ多くのデータを回復することです。
電源障害の後、次のログメッセージがありました。
[RAID5ディスクボリューム：ドライブ1 2 8 4 5 67]ファイルシステムがクリーンではありません。 「ディスクのチェック」を実行することをお勧めします。
そのRAID5論理ボリュームはまだマウントされており、QNAP WebGUIからファイルシステムチェックを開始する機会がありました。しかし、ユーザーに迷惑をかけないように、勤務時間後にこれを行うことにしました。しかし、デバイスが自動的に再起動し、RAID5論理ボリュームが「アンマウント」になったため、二度とチャンスがありませんでした。そのため、「今すぐチェック」ボタンが非アクティブになったため、GUIからファイルシステムチェックを開始できなくなりました。
すべてのドライブに対して「不良ブロックスキャン」を開始しましたが、すべて正常に完了しました。彼らは皆、SMART情報に対して「良い」と言っています。
次に、SSHを介してそのボリュームを手動でマウントしようとしましたが、これが出力です。
[~] # mount /dev/md0 /share/MD0_DATA -t ext4
wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or other error
このマウントの試みのdmesgへの反映：
[ 187.927061] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 0 failed (50238!=44925)
[ 187.927297] EXT4-fs (md0): group descriptors corrupted!
デバイスの起動からのより長いdmesg出力は次のとおりです。
[ 181.203693] raid5: device sda3 operational as raid disk 0
[ 181.203794] raid5: device sdg3 operational as raid disk 6
[ 181.203893] raid5: device sdf3 operational as raid disk 5
[ 181.203992] raid5: device sde3 operational as raid disk 4
[ 181.204095] raid5: device sdd3 operational as raid disk 3
[ 181.204199] raid5: device sdh3 operational as raid disk 2
[ 181.204302] raid5: device sdb3 operational as raid disk 1
[ 181.219295] raid5: allocated 119008kB for md0
[ 181.219532] 0: w=1 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219634] 6: w=2 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219732] 5: w=3 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219830] 4: w=4 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219928] 3: w=5 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220030] 2: w=6 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220129] 1: w=7 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220230] raid5: raid level 5 set md0 active with 7 out of 7 devices, algorithm 2
[ 181.220402] RAID5 conf printout:
[ 181.220492] --- rd:7 wd:7
[ 181.220582] disk 0, o:1, dev:sda3
[ 181.220674] disk 1, o:1, dev:sdb3
[ 181.220767] disk 2, o:1, dev:sdh3
[ 181.220859] disk 3, o:1, dev:sdd3
[ 181.220951] disk 4, o:1, dev:sde3
[ 181.221048] disk 5, o:1, dev:sdf3
[ 181.221144] disk 6, o:1, dev:sdg3
[ 181.221324] md0: detected capacity change from 0 to 17993917661184
[ 182.417718] md0: unknown partition table
[ 182.680943] md: bind<sdf2>
[ 184.776414] md: bind<sdg2>
[ 186.852363] md: bind<sdh2>
[ 187.927061] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 0 failed (50238!=44925)
[ 187.927297] EXT4-fs (md0): group descriptors corrupted!
チェックしたところ、RAIDはmd0に対してアクティブです。
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid5 sda3[0] sdg3[6] sdf3[5] sde3[4] sdd3[3] sdh3[7] sdb3[1]
17572185216 blocks super 1.0 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
md13 : active raid1 sda4[0] sdc4[7] sdh4[6] sdg4[5] sdf4[4] sde4[3] sdd4[2] sdb4[1]
458880 blocks [8/8] [UUUUUUUU]
bitmap: 0/57 pages [0KB], 4KB chunk
md9 : active raid1 sda1[0] sdc1[7] sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] sdb1[1]
530048 blocks [8/8] [UUUUUUUU]
bitmap: 0/65 pages [0KB], 4KB chunk
unused devices: <none>
スーパーブロックも永続的です：
[~] # mdadm --detail /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Tue Jun 14 13:16:30 2011
Raid Level : raid5
Array Size : 17572185216 (16758.14 GiB 17993.92 GB)
Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB)
Raid Devices : 7
Total Devices : 7
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sun Apr 12 14:55:35 2015
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Name : 0
UUID : 43865f30:c89546e6:c4d0f23f:d3de8e1c
Events : 16118285
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
7 8 115 2 active sync /dev/sdh3
3 8 51 3 active sync /dev/sdd3
4 8 67 4 active sync /dev/sde3
5 8 83 5 active sync /dev/sdf3
6 8 99 6 active sync /dev/sdg3
次のようなさまざまなe2fsck_64（e2fsck_64_qnapでも）コマンドの組み合わせを試しました。
e2fsck_64 -f /dev/md0
e2fsck_64 -fy /dev/md0
e2fsck_64 -p /dev/md0
..もちろん、「スワップの追加」セレモニーの後、それ以外の場合は「メモリ割り当てエラー」がすぐにスローされるため、次のようになります。
swapoff /dev/md8
mdadm -S /dev/md8
mkswap /dev/sda2
mkswap /dev/sdb2
mkswap /dev/sdc2
mkswap /dev/sdd2
mkswap /dev/sde2
mkswap /dev/sdf2
mkswap /dev/sdg2
mkswap /dev/sdh2
swapon /dev/sda2
swapon /dev/sdb2
swapon /dev/sdc2
swapon /dev/sdd2
swapon /dev/sde2
swapon /dev/sdf2
swapon /dev/sdg2
swapon /dev/sdh2
スキャンは次のようにハングします。
/dev/md0: Inode 255856286 has compression flag set on filesystem without compression support.
e2fsck_64 -pを使用すると、CLEARED。メッセージも追加されます行の終わりに。しかし、それ以上は進みません。一方、e2fsck_64プロセスのCPU使用率は約0.9％に低下しますが、それでも約46％のメモリを使用します。努力しているようには見えません。システムRAMはほぼいっぱいですが、スワップスペースがいっぱいにならないようです。
ここで説明されているユーザーRottUlfのように、より大きなスワップとしてUSBスティックを追加しようとしました： http://forum.qnap.com/viewtopic.php?p=216117 しかし、それは何も変わりませんでした。
また、次のように/ etc/e2fsck.confに構成ファイルを作成しました。
[scratch_files]
directory = /tmp/e2fsck
dirinfo = false
..そしてその目的のためにUSBスティックを使用しました：
mkdir /tmp/e2fsck
mount /dev/sds /tmp/e2fsck
..ここで述べたように： http://forum.qnap.com/viewtopic.php?f=142&t=102879&p=460976&hilit=e2fsck.conf#p460976
それも役に立たなかった。
一部のドキュメントでは、バックアップスーパーブロックを使用してe2fsck_64を実行することを推奨していますが、見つかりませんでした。
[~] # /usr/local/sbin/dumpe2fs /dev/md0 | grep superblock
dumpe2fs 1.41.4 (27-Jan-2009)
/usr/local/sbin/dumpe2fs: The ext2 superblock is corrupt while trying to open /dev/md0
Couldn't find valid filesystem superblock.
最後に、mdadm -CfR --assume-cleanを使用してレイドを再現しようとしました。これは、同様の問題を経験している一部の人々に役立つことを読んだからです。 、ボリュームをマウントしてデータを確認し、バックアップできるようにするには：
[~] # mdadm -CfR --assume-clean /dev/md0 -l 5 -n 7 /dev/sda3 /dev/sdb3 /dev/sdh3 /dev/sdd3 /dev/sde3 /dev/sdf3 /dev/sdg3
mdadm: Defaulting to version 1.-1 metadata
mdadm: /dev/sda3 appears to contain an ext2fs file system
size=392316032K mtime=Thu Jan 1 02:00:00 1970
mdadm: /dev/sda3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdb3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdh3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdd3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sde3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdf3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdg3 appears to contain an ext2fs file system
size=818037952K mtime=Thu Jan 1 02:00:00 1970
mdadm: /dev/sdg3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: array /dev/md0 started.
..しかし、それは役に立たなかった、それでもマウントできない、同じエラー。
beefierQNAP、ファームウェア3.8.4ビルド20130816を搭載したモデルTS-EC879U-RPもあります。約3.76GBが使用可能ですRAMおよびIntel（R）Xeon（R）CPU E31225 @ 3.10GHzプロセッサ。しかし、重要なデータの別のセットで完全にいっぱいです。
したがって、私が念頭に置いているのは、両方のQNAPをシャットダウンし、8つのディスクすべてを取り出してスロットの順序をマークし、QNAPの8つのディスクすべてを安全な場所で作業し続け、TS-859U +のディスクをTS-EC879U-RPに配置することです。正しい順序で、その強力なQNAPでe2fsck_64を実行します。しかし、他のQNAPが「マウント解除」状態で問題のあるRAIDを正しく検出するかどうかはわかりません...
..または、強力なQNAPのデータは、「ゲストディスク」のe2fsck_64の実行が完了した後も保持され、すべてのディスクを元のスロットに入れて電源を入れます。
どんな助けでも大歓迎です、
前もって感謝します..
7台すべてのドライブをPCに接続した後、TestDiskを使用してほぼすべてのデータを回復することができました。 TestDiskは、RAID5ボリューム上の壊れたファイルシステムを検出し、ほとんどのデータをそのままエクスポートすることに成功しました。
ディスクの順序は重要ではありません。RAIDの構成はコントローラーに保存されます。コントローラーは古いシステムにあり、ディスクを別のコントローラーに移動すると、使用する8つの新しいディスクが表示されます。既存のデータについては知りません。
ファイルシステムは暗号化されていましたか、それとも単なる標準RAID 5でしたか？次回はRAID6を使用してください:)