Komprimierung mit tar und pigz beschleunigen

Tim Koschützki

Mitgründer · Berlin, Deutschland ·

Leiten Sie ein unkomprimiertes tar-Archiv an pigz weiter, um ein Projekt mit mehreren CPU-Kernen zu komprimieren. Sie erhalten eine gewöhnliche Datei im Format .tar.gz, die Empfänger mit gzip und tar entpacken können, ohne pigz zu installieren. Die folgende Anleitung erstellt dieses Archiv, schließt Logs aus und vergleicht die wiederhergestellte Datei mit ihrem Original.

Werkzeuge prüfen

Verwenden Sie Bash und GNU tar unter Linux. Die Beispiele wurden mit GNU tar 1.34, pigz 2.6 und Bash 5.1 unter Ubuntu 22.04 sowie mit GNU tar 1.35, pigz 2.8 und Bash 5.3 unter Ubuntu 26.04 getestet. Unter Ubuntu oder Debian installieren Sie pigz mit:

sudo apt-get update && sudo apt-get install pigz

Prüfen Sie die installierten Versionen, bevor Sie fortfahren:

bash --version && tar --version && pigz --version && gzip --version

Die folgenden Befehle sind für diese GNU/Linux-Umgebungen ausgelegt. macOS liefert eine andere Implementierung von tar mit, und die Paketverfügbarkeit variiert bei anderen Linux-Distributionen. Deren Einrichtung ist nicht Bestandteil dieser Anleitung.

Ein kleines Projekt erstellen

Führen Sie die folgenden Blöcke in derselben Bash-Sitzung aus. Beginnen Sie in einem Verzeichnis, in dem Sie ein neues Verzeichnis namens pigz-demo erstellen können:

mkdir pigz-demo &&
cd pigz-demo &&
mkdir project &&
printf 'Keep this project file.\n' > project/README.txt &&
printf 'Omit this debug log.\n' > project/debug.log

Die Verkettung mit && stoppt, wenn die Einrichtung fehlschlägt. Falls pigz-demo bereits existiert, wählen Sie einen anderen Speicherort; dieser Block verweigert bewusst die Wiederverwendung. Sie sollten sich jetzt in pigz-demo befinden, mit zwei Dateien unter project/.

Das Projekt komprimieren

Führen Sie diesen vollständigen Block einschließlich der Klammern aus:

(
  set -e
  set -o pipefail
  set -o noclobber

  tar --exclude='*.log' -cf - project | pigz -p 4 -6 > project.tar.gz
  printf 'Created project.tar.gz\n'
)

Hier erfasst tar -c das Verzeichnis, und -f - schreibt das Archiv auf die Standardausgabe. pigz komprimiert diesen Datenstrom mit bis zu vier Komprimierungsthreads auf Stufe sechs, seiner Standardstufe. Speichern Sie project.tar.gz außerhalb von project/, damit das Archiv seine eigene Ausgabe nicht einschließen kann. Fügen Sie hier nicht die Option -z von tar hinzu: Sie würde den Datenstrom komprimieren, bevor er pigz erreicht.

Für die Ausgabe gilt: Ein vorhandenes Archiv wird abgelehnt. Die Bash-Option noclobber verhindert, dass die Umleitung eine vorhandene reguläre Datei ersetzt, auch bei einer erneuten nichtinteraktiven Ausführung. Wählen Sie einen neuen Ausgabenamen, um ein weiteres Archiv zu speichern. Die Klammern beschränken diese Shell-Optionen auf diesen Vorgang.

Mit pipefail führt ein Fehler in tar oder pigz zum Fehlschlagen der Pipeline; set -e stoppt den Block dann vor seiner Erfolgsmeldung. Andernfalls könnte pigz einen unvollständigen Datenstrom aus einem fehlgeschlagenen tar-Befehl erfolgreich komprimieren. Ein fehlgeschlagener Durchlauf kann eine unvollständige Datei project.tar.gz hinterlassen; verwenden Sie diese nicht, selbst wenn sie eine Integritätsprüfung mit gzip besteht. Untersuchen Sie den Fehler und wählen Sie einen neuen Ausgabenamen, bevor Sie es erneut versuchen. Siehe die Bash-Dokumentation zu Pipelines und Shell-Optionen.

Ausschlüsse festlegen

Das in Anführungszeichen gesetzte Muster --exclude='*.log' schließt Logs unterhalb des Projektverzeichnisses aus, einschließlich project/debug.log. Durch die Anführungszeichen interpretiert tar den Platzhalter anstelle der Shell. Entfernen Sie diese Option, wenn Logs in Ihr Archiv gehören. Für weitere Ausschlüsse akzeptiert GNU tar mehrfach angegebene Optionen --exclude oder --exclude-from mit einem Muster pro Zeile in einer Datei. Dies sind Muster im Shell-Stil, keine regulären Ausdrücke; siehe die GNU-tar-Dokumentation zu Ausschlüssen.

