Login
Login-Name Passwort


 
Newsletter

Thema: Welches Archivformat nutzen Sie bevorzugt?

25 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr gz
1
Von Ruediger am Fr, 21. April 2017 um 14:07 #

Für den Eigengebrauch immer tar.gz.

mehr ZIP
0
Von asdfghjkl am Fr, 21. April 2017 um 14:21 #

Ich nutze generell zip. Denn wenn 3. ins Spiel kommen, wissen die meist nicht was tar.gz ist. "Eigengebrauch" gibt es bei mir nicht. Gepackt wird immer nur für Datenaustausch.

1
Von Ede am Fr, 21. April 2017 um 14:24 #

tar.gz - wie gewohnt / hat sich bewährt

0
Von autarch am Fr, 21. April 2017 um 15:37 #

Kommt darauf wann was man damit machen will. Eine andere Person soll es öffnen (potentiell auf Windows): zip oder bestenfalls 7z. Es soll schnell gehen: lzop oder besser lz4. Es soll so klein wie möglich sein: xz.

  • 0
    Von nico am Fr, 21. April 2017 um 15:54 #

    hier auch.

    xz und lz4 haben noch den Vor- und Nachteil, dass diese von Dateiscannern und Verwaltungstools zur Indexierung meist in Ruhe gelassen werden. Während diese die Inhalte von gz und zip erfassen, was nicht immer gewollt ist.

0
Von c4shh am Fr, 21. April 2017 um 16:30 #

Interessante Sache. Habe seit Jahren bzip2 verwendet, ohne mir da lange Gedanken zu machen. Nach der Umfrage hab ich mal ein wenig recherchiert, auf dem Markt hat sich weder bei bz2 noch bei gz seit Jahren was getan. Das sollte man näher betrachten.

https://www.lifewire.com/which-is-the-best-compression-tool-for-linux-4082712

0
Von Potz Blitz am Fr, 21. April 2017 um 19:24 #

Irgendwo las ich mal, dass das TAR-Format Probleme mit langen Dateinamen oder Sonderzeichen (Umlaute, etc.) in denselben hat. Weiß jemand was dazu? Und wie ist es bei den anderen Formaten?

  • 0
    Von Falk am Mo, 24. April 2017 um 00:50 #

    Da hast du recht. Danke für den Hinweis. Ich war mir dessen bisher garnicht bewusst.

    Aber es sollte inzwischen gelöst sein.

    Hier ist das Problem dargestellt:

    Mit man tar habe ich herausgefunden, dass diese Optionen mit GNU tar das Posix-Format einstellen:
    --format=posix oder --format=pax

    und aus der Online-Doku von tar

    posix

    Archive format defined by POSIX.1-2001 specification. This is the most flexible and feature-rich format. ...

    This archive format will be the default format for future versions of GNU tar.

    Soweit ich weiß, muss man bei modernen GNU-tar-Implementierungen kaum noch etwas angeben, wenn man wieder entpacken will. Ich habe es bisher aber eigentlich immer doch gemacht.

    Das Problem ist also recht spät aus der Welt geschafft worden (wenn man bedenkt, wie alt tar ist), aber seit ungefähr 15 Jahren sollte es zumindest unter Linux als Quellsystem problemlos funktionieren (also z.B. Backups erstellen zur Langzeitarchivierung), wenn man weiß, was man tut.

    Sofern man aber ein Archiv im alten Format mit falschem Encoding bekommt, dann sind wohl tatsächlich Klimmzüge notwenig:
    siehe hier

0
Von hEAdr00m am Fr, 21. April 2017 um 23:37 #

Ich nutze bevorzugt das gute IZArc. Das kann alle Formate, deswegen eruebrigt sich die Frage nach Formaten.

0
Von blablabla233 am So, 23. April 2017 um 09:26 #

Nutze zpaq für Archivierung oder tar fuer unkomprimier-bares.
Früher noch lrzip aber heute nur noch zpaq (gewaltige Kompression)

