Temos um servidor com Ubuntu 20.04.6 LTS. É o armazenamento secundário para nosso backup, com HDDs de 12x8TB em RAIDZ3, com um sistema de arquivos XFS no topo.
Alguns dias atrás, uma unidade falhou. Pensei: "OK, não tem problema, é um RAIDZ3", mas antes mesmo de substituir e resilver a unidade quebrada, percebi que o sistema de arquivos não está mais montado.
Tentei montá-lo manualmente sem sucesso, executando:
sudo mount -t xfs /dev/zd0 /mnt/veeam_repo_prod
Imediatamente, ele retorna um erro de kernel: "XFS (zd0): erro de E/S de gravação de recuperação de log em daddr 0x1b1b70 len 4096 erro -5", seguido por "mount: /mnt/ veeam_repo_prod: não é possível ler o superbloco em /dev/zd0."
Não consigo ver nenhum problema em zpool status -v
.
pool: zpool01
state: ONLINE
scan: scrub repaired 0B in 2 days 11:10:24 with 0 errors on Wed Feb 28 19:54:19 2024
config:
NAME STATE READ WRITE CKSUM
zpool01 ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
sdh ONLINE 0 0 0
scsi-351402ec000fe5847 ONLINE 0 0 0
scsi-351402ec000fe5848 ONLINE 0 0 0
scsi-351402ec000fe5849 ONLINE 0 0 0
scsi-351402ec000fe584a ONLINE 0 0 0
scsi-351402ec000fe584b ONLINE 0 0 0
errors: No known data errors
Executar uma limpeza retorna 0B reparado.
Tentei executar xfs_repair /dev/zd0
e ele diz que há alterações valiosas de metadados em um log. A execução xfs_repair -L /dev/zd0
retorna novamente um erro de E/S: "xfs_repair: libxfs_device_zero write failed: Input/output error".
Estou simplesmente sem ideias. A única coisa boa é que é apenas a segunda cópia do backup, e eu poderia começar do zero, mas leva semanas para copiar novamente todos os dados. Além disso, se aconteceu uma vez, pode acontecer de novo, e não quero estar lá no dia em que precisarmos do backup e acontecer novamente.
Encontrei a solução por acidente no meu feed do Reddit hoje, um dia depois da minha pergunta aqui; alguém no Reddit teve os mesmos sintomas do Reddit Post .
Causa:
O problema parece ser que o armazenamento está cheio, embora eu não saiba como, porque deveria estar apenas pela metade, mas isso é um problema para outro dia.
Solução:
Uma maneira é obviamente adicionar mais unidades, se possível. Como isso não era possível na minha situação, tive que adotar outra abordagem. Felizmente, a solução também estava na postagem do Reddit. Aumentei o valor para
/sys/module/zfs/parameters/spa_slop_shift
15. Isso me permitiu aumentar a cota emzpool01/veeam
mais 1 TB (sudo zfs set quota=61T zpool01/veeam
). Com o armazenamento recém-utilizável, consegui montar meu XFS normalmente novamente e excluir alguns arquivos e diminuir a retenção por enquanto.Você está executando um sistema de arquivos XFS sobre um zvol ZFS. Empilhar sistemas de arquivos. É possível que o XFS seja interrompido enquanto o ZFS subjacente reporta bem.
Você pode fornecer detalhes específicos do hardware, controladores e detalhes da versão do sistema operacional e do ZFS?
Dependendo da natureza da unidade com falha do seu pool, pode ser necessário reparo no lado do ZFS (uma vez que ele não tem conhecimento do conteúdo do seu sistema de arquivos XFS).
dmesg
produção. Você pode postar isso?Se tudo mais falhar, é possível um envolvimento profissional ou usar o UFS Explorer para recuperação:
Veja também: Como recuperar o sistema de arquivos XFS com “falha na leitura do superblock”