Erro de E / S após falha de energia, remontagem do sistema de arquivos como somente leitura [fechado]

Question

Eu tenho um servidor ESXI de produção com cargas de VMs. Eu tive uma queda de energia há algumas horas que foi tão longa que a bateria do meu UPS foi drenada. O mecanismo de desligamento automático não estava funcionando por algum motivo, então a energia foi cortada para todo o sistema.

Após a interrupção, tudo surgiu, exceto a VM do servidor mysql. Agora ele envia spam ao console com erros de E / S.

end_request: critical medium error, dev sda, sector X
end_request: I/O error, dev sda, sector X
....
EXT4-fs error (device dm-1): ext4_wait_block_bitmap:476 comm bounce: Cannot read block bitmap - block_group = X, block_bitmap = X
Aborting journal on device dm-1-8
EXT4-fs (dm-1): Remounting filesystem read-only

AVMéconfiguradausandooLVMcriptografado.

Oqueesseserrossignificam?Éhardware?Oqueeupossofazer?PesquiseinoGoogleporhoras,masnãoconsigodescobriroquefazer.EuinicializeidoliveCD,executeiofscknapartiçãoraizdesmontada,consertei,reiniciei,masoproblemaéomesmo.

EDITAR#1Eutenteiisso,masnadaaconteceu.

root@ubuntu:~#sudocryptsetup--key-file=/media/ubuntu/7b225e2d-9c0f-4bd4-a4de-1d2f7a0b4c58/keyfileluksOpen/dev/sda5myvolumeroot@ubuntu:~#vgscanReadingallphysicalvolumes.Thismaytakeawhile...Foundvolumegroup"mysql-server-vg" using metadata type lvm2

root@ubuntu:~# tune2fs -O ^has_journal /dev/mysql-server-vg/root 
tune2fs 1.42.13 (17-May-2015)
The needs_recovery flag is set.  Please run e2fsck before clearing
the has_journal flag.

root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root
\e2fsck 1.42.13 (17-May-2015)
/dev/mysql-server-vg/root: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 391687 has zero dtime.  Fix? yes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes
Inode 391697 was part of the orphaned inode list.  FIXED.
Inode 391699 was part of the orphaned inode list.  FIXED.
Inode 391700 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (5462594, counted=5462792).
Fix? yes
Inode bitmap differences:  -391687 -391697 -(391699--391700)
Fix? yes
Free inodes count wrong for group #48 (7946, counted=7950).
Fix? yes
Free inodes count wrong (1854371, counted=1854370).
Fix? yes

/dev/mysql-server-vg/root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mysql-server-vg/root: 95870/1950240 files (0.8% non-contiguous), 2337016/7799808 blocks

root@ubuntu:~# tune2fs -O ^has_journal /dev/mysql-server-vg/root 
tune2fs 1.42.13 (17-May-2015)

root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mysql-server-vg/root: 95870/1950240 files (0.8% non-contiguous), 2304248/7799808 blocks

root@ubuntu:~# tune2fs -j /dev/mysql-server-vg/root
tune2fs 1.42.13 (17-May-2015)
Creating journal inode: done

    

Answer 1

OK, eu descobri e consertei com sucesso. Me custou dois dias.

Primeiramente, verifiquei que o controlador de armazenamento, o hardware do armazenamento de dados (unidade mecânica) e os cabos não estão com defeito. Por favor, note que não consegui acessar o arquivo vmdk no sistema de arquivos corretamente. Eu tentei copiá-lo localmente, com scp e com o vSphere Client, mas depois de um tempo todos eles me deram erro de entrada / saída.

Eu até tentei clonar o disco virtual em um datastore separado.

cd /vmfs/volumes/
vmkfstools -i datastore1/vm/vm.vmdk datastore2/vm/vm.vmdk -d thin -a lsilogic

Ele me deu um erro de entrada / saída depois de 16%.

Eu percebi que a falta de energia causou alguma corrupção, bloqueios obsoletos e whatnots no sistema de arquivos vmfs (armazenamento de dados). Usando o vSphere On-disk Metadata Analyzer (VOMA), verifiquei a consistência de metadados do VMFS. Por favor, note que o armazenamento de dados tem que ser desmontado antes de executar este comando.

voma -m vmfs -f check /vmfs/devices/disks/disk_name:1

Encontrou 34 erros. O voma incluído no vSphere Hypervisor versão 5.5 pode apenas verificar o sistema de arquivos. Eu clonei o armazenamento de dados em um novo disco rígido com o clonezilla no modo de recuperação (clonando disco com setores defeituosos). Depois disso, atualizei para o VMware ESXi versão 6.5, porque ele possui uma versão mais recente do comando voma. Pode corrigir erros, então eu corri o seguinte comando:

voma -m vmfs -f fix /vmfs/devices/disks/disk_name:1

Com certeza fez alguma coisa. Inicializei a VM, mas não consegui a conexão do console por causa do novo absurdo do vCenter vSphere WebClient e da depreciação do vSphere Client , então voltei para a instalação original do VMware ESXi 5.5. Eu clonei o arquivo vmdk mencionado com sucesso. Eu inicializei a VM com o disco clonado, executei fsck uma vez, reiniciei e voila. Funciona como esperado. O servidor entrou online com todos os meus dados.

Envolveu muita confusão, mas não consigo descobrir mais nada. Se alguém souber de uma maneira mais fácil, não hesite em deixar um comentário.

Eu fiz backup do banco de dados 12 horas antes do incidente, mas queria recuperar os dados ao vivo, se possível.