Archiv Browser für tar.gz

[slu]

Kennst jemand ein guten Archiv Browser für die Konsole?
Ich würde mir gerne nur den Inhalt des Archives anschauen, nicht entpacken.

[Meillo]

Code: Alles auswählen

tar tzf foo.tar.gz | less

Zwar kein Browser, zeigt aber auch den Inhalt an.

[gbotti]

mc

[TRex]

Also was direkteres als die less-Variante kenne ich auch nicht. MC muss man aufrufen und sieht dann doch viel mehr, als man möchte.

[gbotti]

Also was direkteres als die less-Variante kenne ich auch nicht. MC muss man aufrufen und sieht dann doch viel mehr, als man möchte.

tar und less muss man ja auch nicht aufrufen

MC bietet halt gleich noch den Vorteil, dass man relativ einfach eine Datei, die im TAR-Archiv ist mit F5 rauskopieren könnte.

[slu]

MC bietet halt gleich noch den Vorteil, dass man relativ einfach eine Datei, die im TAR-Archiv ist mit F5 rauskopieren könnte.

Das muss ich mal testen, im Moment öffnet er noch mein 130 GB Archive

[Meillo]

[...] im Moment öffnet er noch mein 130 GB Archive

[slu]

Code: Alles auswählen

tar tzf foo.tar.gz | less

Zwar kein Browser, zeigt aber auch den Inhalt an.

Also der mc macht sich bei dem 130 GB Archive in die Hosen, "tar tzf foo.tar.gz | less" geht bei kleinen Archiven gut, beim 130 GB Archiv geht nur ein paar mal Page-down dann bleibt er stehen.

Ich frage mich ob man solche großen Archive überhaupt beherschen kann, was bringt mir eine Sicherung wenn ichs nicht auspacken kann.

[Meillo]

"tar tzf foo.tar.gz | less" geht bei kleinen Archiven gut, beim 130 GB Archiv geht nur ein paar mal Page-down dann bleibt er stehen.

Sicher, dass er schon fertig entpackt hat? Vielleicht sind halt noch nicht alle Daten da? Kannst ja die Ausgabe auch in eine Datei umleiten und schauen wann der Prompt wieder kommt.

Solange das Archiv in Ordnung ist und deine tar-Implementierung mit der Archivgroesse klar kommt muss es gehen.

Ich frage mich ob man solche großen Archive überhaupt beherschen kann, was bringt mir eine Sicherung wenn ichs nicht auspacken kann.

Gute Frage -- in jedem Fall die richtige.

Vermutlich bist du gerade dabei dein Backupsystem zu testen; und hoffentlich bist du nicht in dem Fall dass du dein Backup brauchst. Denn wie man wieder an seine Daten kommt und ob das so klappt wie man sich das vorgestellt hat sollte man vorher testen. Hier deutet sich an, dass ein Backup in dieser Groesse nicht auf diese Art gemacht werden sollte.

Nur so nebenbei: Wie lange hat das zippen gedauert?

Ich frage mich ob bei dieser Datenmenge (130G!) ueberhaupt allzuviele Daten dabei sind fuer die sich der Rechenaufwand des Komprimierens ueberhaupt lohnt. Was schon komprimiert ist muss nicht nochmal komprimiert werden (z.B. viele Multimediadaten).

Du solltest dein Backup vermutlich aufsplitten. Einmal wegen der Groesse ueberhaupt (Handhabbarkeit, Sicherheit). Zum anderen um unterschiedliche Inhalte unterschiedlich zu behandeln. Aber das ist natuerlich nur pauschal empfohlen, es haengt zu sehr davon ab was genau in dem Backup steckt.

[TRex]

Ah, da taucht noch ein zweites Problem auf...tar.gz ist soweit ich weiß in zwei Phasen gepackt...einmal zusammengepfercht in ein tar und diese Daten dann g'zippt. Soll heißen, jegliche Browser wären meinem Verständnis nach nur dann in der Lage, so ein Archiv anzuzeigen, wenns entpackt ist..oder?

[slu]

