tar mit unterschiedlichen ergebnissen?

[hjt]

Hallo,

ich habe da eine Frage: Wenn ich ein Verzeichnis mehrfach mit "tar -czvf datei[0-9].tgz verzeichnis" packe, kann es dann sein, dass die Ergebnisse unterschiedlich sind? (mit md5 überprüft)

Das Verzeichnis wird dabei nicht anderweitig verwendet (Rescue-System) und ein Filesystem-Check hat keine Fehler angezeigt.

mfg
hjt

[its-netzwerk]

die Antwort ist: das tar ist gleich (zcat datei.tar|md5sum), aber gzip speichert das Datum der komprimierten Datei (des tar) mit, und das ist eben anders wenn Du ein zweites mal packst.

[hjt]

ja, das scheint tatsächlich so zu sein. Ich habe die tgz-Dateien jetzt mit gzip getestet (hätte ich auch früher drauf kommen können) und festgestellt, dass die Archive zwar unterschiedlich, aber alle valide sind.

Schade, so bleibt mein eigentliches Problem (Server bleibt in unregelmäßigen Abständen einfach stehen) weiter im Dunkeln...

mfg
hjt

[its-netzwerk]

"Schade, so bleibt mein eigentliches Problem (Server bleibt in unregelmäßigen Abständen einfach stehen) weiter im Dunkeln.."

Da würde ich mal in die logs schauen und überprüfen warum er immer stehen bleibt.

Um welche Art von Server handelt es sich?

[hjt]

Habe ich natürlich schon gemacht (bin auch schon etwas länger dabei :-) )
... und dabei leider nichts gefunden.

Auf dem Server läuft CentOS 6.2 mit openvz-Kernel (2.6.32-042stab057.1)
Er dient als Stand-By-Server (Slave) für einen anderen, identischen Server (der Master), der stabil läuft.
Der Master erzeugt via Cron-Job mit vzdump Dateien, die er dann per scp auf
den Slave hochlädt. Auf dem Slave läuft ein Cron-Job, der diese Dumps dann importiert. Ansonsten ist der Server inaktiv (Die Domains der Container verweisen auf IPs eines Failover-Subnetzes, das dem jeweiligen Master zugeordnet ist).

Nur leider bleibt der Slave alle paar Tage (da ist leider kein Muster erkennbar) einfach stehen.

Für mich wäre es das einfachste gewesen, wenn ich das auf ein Hardware-Problem hätte zurückführen können, aber dafür hat sich ja mein Test-Case als unpassend erwiesen :-)

mfg
hjt

[jan10001]

Was ist wenn der Master den Dump noch nicht voll hochgeladen hat und der Slave bereits diesen importieren will? Könnte eine Ursache für dein Problem sein.

[hjt]

Hallo,

das habe habe ich über Lock-Dateien geregelt (sowohl den von dir beschriebene Fall, als auch das Problem, dass die Scripte sich selbst "überholen" könnten).

Ich habe jetzt die Bandbreite des SCP-Uploads begrenzt und die Prozess-Prioirität des Import-Scripts heruntergesetzt. Mal gucken, ob das einen Unterschied macht.

Da der Server zur Zeit nicht wirklich "benutzt" wird, betrachte ich die Sache noch relativ entspannt.

mfg
hjt