Accélérer la compression avec tar et pigz
Redirigez par un pipe une archive tar non compressée vers pigz pour compresser un projet sur
plusieurs cœurs CPU. Vous obtenez un fichier .tar.gz ordinaire que les destinataires peuvent
extraire avec gzip et tar, sans installer pigz. La procédure ci-dessous crée cette archive, exclut
les journaux et compare le fichier restauré à son original.
Vérifier les outils
Utilisez Bash et GNU tar sous Linux. Les exemples ont été testés avec GNU tar 1.34, pigz 2.6 et Bash 5.1 sous Ubuntu 22.04, ainsi qu’avec GNU tar 1.35, pigz 2.8 et Bash 5.3 sous Ubuntu 26.04. Sous Ubuntu ou Debian, installez pigz avec la commande suivante :
sudo apt-get update && sudo apt-get install pigz
Vérifiez les versions installées avant de continuer :
bash --version && tar --version && pigz --version && gzip --version
Les commandes ci-dessous ciblent ces environnements GNU/Linux. macOS fournit une autre implémentation de tar, et la disponibilité des paquets varie selon les autres distributions Linux ; leur configuration dépasse le cadre de cette procédure.
Créer un petit projet
Exécutez les blocs suivants dans la même session Bash. Commencez dans un répertoire où vous pouvez
créer un nouveau répertoire pigz-demo :
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
La chaîne && s’arrête si la configuration échoue. Si pigz-demo existe déjà, choisissez un autre
emplacement ; ce bloc refuse délibérément de le réutiliser. Vous devriez maintenant vous trouver
dans pigz-demo, avec deux fichiers sous project/.
Compresser le projet
Exécutez ce bloc complet, parenthèses comprises :
(
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'
)
Ici, tar -c rassemble le répertoire et -f - écrit l’archive sur la sortie standard. Pigz
compresse ce flux avec jusqu’à quatre threads de compression au niveau six, son niveau par défaut.
Gardez project.tar.gz en dehors de project/ afin que l’archive ne puisse pas inclure son propre
fichier de sortie. N’ajoutez pas ici l’option -z de tar : elle compresserait le flux avant
qu’il n’atteigne pigz.
La règle de sortie consiste à refuser une archive existante. L’option noclobber de Bash empêche
la redirection de remplacer un fichier régulier existant, y compris lors d’une réexécution non
interactive. Pour conserver une autre archive, choisissez un nouveau nom de sortie. Les parenthèses
limitent ces options du shell à cette opération.
Avec pipefail, un échec de tar ou de pigz fait échouer le pipeline ; set -e arrête alors le
bloc avant son message de réussite. Sinon, pigz pourrait compresser avec succès un flux incomplet
issu d’une commande tar en échec. Une exécution en échec peut laisser un fichier project.tar.gz partiel ;
ne l’utilisez pas, même s’il réussit un test d’intégrité gzip. Analysez l’erreur et choisissez un
nouveau nom de sortie avant de réessayer. Consultez la
documentation de Bash sur les pipelines et les options du shell.
Choisir ce qu’il faut exclure
Le motif --exclude='*.log' entre guillemets exclut les journaux situés sous le répertoire du projet, y
compris project/debug.log. Les guillemets permettent à tar, et non au shell, d’interpréter le caractère
générique. Supprimez cette option si les journaux doivent figurer dans votre archive. Pour d’autres
exclusions, GNU tar accepte des options --exclude répétées ou --exclude-from avec un motif par ligne dans
un fichier. Il s’agit de motifs de type shell, et non d’expressions régulières ; consultez la
documentation de GNU tar sur les exclusions.
Vérifier et restaurer l’archive
Après une création réussie, vérifiez le flux gzip et listez les membres de l’archive :
gzip -t project.tar.gz && tar -tzf project.tar.gz
Un gzip -t réussi n’affiche rien. Pour le projet d’exemple, tar affiche ensuite :
project/
project/README.txt
Ces vérifications répondent à des questions différentes : gzip teste l’intégrité des données compressées, tandis que la liste vous permet de vérifier quels chemins ont été archivés. Aucune ne prouve que chaque fichier source prévu a bien été capturé. Le manuel de gzip documente son test d’intégrité.
Extrayez l’archive dans un nouveau répertoire et comparez le fichier restauré avec l’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'
Le message final n’apparaît que si l’extraction et la comparaison octet par octet réussissent. Le
mkdir initial refuse un répertoire restored existant ; réexécuter ce bloc ne peut donc pas
écraser une restauration précédente. Si l’extraction échoue, examinez l’erreur et utilisez une
nouvelle destination pour la tentative suivante. Pour un vrai projet, comparez les fichiers que
vous devez récupérer, pas seulement le README d’exemple.
Choisir le nombre de threads et le niveau de compression
Commencez avec -6. Essayez -1 lorsque le temps de compression compte plus que la
taille, ou -9 lorsque vous pouvez consacrer plus de temps CPU à tenter de réduire la
sortie. Un niveau plus élevé ne signifie pas une compression plus rapide. Sans -p, pigz
utilise par défaut le nombre de processeurs en ligne ; une limite explicite est utile sur une
machine qui effectue d’autres tâches. Ces réglages sont décrits dans le
manuel de pigz.
Le petit exemple ci-dessus vérifie l’exactitude, pas la vitesse. Une fois que vous disposez d’un projet représentatif et inchangé, comparez un et quatre threads de compression au même niveau :
(
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
)
Le time de Bash mesure l’ensemble du pipeline ; comparez les temps écoulés real. Cette
commande élimine la sortie compressée : elle mesure donc la lecture et la compression sans écrire
d’archive sur le disque. Répétez l’opération sur vos propres données : le cache du système de
fichiers, les CPU disponibles, le débit du stockage et les fichiers déjà compressés peuvent modifier
le résultat. Il n’y a pas de gain de vitesse fixe à attendre.
Pigz parallélise la compression, mais la décompression gzip ordinaire utilise toujours un seul thread de décompression, avec des threads auxiliaires pour la lecture, l’écriture et les sommes de contrôle. Ne vous attendez pas au même gain de parallélisme lors de l’extraction. Le manuel de pigz explique cette distinction.
Utiliser l’archive dans une tâche de sauvegarde
Avant d’archiver un vrai projet, arrêtez les processus qui modifient ses fichiers ou archivez un instantané du système de fichiers. Tar ne transforme pas un répertoire actif en sauvegarde cohérente à un instant donné. Pour une tâche planifiée, utilisez des chemins absolus, donnez un nouveau nom de sortie à chaque exécution et conservez les vérifications d’échec avant de transférer ou de découper le résultat.
Cette procédure crée une archive locale complète. Les chaînes de sauvegardes incrémentielles, les transferts SSH et les archives découpées nécessitent leur propre gestion des échecs et leurs propres procédures de restauration. Conservez la dernière sauvegarde réputée valide jusqu’à ce que vous ayez vérifié la nouvelle archive et les fichiers que vous devez récupérer.