"tar tzf foo.tar.gz | less" geht bei kleinen Archiven gut, beim 130 GB Archiv geht nur ein paar mal Page-down dann bleibt er stehen.

Sicher, dass er schon fertig entpackt hat? Vielleicht sind halt noch nicht alle Daten da? Kannst ja die Ausgabe auch in eine Datei umleiten und schauen wann der Prompt wieder kommt.

Das ist eine gute Frage, bestimmt hast Du recht und er war nicht fertig.

Solange das Archiv in Ordnung ist und deine tar-Implementierung mit der Archivgroesse klar kommt muss es gehen.

Das hoffe ich doch, ext4 hat zumindest keine Probleme damit.

Ich frage mich ob man solche großen Archive überhaupt beherschen kann, was bringt mir eine Sicherung wenn ichs nicht auspacken kann.

Gute Frage -- in jedem Fall die richtige.

Vermutlich bist du gerade dabei dein Backupsystem zu testen; und hoffentlich bist du nicht in dem Fall dass du dein Backup brauchst. Denn wie man wieder an seine Daten kommt und ob das so klappt wie man sich das vorgestellt hat sollte man vorher testen. Hier deutet sich an, dass ein Backup in dieser Groesse nicht auf diese Art gemacht werden sollte.

Ich bin beim testen, lässt mich ruhiger schlafen wenn ich weis das es geht

Nur so nebenbei: Wie lange hat das zippen gedauert?

Alles in allem sind es ca. 300 GB und das dauert 6 Stunden (soll ja nur einmal in der Woche gemacht werden).

Ich frage mich ob bei dieser Datenmenge (130G!) ueberhaupt allzuviele Daten dabei sind fuer die sich der Rechenaufwand des Komprimierens ueberhaupt lohnt. Was schon komprimiert ist muss nicht nochmal komprimiert werden (z.B. viele Multimediadaten).

Hintergrund ist der, ich verwende Backuppc um von allen Servern und Clients ein Backup einzusammeln. Nun muss ich aber mindestens einmal die Woche die Daten an einen anderen Ort schaffen (das mache ich mit vier unterschiedlichen 1 TB Festplatten).
Hier bietet Backuppc die "Archive" Funktion an, welche auch komprimieren kann. Da mich die Zeit des komprimierens nicht stört und man je Server ein tar.gz hat hab ich das heute mal so getestet. (Übrigens ungepakt sind das bei dem 130 GB Archive 250 GB).

Du solltest dein Backup vermutlich aufsplitten. Einmal wegen der Groesse ueberhaupt (Handhabbarkeit, Sicherheit). Zum anderen um unterschiedliche Inhalte unterschiedlich zu behandeln. Aber das ist natuerlich nur pauschal empfohlen, es haengt zu sehr davon ab was genau in dem Backup steckt.

An das Aufsplitten des Archives mit "split" habe ich auch schon gedacht und das ist kein Problem, aber zum entpacken muss ich es ja wieder zusammensetzen.

Allerdings ist dein Ansatz richtig, ich kann es nämlich auch ohne zu komprimieren "archivieren", das müsste den Vorteil haben das mein rsync auf die 1 TB Festplatte schneller geht. 1 Archive ist ja eine Datei als 100% Änderung, da hab ich mit rsync keinen Vorteil.

Übrigens, gerade entpackt der auf der Konsole ganz brav, bei ein paar Dateien mecker er ein wenig:

Code: Alles auswählen

2029-01-05 03:33:08 liegt 569843391.758327279 Sekunden in der Zukunft.

Frag mich nicht wie die User das geschaft haben

Leider hat er aber mittlerweile abgebrochen:

Code: Alles auswählen

tar: Springe zum nächsten Kopfteil.
tar: Springe zum nächsten Kopfteil.
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Nun werde ich mal ein Durchlauf ohne komprimieren versuchen.

EDIT:
Oder hat er doch alles entpackt und hat den Fehlerstatus nur wegen der Zeit in der Zukunft?
Aber was heißt "tar: Springe zum nächsten Kopfteil." ?

[slu]

