Dans beaucoup de SI, la compression des fichiers reste un sujet de fond qu’on ne revoit que le jour où un disque se remplit ou qu’un job de sauvegarde dépasse sa fenêtre. Sur Linux, la combinaison gzip et tar est devenue un réflexe de base, aussi bien pour empaqueter un livrable applicatif que pour transférer quelques gigaoctets de logs vers un autre serveur. L’intérêt n’est pas théorique : moins de données sur le fil, moins d’I/O disque, donc moins de frictions quand on déploie ou qu’on sauvegarde.
Face à un environnement hétérogène, comme celui d’Alex, admin d’une PME industrielle avec une douzaine de serveurs Linux et une passerelle vers un NAS Windows, l’objectif est simple : disposer de quelques commandes courtes et fiables pour compresser, décompresser et vérifier des archives, sans avoir à fouiller la doc à chaque fois. Ce texte s’attache donc aux gestes qui servent en production : comment créer une archive avec tar et gzip, quand utiliser directement gzip -c ou gzip -d, comment choisir entre gzip, bzip2 et xz, et quels pièges éviter (fichiers déjà présents, sur‑compression inutile, confusion entre sécurité et compression).
La ligne de commande reste le socle, mais l’interface graphique n’est pas oubliée, notamment pour les postes bureautiques sous GNOME ou KDE où l’on compresse un dossier par clic droit plus souvent qu’on ne le pense. Au passage, quelques commandes de diagnostic (liste de contenu, test d’intégrité, niveaux de compression) permettent de sortir du pilotage à l’aveugle. Le fil rouge est clair : mesurer les gains, garder des commandes courtes, et se rappeler que la bonne configuration est celle qu’un collègue peut relire à froid une semaine plus tard.
- gzip est l’outil de compression présent sur toutes les distributions linux, idéal comme base commune.
- tar regroupe plusieurs fichiers dans une seule archive, souvent combiné avec gzip pour produire des .tar.gz.
- Pour décompresser un .gz, la commande clé est gzip -d ou son alias gunzip.
- gzip -c permet de compresser vers la sortie standard, pratique dans les scripts et les pipelines.
- gzip offre le meilleur compromis vitesse/simplicité, bzip2 et xz n’ont de sens que pour des besoins ciblés.
Gzip, tar et archives .tar.gz sous Linux : qui fait quoi exactement
Beaucoup de confusions viennent d’un point simple : tar et gzip n’ont pas le même rôle. Le premier fait de l’archivage, le second fait de la compression. Tar prend une arborescence de fichiers et de répertoires et la transforme en un seul flux séquentiel .tar, sans réduire la taille. Gzip prend un flux ou un fichier et le compresse en .gz, sans se soucier de savoir s’il contient un fichier unique ou une archive tar à l’intérieur.
Une archive .tar.gz n’est donc rien d’autre qu’un .tar passé à gzip. Sur un serveur de build, par exemple, il est classique de produire d’abord un tar des binaires et scripts, puis de le compresser en une fois pour limiter les aller‑retour disque. C’est aussi ce schéma qui est utilisé pour la majorité des paquets sources distribués sur Internet, ce qui explique pourquoi tout admin système finit par connaître ces formats de tête.
D’ailleurs, c’est précisément parce que gzip ne gère qu’un seul flux à la fois qu’il n’est pas utilisé seul pour empaqueter des répertoires complets. Quand Alex a tenté un jour un « gzip -r » sur un dossier de configuration, il s’est retrouvé avec une multitude de .gz séparés au lieu d’une archive unique. La bonne approche consistait à passer par tar, puis gzip derrière. Cette distinction archivage/compression est la première brique à maîtriser.

