Você deve tentar ativar o TLER - recuperação de erros por tempo limitado
Sem ele, um disco com setores defeituosos tentará ler os afetados por mais de 30 segundos, possivelmente causando falhas em todo o subsistema de disco.
O disco rígido do nosso servidor dedicado foi recentemente diagnosticado com setores defeituosos, e cada vez que certos dados no disco estão prestes a serem acessados, todo o servidor não responde antes de eu reiniciar o painel do robô. Pedimos ao nosso provedor de servidor para instalar uma nova unidade de disco, e eles fizeram. Agora eu quero copiar tudo para o novo disco (como o disco antigo também ainda está conectado), então eu inicio o servidor no modo de recuperação (inicialização de rede) e executo o seguinte no servidor de inicialização de rede via SSH (root) :
ddrescue -d -f -r3 /dev/sdb /dev/sda /home/ddrescue.log
após cerca de 5 minutos, o servidor não responde e nem mesmo responde ao SSH (como se a porta estivesse fechada).
O que poderia causar isso? Como posso evitar que o servidor seja banido quando alguns setores defeituosos estão prestes a serem acessados?
Você deve tentar ativar o TLER - recuperação de erros por tempo limitado
Sem ele, um disco com setores defeituosos tentará ler os afetados por mais de 30 segundos, possivelmente causando falhas em todo o subsistema de disco.
Da aparência dele, seu hardware / driver / o que congela quando encontra um bloco defeituoso e você não pode continuar com o backup.
Você tem uma lista de bloqueios ruins?
Que tal fazer um backup lógico (com o tar, por exemplo)?
A maneira como eu abordaria isso, mas não testei:
fsck.ext4 com -c e / ou -l )? debugfs : icheck block ... Print a listing of the inodes which use the one or more blocks specified on the command line.
tar --exclude ... Boa sorte. : -s
Tags ssh dd debian server-crashes