Ah, da taucht noch ein zweites Problem auf...tar.gz ist soweit ich weiß in zwei Phasen gepackt...einmal zusammengepfercht in ein tar und diese Daten dann g'zippt. Soll heißen, jegliche Browser wären meinem Verständnis nach nur dann in der Lage, so ein Archiv anzuzeigen, wenns entpackt ist..oder?

Ja das konnte ich sehen, der MC hat unter /tmp/mc-root ordentlich entpackt.

[Meillo]

Vermutlich bist du gerade dabei dein Backupsystem zu testen; [...]

Ich bin beim testen, lässt mich ruhiger schlafen wenn ich weis das es geht

Das freut mich zu hoeren -- vorbildlich.

Du solltest dein Backup vermutlich aufsplitten. Einmal wegen der Groesse ueberhaupt (Handhabbarkeit, Sicherheit). Zum anderen um unterschiedliche Inhalte unterschiedlich zu behandeln. Aber das ist natuerlich nur pauschal empfohlen, es haengt zu sehr davon ab was genau in dem Backup steckt.

An das Aufsplitten des Archives mit "split" habe ich auch schon gedacht und das ist kein Problem, aber zum entpacken muss ich es ja wieder zusammensetzen.

Ich dachte an ein anderes Aufsplitten, naemlich mehrere Archive, nicht eines in mehreren Dateien.

Wenn das Archiv einen Macken bekommt, dass kann es kaputt sein. Wenn du mehrere Archive hast, dann ist nur eines kaputt.

Da kann ich noch erwaehnen, dass ich mal gelesen habe, dass der grosse Vorteil von bzip2 gegenueber gzip ist, dass wenn ein Teil der Archivdatei kaputt geht, dann auch nur die dort enthaltenen Daten an der Stelle kaputt sind, nicht aber das ganze Archiv. Habe ich nur so gehoert, aber da findet man im Web sicher mehr Informationen.

Allerdings ist dein Ansatz richtig, ich kann es nämlich auch ohne zu komprimieren "archivieren", das müsste den Vorteil haben das mein rsync auf die 1 TB Festplatte schneller geht. 1 Archive ist ja eine Datei als 100% Änderung, da hab ich mit rsync keinen Vorteil.

Wenn er es nicht trotzdem zu einem tarball zusammenklebt, ja. Bei sovielen Daten ist es sicher sinnvoll nicht immer alle zu kopieren.

Leider hat er aber mittlerweile abgebrochen:

Code: Alles auswählen

tar: Springe zum nächsten Kopfteil.
tar: Springe zum nächsten Kopfteil.
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Nun werde ich mal ein Durchlauf ohne komprimieren versuchen.

Schau lieber dass du es in mehrere Einzelarchive verteilst.

[slu]

Da kann ich noch erwaehnen, dass ich mal gelesen habe, dass der grosse Vorteil von bzip2 gegenueber gzip ist, dass wenn ein Teil der Archivdatei kaputt geht, dann auch nur die dort enthaltenen Daten an der Stelle kaputt sind, nicht aber das ganze Archiv.

Das ist auch noch so eine Sache, backuppc hat aber auch bzip2 im Angebot

Schau lieber dass du es in mehrere Einzelarchive verteilst.

Hab es gerade mal ohne Archiv probiert, nun macht er mir eine daten.tar.raw file, was ist den das?

Die andere Möglichkeit die Kiste zu sichern ist einfach Backuppc zu stopen und /var/lib/backuppc komplett rsyncen.
Edit:
Was aber den Nachteil hat immer ein Backuppc zu benötigen um wieder an die Daten zu kommen.
Vielleicht findet sich noch jemand im Forum der Backuppc auch auf so große Datenmengen los lässt.

[slu]

Das tar ist defekt weil die neue Hardware ein defekt hat, ich weis nur noch nicht wo.
Im Moment laufen Festplatten Stress-Tests und morgen bekommt er anderen Arbeitsspeicher.

[samhain]

Ich mach' die Backups mir rsync, für jeden Tag eines. Am längsten dauert der Teil zum anlegen der Hardlinks