Algorithme de compression gzip : pourquoi il reste une valeur sûre
Gzip implémente l’algorithme DEFLATE, combinant des idées de LZ77 et de codage de Huffman. Dans la pratique, le moteur balaye les données, repère les séquences répétées et les remplace par des références plus courtes, puis code ces références avec des symboles dont la longueur dépend de leur fréquence. Les séquences les plus fréquentes reçoivent les codes les plus courts, ce qui améliore le taux de compression sans compliquer la décompression.
Ce fonctionnement explique deux comportements visibles en production. Plus un fichier est volumineux, plus les séquences répétées sont nombreuses, donc plus le gain est favorable. Inversement, pour de très petits jeux de données, le surcoût des métadonnées nécessaires à la reconstruction peut manger l’essentiel du bénéfice. Sur des logs applicatifs ou des exports CSV de quelques dizaines de mégaoctets, les gains sont en revanche nettes, ce qui en fait un candidat intéressant pour les jobs nocturnes de sauvegarde.
Historiquement, Deflate date du début des années 1990, une époque de liaisons lentes et de disques étroits, mais malgré des alternatives plus récentes, il garde deux atouts : une vitesse de traitement très correcte sur du matériel courant et une compatibilité quasiment universelle. Pour un SI mixte avec Linux, quelques NAS et des outils Windows, miser sur gzip reste une position raisonnable.
Commandes gzip en ligne de commande : compresser et décompresser des fichiers
Sur une machine linux, la commande gzip est quasiment toujours disponible sans installation supplémentaire. C’est d’ailleurs pour cette raison qu’Alex l’utilise comme standard minimal dans ses scripts d’exploitation. L’interface est volontairement réduite : on pointe un fichier, gzip rend un .gz, et l’inverse se fait avec gzip -d. Quelques options changent toutefois beaucoup la vie au quotidien.
Premier réflexe : comprendre que, par défaut, gzip supprime le fichier source après compression. Cette suppression surprend régulièrement les nouveaux venus qui ne lisent que la seconde ligne du man. L’option de conservation devient donc vite un réflexe, surtout en environnement de test ou quand on n’a pas encore validé son pipeline entièrement.
Compresser un fichier avec gzip et garder le contrôle
Pour compresser un fichier unique, la commande de base reste lisible :
gzip monfichier.log
On obtient alors un fichier monfichier.log.gz et le fichier initial disparaît. Pour conserver l’original, il suffit d’ajouter l’option de garde :
gzip -k monfichier.log
Dans un contexte de supervision, Alex a par exemple mis en place un job qui compresse les logs d’application de plus de 7 jours. Les fichiers .gz sont déplacés vers un stockage moins cher, mais les fichiers bruts du jour restent intacts. L’option -k a été utilisée au début pour vérifier à la main quelques archives avant de supprimer systématiquement les originaux via un autre script, une fois la confiance établie.
Sur des répertoires contenant des dizaines de fichiers, l’option -r permet de descendre récursivement et de produire un .gz pour chaque élément. Ce n’est pas toujours ce que l’on veut, mais cela reste utile pour traiter un lot de fichiers homogènes, comme des exports journaliers indépendants.
Utiliser gzip -c dans des pipelines et des scripts
Le vrai levier de gzip en exploitation se trouve dans gzip -c, qui compresse vers la sortie standard au lieu de modifier les fichiers en place. Concrètement, cela permet d’enchaîner les traitements dans un pipeline sans créer de fichiers temporaires intermédiaires. Par exemple, pour compresser un dump SQL à la volée :
pg_dump ma_base | gzip -c > ma_base.sql.gz
On garde la main sur le nom du fichier généré, et surtout, on ne laisse jamais traîner un dump non compressé sur le disque. Sur un serveur de production exposé, cette différence compte. Le même principe se retrouve dans la rotation de logs, où l’on peut chaîner un tail ou un awk avant la compression pour filtrer les lignes réellement utiles.
Autre cas pratique : Alex souhaitait vérifier rapidement la taille compressée d’un fichier sans écraser le .gz existant. Un simple « cat fichier.log | gzip -c > /tmp/test.log.gz » permet de comparer les tailles en testant un niveau de compression différent, sans toucher à l’archive utilisée en production. C’est une manière propre d’expérimenter sans casser les habitudes des jobs existants.
Décompression avec gzip -d et gestion des collisions de fichiers
Côté décompression, la commande est tout aussi directe : gzip -d archive.log.gz redonne archive.log, en supprimant l’archive une fois l’opération terminée. L’alias gunzip réalise exactement la même opération. Là encore, l’option -k permet de conserver l’archive compressée si nécessaire :
gzip -dk archive.log.gz
Un cas classique de terrain : un fichier du même nom existe déjà dans le répertoire courant. Par défaut, gzip demande quoi faire, ce qui bloque un script automatisé. Pour forcer l’écrasement sans interaction, on combine -d et -f :
gzip -df archive.log.gz
Alex s’est retrouvé un jour avec une restauration qui tournait dans le vide à cause de ce prompt interactif ignoré. Le correctif a simplement consisté à ajouter -f dans le script de décompression, après s’être assuré que l’emplacement de sortie était clairement dédié aux données restaurées. Moralité : toute automatisation mérite un passage en revue des cas de conflit de nom de fichier.
Tar et gzip ensemble : créer et extraire des archives tar.gz efficaces
Dès qu’il s’agit de regrouper plusieurs fichiers ou une arborescence complète, la solution la plus robuste reste l’usage combiné de tar et gzip. L’avantage majeur est la lisibilité : une seule commande, un seul fichier .tar.gz, et des options devenues quasi standards dans toute équipe qui touche à Linux. Sur le terrain, on voit ce tandem partout, des déploiements applicatifs aux sauvegardes d’urgence d’un répertoire de configuration avant une mise à jour système.
Du point de vue des performances, la séquence est simple : tar crée le flux séquentiel .tar, puis passe ce flux à gzip qui applique sa compression. Cette approche évite de compresser chaque fichier individuellement et permet souvent un meilleur gain global, les motifs de données traversant parfois plusieurs fichiers à l’intérieur de l’archive.
Créer une archive .tar.gz avec tar et gzip
Pour compresser un répertoire complet, Alex utilise une ligne qu’il pourrait écrire les yeux fermés :
tar -czvf sauvegarde-conf.tar.gz /etc/app_conf/
Le décryptage des options est rapide :
- -c pour créer une nouvelle archive.
- -z pour passer par gzip (compression Deflate).
- -v pour afficher les noms des fichiers traités, utile lors des vérifications.
- -f pour indiquer le nom du fichier d’archive à produire.
La même logique fonctionne avec plusieurs chemins en entrée. Par exemple, regrouper un répertoire de configuration, un PDF de documentation et un binaire spécifique pour un support :
tar -czvf ticket-support.tar.gz /etc/app_conf/ /opt/app/bin/outillage /home/alex/Documents/incident.pdf
Ce type d’archive unifiée évite les transferts multiples par mail ou via un outil de ticketing qui n’aime ni les dossiers ni les chemins relatifs. Une commande claire, un fichier unique, et surtout un contenu traçable grâce au mode verbeux et à la commande de listing.
Exclure des fichiers et dossiers dans une archive tar.gz
Dans un atelier agroalimentaire qu’Alex accompagne, les équipes souhaitaient archiver des historiques de mesures sans embarquer les sous-répertoires de tests de développement, pourtant placés dans la même arborescence. La solution a consisté à utiliser les options d’exclusion de tar pour filtrer finement le contenu de l’archive :
tar -czvf mesures.tar.gz /data/mesures –exclude=/data/mesures/dev –exclude=/data/mesures/tmp
La même approche fonctionne avec des motifs, par exemple pour ignorer tous les .jpg :
tar -czvf mesures.tar.gz /data/mesures –exclude=*.jpg
Ce filtrage au moment de la création évite d’avoir à faire le ménage après coup, ce qui est plus fiable et plus lisible dans un script. Cela force aussi une réflexion sur ce qui mérite vraiment d’être archivé, ce qui n’est jamais un mauvais exercice dans un système qui grossit année après année.
Décompresser une archive tar.gz dans le bon répertoire
Une fois l’archive .tar.gz reçue ou copiée, la décompression complète tient sur une ligne :
tar -xzvf sauvegarde-conf.tar.gz
Cette commande extrait tout dans le répertoire courant. Pour contrôler la destination, l’option -C devient vite indispensable :
tar -xzvf sauvegarde-conf.tar.gz -C /tmp/restauration_test/
Dans un scénario de restauration prudente, Alex commence toujours par un déballage dans un répertoire temporaire, puis compare quelques fichiers critiques avant de décider d’écraser les fichiers de production. Cette habitude, née d’un incident où un mauvais tar avait remplacé un fichier de configuration système, a été formalisée dans une simple checklist interne. Là encore, une commande simple, mais une discipline d’usage qui fait la différence.
Comparer gzip, bzip2 et xz sous Linux : vitesse, taux de compression, compatibilité
Dès que l’on parle de compression sous linux, trois noms reviennent : gzip, bzip2 et xz. Tous les trois répondent au même besoin, mais avec des compromis différents entre vitesse, taux de compression et compatibilité hors Linux. Pour une PME, le choix par défaut reste souvent gzip, mais il y a des cas précis où bzip2 ou xz se défendent.
La question posée à Alex par une équipe data a un jour été très concrète : « vaut-il mieux stocker nos archives d’exports en .tar.gz ou en .tar.xz si on les lit rarement mais qu’on les transfère sur un lien un peu instable ? ». Ce genre de cas oblige à regarder au-delà du réflexe historique et à poser quelques chiffres sur la table.
| Outil | Algorithme | Vitesse de compression | Vitesse de décompression | Taux de compression | Compatibilité Linux | Compatibilité Windows |
|---|---|---|---|---|---|---|
| gzip | DEFLATE | Rapide | Très rapide | Correct | Excellente | Bonne (nombreux outils) |
| bzip2 | bzip2 | Moyenne | Plus lente | Meilleure que gzip | Très bonne | Moyenne |
| xz | LZMA2 | Lente | Moyenne | Supérieure à bzip2/gzip | Bonne | Très bonne (7-Zip, etc.) |
Dans la pratique, le trio peut se résumer ainsi. Gzip gagne largement sur la vitesse et la disponibilité, bzip2 se place au milieu du gué, et xz joue la carte du gain maximal au prix d’un temps de traitement plus long. Pour des archives qu’on ouvre rarement et qui voyagent sur des liens coûteux ou limités, xz a du sens. Pour tout ce qui tourne dans une boucle CI/CD ou dans des jobs quotidiens, rester sur gzip reste une décision parfaitement défendable.
Alex a par exemple choisi xz pour un lot d’archives annuelles de mesures environnementales qui ne sont relues qu’en cas d’audit. À l’inverse, tous les livrables d’applications et les sauvegardes de configuration restent en .tar.gz, avec des temps de compression courts et une décompression instantanée sur des VM de test. Un même outil, trois usages, en fonction du rythme d’accès et du coût de la bande passante.
Utiliser tar avec gzip, bzip2 ou xz selon le besoin
Tar simplifie le passage d’un outil de compression à l’autre via une seule option. Pour gzip, le drapeau est -z (comme déjà vu). Pour xz, on bascule sur -J, et pour bzip2, sur -j. Concrètement :
tar -cJvf archive.tar.xz /chemin/vers/donnees
tar -cjvf archive.tar.bz2 /chemin/vers/donnees
La structure de commande reste la même, ce qui évite de multiplier les mémos pour chaque outil. La seule vraie question à trancher reste celle de la compatibilité côté destinataire. Alex a déjà vu des archives .tar.xz arriver chez un partenaire équipé uniquement d’outils anciens sous Windows, incapable de les ouvrir. Depuis, chaque choix de format est documenté dans la procédure d’échange, ce qui évite de transformer un gain de 10 % de compression en deux jours de support.
Sur un parc très homogène et maîtrisé, pousser vers xz n’est pas choquant. Mais dès que l’on ouvre la porte à des tiers, aux équipes métiers ou à des prestataires externes, rester sur gzip garde un côté rassurant, justement parce que tout le monde sait quoi faire devant un fichier .tar.gz.
Graphique ou terminal : compresser des fichiers sous Linux sans effrayer les non-admins
Tout le monde n’a pas envie de retenir « tar -czvf » par cœur. Sur les postes bureautiques ou pour les équipes qui manipulent des documents plutôt que des dumps SQL, les gestionnaires de fichiers GNOME et KDE proposent une intégration graphique de la compression et de la décompression. Alex s’en sert d’ailleurs pour former des collègues qui n’ouvriront jamais un terminal, mais qui doivent quand même envoyer une archive propre à un fournisseur ou à un service support.
Le principe est simple : clic droit, action d’archivage, choix du format, et en arrière-plan, le système s’appuie sur les mêmes briques que la ligne de commande. Le résultat reste donc compatible avec les scripts et outils d’administration, ce qui évite de créer deux mondes étanches.
Créer et extraire des archives avec KDE et GNOME
Sous KDE (gestionnaire de fichiers Dolphin), un clic droit sur un dossier propose un menu « Compresser ». Les options « Ici (en tar.gz) » ou « Ici (en zip) » produisent respectivement une archive .tar.gz (donc avec gzip derrière) ou un .zip. L’entrée « Compresser vers » ouvre plus de possibilités, dont des formats plus exotiques. Pour l’essentiel, le couple tar.gz couvre déjà l’immense majorité des cas d’usage.
Sous GNOME (gestionnaire Fichiers), la logique est très proche. Clic droit, « Compresser », nom de l’archive, puis choix du format : .zip, .tar.xz ou .7z selon les préférences et les contraintes de compatibilité. Pour un échange avec un environnement Windows peu outillé, .zip reste un format sûr. Pour une archive interne qui restera sur des serveurs Linux, .tar.xz tire mieux parti des capacités de compression de LZMA2.
Côté décompression, l’approche est encore plus directe. Dans KDE, « Extraire ici » déplie l’archive dans le dossier courant, tandis que « Extraire vers » laisse choisir le répertoire de destination. GNOME propose des options similaires. Pour les utilisateurs peu à l’aise avec le système de fichiers, Alex conseille souvent de créer un dossier « temp » explicite, d’y extraire les données puis de faire le tri. Ce simple réflexe limite les confusions entre données originales et versions restaurées.
Quelques commandes gzip avancées en Linux pour diagnostiquer et optimiser
Une fois les bases maîtrisées, deux besoins apparaissent rapidement : vérifier qu’une archive est saine et ajuster le compromis entre vitesse et taux de compression. Gzip répond à ces attentes avec quelques options peu connues mais très utiles en production. Ce sont précisément ces détails qui font la différence entre un usage « bricolé » et un usage fiable dans la durée.
Alex a mis en place, sur un de ses serveurs de sauvegarde, un petit script qui valide chaque archive fraîchement créée avant de supprimer les fichiers bruts. L’objectif est simple : éviter de découvrir une corruption d’archive le jour où l’on en a réellement besoin. Là encore, les commandes restent courtes, mais la valeur ajoutée est élevée.
Lister, tester, régler la compression avec gzip
Pour obtenir des informations sur une archive .gz, la commande suivante affiche les tailles avant/après et le ratio :
gzip -l sauvegarde-conf.tar.gz
Ce type de sortie permet de vérifier rapidement que le gain est cohérent avec le type de données. Sur des fichiers déjà compressés (vidéos, images JPEG, archives zip), le taux de compression sera quasi nul, ce qui alimente une bonne pratique : éviter de sur‑compresser des contenus déjà optimisés. C’est un point qu’Alex rappelle souvent aux équipes qui rêvent de passer toutes leurs sauvegardes dans une cascade de .zip puis .gz.
Pour tester l’intégrité d’une archive sans la décompresser complètement, gzip -t est très pratique :
gzip -t sauvegarde-conf.tar.gz
En l’absence de problème, la commande se termine silencieusement. En cas de corruption, un message explicite apparaît, ce qui permet d’automatiser une alerte ou une reprise. Ce test en fin de chaîne d’un job de sauvegarde ajoute quelques secondes, mais évite des surprises douloureuses.
Enfin, pour ajuster le compromis temps/gain, gzip accepte un niveau de 1 à 9. Par exemple :
gzip -1 groslog.log
gzip -9 groslog.log
Le niveau 1 privilégie la vitesse, utile pour des opérations fréquentes sur des données peu sensibles au volume. Le niveau 9 pousse la compression au maximum, intéressant pour des archives froides. En pratique, le niveau par défaut (6) couvre déjà bien les besoins. Alex a mesuré sur certains fichiers de taille moyenne que passer de 6 à 9 ne changeait presque rien à la taille, mais augmentait sensiblement le temps de traitement. L’ajustement mérite donc un test ciblé plutôt qu’un réglage dogmatique.
Repères rapides de commandes gzip et tar à garder sous la main
Pour finir, quelques commandes reviennent tellement souvent qu’elles finissent collées sur un coin de bloc-notes ou dans un fichier README interne. Les garder visibles aide à homogénéiser les pratiques entre les membres d’une équipe, surtout quand tout le monde ne passe pas ses journées dans un terminal.
Alex a construit sa propre mini antisèche, qu’il partage aux nouveaux arrivants. Elle couvre la création d’archives .tar.gz, la décompression et le listing, ainsi que les formes directs de gzip comme gzip -d et gzip -c. Ce n’est pas exhaustif, mais largement suffisant pour les opérations quotidiennes.
- tar -czvf archive.tar.gz /chemin/vers/dossier : créer une archive tar compressée avec gzip.
- tar -xzvf archive.tar.gz : extraire une archive tar.gz dans le répertoire courant.
- gzip fichier.log : compresser un fichier en fichier.log.gz.
- gzip -d fichier.log.gz : décompresser un fichier .gz en supprimant l’archive.
- gzip -c fichier.log > fichier.log.gz : compresser vers la sortie standard sans modifier le fichier source.
Quelle différence entre gzip et tar sous Linux ?
Sous linux, gzip est un outil de compression qui réduit la taille d’un fichier unique en produisant un fichier .gz. Tar est un outil d’archivage qui regroupe plusieurs fichiers et répertoires en un seul flux .tar sans les compresser. Dans la pratique, on utilise souvent les deux ensemble pour créer des archives tar.gz, où tar assemble, puis gzip compresse.
Quand utiliser gzip -d plutôt que gunzip ?
gzip -d et gunzip exécutent la même action de décompression, la seconde étant un alias plus lisible. Dans un script ou une documentation technique orientée options, beaucoup préfèrent gzip -d pour rappeler clairement l’outil et l’option utilisée. Gunzip reste pratique en utilisation interactive pour taper plus vite.
À quoi sert gzip -c dans un pipeline Linux ?
L’option gzip -c envoie les données compressées sur la sortie standard au lieu d’écraser le fichier d’entrée. Cela permet de chaîner des commandes, par exemple un dump de base ou un filtrage de logs, puis de rediriger le flux compressé vers un fichier ou un autre programme. C’est la méthode recommandée dans les scripts pour éviter de laisser traîner des fichiers temporaires non compressés.
Faut-il encore utiliser bzip2 ou xz, ou rester uniquement sur gzip ?
Pour les usages quotidiens, gzip suffit largement, surtout grâce à sa vitesse et à sa compatibilité quasi universelle. Bzip2 et xz ont leur place pour des archives rarement ouvertes où l’on cherche à gratter quelques pourcents de gain supplémentaires, par exemple pour de l’archivage froid ou des transferts sur des liens coûteux. Pour une PME ou un parc hétérogène, garder gzip comme standard et réserver xz à quelques cas ciblés reste une stratégie raisonnable.
La compression avec gzip protège-t-elle les données ?
Non, gzip ne fournit aucune forme de chiffrement ou de protection. Il ne fait que compresser les données, sans empêcher leur lecture par quelqu’un qui a accès aux fichiers .gz. Pour protéger le contenu, il faut combiner la compression avec des outils de chiffrement dédiés, comme gpg ou openssl, en fonction des contraintes de sécurité et des politiques internes.