0
Von Lothar am So, 23. April 2017 um 13:34 #

RAR mit multiplen Archive Parts ist das einzige Format das bei bitrot (ein paar gekippte Bits im Datenstream) nicht alles im Archiv unlesbar macht daher geeigneter als die anderen.

Archive ist kein "feel good" Ding wie es hier wohl einige meinen a la: Ich hab noch nie Probleme gehabt.

Wichtige Daten sollte man sowieso nicht komprimieren.

  • 0
    Von dfg am So, 23. April 2017 um 14:36 #

    Rar ist doch propritär und danmit für viele sicher keine Alternative. Bleiben die Zugriffs/Nutzerrechte erhalten?

    0
    Von nanox am Mo, 24. April 2017 um 08:34 #

    Richtig!

    Ich bin voriges Jahr umgestiegen und habe all meine Archive neu in rar umgewandelt.

    Grund: Die Wiederherstellungsdaten die sonst niemand bietet. Ich hatte gemerkt wenn files über Jahre und Jahrzehnte lagern gibt einen gewissen Prozentsatz an Bitdrehern und das Archiv ist hinüber. Da hilft auch kein Backup mehr, denn die Bitdreher werden mitgesichert.

    Natürlich wäre mit ein offenes Format deutlich lieber, aber RAR ist hier nunmal einzigartig. Meine Daten sind mir wichtig.

    • 0
      Von blablabla233 am Mo, 24. April 2017 um 13:11 #

      Ist es nicht.
      Nimm lrzip oder zpaq, die haben genau die gleichen recovery daten mitgepackt, bei zpaq sogar mit journal (veränderungen werden also wenn gewollt mitgeschrieben), einem prop. format würde ich niemals meine Daten anvertrauen.

      • 0
        Von pinguinesser am Mo, 24. April 2017 um 20:25 #

        lrzip ist eher ein hack, alles andere als stabil, damit seine daten zu archivieren ist ganz schön mutig. Als ich das zuletzt mal getestet habe ist das schon im laufenden Betrieb abgekackt, Probleme mit übergrossen Dateien obwohl es dafür angeblich geeignet sei,...

        zpaq ist auch unter heavy development. das ging aus paq hervor, einem experimentellen Packer für Wettbewerbe. zpaq sollte für Anwender sein, ist aber im Laufe der Zeit ständig umgebaut worden, inzwischen ist es mehr backuptool als packer. Das Ding ist mir viel zu inkompatibel, es hat ein paar Features wo ich eher dar nehmen würde wenn mir incrementelles (remote) backup wichtig ist. Das hat nen gut abgehangenen Container, kompression und verschlüsselung nach Wahl, so wie man das haben will, neben anderer nützlicher Features.

        Zu den "recovery"daten (es hat keine) von zpaq
        Was wenn das journal kaputt ist? Das ist doch das Problem: Verwaltungsdaten am Arsch -> komplette Daten im Arsch, selbst wenn der eigentliche Datenpart noch intakt ist, da kann man wenn die Daten nicht gepackt sind noch mit Datenrettungstools ran aber wenn gepackt wurde ist schicht im Schacht.
        Deshalb recoverydaten, am einfachsten kann das rar, das jagt reedsolomon über die abgeschlossenen archivdaten und klebt die recoverydaten hinten drann oder wahlweise in separate Dateien und den Grad der Redundanz kann ich aus festlegen wie bei par2.

        Wenn der Packer+Containerformat das nicht kann nimmt man par2 zum erzeugen von Recoverydaten über das finale Archiv.
        Ausserdem kann ich hier den Grad der Redundanz festlegen: 1%, 10% oder 50% oder noch mehr? Kein Problem.

        lzip hat nen wenn auch primitiven recoverymodus, mit dem man wenigsten den Rest wiederherstellen kann und evt. kleine defekte reparieren kann, besser ist auch hier nochmal par2 drüberzujagen. Ist aber auch nur eine Notlösung weil man auf tar aufsetzt und keinen vernünftigen Container nutzt der dateiweise packt und die Verwaltungsdaten in einer Verwaltungsstruktur speichert wie es rar oder andere machen.

        tar + reine packer ist deshalb ein ziemlicher murks was Sicherheit angeht, die reinen Packer haben oft nicht mal redundant ihre Verwaltungsdaten gespeichert, keine fixen Header,...

        Wichtige Daten würde ich nie komprimieren und immer alles doppelt und dreifach vorhalten.

    0
    Von blablabla233 am Mo, 24. April 2017 um 13:15 #

    Stimmt nicht ganz, nur bei solid gepackten Archiven sind uU alle daten im archiv kaputt wenn ein bitrot vorliegt:
    https://en.wikipedia.org/wiki/Solid_compression#Costs
    in andren Worten, alles was *.tar.* ist

