Consegui recuperar quase todos os dados com a ajuda do TestDisk, depois de conectar todos os 7 drives a um PC. O TestDisk conseguiu detectar o sistema de arquivos quebrado no volume RAID5 e exportar a maioria dos dados intactos.
Temos este QNAP TS-859U + com a versão de firmware 3.8.1 Build 20121205 no nosso datacenter. Ele possui unidades de processador Intel® Atom ™ D525 a 1,80 GHz e 1 GB de RAM, 8 unidades de 3 TB (Seagate ST33000651AS CC44) e uma matriz RAID5 de 7 unidades. O outro disco é uma reserva global.
Minha intenção é recuperar o máximo de dados possível.
Após uma falha de energia, houve essa mensagem de log:
[RAID5 Disk Volume: Drive 1 2 8 4 5 6 7] The file system is not clean. It is suggested that you run "check disk".
Esse volume lógico do RAID5 ainda estava montado e tivemos a chance de iniciar uma verificação do sistema de arquivos a partir do QNAP Web GUI. Mas decidimos fazer isso depois do horário de trabalho para não causar nenhum inconveniente aos usuários. Mas nós nunca tivemos a chance novamente porque o dispositivo foi reinicializado eo volume lógico do RAID5 tornou-se "Unmounted", então não foi possível iniciar uma verificação do sistema de arquivos a partir da GUI, pois o botão "CHECK NOW" ficou inativo.
Eu iniciei o "Bad Blocks Scan" para todas as unidades e todas foram concluídas com sucesso. Todos dizem "BOA" para informações SMART.
Então eu tentei montar esse volume manualmente via SSH e esta é a saída:
[~] # mount /dev/md0 /share/MD0_DATA -t ext4
wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or other error
Reflexão desta tentativa de montagem no dmesg:
[ 187.927061] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 0 failed (50238!=44925)
[ 187.927297] EXT4-fs (md0): group descriptors corrupted!
Aqui está uma saída mais longa do dmesg da inicialização do dispositivo:
[ 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!
Eu verifiquei e o RAID está ativo para 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>
O Superblock também é persistente:
[~] # 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
Eu tentei várias combinações de comandos e2fsck_64 (mesmo e2fsck_64_qnap) como:
e2fsck_64 -f /dev/md0
e2fsck_64 -fy /dev/md0
e2fsck_64 -p /dev/md0
.. é claro, após a cerimônia de "adicionar troca extra", porque isso gera um "erro de alocação de memória" de outra forma:
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
A verificação trava assim:
/dev/md0: Inode 255856286 has compression flag set on filesystem without compression support.
Se eu usar e2fsck_64 -p , ele também adicionará uma mensagem CLEARED. ao final da linha. Mas não vai mais longe. Enquanto isso, o uso da CPU do processo e2fsck_64 cai para ~ 0,9%, mas ainda usa cerca de% 46 de memória. Eu não pareço estar fazendo nenhum esforço. A RAM do sistema está quase cheia, mas parece que não preenche mais nenhum espaço de troca.
Eu tentei adicionar um dispositivo USB como uma troca maior do que o usuário RottUlf descrito aqui: link , mas não mudou nada.
Eu também criei o arquivo de configuração em /etc/e2fsck.conf assim:
[scratch_files]
directory = /tmp/e2fsck
dirinfo = false
.. e usou um stick USB para esse fim:
mkdir /tmp/e2fsck
mount /dev/sds /tmp/e2fsck
.. como mencionado aqui: link
Também não ajudou.
Alguns documentos recomendam tentar executar o e2fsck_64 com um superbloco de backup, mas não consegui encontrar nenhum:
[~] # /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 /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.
.. mas isso não ajudou, ainda não pode montar, os mesmos erros.
Temos também um beefier QNAP, modelo TS-EC879U-RP com firmware 3.8.4 Build 20130816. Possui cerca de 3.76 GB de RAM utilizável e CPU Intel® Xeon (R) E31225 @ Processador de 3,10 GHz. Mas está completamente cheio com outro conjunto de dados importantes.
Então, o que eu tenho em mente é desligar os dois QNAPs e retirar todos os 8 discos marcando a ordem dos slots, continuar trabalhando todos os 8 discos da QNAP em um local seguro e colocar os discos do TS-859U + no TS-EC879U- RP com a ordem correta e execute e2fsck_64 nesse poderoso QNAP. Mas eu não sei se o outro QNAP detectará corretamente o RAID problemático no estado "Desmontado" ...
.. ou os dados no poderoso QNAP serão retidos depois que ele conseguir terminar os e2fsck_64 dos "guest discos" e eu colocar todos os discos no slot original e ligar.
Qualquer ajuda será muito apreciada,
Obrigado antecipadamente ..
A ordem dos discos não importa, a configuração para o RAID é armazenada no controlador, que está em seu sistema antigo e mover os discos para outro controlador apenas apresentará 8 novos discos para uso. Não saberá sobre nenhum dado existente.
O sistema de arquivos foi criptografado ou apenas um RAID 5 padrão? Use o RAID 6 na próxima vez:)