Das Archiv prüfen und wiederherstellen

Prüfen Sie nach erfolgreicher Erstellung den gzip-Datenstrom und listen Sie den Archivinhalt auf:

gzip -t project.tar.gz && tar -tzf project.tar.gz

Bei erfolgreicher Ausführung erzeugt gzip -t keine Ausgabe. Für das Beispielprojekt gibt tar anschließend Folgendes aus:

project/
project/README.txt

Diese Prüfungen beantworten unterschiedliche Fragen: gzip prüft die Integrität der komprimierten Daten, während die Auflistung zeigt, welche Pfade archiviert wurden. Keine der beiden Prüfungen beweist, dass jede vorgesehene Quelldatei erfasst wurde. Das gzip-Handbuch dokumentiert die Integritätsprüfung.

Entpacken Sie das Archiv in ein neues Verzeichnis und vergleichen Sie die wiederhergestellte Datei mit dem Original:

mkdir restored &&
tar -xzf project.tar.gz -C restored &&
cmp project/README.txt restored/project/README.txt &&
printf 'Restored README.txt matches the original.\n'

Die abschließende Meldung erscheint nur, wenn das Entpacken und der byteweise Vergleich erfolgreich sind. Der anfängliche Befehl mkdir lehnt ein vorhandenes Verzeichnis restored ab. So kann eine erneute Ausführung dieses Blocks keine frühere Wiederherstellung überschreiben. Falls das Entpacken fehlschlägt, untersuchen Sie den Fehler und verwenden Sie beim nächsten Versuch ein neues Ziel. Vergleichen Sie bei einem tatsächlichen Projekt die Dateien, die Sie wiederherstellen müssen, nicht nur die README-Datei aus dem Beispiel.

Threadanzahl und Komprimierungsstufe wählen

Beginnen Sie mit -6. Probieren Sie -1, wenn die Komprimierungsdauer wichtiger ist als die Größe, oder -9, wenn Sie mehr CPU-Zeit aufwenden können, um die Ausgabe möglichst klein zu halten. Eine höhere Stufe bedeutet keine schnellere Komprimierung. Ohne -p verwendet pigz standardmäßig die Anzahl der aktiven Prozessoren. Eine explizite Begrenzung ist auf einem Rechner sinnvoll, der weitere Aufgaben ausführt. Diese Einstellungen sind im pigz-Handbuch beschrieben.

Das kleine Beispiel oben prüft die Korrektheit, nicht die Geschwindigkeit. Sobald Sie ein repräsentatives, unverändertes Projekt haben, vergleichen Sie einen und vier Komprimierungsthreads bei derselben Stufe:

(
  set -e
  set -o pipefail

  for threads in 1 4; do
    printf 'Compression threads: %s\n' "$threads"
    time tar --exclude='*.log' -cf - project | pigz -p "$threads" -6 > /dev/null
  done
)

Der Bash-Befehl time misst die gesamte Pipeline; vergleichen Sie die verstrichenen Zeiten unter real. Dabei wird die komprimierte Ausgabe verworfen. Gemessen werden also das Lesen und die Komprimierung, ohne ein Archiv auf den Datenträger zu schreiben. Wiederholen Sie dies mit Ihren eigenen Daten: Dateisystem-Caching, verfügbare CPUs, Datenträgerdurchsatz und bereits komprimierte Dateien können das Ergebnis verändern. Eine feste Beschleunigung ist nicht zu erwarten.

pigz parallelisiert die Komprimierung, doch die gewöhnliche gzip-Dekomprimierung verwendet weiterhin einen Dekomprimierungsthread, unterstützt durch Hilfsthreads zum Lesen, Schreiben und Berechnen von Prüfsummen. Erwarten Sie beim Entpacken nicht dieselbe Skalierung. Das pigz-Handbuch erläutert diesen Unterschied.

Das Archiv in einem Sicherungsauftrag verwenden

Bevor Sie ein tatsächliches Projekt archivieren, stoppen Sie Prozesse, die seine Dateien verändern, oder archivieren Sie einen Dateisystem-Snapshot. tar macht aus einem laufend veränderten Verzeichnis keine konsistente Sicherung eines bestimmten Zeitpunkts. Verwenden Sie für einen geplanten Auftrag absolute Pfade, geben Sie jedem Durchlauf einen neuen Ausgabenamen und behalten Sie die Fehlerprüfungen bei, bevor Sie das Ergebnis übertragen oder aufteilen.

Dieser Ablauf erstellt ein vollständiges lokales Archiv. Inkrementelle Sicherungsketten, SSH-Übertragungen und aufgeteilte Archive benötigen eine eigene Fehlerbehandlung und eigene Wiederherstellungsverfahren. Bewahren Sie die letzte nachweislich funktionierende Sicherung auf, bis Sie das neue Archiv und die Dateien geprüft haben, die Sie wiederherstellen müssen.