Como depurar: tar: Um bloco zero solitário

Question

Como depurar isso? Esta questão apareceu de repente nos últimos dois dias. Todos os backups de um site estão corrompidos.

Se o backup for deixado como tar , não haverá problemas, mas assim que o tar for compactado como gz ou xz , não consigo descompactá-los.

Há muito disco livre

Local disk space    2.68 TB total / 2.26 TB free / 432.46 GB used

erro

tar: Skipping to next header[===============================>                                                    ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================>                                                ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
 878MiB 0:00:58 [15.1MiB/s] [===================================>                                                ] 44%

E por que diz Skipping to next header ? Nunca fez isso antes. Algo está terrivelmente errado em alguns dos arquivos.

Existem cerca de 15k arquivos pdf, jpg ou png nos diretórios.

comando

pv $backup_file | tar -izxf - -C $import_dir

Deve haver alguns dados que corrompam a compactação.

Eu também tentei verificar a integridade do disco rígido fazendo isso:

# getting the drives
lsblk -dpno name

smartctl -H /dev/sda
smartctl -H /dev/sdb

Em ambas as unidades, recebo isto:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Como posso descobrir quais arquivos que estão corrompendo o tar.gz? Eu só quero deletá-los.

atualizar

Agora copiei todos os arquivos para outro servidor e tenho exatamente o mesmo problema. Eu posso tar tudo e extraí-lo sem problemas, mas assim que eu quiser comprimir os arquivos, não posso descompactá-los (gz / xz).

    

Answer 1

Seu arquivo está truncado ou corrompido, portanto xz não pode chegar ao final dos dados. tar reclama porque o arquivo é interrompido no meio, o que é lógico, pois xz não conseguiu ler todos os dados.

Execute os seguintes comandos para verificar onde está o problema:

cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null

Se cat reclamar, o arquivo está corrompido no disco e o sistema operacional detectou a corrupção. Verifique os logs do kernel para mais informações; geralmente o disco precisa ser substituído neste momento. Se somente xz reclamar, o sistema operacional não detectou nenhum dano, mas o arquivo não é válido (corrompido ou truncado). De qualquer maneira, você não poderá recuperar este arquivo. Você precisará recuperá-lo de seus backups off-line.

    

Answer 2

Você está usando o sinalizador -i que, em sua forma longa, é --ignore-zeros . É por isso que o tar não reclama dos arquivos corrompidos. Então, se você quiser depurar seu arquivo tar, apenas remova a opção -i e você verá a lista de arquivos corrompidos.

Existem também outras 2 maneiras de encontrar arquivos corrompidos no unix (em geral). Cito uma resposta dada em outra pergunta.

rsync can be used to copy directories, and is capable of restarting the copy from the point at which it terminated if any error causes the rsync to die.

Using rsync's --dry-run option you can see what would be copied without actually copying anything. The --stats and --progress options would also be useful. and --human-readable or -h is easier to read.

e.g.

rsync --dry-run -avh --stats --progress /path/to/src/ /path/to/destination/

I'm not sure if rsync is installed by default on Mac OS X, but I have used it on Macs so I know it's definitely available.

For a quick-and-dirty check on whether files in a subdirectory can be read or not, you could use grep -r XXX /path/to/directory/ > /dev/null. The search regexp doesn't matter, because output is being discarded anyway.

STDOUT is being redirected to /dev/null, so you'll only see errors.

The only reason I chose grep here was because of its -R recursion option. There are many other commands that could be used instead of grep here, and even more if used with find.

Como referência: Encontrando arquivos corrompidos

    

Answer 3

Eu não vejo nenhuma menção de como os arquivos tar quebrados são criados?

Você diz que são backups de um site, mas os problemas que você está mostrando são todos ao restaurar / descompactar, de modo que lá (a origem) é onde você precisa colocar o trabalho de solucionar problemas.

Se os arquivos não puderem ser descompactados depois de mover o backup para outra máquina / local, eles devem ser criados com falhas ou quebrados no transporte.

Para localizar a origem do erro:

• crie manualmente um backup no servidor da Web (sem pv e sem -i )
• teste manualmente o backup no servidor da web (sem pv e sem -i )

Se nenhum problema foi encontrado até agora:

• copie o backup do servidor da web
• teste o backup copiado na máquina de destino (sem pv e sem -i )

Se nenhum problema foi encontrado até agora, o script de backup não cria o arquivo da mesma maneira que você fez ao fazer isso manualmente (e provavelmente deveria ser modificado para fazer o que você fez manualmente).

Além disso, certifique-se de usar os caminhos absolutos de todos os comandos envolvidos. Se você tem uma variável $PATH e / ou $LD_LIBRARY_PATH ruim e um intruso no sistema, você pode estar usando binários troianos, o que poderia causar efeitos colaterais não intencionais.

Obviamente, ele também pode ser incompatível com tar versões envolvidas, a menos que ambos os sistemas sejam debian. Você pode tentar forçar o modo POSIX nos dois lados.