Zip: files größer als 2 GB

[firemail]

Hi,

ich backuppe ja brav immer per cron, aber nun sind meine output files größer als 2gb weshalb er genau bei 2GB abbricht.

zipsplit bringt mir ja auch nichts da ich ja nur vorhandene files splitten kann und in der manpage habe ich nichts bzgl teilarchivierung mit archiven größe X gefunden.
gibts da einen parameter den ich überlesen habe?

oder brauch ich dazu evntl tar oder ein anderes packprogramm?

[dnspyder]

Schau dir mal "man tar" an

[Joe User]

Backups packt man niemals per zip, wenn man keinen physischen Zugriff auf den Server hat. Dies begründet sich darin, dass man nie gewährleisten kann, das man beim Recover ein unzip parat hat. Allein aus diesem Grund solltest Du tar zum Archivieren und gzip/bzip2 zum Komprimieren einsetzen.

man tar
man gzip
man bzip2

[firemail]

ok werde mir jene mal ansehen, der vorteil den ich bei zip nunmal gesehen habe war die möglichkeit das ganze mit einem kennwort zu sichern.
eventuell gibts das bei tar ja auch ...

[mad cow]

Dabei hilft "man gpg".

[lucki2]

man gzip

Brauchst Du nicht ansehen. Beschränkt wie Zip -> bzip2(b wie big).


tar lege ich dir statt man die infopage ans Herz:

Code: Select all

info tar

Das kann (sehr viel)mehr als in der man page steht. Ist mehr ein Paketmanager, Backup bzw Restoretool(t wie "tape"-Magnetband). Tar kann seine Pakete auch mit bzip packen oder aus bzip lesen,

[mattiass]

man gzip

Brauchst Du nicht ansehen. Beschränkt wie Zip -> bzip2(b wie big).

Und ich dachte immer, das "b" stände für "block-sorting". Danke für die Korrektur.

Auch bei der Dateigröße muss ich bei der Komprimierung und Dekomprimierung großer Dateien Halluzinationen aufgesessen sein: seltsamerweise liessen sich auch große, mit "tar" und "gzip" gepackte Backups immer zurückspielen...

[lucki2]

Oh ja, Du hast tatsächlich recht. Ich habe geschaut, das ist anscheinend sogar schon seit einigen Jahren möglich.

[mattiass]

Oh ja, Du hast tatsächlich recht. Ich habe geschaut, das ist anscheinend sogar schon seit einigen Jahren möglich.

Streamer mit 2GB-Bändern gibt es schon ein paar Tage. Zumindest beim Packen von Datenströmen dürfte gzip demnach noch nie einer Beschränkung aufgesessen sein. Dass beim Packen von einzelnen Dateien das Dateisystem oder das Betriebssystem 2GB als Grenze gesetzt hatten, ist dagegen durchaus möglich.

[lucki2]

gzip hatte sicher eine Beschränkung.

[captaincrunch]

Ich behaupte (wie Matthias) aus gemachten Erfahrungen heraus das Gegenteil. Quellen für das Limit innerhalb gzips?

[lucki2]

eine Idee ist Google:
http://www.google.com/search?q=gzip+4GB&btnG=Search

[mattiass]

eine Idee ist Google:
http://www.google.com/search?q=gzip+4GB&btnG=Search

Da findet man eine absolut inkonsistente Implementierung eines alten RFCs, die -- wenn überhaupt -- zumeist in einer Warnung bei Dateien >4GB und einem noch inkonsistenteren Verhalten bei Streams resultiert. Und das schon seit Jahren.

Wer von Euch ist eigentlich masochistisch genug, auf Solaris nicht die GNU Tools zu installieren?

[lucki2]

red Dich halt nicht raus.

[mattiass]

red Dich halt nicht raus.

Nö. Ich rede mich nicht raus. Die alte Grenze bei 4GB Files ist klar. Bei Datenströmen und der zlib (die von bsdtar benutzt wird), sieht es anders aus. Ich kann mich da nur meinem Vorredner anschließen: Probleme sind mir nicht aufgefallen, ich kann mir aber durchaus vorstellen, dass es diese gibt, wenn man Dateien entpackt, die mit einem "robusten" gzip gepackt wurden.