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 tar for compactado como gzou xznão consigo descompactá-lo.
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 15 mil 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.
Também tentei verificar a integridade do HDD fazendo o seguinte:
# getting the drives
lsblk -dpno name
smartctl -H /dev/sda
smartctl -H /dev/sdb
Em ambas as unidades eu recebo isto:
=== 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 tenho exatamente o mesmo problema. Posso tarar tudo e extrair sem problemas, mas assim que quero compactar os arquivos não consigo descompactá-los (gz/xz).
Responder1
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 já que 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 catreclamar, o arquivo está corrompido no disco e o sistema operacional detectou a corrupção. Verifique os logs do kernel para obter mais informações; normalmente 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 conseguirá recuperar este arquivo. Você precisará recuperá-lo de seus backups offline.
Responder2
Não vejo nenhuma menção sobre como os arquivos tar corrompidos são criados.
Você diz que são backups de um site, mas os problemas que você está mostrando são todos durante a restauração/descompactação, então é aí (a fonte) que você precisa se esforçar para solucionar o problema.
Se os arquivos não puderem ser descompactados após mover o backup para outra máquina/local, eles deverão ser criados com defeito ou quebrados no transporte.
Para localizar a origem do erro:
- crie manualmente um backup no servidor web (sem
pve sem-i) - testar manualmente o backup no servidor web (sem
pve sem-i)
Se nenhum problema for encontrado até agora:
- copie o backup do servidor web
- teste o backup copiado na máquina de destino (sem
pve sem-i)
Se nenhum problema for encontrado até o momento, o script de backup não cria o arquivo da mesma maneira que você fez 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ê tiver uma variável $PATHe/ou ruim $LD_LIBRARY_PATHe um intruso no sistema, você pode estar usando binários trojanados, o que pode causar efeitos colaterais não intencionais.
É claro que também podem estar tarenvolvidas versões incompatíveis, a menos que ambos os sistemas sejam debian. Você poderia tentar forçarPOSIX-modo em ambos os lados.
Responder3
Você está usando o sinalizador -ique em seu formato longo é --ignore-zeros. É por isso que o tar não reclama dos arquivos corrompidos. Então, se você quiser depurar seu arquivo tar, basta remover a -iopção e você obterá a lista de arquivos corrompidos.
Existem também 2 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 ela foi encerrada, se algum erro causar a interrupção do rsync.
Usando a opção do rsync
--dry-runvocê pode ver o que seria copiado sem realmente 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 usei-o em Macs, então sei que está definitivamente disponível.
Para uma verificação rápida e suja 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 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 find.
Como referência:Encontrando arquivos corrompidos
Responder4
A linha de raciocínio respondida por @MattBianco é o que eu seguiria metodicamenteresolveresta questão específica.
Blocos zerados indicam EOF, mas isso depende do fator de bloqueio (o padrão é uma constante compilada, normalmente 20). Alcatrão --compare| --diffparecem ser executados com --ignore-zeros( -i) implicitamente.
Dada a complicação extra de pv, suspeito tar -ique esteja causando problemas xz, olhando paratar man no fator de bloqueioEu sugiro primeiro remover-i
Então, se isso não ajudar, substitua por:
--read-full-records --blocking-factor=300
Se você está lendo isso depois de pesquisar no Google"tar: Um bloco zero solitário em N", e não está canalizando nada, então tente --ignore-zeros.