Sur un serveur Linux qui gère des sauvegardes, des journaux applicatifs et des exports de base de données, la compression n’est pas un détail cosmétique. Elle conditionne la vitesse des transferts, la taille des archives et parfois la fenêtre de maintenance. L’outil gzip, accessible en ligne de commande, reste l’un des réflexes les plus fiables pour réduire un fichier volumineux avant de l’envoyer sur un NAS, un cloud ou un autre datacenter. Utilisé seul ou avec tar pour produire des archives complètes, il s’intègre aussi bien dans un script de sauvegarde nocturne que dans une simple commande ponctuelle lancée depuis un terminal SSH.
Sur une machine Debian ou Red Hat fraîchement installée, gzip est presque toujours présent par défaut, ce qui évite de passer par un outil exotique qu’il faudrait déployer partout. Sa syntaxe reste directe, mais cache plusieurs usages souvent ignorés : création d’un fichier compressé sans supprimer l’original, réglage du niveau de compression, lecture d’un fichier .gz sans le décompresser sur disque, concaténation de flux… Autant de fonctions qui, bien maîtrisées, font gagner du temps pendant les migrations ou les opérations de nettoyage. L’article qui suit s’appuie sur des cas concrets rencontrés en PME pour montrer comment exploiter au mieux gzip et ses proches cousins en environnement Linux.
- gzip compresse un fichier unique et produit un fichier .gz, souvent plus rapide que bzip2 ou xz pour un usage courant.
- L’association tar + gzip permet de créer une archive complète d’un répertoire sous la forme .tar.gz, pratique pour les sauvegardes et les transferts.
- La décompression s’effectue soit avec gzip -d, soit avec gunzip, soit via tar pour les archives.
- Les options comme gzip -c, -k ou le choix du niveau de compression offrent un contrôle fin adapté aux scripts.
- D’autres utilitaires comme bzip2 ou pigz complètent l’arsenal pour des besoins spécifiques de performance ou de taux de compression.
gzip sous Linux en pratique : installation, principe et usages de base en ligne de commande
Dans la plupart des distributions Linux, gzip fait partie du socle minimal installé dès l’origine, au même titre que tar ou les utilitaires réseau classiques. Sur Debian ou Ubuntu, une simple vérification avec gzip –version confirme sa présence. Si la commande retourne une erreur, un sudo apt install gzip règle la question en quelques secondes. Sur Fedora, CentOS ou AlmaLinux, le paquet se récupère avec sudo dnf install gzip. L’avantage est clair : aucun dépôt obscur, uniquement les paquets de base.
Techniquement, gzip s’appuie sur l’algorithme de compression Lempel-Ziv (LZ77), robuste et assez rapide pour les usages quotidiens. Son terrain de jeu idéal : les gros fichiers texte comme les logs, les exports SQL, les fichiers CSV ou les dumps de configuration. Sur ces contenus, le gain d’espace peut dépasser les 70 %, ce qui change la donne quand une partition se remplit ou qu’un tunnel VPN a une bande passante limitée. Sur des fichiers déjà compressés (images JPEG, vidéos H.264, archives .zip), le gain devient négligeable, voire négatif, car la couche supplémentaire ajoute une légère surcouche.
La syntaxe générale reste simple : gzip [OPTIONS] fichier1 fichier2 …. Sans aucune option, la commande gzip monfichier.txt crée un fichier compressé nommé monfichier.txt.gz et supprime l’original. Ce comportement surprend parfois les débutants, surtout lors d’une première manipulation sur un répertoire sensible. Heureusement, une option comme -k permet de conserver la source : gzip -k monfichier.txt produit le .gz sans effacer le fichier texte, ce qui reste préférable en environnement de production.
Un point souvent sous-estimé concerne la compatibilité. Les fichiers .gz sont lisibles non seulement sous Linux, mais aussi sous macOS, BSD et Windows (via des outils comme 7-Zip ou les utilitaires intégrés des distributions WSL). Cette portabilité rend gzip très pratique pour échanger des archives de logs ou des exports de données entre équipes qui n’utilisent pas toutes le même système. Dans une équipe hybride, tout le monde peut récupérer un fichier compressé généré par un script Bash et l’ouvrir sans galère.
La commande sait également traiter plusieurs fichiers d’un coup : gzip fichier1.log fichier2.log fichier3.log crée autant de .gz que de sources, chacun traité individuellement. Pour un lot de journaux quotidiens, cette approche fonctionne bien, surtout si l’outil de supervision gère nativement les extensions .gz. En revanche, pour distribuer un projet complet avec sa hiérarchie de dossiers, gzip seul n’est pas l’outil adapté ; l’association avec tar prendra alors le relais pour générer une archive unique.
Un dernier point mérite d’être souligné d’entrée de jeu : gzip est pensé pour les fichiers, pas pour les répertoires. Tenter un gzip mon_dossier aboutit typiquement à un message d’erreur. Le rôle de gzip se limite à transformer un flux de données en un flux compressé. Quand un besoin inclut une structure de répertoires, tar devient l’outil qui assemble le tout, et gzip vient ensuite réduire le résultat. Ce découpage des rôles évite plus tard les malentendus dans les scripts ou les documentations internes.
Commandes élémentaires gzip et gunzip à connaître dès le départ
Pour un administrateur ou un développeur, quelques commandes couvrent déjà une bonne partie des cas quotidiens. Le trio de base se résume facilement. D’abord, la simple compression avec suppression de l’original : gzip fichier.log. Ensuite, la version qui garde la source : gzip -k fichier.log. Enfin, la décompression via gzip -d fichier.log.gz ou son équivalent lisible gunzip fichier.log.gz.
Dans un scénario concret, une petite société de e-commerce récupère chaque jour un dump de base de données nommé dump.sql. La tâche planifiée génère ensuite un dump.sql.gz par un simple gzip dump.sql, histoire de libérer de l’espace sur le disque de sauvegarde. Quand un développeur doit restaurer une journée précise, il commence par gunzip dump-2024-09-15.sql.gz puis relance sa commande d’import. Le cycle complet repose sur des ordres simples, faciles à documenter dans un wiki interne.
Un usage souvent oublié consiste à combiner gzip avec une autre commande via un pipe. Exemple classique : ls -l /var/log | gzip > liste-logs.txt.gz. Ici, aucune archive n’est créée, mais le résultat de la commande ls est compressé directement vers un fichier. Cela sert à garder un état précis d’un dossier à un instant donné, sans polluer la machine avec un gros fichier texte brut. Sur un serveur multi-sites, ce genre de trace peut aider à investiguer un incident après coup.
Autre réflexe utile : contrôler rapidement le contenu d’un fichier .gz sans passer par une extraction. Pour cela, deux solutions pratiques : zcat fichier.log.gz ou gunzip -c fichier.log.gz. Dans les deux cas, les données sont envoyées sur la sortie standard, prêtes à être filtrées par less, grep ou un autre outil. Une commande comme zcat access.log.1.gz | grep « /api/ » | less évite de multiplier les fichiers temporaires sur disque.
Enfin, gzip accepte une plage de niveaux de compression de 1 à 9. En pratique, gzip -1 sacrifie un peu de ratio pour optimiser la vitesse, tandis que gzip -9 cherche à compresser au maximum, au prix d’un CPU plus sollicité. Pour des sauvegardes quotidiennes lancées la nuit, le niveau 9 a du sens. Pour compresser à la volée un flux bien chargé sur une machine déjà limite en ressources, un simple gzip -1 restera plus raisonnable. Ce réglage donne un vrai levier pour adapter l’outil au contexte matériel.
Créer, compresser et extraire des archives tar.gz : association tar et gzip sous Linux
Dès que la question dépasse le simple fichier isolé, l’association tar + gzip s’impose. Tar sert à regrouper des fichiers et répertoires dans une archive unique, tandis que gzip prend en charge la compression. Historiquement, tar a été conçu pour la bande magnétique, ce qui explique certains choix d’options, mais son usage reste parfaitement adapté aux disques actuels. La combinaison donne les extensions bien connues .tar.gz ou parfois .tgz, interchangeables pour l’essentiel.
Pour une équipe qui doit livrer un package applicatif contenant du code, des fichiers de configuration et des scripts SQL, un seul fichier .tar.gz se transporte beaucoup plus facilement que dix répertoires dispersés. Une commande comme tar -czvf deploy-app.tar.gz app/ config/ sql/ assemble l’ensemble. L’option -c crée l’archive, -z déclenche la compression via gzip, -v affiche chaque élément traité et -f spécifie le nom final. Ce format reste de loin le plus répandu dans les distributions Linux pour distribuer du code source.
Côté extraction, la commande symétrique tar -xzvf deploy-app.tar.gz recrée la structure de répertoires dans le dossier courant. Dans un homelab, un administrateur qui teste plusieurs versions d’un même outil peut stocker ses paquets sources dans un répertoire dédié, puis les extraire un par un pour reproduire un bug. Le flux est fluide : téléchargement du .tar.gz, extraction, test, suppression du dossier, et ainsi de suite. Pas besoin d’outil graphique lourd sur la machine distante.
Une erreur fréquente chez les débutants consiste à vouloir appliquer gzip directement sur un répertoire complet, du type gzip mon_dossier. Le message d’erreur alors affiché rappelle que gzip attend un fichier ou un flux, pas une arborescence entière. La bonne séquence consiste au contraire à utiliser tar -cvf mon_dossier.tar mon_dossier/, puis gzip mon_dossier.tar. En combinant les deux étapes avec l’option -z, tar gère lui-même l’appel à gzip, ce qui simplifie les scripts.
Dans un contexte de sauvegarde, une PME qui gère plusieurs sites peut décider d’archiver chaque nuit les répertoires /etc, /var/www et /var/lib/mysql/backups d’un serveur. Une commande planifiée comme tar -czf backup-$(date +%F).tar.gz /etc /var/www /var/lib/mysql/backups produit une archive datée, simple à synchroniser vers un stockage distant. Si un incident survient, restaurer une configuration devient alors une question d’extraction ciblée de fichiers, plutôt qu’une réinstallation complète du système.
En résumé, tar et gzip se complètent parfaitement : tar rassemble et structure, gzip réduit et accélère les transferts. Confondre les rôles conduit souvent à des scripts fragiles. En prenant l’habitude de réfléchir d’abord en termes d’archive, puis en termes de compression, on garde la main sur le contenu comme sur la performance.
Comparatif rapide des options tar et gzip les plus utiles
Pour ne pas se perdre dans la jungle des options, un tableau comparatif sert de mémo et aide à choisir la bonne combinaison de paramètres selon la tâche. Les administrateurs finissent par mémoriser les plus courantes, mais disposer d’un repère visuel reste pratique, surtout pour ceux qui utilisent tar et gzip de manière occasionnelle.
| Commande / option | Rôle principal | Cas d’usage typique |
|---|---|---|
| gzip fichier | Compresser un fichier unique et supprimer l’original | Réduire la taille d’un log ou d’un dump SQL après génération |
| gzip -k fichier | Compresser en conservant le fichier source | Sauvegarde de sécurité avant envoi vers un stockage externe |
| gzip -d fichier.gz / gunzip | Décompression d’un fichier .gz | Restauration ponctuelle d’un fichier de configuration ou d’un dump |
| tar -czf archive.tar.gz dossier/ | Créer une archive compressée tar.gz | Emballer un projet complet ou un répertoire d’application |
| tar -xzf archive.tar.gz | Extraire une archive tar.gz | Installation de sources, restauration d’une sauvegarde |
Une fois ces commandes intégrées, la majorité des opérations deviennent routinières. Les scripts de backup ou de déploiement peuvent les enchaîner sans difficulté, en ajoutant au besoin des vérifications de retour de commande. Pour un lecteur qui débute avec les archives, ce tableau sert de base solide avant d’aller explorer des options plus avancées comme la sauvegarde incrémentale ou la gestion d’exclusions.
Options avancées gzip : gzip -c, niveaux de compression, concaténation de flux
Au-delà des usages basiques, gzip propose quelques options qui, une fois maîtrisées, simplifient sérieusement les scripts de sauvegarde ou les tâches d’archivage. L’option -c, par exemple, redirige la sortie compressée vers la sortie standard au lieu de modifier le fichier d’origine. Une commande comme gzip -c rapport.csv > rapport.csv.gz produit un fichier compressé sans toucher au rapport initial. Même logique pour la décompression avec gzip -c -d fichier.csv.gz > fichier.csv, qui génère un nouveau fichier tout en préservant l’archive.
Cette approche convient bien aux scripts prudents, où l’on préfère éviter toute suppression implicite. Une équipe qui gère des états comptables mensuels peut ainsi compresser les exports tout en gardant les fichiers sources en stockage froid pendant quelques jours, le temps de vérifier que la chaîne d’intégration fonctionne correctement. En cas de problème, le retour arrière ne nécessite pas de restaurer une sauvegarde complète : les fichiers originaux sont encore présents.
Les niveaux de compression, déjà évoqués, méritent un exemple plus concret. Imaginez un serveur de logs centralisé qui reçoit en continu des journaux d’applications. Le but est de compresser les fichiers de la veille sans saturer le CPU. Sur cette machine, un gzip -1 sur les logs quotidiens offre un compromis : taille réduite, charge modérée. Sur un autre serveur dédié aux sauvegardes nocturnes, où la fenêtre disponible est large et la machine peu sollicitée, un gzip -9 sur des dumps volumineux diminue sensiblement l’espace disque consommé à long terme.
Autre fonctionnalité parfois sous-estimée : la possibilité de concaténer plusieurs flux compressés dans un seul fichier. Par exemple, en enchaînant gzip -c part1.txt > total.txt.gz puis gzip -c part2.txt >> total.txt.gz, on obtient un unique fichier .gz contenant les deux séquences. Les utilitaires comme zcat ou gunzip -c lisent alors le flux combiné sans difficulté. Cette technique peut servir pour regrouper des rapports quotidiens en un seul conteneur, sans passer par tar, quand la structure de répertoire n’a pas d’importance.
En contrepartie, cette concaténation ne remplace pas une vraie archive structurée. On ne peut pas extraire « uniquement le deuxième fichier » d’un total.txt.gz comme on le ferait dans un tar. Les données sont simplement lues à la suite. Dans les environnements où il faut cibler précisément un répertoire ou un sous-ensemble de fichiers, l’archive tar.gz reste donc la bonne approche. Gzip seul gère les flux, pas la hiérarchie.
Pour finir, certains administrateurs apprécient d’afficher ou de vérifier les fichiers compressés sans en créer de copie sur disque. Un enchaînement comme gunzip -c logs-2024-10-01.gz | less ou zcat config-backup.gz | grep « Listen » permet de diagnostiquer un incident ou de comparer une configuration ancienne à la volée. Ce mode de lecture « en streaming » s’intègre particulièrement bien dans une séance de dépannage à distance, où l’espace en /tmp reste limité.
Liste des options gzip les plus utiles en script
Pour fixer les idées, un rappel synthétique des options clés aide à écrire des scripts plus fiables. Sans viser l’exhaustivité, certaines méritent clairement d’être utilisées régulièrement :
- -k pour conserver les fichiers d’origine lors de la compression, utile dans les scripts prudents.
- -c pour envoyer les données vers la sortie standard, très pratique avec les redirections et les pipes.
- -d ou gzip -d pour la décompression explicite, équivalente à gunzip.
- -1 à -9 pour choisir le compromis vitesse/ratio de compression selon la charge serveur.
- -v pour obtenir un mode verbeux, intéressant pendant les tests afin de voir ce qui est réellement traité.
Une fois que ces quelques drapeaux sont intégrés, écrire un script qui archive des logs, compresse des dumps ou prépare des exports devient nettement plus fluide. On n’est plus obligé de bricoler avec des copies intermédiaires inutiles, et la lecture du code des scripts reste lisible pour les collègues qui devront les maintenir derrière.
Lire, inspecter et manipuler des fichiers compressés sans les décompresser sur disque
Dans la réalité d’un système en production, on passe souvent plus de temps à consulter des fichiers qu’à les manipuler. Les journaux applicatifs, en particulier, peuvent représenter plusieurs gigaoctets par jour. Les compresser à l’aide de gzip allège le stockage, mais pose une autre question : comment lire ces données sans les extraire en entier à chaque fois. Heureusement, Linux propose plusieurs outils adaptés : zcat, zless, mais aussi gunzip -c combiné à des outils classiques comme grep ou awk.
Imaginons Lucie, admin système dans une PME, qui doit diagnostiquer un incident survenu un dimanche. Les logs concernés se trouvent dans access.log.3.gz. Plutôt que de décompresser le fichier, elle enchaîne un zcat access.log.3.gz | grep « 500 » | less. Elle repère immédiatement les réponses HTTP en erreur, puis affine la recherche par IP ou par URL. La machine n’a rien eu besoin d’écrire sur le disque pendant l’analyse, hormis le buffer de less, ce qui limite l’usure sur certains SSD vieillissants.
Le duo gunzip -c et less fournit le même type de confort. Une commande telle que gunzip -c error.log.2.gz | less ouvre le fichier comme s’il n’avait jamais été compressé. On peut alors naviguer, rechercher des motifs, copier-coller des extraits, tout en conservant l’archive originale intacte. Pour les environnements sensibles, cette approche évite aussi de laisser traîner des fichiers décompressés contenant des informations critiques sur une partition non chiffrée.
Pour les cas où l’on sait que l’analyse va être longue, l’utilitaire zless tombe à point. Il agit en gros comme la combinaison zcat + less, avec un comportement adapté aux fichiers .gz directement. Taper zless access.log.4.gz est souvent plus rapide à écrire que de monter manuellement un pipeline. Dans un atelier de dépannage où le temps compte, ces quelques touches gagnées finissent par faire une différence.
Une autre manipulation courante consiste à extraire une portion du fichier compressé pour la transmettre à un collègue, par exemple les 500 dernières lignes pertinentes pour un ticket de support. Ici, une commande comme zcat app.log.1.gz | tail -n 500 > extrait-incident.log produit un petit fichier texte qu’on pourra joindre à un mail ou à un système de ticketing. Cela évite de faire transiter des archives complètes de plusieurs centaines de mégaoctets pour un simple diagnostic.
En s’appropriant ces commandes de lecture, on arrête de voir gzip comme un simple écraseur de fichiers. Il devient plutôt une couche de stockage transparente, que l’on traverse facilement avec les outils habituels de la ligne de commande. Pour les équipes qui surveillent plusieurs applications en parallèle, cette capacité joue vite un rôle clé dans la réactivité.
Comparer gzip, bzip2 et les alternatives modernes : choisir l’outil selon le contexte
Gzip n’est pas seul dans le paysage de la compression sous Linux. D’autres utilitaires comme bzip2, xz ou pigz viennent occuper des niches spécifiques. Les connaître un minimum aide à prendre des décisions cohérentes, sans forcément multiplier les formats. Bzip2, par exemple, mise sur un algorithme différent, basé sur le tri de blocs Burrows-Wheeler et le codage de Huffman. En pratique, il fournit souvent un meilleur taux de compression que gzip, mais au prix d’un temps de traitement plus long.
Sur un serveur de production où la fenêtre de maintenance est courte, ce surcoût n’est pas toujours acceptable. Pour des archives froides, en revanche, qui ne seront ouvertes qu’en cas de gros incident, bzip2 garde un intérêt. La syntaxe reste proche de celle de gzip : bzip2 fichier produit un fichier .bz2, bzip2 -d fichier.bz2 le décompresse, bunzip2 jouant le même rôle que gunzip. Même logique pour bzcat, qui permet de lire un fichier compressé sans extraction préalable.
Une équipe qui gère un entrepôt de sauvegardes peut, par exemple, réserver bzip2 aux archives mensuelles de très gros volumes de données, en les stockant dans un espace moins coûteux mais moins performant. Les sauvegardes quotidiennes, elles, restent en gzip pour garantir des temps de restauration plus courts. Cette approche mixte a déjà été adoptée dans plusieurs infrastructures, où l’on sépare clairement les sauvegardes « opérationnelles » des archives « réglementaires ».
Les outils modernes comme pigz viennent ajouter une autre dimension : la compression parallèle. Pigz réimplémente l’algorithme de gzip mais exploite plusieurs cœurs CPU en même temps. Dans un monde où même un petit serveur possède 4 ou 8 cœurs, ignorer ce type d’outil revient à laisser des ressources dormir. Les fichiers produits restent compatibles avec les utilitaires gzip classiques, ce qui facilite leur adoption progressive.
Pour autant, sur un parc hétérogène, une multiplication incontrôlée de formats différents complique le support. Une règle simple peut aider : utiliser gzip comme standard de base, employer bzip2 seulement pour les volumes archivés à long terme, et réserver pigz aux scénarios très lourds où le temps de traitement est critique. Ce type de politique claire permet de garder des scripts lisibles et de limiter les surprises lors des restaurations.
En fin de compte, gzip tient sa place parce qu’il reste lisible partout et facile à intégrer dans des chaînes existantes. Même avec l’arrivée d’outils plus récents, il continue de jouer le rôle de dénominateur commun dans de nombreux environnements Linux, qu’il s’agisse de gros clusters ou de simples serveurs mutualisés.
Comment compresser un répertoire complet avec gzip sous Linux ?
gzip ne sait pas compresser directement un répertoire. Pour traiter un dossier entier, créez d’abord une archive avec tar, puis appliquez la compression. La commande classique est : tar -czf mon_dossier.tar.gz mon_dossier/. L’option -c crée l’archive, -z appelle gzip et -f indique le nom du fichier de sortie. Pour extraire ensuite le contenu, utilisez tar -xzf mon_dossier.tar.gz dans le répertoire de destination.
Quelle est la différence entre gzip et gunzip pour la décompression ?
gunzip est en pratique un alias dédié à la décompression, équivalent à la commande gzip -d. Les deux acceptent les mêmes options principales et produisent le même résultat sur un fichier .gz. Par habitude, beaucoup d’administrateurs emploient gunzip pour décompresser et gzip pour compresser, ce qui rend les scripts plus lisibles. Techniquement, les deux reposent sur le même binaire sur de nombreuses distributions Linux.
Que fait exactement l’option gzip -c dans un script Bash ?
L’option -c indique à gzip d’écrire les données compressées ou décompressées sur la sortie standard au lieu de modifier les fichiers sur disque. En pratique, gzip -c fichier.txt > fichier.txt.gz crée un fichier compressé sans supprimer l’original. De même, gzip -c -d fichier.txt.gz > fichier.txt reconstruit le fichier texte tout en conservant l’archive. Cette option est très utilisée dans les scripts de sauvegarde qui veulent éviter toute suppression implicite.
Est-ce utile de compresser un fichier déjà compressé avec gzip ?
Non, compresser un fichier déjà compressé n’apporte quasiment jamais de gain. Sur un fichier JPEG, un MP4 ou une archive zip, ajouter une couche gzip crée la plupart du temps un fichier légèrement plus gros, tout en consommant du temps CPU. La bonne pratique consiste à ne compresser que les formats naturellement redondants, principalement les fichiers texte, logs, dumps SQL ou configurations.
Comment choisir le niveau de compression gzip entre 1 et 9 ?
Les niveaux 1 à 9 de gzip représentent un compromis entre vitesse et taux de compression. Le niveau 1 privilégie la rapidité au détriment du ratio, tandis que le niveau 9 cherche à réduire le plus possible la taille, en consommant davantage de CPU. Pour des tâches interactives ou des serveurs déjà chargés, un niveau faible (1 à 3) reste raisonnable. Pour des sauvegardes nocturnes ou des archives peu consultées, un niveau élevé (7 à 9) permet d’économiser de l’espace disque à long terme.
