Bestimmte Binärsequenzen erzeigen CRC-Error bei tar -cz

[testit]

Guten Tag,

als ich gestern eine bestimmte mysqlDB sichern wollte (nach shutdown des MySQL-Servers), stelle ich fest, dass sich die erzeugte tar.gz nicht entpacken liess und immer mit einer Fehlermeldung nach einer Weile der Entpack-Prozess beendet wurde:

Das Spielchen wiederholte sich bei mehreren Tests.

Habe dann mit gzip -vt die Integrität der tar.gz-Datei geprüft und einen CRC-Error angezeigt bekommen:
backup.tar.gz: invalid compressed data--crc error

Da dieses Problem auch bei mehreren Versuche, die gleiche Datei zu packen, aufgetaucht ist, liegt der Schluss nahe, dass irgendeine Bytesequenz in der Datei vorliegt, die Probleme bereitet.

Habt Ihr diesbezüglich Erfahrungen? Sollte man besser einen bzip zum Packen des entstandenen TARs nutzen?

Bin dankbar für entsprechende Hinweise.


Nette Grüsse
testit

 

[testit]

Hallo,

habe mir nun GNU tar installiert, da dieses über eine Verify-Funktion verfügt.

gtar --verify -cvpzf backup.tar verzeichnis, um das tar zu komprimieren, haut nicht hin, da gtar dann meldet: gtar: Cannot verify compressed archives

Um dies zu umgehen, probierte ich folgendes:
gtar --verify -cvpzf backup.tar verzeichnis | gzip > myfile.tar.gz

Allerdings steht dann anschliessend in dem myfile.tar.gz nicht die komprimierte backup.tar drin, sondern eine Datei namens "myfile.tar". Diese zu entpacken ist nicht möglich.

Es sollte doch eine Möglichkeit geben, GNU tar einzusetzen, um ein verify machen zu können und gleichzeitig/anschliessend das Ganze zu komprimieren.

Weiss jemand Rat?

Danke und nette Grüsse
testit

 

[Kamikaze]

Komprimierte tars erstellt man so:

# tar -czf backup.tar.gz verzeichnis

 

[testit]

Komprimierte tars erstellt man so:

# tar -czf backup.tar.gz verzeichnis

Ich will Dir ja nicht zu nahe treten, aber kann es sein, dass Du mich verschaukeln willst?

Vielleicht solltest Du nochmal einen Bick auf meine Frage werfen!


Gruss
testit

 

[Kamikaze]

# cd /usr/src/usr.bin/tar
# make install clean

Nochmal probieren.

 

[testit]

# cd /usr/src/usr.bin/tar
# make install clean

Nochmal probieren.

Okay,

ich zitiere nochmals die von mir o.a. Problemstellung:

...
habe mir nun GNU tar installiert, da dieses über eine Verify-Funktion verfügt.

gtar --verify -cvpzf backup.tar verzeichnis, um das tar zu komprimieren, haut nicht hin, da gtar dann meldet: gtar: Cannot verify compressed archives

Um dies zu umgehen, probierte ich folgendes:
gtar --verify -cvpzf backup.tar verzeichnis | gzip > myfile.tar.gz

Allerdings steht dann anschliessend in dem myfile.tar.gz nicht die komprimierte backup.tar drin, sondern eine Datei namens "myfile.tar". Diese zu entpacken ist nicht möglich.

Es sollte doch eine Möglichkeit geben, GNU tar einzusetzen, um ein verify machen zu können und gleichzeitig/anschliessend das Ganze zu komprimieren.

Weiss jemand Rat?

Das gtar --verify -cvpzf backup.tar verzeichnis funktioniert wunderbar.

Aber das ZIPPEN via | gzip > myfile.tar.gz nicht!

Offenbar hängt das Problem damit zusammen, dass der Verify-Prozess erst nach dem kompletten TAR-Vorgang angestossen wird und daher nicht in o.a. Form gepiped werden kann.

Vermutlich eher ein Fall für eine kleine Batchdatei.


Gruss
testit

 

[minuseins]

Okay,
gtar --verify -cvpzf backup.tar verzeichnis | gzip > myfile.tar.gz

Du hast da einen Denkfehler. Du kannst nur PIPEN, wenn du auch etwas nach STDIO leitest.

mit

gtar -cvpzf backup.tar erstellst du bereits eine Datei die mit GZIP gepackt ist.

