Мы получили QNAP TS-859U + с версией прошивки 3.8.1 Build 20121205 в нашем центре обработки данных. Он имеет процессор Intel (R) Atom (TM) D525 @ 1,80 ГГц и 1 ГБ оперативной памяти, 8 дисков по 3 ТБ (Seagate ST33000651AS CC44), и они образуют массив RAID5 из 7 дисков. Другой диск является глобальным запасным.
Я намерен восстановить как можно больше данных.
После сбоя питания в журнале появилось следующее сообщение:
[Дисковый том RAID5: Диск 1 2 8 4 5 6 7] Файловая система не чистая. Предлагается запустить «Проверить диск».
Этот логический том RAID5 все еще был смонтирован, и у нас была возможность запустить проверку файловой системы из веб-интерфейса QNAP. Но мы решили сделать это в нерабочее время, чтобы не доставлять неудобств пользователям. Но у нас больше не было шанса, потому что устройство перезагрузилось, и логический том RAID5 стал «размонтированным», поэтому было невозможно запустить проверку файловой системы из графического интерфейса пользователя, поскольку кнопка «ПРОВЕРИТЬ СЕЙЧАС» стала неактивной.
Я запустил «сканирование плохих блоков» для всех дисков, и все они успешно завершились. Все они говорят "ХОРОШО" за информацию 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, он также добавляет УДАЛЕНО. сообщение в конце строки. Но дальше дело не идет. Между тем, загрузка ЦП процессом e2fsck_64 снижается до ~ 0,9%, но он по-прежнему использует около 46% памяти. Не похоже, чтобы он прилагал какие-либо усилия. Системная оперативная память почти заполнена, но похоже, что она больше не заполняет пространство подкачки.
Я попытался добавить USB-накопитель в качестве свопа большего размера, как описано здесь пользователем RottUlf: 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.
..но не помогло, все равно не могу смонтировать, те же ошибки.
У нас также есть крепче QNAP, модель TS-EC879U-RP с прошивкой 3.8.4 Build 20130816. Он имеет около 3,76 ГБ полезной оперативной памяти и процессор Intel (R) Xeon (R) CPU E31225 @ 3,10 ГГц. Но он полностью заполнен другим набором важных данных.
Итак, я имею в виду выключить оба QNAP и вынуть все 8 дисков, пометив порядок слотов, продолжить работу всех 8 дисков QNAP в безопасном месте и поместить диски TS-859U + на TS-EC879U-RP с исправьте порядок и запустите e2fsck_64 на этом мощном QNAP. Но я не знаю, правильно ли другой QNAP обнаружит проблемный RAID в состоянии «Не подключено» ...
..или данные на мощном QNAP будут сохранены после того, как ему удастся завершить e2fsck_64'ing "гостевые диски", и я вставлю все диски в их исходный слот и включу.
Любая помощь будет оценена,
Заранее спасибо..
Мне удалось восстановить почти все данные с помощью TestDisk после подключения всех 7 дисков к ПК. TestDisk удалось обнаружить неисправную файловую систему на томе RAID5 и экспортировать большую часть данных без изменений.
Порядок дисков не имеет значения, конфигурация RAID хранится на контроллере, который находится в вашей старой системе, и при перемещении дисков на другой контроллер он будет использовать только 8 новых дисков. Он не будет знать ни о каких существующих данных.
Была ли файловая система зашифрована или это был стандартный RAID 5? В следующий раз используйте RAID 6 :)