☰

Fehler

tag-icon • tag-icon debian tar corruption
Fehler

Wie kann ich das debuggen? Dieses Problem ist in den letzten Tagen plötzlich aufgetreten. Alle Backups einer Website sind beschädigt.

Wenn das Backup einfach als belassen wird tar, gibt es keine Probleme, aber sobald das Tar als komprimiert ist gzoder xzkann ich es nicht mehr entpacken.

Es gibt viel freien Speicherplatz

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

Fehler

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%

Und warum steht da Skipping to next header? Das ist noch nie passiert. Mit einigen Dateien stimmt etwas ganz und gar nicht.

In den Verzeichnissen befinden sich etwa 15.000 PDF-, JPG- oder PNG-Dateien.

Befehl

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

Es müssen Daten vorhanden sein, die die Komprimierung beschädigen.

Ich habe auch versucht, den Zustand der Festplatte folgendermaßen zu überprüfen:

# getting the drives
lsblk -dpno name

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

Auf beiden Laufwerken erhalte ich Folgendes:

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

Wie kann ich herausfinden, welche Dateien das Tar.gz beschädigen? Ich möchte sie einfach löschen.

aktualisieren

Habe nun alle Dateien auf einen anderen Server kopiert und habe genau das gleiche Problem. Ich kann alles problemlos tarnen und extrahieren, aber sobald ich die Dateien komprimieren möchte, kann ich sie nicht dekomprimieren (gz/xz).

Antwort1

Ihre Datei ist entweder abgeschnitten oder beschädigt, sodass xzSie nicht ans Ende der Daten gelangen. tarbeschwert sich, weil das Archiv in der Mitte stoppt, was logisch ist, da xzes nicht gelungen ist, die gesamten Daten zu lesen.

Führen Sie die folgenden Befehle aus, um zu prüfen, wo das Problem liegt:

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

Wenn cates eine Fehlermeldung gibt, ist die Datei auf der Festplatte beschädigt und das Betriebssystem hat die Beschädigung erkannt. Weitere Informationen finden Sie in den Kernel-Protokollen. Normalerweise muss die Festplatte an diesem Punkt ausgetauscht werden. Wenn es nur xzeine Fehlermeldung gibt, hat das Betriebssystem keine Beschädigung erkannt, aber die Datei ist trotzdem ungültig (entweder beschädigt oder abgeschnitten). In beiden Fällen können Sie diese Datei nicht wiederherstellen. Sie müssen sie aus Ihren Offline-Backups zurückholen.

Antwort2

Ich sehe keine Erwähnung, wie die beschädigten TAR-Dateien erstellt werden?

Sie sagen, es handelt sich um Backups von einer Website, aber die von Ihnen angezeigten Probleme treten alle beim Wiederherstellen/Entpacken auf, Sie müssen also dort (an der Quelle) Ihre Fehlerbehebungsbemühungen ansetzen.

Wenn die Dateien nach dem Verschieben des Backups auf einen anderen Rechner/Standort nicht dekomprimiert werden können, müssen sie entweder fehlerhaft erstellt oder beim Transport beschädigt worden sein.

So finden Sie die Fehlerquelle:

  • manuelles Erstellen eines Backups auf dem Webserver (mit pvund ohne -i)
  • manuelles Testen des Backups auf dem Webserver (mit pvund ohne -i)

Wenn bisher keine Probleme gefunden wurden:

  • Kopieren Sie das Backup vom Webserver
  • Testen des kopierten Backups auf der Zielmaschine (mit pvund ohne -i)

Wenn bisher keine Probleme gefunden wurden, erstellt das Sicherungsskript das Archiv nicht auf dieselbe Weise wie beim manuellen Erstellen (und sollte wahrscheinlich so geändert werden, dass es das tut, was Sie manuell erstellt haben).

Stellen Sie außerdem sicher, dass Sie die absoluten Pfade aller beteiligten Befehle verwenden. Wenn Sie eine fehlerhafte $PATHund/oder $LD_LIBRARY_PATHVariable und einen Eindringling im System haben, verwenden Sie möglicherweise mit einem Trojaner infizierte Binärdateien, die unbeabsichtigte Nebeneffekte verursachen können.

Es könnten natürlich auch inkompatible tarVersionen beteiligt sein, es sei denn, beide Systeme sind Debian. Sie könnten versuchen,POSIX-Modus auf beiden Seiten.

Antwort3

Sie verwenden das Flag -i, das in seiner Langform lautet --ignore-zeros. Aus diesem Grund beschwert sich Tar nicht über beschädigte Dateien. Wenn Sie also Ihre Tar-Datei debuggen möchten, entfernen Sie einfach die -iOption und Sie erhalten die Liste der beschädigten Dateien.

Es gibt auch zwei andere Möglichkeiten, beschädigte Dateien unter Unix (im Allgemeinen) zu finden. Ich zitiere eine Antwort aus einer anderen Frage.

Mit rsync können Verzeichnisse kopiert werden. Wenn rsync durch einen Fehler abstürzt, kann der Kopiervorgang an der Stelle neu gestartet werden, an der er beendet wurde.

Mit der Option von rsync --dry-runkönnen Sie sehen, was kopiert werden würde, ohne tatsächlich etwas zu kopieren. Die Optionen --statsund --progresswären ebenfalls nützlich. und --human-readableoder -hist leichter zu lesen.

z.B

rsync --dry-run -avh --stats --progress /Pfad/zur/Quelle/ /Pfad/zum/Ziel/

Ich bin nicht sicher, ob rsync unter Mac OS X standardmäßig installiert ist, aber ich habe es auf Macs verwendet, also weiß ich, dass es definitiv verfügbar ist.

Um schnell und einfach zu prüfen, ob Dateien in einem Unterverzeichnis gelesen werden können oder nicht, können Sie verwenden grep -r XXX /path/to/directory/ > /dev/null. Der Such-Regexp spielt keine Rolle, da die Ausgabe ohnehin verworfen wird.

STDOUT wird zu /dev/null umgeleitet, daher werden Ihnen nur Fehler angezeigt.

Der einzige Grund, warum ich hier grep gewählt habe, war die -RRekursionsoption. Es gibt viele andere Befehle, die man hier anstelle von grep verwenden könnte, und noch mehr, wenn man sie mit find verwendet.

Als Referenz:Beschädigte Dateien finden

Antwort4

Die Argumentation in der Antwort von @MattBianco ist das, was ich methodisch verfolgen würde, umlösendieses spezielle Problem.

Auf Null gesetzte Blöcke zeigen EOF an, aber das hängt vom Blockierungsfaktor ab (der Standardwert ist eine kompilierte Konstante, normalerweise 20). Tars --compare| --diffscheint implizit mit --ignore-zeros( -i) ausgeführt zu werden.

Angesichts der zusätzlichen Komplikation von pv, die meiner Meinung nach tar -iProbleme verursacht xz, wenn man sich ansiehtTeermann über BlockierungsfaktorIch würde vorschlagen, zuerst zu entfernen-i

Wenn das nicht hilft, ersetzen Sie es durch:

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

Wenn Sie dies gerade lesen, nachdem Sie gegoogelt haben"tar: Ein einsamer Nullblock bei N", und nichts weiterleiten, dann versuchen Sie es mit --ignore-zeros.

verwandte Informationen