Dafuer ist die "z" Option gedacht. (Sollte auch auf Fehler laufen, wenn GZIP nicht gefunden wird.

Damit wird das PIPEN "|" auch hinfaellig. Du musst also lediglich die Datei mit einer .gz Endung versehen. Wenn du nur ein ".tar" erzeugen willst und danach per PIPE nach gzip jagen willst, dann muesstest du auch eher folgende Zeile verwenden:

tar -cf - verzeichnis | gzip -c > myfile.tar.gz.

Damit kannst du aber ein --verify vergessen, da "tar" keine Datei erzeugt, die verifiziert werden kann, sondern lediglich einen stream nach stdout schiebt.

da minus

 

[testit]

IMMER WIEDER: invalid compressed data--crc error

Du hast da einen Denkfehler. Du kannst nur PIPEN, wenn du auch etwas nach STDIO leitest.

mit

gtar -cvpzf backup.tar erstellst du bereits eine Datei die mit GZIP gepackt ist.

Dafuer ist die "z" Option gedacht. (Sollte auch auf Fehler laufen, wenn GZIP nicht gefunden wird.

Damit wird das PIPEN "|" auch hinfaellig. Du musst also lediglich die Datei mit einer .gz Endung versehen. Wenn du nur ein ".tar" erzeugen willst und danach per PIPE nach gzip jagen willst, dann muesstest du auch eher folgende Zeile verwenden:

tar -cf - verzeichnis | gzip -c > myfile.tar.gz.

Damit kannst du aber ein --verify vergessen, da "tar" keine Datei erzeugt, die verifiziert werden kann, sondern lediglich einen stream nach stdout schiebt.

da minus

Hallo,

das z oben im tar-Befehl war ein Schreibfehler in diesem Posting.

Ich bin wirklich am verzweifeln: Wenn ich grössere Datenmengen auf meinem Server tar-zippe und anschliessend einen CRC-Test mache, ist das File fehlerhaft.

Bsp.:
cd /usr
tar cvfpz usr_home.tar.gz home
gzip -vt usr_home.tar.gz (Checke Integrität)
gzip: usr_home.tar.gz: invalid compressed data--crc error

Wenn ich anschliessend ein solches File via tar -xzvpf entpacke, wird der Entpack/Dekomprimiervorgang irgendwann mit folgender Meldung abgebrochen:
tar: Unrecognized archive format: Inappropriate file type or format

Ich bin dabei, Daten von einem Webserver auf einen neuen zu ziehen, wozu ich natürlich die Daten taren und zippen will, bevor ich sie übertrage.

Aber o.a. Fehler verfolgt mich jetzt schon den ganzen Tag.

Hat jemand eine Idee?


Nette Grüsse
testit

 

[minuseins]

Wie gross ist denn das Endprodukt?

Evtl. hast du Probleme mit Dateigroessen. (>2GB)

Auf den rebuild von kamikaze bist du scheinbar nicht eingegangen. Und wenn es ohnehin nur um einen Umzug geht, wurde ich rsync zum kopieren empfehlen.

Sollte das auch nicht gehen, wird es wohl ein paar Probleme mit deinem Quellsystem geben.

da minus

 

[kili]

$ tar -czf - home | tee home.tar.gz | md5
$ md5 home.tar.gz

Wenn da unterschiedliche MD5-Summen rauspurzeln, dann wuerde ich mal auf kaputten Speicher, Festplattenkabel etc. tippen.

 

[testit]

Wie gross ist denn das Endprodukt?

Evtl. hast du Probleme mit Dateigroessen. (>2GB)

Auf den rebuild von kamikaze bist du scheinbar nicht eingegangen. Und wenn es ohnehin nur um einen Umzug geht, wurde ich rsync zum kopieren empfehlen.

Sollte das auch nicht gehen, wird es wohl ein paar Probleme mit deinem Quellsystem geben.

da minus

Hallo,

die enstehenden TAR-Dateien, bei denen das beschriebene Problem auftaucht, sind zum Teil wesentlich kleiner (bspw. 200 MB).

Auf den Rebuild-Vorschlag von Kamikaze konnte ich nicht eingehen, da ein
cd /usr/src/usr.bin/tar
bei mir offenbar gar nicht vorhanden ist.

Habe stattdessen die aktuelle GNU tar Version frisch installiert - mit dem gleichen Ergebnis.

Ich ziehe ja nicht grundlos von dem betreffenden Webserver um: Wiederholte Reboots ohne ersichtlichen Grund etc.!

Insofern tippe ich inzwischen auf defekte Hardware-Komponenten wie minuseins oben.

Gruss und Dank!
testit

 

[testit]

$ tar -czf - home | tee home.tar.gz | md5
$ md5 home.tar.gz

Wenn da unterschiedliche MD5-Summen rauspurzeln, dann wuerde ich mal auf kaputten Speicher, Festplattenkabel etc. tippen.

Habe soeben die md5-Prüfung vorgenommen und es "purzeln" in der Tat unterschiedliche Werte raus.

Gruss
testit

 

[Elessar]

Dann den neuen Server mal besser mit einem Datensatz vom Backup bestücken.

 

[testit]

Dann den neuen Server mal besser mit einem Datensatz vom Backup bestücken.

Aufgrund der beschriebenen Problematik und der auch von anderen vermuteten Ursache Hardwaredefekte dürften diese Backups ebenso viel wert sein wie jene, die ich bspw. jetzt mit tar anlege.

Gruss
testit

 

[rMarkus]

Dann würde ich die Platte(n) so schnell wie möglich in ein anderes System packen und von dort aus sichern.

 

[minuseins]

Habe stattdessen die aktuelle GNU tar Version frisch installiert - mit dem gleichen Ergebnis.

gtar =! gzip. Das sind zwei verschiedene Programme. gtar ruft lediglich ein gzip mit auf (option z). Die CRC Fehler hast du also aufgrund des "gzip". Nicht wg. des "tar"s.

Vielleicht liegt es an einem Hardwaredefekt, vielleicht auch nur an einer korrupten zlib.

Liesse sich einfach herrausfinden, indem man lediglich tars erzeugt und deren md5-Summen vergleicht. Und im Falle einer defekten Hardware kann man sich unter Umstaenden nicht einmal auf die md5-Werte verlassen.

Wie gesagt, ich wuerde per "rsync" die Daten auf den anderen Server sichern. Sollte sich md5 als stabiles Tool erweisen, dann kannst du hinterher den Stand vergleichen und dann ein Backup vom neuen Server ziehen.

Viel erfolg.

 

[kili]

Aufgrund der beschriebenen Problematik und der auch von anderen vermuteten Ursache Hardwaredefekte dürften diese Backups ebenso viel wert sein wie jene, die ich bspw. jetzt mit tar anlege.

Kommt drauf an,

- wie alt die Backups sind (irgendwas vor den ersten Defekten?)

- was Du an wichtigen Daten hast (plaintext oder binaeres (Datenbank-) Geraffel)

- wieviel Aufwand es fuer Dich bedeutet, die einzelnen Backups miteinander zu vergleichen, um den ersten fehlerhaften Zustand zu orten.


Ich vermute mal, dass es sich um einen Mietserver handelt. Wenn sich der Dienstleister nicht zu einer genauren Fehlersuche (inklusive kompletten Speicheraustausch) ueberreden laesst, dann solltest Du evtl. nachfragen, ob Du wenigstens die Platte fuer Datarecovery bekommen kannst. Der md5-Test sollte als Nachweis fuer einen Hardware-Fehler reichen (notfalls auch mal ohne -z laufen lassen). Eine kaputte zlib, die sich nicht-deterministisch verhaelt, ist IMHO extrem unwahrscheinlich.

 

[testit]

gtar =! gzip. Das sind zwei verschiedene Programme. gtar ruft lediglich ein gzip mit auf (option z). Die CRC Fehler hast du also aufgrund des "gzip". Nicht wg. des "tar"s.

Mach "Dinger"!
Mal im Ernst: Wenn Du meine Beiträge oben durchliest, wirst Du feststellen, dass der Verify auch beim reinen TARen fehlschlägt. Da Gtar im Gegensatz zum defaultmässig installierten tar eine verify-Funktion aufweist, hatte ich dieses bewusst benutzt.

Vielleicht liegt es an einem Hardwaredefekt, vielleicht auch nur an einer korrupten zlib.

Habe auch gzip neu installiert!

Liesse sich einfach herrausfinden, indem man lediglich tars erzeugt und deren md5-Summen vergleicht.

Nicht nötig, wenn man gtar mit --verify-Funktion nutzt!

Und im Falle einer defekten Hardware kann man sich unter Umstaenden nicht einmal auf die md5-Werte verlassen.

Die Logik verstehe ich nun nicht so ganz

Für mich ist vielmehr das Gegenteil Deiner Aussage der Fall!

Wie gesagt, ich wuerde per "rsync" die Daten auf den anderen Server sichern. Sollte sich md5 als stabiles Tool erweisen, dann kannst du hinterher den Stand vergleichen und dann ein Backup vom neuen Server ziehen.

Dem Rat bin ich auch gefolgt und schon dabei, auf diese Art die Daten rüberzuziehen.

Vielen Dank nochmals für Eure Tipps/Hinweise in diesem Thread!

Gruss
testit

 

[marzl]

Habe soeben die md5-Prüfung vorgenommen und es "purzeln" in der Tat unterschiedliche Werte raus.

Riecht verdächtig nach einer Bestellung neuer Speicherriegel eines Herstellers Deiner Wahl.

 

[minuseins]

Mach "Dinger"!
Mal im Ernst: Wenn Du meine Beiträge oben durchliest, wirst Du feststellen, dass der Verify auch beim reinen TARen fehlschlägt. Da Gtar im Gegensatz zum defaultmässig installierten tar eine verify-Funktion aufweist, hatte ich dieses bewusst benutzt.

Dann guck dir nochmal deine Posts an. Alle genannten gtar Aufrufe haben eine "z" Option. Wie soll ich darauf kommen, dass du auch ein "normales" tar verwendet hast. Von dem gtar | pipe Konstrukt am Anfang ganz zu schweigen. Sorry das ich da annehme, dich fuer "unbedarft" zu halten.

Habe auch gzip neu installiert!

Haette ich wohl telephatisch erahnen sollen?

Die Logik verstehe ich nun nicht so ganz

Nennt sich "eingrenzen". Sollten .tars in Ordnung sein, dann liegt der Fehler in der Verwendung von gzip. Wenn nicht, dann kann man auch pruefen ob md5 ueberhaupt fuer ein und dieselbe Datei gleiche Werte auspuckt. Klappt beides nicht => ganz grober Hardwarefehler.

 

[AndreasMeyer]

dürften diese Backups ebenso viel wert sein wie jene, die ich bspw. jetzt mit tar anlege.

Backups und Serverzügelaktionen gehen einfacher, sicherer und schneller mit dump:
http://wiki.bsdforen.de/index.php/FreeBSD_-_Backup

 

[testit]

Dann guck dir nochmal deine Posts an. Alle genannten gtar Aufrufe haben eine "z" Option. Wie soll ich darauf kommen, dass du auch ein "normales" tar verwendet hast. Von dem gtar | pipe Konstrukt am Anfang ganz zu schweigen. Sorry das ich da annehme, dich fuer "unbedarft" zu halten.



Haette ich wohl telephatisch erahnen sollen?



Nennt sich "eingrenzen". Sollten .tars in Ordnung sein, dann liegt der Fehler in der Verwendung von gzip. Wenn nicht, dann kann man auch pruefen ob md5 ueberhaupt fuer ein und dieselbe Datei gleiche Werte auspuckt. Klappt beides nicht => ganz grober Hardwarefehler.

Die PIPE-Konstruktion oben war völlig korrekt, nur das z im tar-Befehl ist, wie schon angemerkt, versehentlich dringeblieben. Die --verify-Option bei gtar machte der Pipe-Konstruktion einen Strich durch die Rechnung!

Was Deine telepathischen Kräfte angeht, hätte es auch gereicht, einen Blick auf mein o.a. Posting unter http://www.bsdforen.de/showpost.php?p=125738&postcount=8 zu werfen

Gruss
testit

 

[minuseins]

Die PIPE-Konstruktion oben war völlig korrekt,

Nein ist sie nicht. ein -f <datei> erzeugt ein datei. da laesst sich nichts pipen
ein -f - schreibt nach stdout. DAS laesst sich pipen.

Deine Variante erzeugt zwei Dateien. Eine "backup.tar" und eine backup.tar.gz. Letztere ist aber um die ~20 bytes gross und taugt als daten container relativ wenig.

Auch muss hinter der option f (egal ob mit - oder nicht) immer ein Dateiname folgen. Demzufolge erzeugt dein erwaehntes posting, auch lediglich eine normale tar datei mit dem namen pz mit inhalt der datei "home.tar.gz" und des verzeichnisses "home".

da minus