Universelles CLI-Komprimierungsprogramm mit guter Integritätsprüfung in Linux

Wie der Titel schon sagt, bin ich auf der Suche nach einem guten, definiert als das beste verfügbare , universelle Befehlszeilen-Komprimierungsprogramm mit guter Integritätsprüfung in Linux.

Diese Archive werden für die Langzeitspeicherung verwendet

auf Blu-ray M-Discs ; Details zu gebrauchter Hardware .

Anforderungen:

  • Je besser die integrierte Integritätsprüfung , desto besser die Software für meine Archivierungszwecke

  • muss quelloffen sein

  • vorzugsweise in gepackter Form in den meisten Distributionen verfügbar oder besser = standardmäßig installiert

  • einstellbares Komprimierungsverhältnis, während beim Komprimieren bis zu 10 GB RAM verwendet werden

  • sollte multithreaded sein, da ich eine 8-Kern-CPU habe

Soll die Integritätsprüfung nur eine Prüfung sein (z. B. mit MD5 im Dateinamen) oder eine Korrektur versuchen?
@NicolasRaoul Wenn ich Ihre Frage richtig verstehe, wäre es schön, die Möglichkeit zu haben, eine Wiederherstellung zu versuchen.
Das Überprüfen der Dateiintegrität und das Ändern des Komprimierungsverhältnisses sind die grundlegendsten Dinge, die alle Archivierungstools haben müssen
@phuclv Ich stimme zu, aber diese Frage ist, inwieweit bestimmte Tools dies haben.

Antworten (1)

Nachdem ich viele Handbuchseiten gelesen habe, kann ich Folgendes empfehlen:

xz (Manpage)

Da es eine eingebaute Integritätsprüfung hat, die mit dem folgenden Schalter auf SHA-256 einstellbar ist:

--check=sha256

Weitere Boni:

  • Sie können die Anzahl der CPU-Threads mit dem folgenden Schalter festlegen:

    --threads=8
    
  • Der Standardschalter für die Komprimierungsstufe ist auf 6 eingestellt, Sie können dies auf das Maximum ändern mit:

    -9
    
  • Es implementiert einen Maximum-Effort -Algorithmus mit dem folgenden Schalter, obwohl es ziemlich langsam ist:

    --extreme
    

Sie können ganz einfach einen Alias ​​einer beliebigen Kombination definieren.


Benchmarks

Ich werde diesen Abschnitt nacheinander ergänzen, was ich getestet habe.

  1. xz( Multithreading + SHA-256 + Level 9 + Extrem )

    alias xz-extreme='xz --format=xz --check=sha256 -9 --threads=8 --keep --verbose --verbose --extreme'
    

    Mit diesem Befehl dauerte die Komprimierung fast 25 Minuten und ergab ein Verhältnis von 0,772 .

    $ xz-extreme data.tar
    
    7,991.0 MiB / 10.1 GiB = 0.772   7.0 MiB/s      24:28
    
  2. xz( Multithreading + CRC-32 + Standardstufe 6 )

    alias xz='xz --format=xz --threads=8 --keep --verbose --verbose'
    

    Mit diesem Befehl dauerte die Komprimierung weniger als 15 Minuten und ergab ein Verhältnis von 0,786 ( +138 MiB ).

    $ xz data.tar
    
    8,129.8 MiB / 10.1 GiB = 0.786    12 MiB/s      14:15
    

bzip2 (Manpage)

Im Gegensatz zu xz, aufgrund seiner Singlethread-Natur, dieselbe Datei mit dem Befehl:

$ bzip2 --keep -9 --verbose data.tar

data.tar:  1.244:1,  6.430 bits/byte, 19.63% saved, 10848870400 in, 8719149908 out.

Es dauerte genau 27 Minuten , während ein Verhältnis von 0,803 ( +324 MiB ) erreicht wurde.


Kurze Datenanalyse des präsentierten Datensatzes

  • Weitere nicht komprimierbare Dateien 4,3 GiB (wie RAR oder 7-Zip bei maximaler Komprimierung).

  • Bilddateien (JPEG) 2 GiB.

  • Ausführbare Windows-Installationsprogramme (d. h. auch komprimiert) 0,8 GiB.

  • Nur die restlichen 3 GiB waren mehr oder weniger gut komprimierbare Dateien.


Anderer Datensatz

  • ca. 100.000 Codedateien (stark komprimierbare Daten)

  • Einige PDFs enthalten JPEG-Bilder von Text (eher nicht komprimierbar)

Interessante Ergebniszusammenfassung

  1. 4.5G -Code_und_einige_Bücher. Teer
  2. 2.3G code_and_some_books.tar. gz ( -9)
  3. 2.1G code_and_some_books.tar. bz2 ( -9)
  4. 1.6G code_and_some_books.tar. xz (der oben xz-extremeverwendete Alias)
Ich habe es mit 6,1 MB einfachen Textdateien auf einem Dual-Core-Computer ausprobiert. tar -cf zzz.tar * && bzip2 -9 zzz.tardauerte 1,5 s und führte zu einer 968-k-Datei, während dasselbe mit xzIhren Optionen 11 s dauerte und zu einer 863-k-Datei führte. Es dauerte also xz7-mal so lange und bot mit dieser Eingabe eine um 11% bessere Komprimierung. Mein Fazit: Wenn ich bei einem häufigen Vorgang (vorübergehend) etwas Platz sparen möchte, greife ich lieber zu bzip2– während es für die Langzeitarchivierung xzvielleicht die bessere Wahl ist. Obwohl diese Schlussfolgerung auf zu wenig Daten basiert :)
Vielen Dank für die Mühe, die Sie sich gemacht haben (jetzt positiv bewertet). Ich hinterlasse meinen korrigierten Kommentar oben für ein zusätzliches Beispiel. Im Alltag komprimieren die meisten von uns selten so große Mengen wie du es gerade getan hast :)