Você poderia tentar inspecionar logs de tempo de execução após o rsync. O log do kernel provavelmente diz Remounting filesystem read-only . Isso acontece automaticamente ao encontrar erros, mesmo quando apenas leitura. O log do kernel na memória é recuperado com dmesg . Se estiver usando systemd, journalctl -b também poderá continuar trabalhando, usando um tmpfs.
Eu vejo outras pessoas comentando sobre os logs também. Para ser claro, quando um erro faz com que seu sistema de arquivos seja re-montado como somente leitura, você pode esperar que não haja oportunidade de gravar a (s) mensagem (ns) de erro no arquivo de log no sistema de arquivos :).
A razão pela qual estou tão confiante sobre isso é a subsequente "correção automática de alterações porque problemas foram detectados na unidade".
Também sei que o rsync pode continuar em face de pelo menos alguns erros, por isso não necessariamente teria abortado cedo com uma mensagem de erro proeminente. Em vez disso, ele pode terminar com um aviso genérico de que ocorreu um erro na transferência de alguns arquivos - ignorei isso no passado. (Ou o rsync pode não ter sido afetado pelo erro, mas não consigo pensar em uma situação que cause isso).
Sem quebrar seu sistema novamente
O disco rígido está provavelmente com defeito
Por favor, verifique a sua saúde usando o SMART. %código%. Também smartctl -H e olhe especificamente para os contadores que mencionam setores. Se houver setores "Pendente" ou "Incorrigível", é altamente recomendável considerar a unidade com defeito.
(Empresas que criam sistemas de armazenamento grandes escrevem redundância de uso sobre unidades, reescrevem setores defeituosos e escrevem algoritmos para adivinhar se a falha foi transitória ou persistente. Não parece que você está executando um sistema redundante (RAID); Neste caso, os riscos de usar o drive são geralmente muito maiores do que qualquer benefício de tentar recuperar a falha de hardware).