Zeros copiados para minha unidade externa, erros relatados, ainda é seguro para o rsync diário e quais sistemas de arquivos são mais seguros?

0

Eu tinha um arquivo corrompido que suspeitei ser causado pelo rsync para e do meu HDD portátil externo mecânico antigo.

Eu fiz um backup e decidi escrever zeros para ver se há erros de escrita. Com certeza, eu tenho alguns, mas não muito. Veja abaixo.

Eu quero saber se isso é seguro para usar o rsync diário entre meu computador Linux e meu laptop Linux. Quais sistemas de arquivos são seguros para isso, o NTFS é inseguro comparado ao ext4?

$ sudo dd if=/dev/zero of=/dev/sdc1 bs=1024
dd: error writing '/dev/sdc1': Input/output error
960119073+0 records in
960119072+0 records out
983161929728 bytes (983 GB, 916 GiB) copied, 51641 s, 19,0 MB/s

$ sudo smartctl -a /dev/sdc1  
smartctl 6.5
2016-01-24 r4214 [x86_64-linux-4.4.0-109-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org

=== START OF INFORMATION SECTION === Vendor:               WD Product:              My Passport 0748 Revision:             1019 Compliance:          
SPC-4 User Capacity:        1 000 170 586 112 bytes [1,00 TB] Logical
block size:   512 bytes Rotation Rate:        5400 rpm Serial number: 
WX81A7242861 Device type:          disk Local Time is:        Thu Jan
18 11:30:41 2018 CET SMART support is:     Unavailable - device lacks
SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported

No self-tests have been logged


$ dmesg | grep sdc1 
[ 8279.937899]  sdc: sdc1 [21382.527511] Buffer
I/O error on dev sdc1, logical block 240030162, lost async page write
[21382.527516] Buffer I/O error on dev sdc1, logical block 240030163,
lost async page write [21382.527518] Buffer I/O error on dev sdc1,
logical block 240030164, lost async page write [21382.527524] Buffer
I/O error on dev sdc1, logical block 240030165, lost async page write
[21382.527526] Buffer I/O error on dev sdc1, logical block 240030166,
lost async page write [21382.527528] Buffer I/O error on dev sdc1,
logical block 240030167, lost async page write [21382.527530] Buffer
I/O error on dev sdc1, logical block 240030168, lost async page write
[21382.527532] Buffer I/O error on dev sdc1, logical block 240030169,
lost async page write [21382.527534] Buffer I/O error on dev sdc1,
logical block 240030170, lost async page write [21382.527535] Buffer
I/O error on dev sdc1, logical block 240030171, lost async page write
[21387.552539] VFS: Dirty inode writeback failed for block device sdc1
(err=-5). [21398.777810]  sdc: sdc1 [21550.843225] EXT4-fs (sdc1):
mounted filesystem with ordered data mode. Opts: (null)
    
por grokkaine 18.01.2018 / 13:39

1 resposta

2

Você já teve um arquivo corrompido e há um problema conhecido no disco. O problema pode permanecer o mesmo ou piorar: é extremamente improvável que "cure". Então, não, não é seguro.

No entanto, um backup conhecido não confiável ainda é (marginalmente) melhor do que nenhum backup: ele pode permitir que você recupere pelo menos alguns dos seus dados se perder o laptop.

Se você continuar usando esse disco, tente ler todos os arquivos dos quais fez backup: talvez não diariamente, mas certamente semanalmente.

E, em todo caso, você deve se perguntar:

  • Quanto os dados valem para você? Mais do que o custo de um novo disco? Quantas vezes mais?
  • Quanto é necessário o tempo para recuperar seus dados de um backup com falha para você? Em uma situação em que seu laptop já está perdido ou destruído? Isso faria com que você perdesse negócios importantes? Quanto estresse e ansiedade isso causaria? Vale a pena o risco?

Você parece ter um bom esquema de backup (comparado a um proprietário médio de laptop). Você configurou por um motivo. Não prejudique isso.

Atualização:

Cada mensagem logical block NNNNN, lost async page write significa que o sistema operacional disse ao disco para gravar um bloco de dados no disco e recuperou um I failed to do it properly do disco.

Isso poderia teoricamente significar que apenas um único bit foi invertido na saída escrita, ou que o bloco inteiro é agora algo sem sentido aleatório. A realidade provavelmente está em algum lugar entre esses dois extremos.

Os discos modernos normalmente lidam com falhas de gravação de forma transparente marcando o bloco como malsucedido e usando um bloco sobressalente. O fato de que o disco está reportando a falha de volta significa que esta capacidade de reserva já foi esgotada: isso significa que já existe um grande número de blocos com falha no disco.

Como seu comando smartctl informa:

SMART support is:     Unavailable - device lacks SMART capability.

não há como saber mais detalhes além de tentar ler todos os dados, compará-los ao original e contar os erros.

NTFS e ext4 são ambos tipos de sistema de arquivos resilientes, mas nenhum pode sobreviver indefinidamente se a mídia de armazenamento físico não for confiável: se ocorrer uma falha no local de alguns metadados críticos do sistema de arquivos, arquivos ou diretórios inteiros podem ficar inacessíveis.

Os dados desses arquivos perdidos ainda podem estar fisicamente presentes no disco se estiverem localizados em blocos que ainda não falharam, mas sem os metadados do sistema de arquivos, você precisa de algum software de recuperação de dados para encontrar os blocos corretos correspondentes para cada arquivo ausente. Mesmo assim, se os arquivos estiverem fragmentados ou usando um formato de arquivo desconhecido pelo software de recuperação, não há garantia de 100% de que o software de recuperação possa encontrar exatamente os blocos certos e montá-los novamente em arquivos intactos.

Alguém disse: "Os discos são inerentemente máquinas que falham - o armazenamento de dados é apenas um efeito colateral." Eventualmente, qualquer disco giratório falhará devido a desgaste mecânico. Os HDDs portáteis também estão sujeitos a mais impactos e empecilhos do que os instalados em sistemas desktop ou de servidor.

    
por 18.01.2018 / 14:13