Comment déboguer ça? Ce problème est soudainement apparu au cours des deux derniers jours. Toutes les sauvegardes d'un site Web sont corrompues.

Si la sauvegarde est laissée comme tar, il n'y a pas de problème, mais dès que le tar est compressé en tant que gzou xzje ne peux pas les décompresser.

Il y a beaucoup de disque libre

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

Erreur

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%

Et pourquoi ça dit Skipping to next header? Il n'a jamais fait cela auparavant. Quelque chose ne va vraiment pas dans certains fichiers.

Il y a environ 15k fichiers pdf, jpg ou png dans les répertoires.

commander

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

Il doit y avoir des données qui corrompt la compression.

J'ai également essayé de vérifier la santé du disque dur en procédant comme suit:

# getting the drives
lsblk -dpno name

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

Sur les deux disques, j'obtiens ceci:

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

Comment savoir quels fichiers corrompent tar.gz? Je veux juste les supprimer.

mise à jour

J'ai maintenant copié tous les fichiers sur un autre serveur et j'ai exactement le même problème. Je peux tout tarer et l'extraire sans problème, mais dès que je veux compresser les fichiers, je ne peux pas les décompresser (gz / xz).

Votre fichier est tronqué ou corrompu, xzvous ne pouvez donc pas atteindre la fin des données. tarse plaint parce que l'archive s'arrête au milieu, ce qui est logique car xzn'a pas réussi à lire l'ensemble des données.

Exécutez les commandes suivantes pour vérifier où se situe le problème:

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

Si se catplaint, le fichier est corrompu sur le disque et le système d'exploitation a détecté la corruption. Consultez les journaux du noyau pour plus d'informations; généralement, le disque doit être remplacé à ce stade. Si seulement se xzplaint, le système d'exploitation n'a détecté aucune corruption, mais le fichier n'est néanmoins pas valide (corrompu ou tronqué). Dans tous les cas, vous ne pourrez pas récupérer ce fichier. Vous devrez le récupérer à partir de vos sauvegardes hors ligne.

Je ne vois aucune mention de la façon dont les fichiers tar cassés sont créés?

Vous dites que ce sont des sauvegardes à partir d'un site Web, mais les problèmes que vous montrez concernent tous la restauration / décompression, donc là (la source) est l'endroit où vous devez mettre l'effort de dépannage.

Si les fichiers ne peuvent pas être décompressés après avoir déplacé la sauvegarde vers un autre ordinateur / emplacement, ils doivent être soit créés défectueux, soit interrompus pendant le transport.

Pour localiser la source de l'erreur:

• créer manuellement une sauvegarde sur le serveur Web (sans pvet sans -i)
• tester manuellement la sauvegarde sur le serveur web (sans pvet sans -i)

Si aucun problème n'a été détecté jusqu'à présent:

• copier la sauvegarde depuis le serveur web
• tester la sauvegarde copiée sur la machine cible (sans pvet sans -i)

Si aucun problème n'a été détecté jusqu'à présent, le script de sauvegarde ne crée pas l'archive de la même manière que vous le faisiez à la main (et devrait probablement être modifié pour faire ce que vous avez fait manuellement).

Assurez-vous également d'utiliser les chemins absolus de toutes les commandes impliquées. Si vous avez une mauvaise $PATHet / ou $LD_LIBRARY_PATHvariable et un intrus dans le système, vous utilisez peut-être des fichiers binaires de Troie, ce qui pourrait provoquer des effets secondaires involontaires.

Il pourrait bien entendu également s'agir de tarversions incompatibles , à moins que les deux systèmes ne soient Debian. Vous pouvez essayer de forcer le mode POSIX des deux côtés.

Vous utilisez le drapeau -iqui est sous sa forme longue --ignore-zeros. C'est pourquoi tar ne se plaint pas des fichiers corrompus. Donc, si vous souhaitez déboguer votre fichier tar, supprimez simplement l' -ioption et vous obtiendrez la liste des fichiers corrompus.

Il existe également 2 autres façons de trouver des fichiers corrompus sous Unix (en général). Je cite une réponse donnée dans une autre question.

rsync peut être utilisé pour copier des répertoires et est capable de redémarrer la copie à partir du moment où elle s'est terminée si une erreur entraîne la mort de rsync.

En utilisant l' --dry-runoption de rsync, vous pouvez voir ce qui serait copié sans rien copier. Les options --statset --progressseraient également utiles. et --human-readableou -hest plus facile à lire.

par exemple

rsync --dry-run -avh --stats --progress / chemin / vers / src / / chemin / vers / destination /

Je ne sais pas si rsync est installé par défaut sur Mac OS X, mais je l'ai utilisé sur Mac donc je sais qu'il est définitivement disponible.

Pour une vérification rapide et sale si les fichiers dans un sous-répertoire peuvent être lus ou non, vous pouvez utiliser grep -r XXX /path/to/directory/ > /dev/null. La regexp de recherche n'a pas d'importance, car la sortie est de toute façon supprimée.

STDOUT est redirigé vers / dev / null, vous ne verrez donc que des erreurs.

La seule raison pour laquelle j'ai choisi grep ici était à cause de son -Roption de récursivité. Il existe de nombreuses autres commandes qui pourraient être utilisées à la place de grep ici, et encore plus si elles sont utilisées avec find.

Comme référence: trouver des fichiers corrompus

Le raisonnement en réponse par @MattBianco est ce que je suivrais méthodiquement pour résoudre ce problème particulier.

Les blocs mis à zéro indiquent EOF, mais cela dépend du facteur de blocage (la valeur par défaut est une constante compilée, généralement 20). Tar's --compare| --diffsemblent s'exécuter avec --ignore-zeros( -i) implicitement.

Étant donné la complication supplémentaire de pv, je soupçonne que cela tar -icause des problèmes xz, en regardant tar man sur le facteur de blocage, je suggère d'abord de supprimer-i

Si cela ne vous aide pas, remplacez par:

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

Si vous ne faites que lire ceci après avoir googlé "tar: un bloc nul à N" et que vous ne lancez rien, essayez --ignore-zeros.