0
Von Securitychef am So, 23. April 2017 um 13:42 #

Das kann defekte Archive dennoch grösstenteils entpacken. gzip, bzip2,.. sind da viel zu anfällig. Ein byte am Anfang kaputt wo die Konfig drinn steht und man kann zig GB wegwerfen.

Oder meinetwegen was anderes anfälligeres aber dann mit par2 oder rar mit recoverydaten,....
Jedenfalls niemals alleine tar.gz oder ähnlich primitives Zeugs

  • 0
    Von pagan am Mo, 24. April 2017 um 09:04 #

    Ein byte am Anfang kaputt wo die Konfig drinn steht und man kann zig GB wegwerfen.


    bietet tar.xz / xz utils nicht die gleiche funktionalität wie lzip, was die wiederherstellung / entpacken bei defekten archiven (bitrot) angeht und ist mittlerweile nicht auch weiter verbreitet als lzip?

    • 0
      Von pinguinesser am Mo, 24. April 2017 um 20:04 #

      http://www.nongnu.org/lzip/xz_inadequate.html

      • 0
        Von pagan am Mo, 24. April 2017 um 21:52 #

        vielen dank für den link.

        welches offene format eignet sich denn dann zur langzeitarchivierung und bietet neben guter kompressionsgröße/zeit auch noch die möglichkeit, defekte archive zu reparieren und zu entpacken?

        ich habe ich mir heute mal lzip (wegen recover) und lrzip angeschaut. mein kandidat wäre klar lrzip, nur habe ich da nichts vergleichbares in puncto recover gefunden?

        • 0
          Von pinguinesser am Mo, 24. April 2017 um 23:15 #

          lrzip: habe ich oben schon geschrieben was ich davon halte, m.M. u. E. ist es viel zu buggy. Ist vielleicht in der aktuellen Version anders, aber jede Version die ich bisher getestet hatte lief schon bei normaler Anwendung nicht stabil. Probleme bei grossen Dateien oder Threading, irgendwann habe ich es nicht mehr weiter getestet weil die bugs nie richtig gefixed wurden und auch die Entwicklung für meinen Geschmack am einschlafen war.

          All in one bietet das auch wenn es viele nicht hören wollen: rar
          Es generiert Reedsolomonrecoverydaten auf das nakte archiv, deckt somit alle Fehler ab, egal wo sie auftreten, in den Verwaltungsbereich oder eigentlichen komprimierten Daten
          und ist einfach zu handeln weil es das alles von Haus aus mitbringt. Kompression hält gut mit xz/lzip bei schneller Speed, hat m.M. die optimale Balance zw. Speed und Packrate bei defaultlevel für -m. Um das Rechteproblem unter unix zu umgehen kann man vorher tar'en, dann rar zum eindampfen +dessen recoverydatenfunktion nutzen.

          Will man kein rar nimmt man tar + irgendeinen packer der schnell oder möglichst klein packt, beides zusammen gibts nicht, was der beste Kompromiss für dich ist musst du selber rausfinden. Recoverydaten erzeugt man dann mit par2

          lzip ist ziemlich lahm, plzip die parallele Variante ist deutlich schneller aber erzeugt evt. grössere Dateien als wenn man sie mit lzip in den gleichen Einstellungen packt, ist auch klar weil es eben die Daten auf verschiedene Packthreads aufteilen muss und so nicht evt. sich überschneidende Wdhg nicht erkennen und ausnutzen kann. Den Effekt gibts bei allen parallelen Packern, egal welches Packverfahren sie anwenden.

          7z ist von den LZMA-basierten Packern in meinen Tests der schnellste unter Linux und erzeugt auch meist die kleinsten Daten, sind aber nur minimale Unterschiede in der Grösse, entscheidend sind hier vermutlich die kleineren Verwaltungsdaten, aber er packt "sehr schnell", wobei alle LZMA-basierten Packer ziemlich lahm sind, das kann schon mal nerven bei grossen Datenmengen.
          Wenn du mal eine 16GB tar-Datei packst und das dauert über eine Stunde, dann nervt dich das irgendwann und pfeifst auf die Grösse. Deshalb packe heute wieder teilweise mit lzo oder gzip, das geht deutlich schneller es gibt auch parallele Varianten von (g)zip bzw. Packern die den deflate-Pack-Algo nutzen.

          Bei Backups wo man inkrementell arbeitet nehme ich wieder das Packverfahren mit maximaler Kompression, weil die diffs nur klein sind und die längerer Rechnerei kaum spürbar ist bei den kleinen Datenmengen.

          Kommt auch immer darauf an was du für Daten hast ob sie sich gut packen lassen oder eher schlecht. Für jpg gibts spezielle Packer die nochmal bis zu 30% rausholen, nach meinen Tests.
          packJPG ist die freie Variante davon.

          Alles was archivert wird und wichtig ist wird vorher Recoverydaten mit par2 generiert und diese auf anderem Medium gespeichert.
          Diese Recoverydaten haben mir schon mehrmals die Daten gerettet als mir schleichend mein Brenner die Daten geschreddert hat.

          Geht mal was grösseres übers Netz kopiere ich die Header des gepackten Archivs nochmal separat, oder generiere mit par2 Recoverydaten. Hashes werden auch immer erstellt.

          Ohne par2 wird bei mir jedenfalls nix mehr eingelagert.

          • 0
            Von pagan am Di, 25. April 2017 um 11:42 #

            vielen dank für die ausführliche antwort. ich bleibe wahrscheinlich ersteinmal bei lrzip (bisher keine probleme, ist sehr schnell und packt sehr gut) und schaue mir par2 mal genauer an.

            trotzdem, so etwas wie lziprecover gibt es für lrzip nicht, oder?

            • 0
              Von pinguinesser am Fr, 28. April 2017 um 14:34 #

              Nein gibts nicht. Das Format selber wurde auch nochmal einer der Vorgängerversionen nochmal überarbeitet und heutige Versionen sind nicht mehr abwärtskompatibel.
              Bei solchen Tools würde ich immer das Programm bzw. den Source gleich mit archivieren, wer weiss was in 10 Jahren ist wenn du mal wieder an die Daten willst, dann gibts längst neuere Versionen oder die Entwicklung wurde eingestellt....

              Habe jetzt nochmal die aktuelle lrzip version gezogen, compiliert und getestet, die alten bugs die ich entdeckt hatte sind alle weg.

              Es komprimiert mit den gängigen Verfahren nochmal deutlich besser, ist schon beeindruckend. Da kann man dann nochmal deutlich platz sparen und ist genauso schnell beim packen, z.T. sogar schneller.

              Hmm muss ich mal im Auge behalten und evt. auch umsteigen.

Pro-Linux
Traut euch!
Neue Nachrichten