Como depurar isso? Esse problema apareceu repentinamente nos últimos dias. Todos os backups de um site estão corrompidos.

Se o backup for deixado como tar, não há problemas, mas assim que o alcatrão é compactado gzou xznão posso 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 isso Skipping to next header? Isso nunca foi feito 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 corrompem a compactação.

Eu também tentei verificar a saúde do HDD fazendo o seguinte:

# getting the drives
lsblk -dpno name

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

Nas duas unidades, recebo o seguinte:

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

Como posso descobrir quais arquivos estão corrompendo o tar.gz? Eu só quero excluí-los.

atualizar

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

Seu arquivo está truncado ou corrompido; portanto, xznão é possível chegar ao final dos dados. tarreclama porque o arquivo para no meio, o que é lógico, pois xznã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 houver catreclamação, 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 apenas xzreclamar, o sistema operacional não detectou nenhuma corrupção, mas o arquivo não é válido (corrompido ou truncado). De qualquer forma, você não poderá recuperar este arquivo. Você precisará recuperá-lo dos seus backups offline.

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, então é aí que (a fonte) é onde você precisa fazer o esforço para solucionar problemas.

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

Para localizar a fonte do erro:

• crie manualmente um backup no servidor web (sem pve sem -i)
• testar manualmente o backup no servidor da web (sem pve sem -i)

Se nenhum problema encontrado até agora:

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

Se nenhum problema foi encontrado até agora, o script de backup não cria o arquivo da mesma maneira que você criou ao fazê-lo manualmente (e provavelmente deve 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 ruim $PATHe / ou $LD_LIBRARY_PATHvariável e um invasor no sistema, pode estar usando binários de Trojan, o que pode causar efeitos colaterais não intencionais.

É claro que também pode haver tarversões incompatíveis envolvidas, a menos que ambos os sistemas sejam debian. Você pode tentar forçar o modo POSIX nos dois lados.

Você está usando a bandeira -ique, em sua forma longa, é --ignore-zeros. É por isso que o tar não reclama dos arquivos que estão corrompidos. Portanto, se você deseja depurar seu arquivo tar, basta remover a -iopção e você obterá a lista de arquivos corrompidos.

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

O rsync pode ser usado para copiar diretórios e é capaz de reiniciar a cópia a partir do ponto em que foi finalizada, se algum erro causar a morte do rsync.

Usando a --dry-runopção do rsync, você pode ver o que seria copiado sem copiar nada. As opções --statse --progresstambém seriam úteis. e --human-readableou -hé mais fácil de ler.

por exemplo

rsync --dry-run -avh --stats --progress / caminho / para / src / / caminho / para / destino /

Não tenho certeza se o rsync está instalado por padrão no Mac OS X, mas eu o usei em Macs, então eu sei que ele definitivamente está disponível.

Para verificar rapidamente se os arquivos em um subdiretório podem ser lidos ou não, você pode usar grep -r XXX /path/to/directory/ > /dev/null. O regexp de pesquisa não importa, porque a saída está sendo descartada de qualquer maneira.

STDOUT está sendo redirecionado para / dev / null, então você verá apenas erros.

A única razão pela qual escolhi o grep aqui foi por causa de sua -Ropção de recursão. Existem muitos outros comandos que podem ser usados ​​em vez do grep aqui e ainda mais se usados ​​com o find.

Como referência: Localizando arquivos corrompidos

A linha de raciocínio em resposta de @MattBianco é o que eu metodicamente seguiria para resolver esse problema específico.

Blocos zerados indicam EOF, mas isso depende do fator de bloqueio (o padrão é uma constante compilada, geralmente 20). Tar's --compare| --diffparecem executar implicitamente com --ignore-zeros( -i).

Dada a complicação extra de pv, suspeito que tar -iesteja causando problemas xz, olhando para o alcatrão no fator de bloqueio, sugiro que remova primeiro-i

Então, se isso não ajudar, substitua por:

--read-full-records --blocking-factor=300

Se você está lendo este artigo no Google "tar: um bloco zero solitário em N" e não está canalizando nada, tente --ignore-zeros.