tar avancé : backups, compression et restauration sélective

Tout le monde sait créer un .tar.gz. Le niveau RHCSA et LFCS exige davantage. Sauvegardes incrémentales après minuit, exclusion des /proc et des caches, transfert direct vers un serveur de backup via SSH sans créer de fichier intermédiaire, restauration d'un seul fichier dans une archive de 50 Go, ce sont ces gestes que ce guide couvre.

Ce sujet est un objectif direct RHCSA ("Archive, compress, unpack, and uncompress files using tar, star, gzip, and bzip2") et LFCS ("Archive, backup, compress, unpack, and decompress files").

Ce que vous allez apprendre

• Créer une sauvegarde complète puis des sauvegardes incrémentales avec --listed-incremental
• Exclure des répertoires ou patterns avec --exclude et --exclude-from
• Choisir entre gzip, bzip2, xz et zstd selon le compromis vitesse/taux
• Extraire un fichier précis d'une grande archive sans tout décompresser
• Transférer une archive via SSH en un pipeline sans fichier temporaire
• Vérifier l'intégrité d'une archive avant restauration

Dans quel contexte ?

Le tableau ci-dessous fait le lien entre une situation d'exploitation réelle et l'option tar qui la résout. Lisez-le de gauche à droite : la colonne de droite donne le mot-clé à retenir, pas la commande complète. Chaque technique est détaillée plus bas avec sa commande de vérification, car une sauvegarde qu'on n'a jamais relue n'est pas une sauvegarde.

Situation	Technique tar
Backup quotidien d'un répertoire de config	--listed-incremental
Sauvegarder /home sans les caches et .git	--exclude
Archiver un gros répertoire sur un serveur limité en espace	xz ou zstd
Restaurer un seul fichier /etc/nginx.conf depuis une archive	extraction sélective
Envoyer un backup vers un serveur distant sans monter de NFS	tar + ssh pipeline
Vérifier qu'une archive de sauvegarde est lisible	tar -tvf ou --compare

Glissez pour voir

Prérequis

Ce guide suppose la maîtrise du guide Archiver et compresser, commandes de base tar, gzip, zip.

Rappel express : les options fondamentales

Une seule règle de syntaxe évite la majorité des erreurs de débutant : l'option -f doit être la dernière lettre du groupe, parce que c'est elle qui consomme l'argument suivant comme nom d'archive. Taper tar -fcz archive.tar.gz fait lire cz comme nom de fichier, et tar répond You must specify one of the '-Acdtrux' … options. Les autres lettres se répartissent en deux familles : le mode d'action (-c, -x, -t), dont une seule est autorisée par commande, et le codec de compression (-z, -j, -J, --zstd).

# Créer une archive compressée gzip
tar -czf archive.tar.gz /repertoire/

# Lister le contenu
tar -tvf archive.tar.gz

# Extraire
tar -xzf archive.tar.gz -C /destination/

-c créer · -x extraire · -t lister · -v verbose · -f fichier · -z gzip · -j bzip2 · -J xz · --zstd zstd

---

Sauvegardes incrémentales avec --listed-incremental

Une sauvegarde complète archive tout. Une sauvegarde incrémentale n'archive que les fichiers modifiés ou créés depuis la dernière sauvegarde. C'est la brique de base d'un plan de sauvegarde, pas le plan lui-même : ce que tar ne saura jamais faire pour vous est traité plus bas, dans la section qui pose ses limites.

tar gère cela nativement via un fichier snapshot (.snar) qui enregistre l'état du répertoire au moment du backup.

Étape 1, Backup complet (niveau 0)

Le premier appel a deux effets simultanés : il produit l'archive complète et il crée le fichier snapshot. Placez ce .snar hors du répertoire sauvegardé, sinon il finit dans sa propre archive et change à chaque exécution. Le répertoire /var/backup/ doit exister au préalable : tar ne crée pas l'arborescence du snapshot et s'arrête sur Cannot open.

tar --listed-incremental=/var/backup/home.snar \
    -czf /var/backup/home-full-$(date +%F).tar.gz \
    /home/bob/

• --listed-incremental=/var/backup/home.snar : crée ou met à jour le fichier snapshot
• Au premier appel, le .snar n'existe pas → tar archive tout

Étape 2, Backup incrémental (niveau 1+)

tar --listed-incremental=/var/backup/home.snar \
    -czf /var/backup/home-incr-$(date +%F-%H%M).tar.gz \
    /home/bob/

La deuxième fois, tar lit le snapshot et n'inclut que les fichiers modifiés depuis la dernière exécution.

Règle d'or du backup incrémental

Pour reprendre une chaîne incrémentale depuis zéro, ne réutilisez pas le même .snar, supprimez-le ou renommez-le. Sans cela, tar considérera que tout est déjà sauvegardé.

Vérification

# Compter les fichiers dans chaque backup
tar -tvf /var/backup/home-full-2026-04-09.tar.gz | wc -l
tar -tvf /var/backup/home-incr-2026-04-09-0200.tar.gz | wc -l

Le backup incrémental doit contenir beaucoup moins de fichiers que le backup complet. Ne vous étonnez pas d'y retrouver tous les répertoires de l'arborescence, même ceux qui n'ont pas bougé : tar les réinscrit à chaque niveau pour pouvoir rejouer les suppressions à la restauration. Ce sont les lignes commençant par -rw qu'il faut compter, pas celles en drwx.

Restauration d'une chaîne incrémentale

La restauration se fait dans l'ordre : backup complet, puis chaque incrémental dans l'ordre chronologique.

# 1. Extraire le backup complet
tar --listed-incremental=/dev/null \
    -xzf /var/backup/home-full-2026-04-09.tar.gz \
    -C /restore/

# 2. Appliquer l'incrémental du lendemain
tar --listed-incremental=/dev/null \
    -xzf /var/backup/home-incr-2026-04-10-0200.tar.gz \
    -C /restore/

--listed-incremental=/dev/null lors de l'extraction indique à tar d'appliquer les suppressions enregistrées dans le snapshot (fichiers effacés entre deux backups).

---

Exclure des fichiers et répertoires

Sauvegarder /home en incluant les caches de navigateur, les .git et les répertoires node_modules est un gaspillage. tar offre deux mécanismes d'exclusion.

--exclude, exclure un pattern

Un --exclude mal placé ne sert à rien : l'option doit apparaître avant le chemin à archiver sur la ligne de commande, faute de quoi GNU tar l'applique seulement aux arguments qui la suivent. Pensez aussi à quoter chaque motif, sinon le shell l'expanse avant que tar le reçoive et l'exclusion ne portera que sur les fichiers présents dans le répertoire courant.

tar -czf /var/backup/home-clean.tar.gz \
    --exclude='.cache' \
    --exclude='.local/share/Trash' \
    --exclude='**/node_modules' \
    --exclude='**/.git' \
    /home/bob/

• Les patterns sont relatifs au répertoire archivé
• On peut cumuler plusieurs --exclude
• Les ** (globbing) fonctionnent avec GNU tar

--exclude-from, fichier de liste d'exclusions

Au-delà de trois ou quatre motifs, la ligne de commande devient illisible et surtout impossible à versionner. Un fichier d'exclusions se relit et se partage entre plusieurs scripts de sauvegarde. Deux contraintes de format : un motif par ligne, sans guillemets (c'est tar qui lit le fichier, pas le shell), et aucun commentaire, car GNU tar traite une ligne commençant par # comme un motif ordinaire qui ne correspondra à rien.

Contenu de /etc/backup/exclusions.txt :

.cache
.local/share/Trash
**/node_modules
**/.git
**/tmp
*.log
*.pid
/proc
/sys
/dev
/run

tar -czf /var/backup/systeme.tar.gz \
    --exclude-from=/etc/backup/exclusions.txt \
    /

Référence croisée : sauvegarde avec rsync

Pour les synchronisations continues vers un serveur distant, rsync est souvent plus adapté. tar excelle pour les archives ponctuelles et les snapshots.

---

Choisir entre gzip, bzip2, xz et zstd

Le choix d'un codec est un arbitrage entre le temps CPU passé à compresser et l'espace disque économisé. Deux colonnes du tableau comptent vraiment : la vitesse, qui détermine si la sauvegarde tient dans sa fenêtre nocturne, et le taux, qui décide de la place occupée sur le serveur de backup. La compression n'est pas intégrée à tar : l'option délègue à un programme externe (gzip, bzip2, xz, zstd). Le codec doit donc être installé sur la machine qui relit l'archive, pas seulement sur celle qui la crée. Une sauvegarde en .tar.zst illisible sur le serveur de restauration est un incident classique.

Codec	Option tar	Extension	Taux	Vitesse	Quand l'utiliser
gzip	-z	.tar.gz	Moyen	Très rapide	Par défaut, logs, configs, transferts fréquents
bzip2	-j	.tar.bz2	Bon	Lent	Archivage longue durée, espace prioritaire
xz	-J	.tar.xz	Excellent	Très lent	Distributions, sources, taille minimale
zstd	--zstd	.tar.zst	Très bon	Rapide	Backups modernes, meilleur ratio vitesse/taux

Glissez pour voir

Exemples concrets

Repérez l'extension utilisée dans chaque commande : elle n'a aucun effet technique (tar détecte seul le format à la lecture), mais elle documente le codec pour l'administrateur qui trouvera le fichier dans six mois. Notez aussi que --zstd est une option longue et ne se groupe pas avec les autres lettres : on écrit tar --zstd -cf, jamais tar -c--zstdf.

# gzip : usage quotidien (défaut)
tar -czf logs-$(date +%F).tar.gz /var/log/nginx/

# bzip2 : archivage longue durée
tar -cjf archives-2025.tar.bz2 /var/archive/2025/

# xz : distribution de sources
tar -cJf mon-projet-1.0.tar.xz ./mon-projet/

# zstd : backup rapide avec bon taux
tar --zstd -cf backup-$(date +%F).tar.zst /home/

Vérifier le taux de compression effectif

Les taux annoncés dans le tableau sont des ordres de grandeur : le gain réel dépend entièrement de vos données. Des logs texte se compressent à plus de 90 %, des images JPEG ou des archives déjà compressées ne gagnent rien et coûtent du temps CPU pour rien. Mesurez sur votre jeu de données avant de figer un codec dans un script de production, en comparant la taille des archives à celle de la source.

ls -lh /var/backup/home-full-2026-04-09.tar.{gz,zst,bz2,xz}
du -sh /home/bob/

zstd sur les systèmes anciens

zstd est disponible depuis GNU tar 1.31. Vérifiez la version avant d'utiliser ce format dans des scripts de production : tar --version.

---

Que préserve tar des métadonnées, et que perd-il en silence ?

GNU tar ne préserve par défaut ni les ACL, ni les attributs étendus, ni les contextes SELinux, et l'option qui les active doit être passée des deux côtés, à la création et à l'extraction. C'est le piège qui transforme une restauration réussie en incident : les fichiers sont là, les droits fins ont disparu, et personne ne s'en aperçoit avant que le service refuse de démarrer.

Mesures relevées le 20 septembre 2026 avec GNU tar 1.35 sur AlmaLinux 10.2, système de fichiers ext4 dédié monté avec acl et user_xattr :

Métadonnée	Par défaut	Option nécessaire	Ce que la mesure donne
Permissions et dates	préservées	aucune	rien à faire
Liens physiques	préservés	aucune	même inode après restauration
ACL POSIX	perdues	--acls aux deux bouts	u:nobody:rwx disparaît
Attributs étendus	perdus	--xattrs aux deux bouts	user.origine disparaît
Contextes SELinux	perdus	--selinux aux deux bouts	httpd_sys_content_t retombe sur le défaut du répertoire
Propriétaire (UID/GID)	dépend de qui extrait	extraction par root	1500:1600 devient l'UID de l'extracteur
Fichiers creux	non détectés	--sparse	513 Mo contre 10 Ko

Glissez pour voir

Pourquoi l'option se passe deux fois

Le point contre-intuitif tient en une phrase : une archive créée avec --acls mais extraite sans perd quand même ses ACL. L'archive contient bien l'information, tar refuse simplement de la réappliquer si on ne le lui demande pas. La mesure est sans appel :

# Archive créée AVEC l'option, extraite SANS : l'ACL est perdue
tar --acls -cf sauvegarde.tar dossier/
tar -xf sauvegarde.tar -C /restore/
getfacl -c /restore/dossier/fichier | grep '^user:nobody'   # ne renvoie rien

# Option aux deux bouts : l'ACL revient
tar --acls -xf sauvegarde.tar -C /restore/
getfacl -c /restore/dossier/fichier | grep '^user:nobody'   # user:nobody:rwx

La même règle vaut pour --xattrs et pour --selinux. Écrivez donc ces options dans vos scripts de sauvegarde et dans vos procédures de restauration, qui sont rarement les mêmes fichiers et divergent avec le temps.

Sur RHEL, un contexte SELinux perdu casse le service

Le cas SELinux mérite son paragraphe parce que l'échec y est différé et silencieux. Mesuré sur la même machine, en mode enforcing, avec un fichier volontairement étiqueté httpd_sys_content_t :

Archive créée	Extraction	Contexte du fichier restauré
--selinux	sans l'option	var_t (le défaut du répertoire)
--selinux	--selinux	httpd_sys_content_t préservé
sans l'option	--selinux	var_t : l'information n'est pas dans l'archive

Glissez pour voir

La troisième ligne est celle qui piège : passer --selinux à la restauration ne rattrape rien si l'archive ne le portait pas. Les fichiers sont restaurés, les droits sont bons, et le serveur web répond 403 parce qu'il n'a pas le droit de lire un fichier étiqueté var_t.

La parade de secours existe et vaut d'être connue : restorecon -Rv réapplique les contextes attendus par la politique, ce qui suffit quand l'arborescence restaurée est à son emplacement habituel. Cela ne remplace pas --selinux pour les fichiers dont le contexte a été posé à la main.

Le propriétaire dépend de qui extrait, pas de l'archive

Un fichier appartenant à 1500:1600 dans l'archive ne retrouve son propriétaire que si l'extraction est faite par root. Extrait par un compte ordinaire, il prend l'UID de celui qui extrait, silencieusement, parce qu'un utilisateur non privilégié ne peut pas donner un fichier à quelqu'un d'autre.

source                  : uid=1500 gid=1600
extrait par un compte   : uid=1001 gid=1001      <- remplacé
extrait par root        : uid=1500 gid=1600      <- préservé

Restaurer une arborescence système sans être root produit donc une arborescence dont tous les fichiers appartiennent à l'opérateur. C'est irrattrapable sans la liste des propriétaires d'origine, que seule l'archive porte encore.

Les fichiers creux, le gain le plus spectaculaire

Un fichier creux est un fichier dont les zones vides ne consomment aucun bloc disque : images de machines virtuelles, fichiers d'échange, bases préallouées. Sans --sparse, tar écrit consciencieusement tous les zéros dans l'archive.

truncate -s 512M disque.img      # 512 Mo apparents, 0 octet occupé

tar -cf sans.tar disque.img      # archive de 513 Mo
tar --sparse -cf avec.tar disque.img   # archive de 10 Ko

511 Mio économisés sur un seul fichier vide. Sur un serveur portant quelques images de machines virtuelles, l'oubli de --sparse fait la différence entre une sauvegarde qui tient sur son volume et une qui le remplit.

Une commande de sauvegarde complète

Rassemblées, les options qui préservent réellement un système donnent une commande plus longue que celle qu'on écrit d'instinct :

sudo tar --acls --xattrs --selinux --sparse --one-file-system \
    --listed-incremental=/var/backup/systeme.snar \
    -czf /var/backup/systeme-$(date +%F).tar.gz /etc /srv

Et sa restauration, qui doit répéter les mêmes options :

sudo tar --acls --xattrs --selinux --listed-incremental=/dev/null \
    -xzf /var/backup/systeme-2026-09-20.tar.gz -C /restore/

Sur une distribution sans SELinux, --selinux est accepté et sans effet : la commande reste portable entre Debian et RHEL.

---

Extraction sélective, un seul fichier d'une grande archive

Inutile de décompresser 50 Go pour récupérer un seul fichier de configuration.

Lister le contenu pour trouver le chemin exact

L'extraction sélective échoue presque toujours pour la même raison : le chemin demandé ne correspond pas à celui stocké dans l'archive. Commencez donc par lister, puis copiez-collez le chemin affiché. Sur une archive volumineuse, cette lecture décompresse quand même tout le flux ; comptez plusieurs minutes sur plusieurs dizaines de gigaoctets, et filtrez avec grep plutôt que de faire défiler la sortie.

tar -tvf /var/backup/home-full-2026-04-09.tar.gz | grep nginx.conf

-rw-r--r-- bob/bob  2847 2026-04-08 22:13 home/bob/.config/nginx/nginx.conf

Extraire un fichier précis

tar -xzf /var/backup/home-full-2026-04-09.tar.gz \
    -C /tmp/restore/ \
    home/bob/.config/nginx/nginx.conf

Le chemin doit correspondre exactement à ce que tar -tvf affiche (sans / initial dans la plupart des cas).

Extraire un répertoire complet

Le même principe s'applique à un répertoire : passez son chemin sans le / initial et tar restaure toute la sous-arborescence, permissions et dates comprises. Le répertoire de destination passé à -C doit exister, tar ne le crée pas et s'arrête sur Cannot open. L'arborescence complète du chemin est recréée sous cette destination.

tar -xzf /var/backup/home-full-2026-04-09.tar.gz \
    -C /tmp/restore/ \
    home/bob/.config/

Extraire vers un répertoire différent

tar -xzf /var/backup/home-full-2026-04-09.tar.gz \
    --strip-components=2 \
    -C /tmp/restore/ \
    home/bob/.config/

--strip-components=2 supprime les 2 premiers niveaux du chemin dans l'archive (home/bob/) pour extraire directement dans /tmp/restore/.

---

Transfert via SSH, sans fichier intermédiaire

L'un des gestes les plus élégants de tar : créer une archive sur la sortie standard, la passer directement dans SSH, et l'extraire sur le serveur distant, tout en un seul pipeline.

Envoyer vers un serveur distant

Le - qui suit -czf remplace le nom de fichier par la sortie standard : tar n'écrit rien sur le disque local, le flux part directement dans le tube vers ssh. Attention à l'endroit où $(date +%F) est évalué : entre guillemets doubles, la substitution a lieu sur la machine locale avant l'envoi, ce qui est généralement le comportement voulu pour dater l'archive selon l'horloge de la source.

# Archiver localement, extraire sur le serveur distant
tar -czf - /home/bob/projets/ | ssh bob@serveur-backup "cat > /backup/projets-$(date +%F).tar.gz"

Copier une arborescence en préservant les permissions

# Archiver et extraire immédiatement sur le serveur distant
tar -czf - /etc/ | ssh bob@serveur-backup "tar -xzf - -C /backup/etc/"

Ce pipeline préserve les permissions, les UID, les GID, les liens symboliques et les dates, ce que scp -r ne fait pas toujours correctement.

Récupérer une archive depuis un serveur distant

Le sens inverse fonctionne aussi : c'est tar qui s'exécute à distance et écrit sur sa sortie standard, que ssh rapatrie et qu'une redirection locale enregistre. Utile quand le serveur source manque d'espace disque pour héberger l'archive intermédiaire. Vérifiez toujours l'archive reçue avec tar -tvf avant de supprimer quoi que ce soit à la source : une coupure réseau produit un fichier tronqué qui a l'air normal jusqu'à ce qu'on tente de le lire.

ssh bob@serveur-source "tar -czf - /var/www/html/" > /backup/html-$(date +%F).tar.gz

Quand préférer ce pattern ?

Cette technique est idéale pour les migrations et les backups ponctuels sans espace disque intermédiaire. Pour les synchronisations régulières, rsync est plus efficace (ne transfère que les différences).

---

Vérifier l'intégrité d'une archive

Un backup inutilisable est pire qu'aucun backup. Toujours vérifier avant de se retrouver dans une situation d'urgence. Gardez en tête la limite du format : une archive tar ne porte aucune somme de contrôle globale. Une lecture complète détecte une troncature au milieu d'un fichier, mais une archive coupée pile sur une frontière de bloc peut se lister sans erreur. Pour une garantie réelle, stockez un sha256sum de l'archive à côté d'elle.

Lister le contenu (test de lecture)

tar -tvf /var/backup/home-full-2026-04-09.tar.gz > /dev/null && echo "Archive OK"

Si tar renvoie un code de retour non-nul, l'archive est corrompue.

Récupérer le bon code de retour dans un script

Le piège se cache dans le tube : $? renvoie le code du dernier élément du pipeline, donc celui de tail, qui réussit même quand tar a échoué avant lui. Un script de supervision écrit ainsi déclare toutes ses archives valides. Deux parades en bash : tester tar seul, ou lire ${PIPESTATUS[0]} immédiatement après le pipeline.

# Mauvais : $? contient le code de tail, toujours 0
tar -tvf /var/backup/home-full-2026-04-09.tar.gz | tail -5
echo "Code retour : $?"

# Correct : on lit le code de tar lui-même
tar -tvf /var/backup/home-full-2026-04-09.tar.gz | tail -5
echo "Code retour tar : ${PIPESTATUS[0]}"

Une archive tronquée, par exemple parce que le disque s'est rempli pendant la sauvegarde, se signale par tar: Unexpected EOF in archive ou par une erreur remontée du décompresseur, et tar sort avec le code 2.

Comparer avec la source (si elle existe encore)

tar --compare -f sauvegarde.tar.gz -C / 2>&1 | head -20

Cette commande compare le contenu de l'archive existante avec le système de fichiers actuel, et affiche les différences (taille, date, contenu). L'option -C / indique depuis quelle racine comparer les chemins de l'archive.

`--compare` ne se combine pas avec `-c`

--compare (ou -d) travaille sur une archive existante, alors que -c sert à en créer une : les deux s'excluent. Écrire tar --compare -czf … provoque, sur GNU tar 1.35, l'erreur You may not specify more than one '-Acdtrux', '--delete' or '--test-label' option.

---

tar suffit-il comme solution de sauvegarde ?

Non, et la nuance compte : tar sait produire une archive de sauvegarde, il ne constitue pas à lui seul une stratégie de sauvegarde. Ce guide vous a montré comment fabriquer une archive fidèle ; ce qui suit dit ce que l'outil ne fera jamais pour vous, et qu'il faut donc placer autour de lui.

Ce que tar ne fait pas	La conséquence concrète
Aucune déduplication	dix sauvegardes complètes occupent dix fois la place, même si rien n'a changé
Aucun chiffrement natif	une archive volée se lit telle quelle. Il faut chaîner gpg ou age
Aucune rétention, aucun catalogue	c'est à vous d'écrire la purge, et de savoir quelle archive contient quoi
Aucune cohérence applicative	une base de données archivée à chaud donne une copie incohérente, pas une sauvegarde
Aucune gestion des fichiers ouverts	un fichier modifié pendant l'archivage est capturé dans un état intermédiaire
Aucune somme de contrôle globale	une archive tronquée sur une frontière de bloc se liste sans erreur

Glissez pour voir

Le point le plus dangereux est le quatrième, parce qu'il ne produit aucun message d'erreur. tar -czf base.tar.gz /var/lib/postgresql/ réussit toujours, et l'archive produite est inutilisable : il fallait un pg_dump ou un arrêt du service. Une sauvegarde qui réussit n'est pas une sauvegarde qui restaure.

tar produit une archive, pas une stratégie

Une stratégie de sauvegarde répond à trois questions auxquelles tar ne répond pas : combien de temps je garde, où je garde, et quand ai-je vérifié que je sais restaurer. Le cadre usuel est la règle 3-2-1 :

• 3 copies des données, l'originale comprise ;
• sur 2 supports différents ;
• dont 1 hors site, ou du moins hors du même incident.

Et une quatrième condition, qui est celle qu'on oublie : une restauration réellement testée, sur une machine vide, à intervalle régulier. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Au-delà de quelques serveurs, des outils dédiés apportent la déduplication, le chiffrement et le catalogue que tar n'a pas : restic, borg, bacula. tar garde tout son intérêt pour les archives ponctuelles, les migrations et les snapshots avant intervention.

---

Dépannage courant

Les erreurs de tar sont laconiques et la cause réelle est rarement celle qu'annonce le message. Avant de chercher plus loin, distinguez trois familles : un problème d'archive (corrompue, tronquée), un problème d'environnement (codec absent, disque plein) et un problème de chemin (snapshot égaré, / initial retiré). Le tableau ci-dessous associe le message affiché à la famille concernée et à l'action corrective.

Symptôme	Cause probable	Solution
tar: Error is not recoverable: exiting now	Archive corrompue ou tronquée	Vérifier le fichier source, retester avec -tvf
tar: Removing leading '/' from member names	Chemins absolus dans l'archive	Normal avec -C / à l'extraction. Utiliser --strip-components si besoin
Backup incrémental archive tout malgré le .snar	Fichier .snar absent ou corrompu	Supprimer le .snar et refaire un backup complet
Un fichier modifié juste après la sauvegarde manque dans l'incrémentale	Sa date de changement tombe dans le même tic d'horloge que l'écriture du snapshot	Espacer les niveaux. Mesuré le 20 septembre 2026 sur ext4 : modifié dans le même tic, le fichier est manqué ; modifié 1 ms plus tard, il est pris. Sans effet sur une sauvegarde nocturne, mais fatal dans un script qui enchaîne les deux niveaux
Les ACL ou le contexte SELinux ont disparu après restauration	L'option --acls, --xattrs ou --selinux manquait à l'extraction	Rejouer l'extraction avec les mêmes options qu'à la création. restorecon -Rv rattrape les contextes standard, pas ceux posés à la main
xz: Cannot exec: No such file or directory	xz non installé	apt install xz-utils ou dnf install xz
zstd: command not found	zstd non installé	apt install zstd ou dnf install zstd
Extraction coupée à mi-chemin	Espace disque insuffisant	df -h pour vérifier, libérer de l'espace

Glissez pour voir

---

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• --listed-incremental est le mécanisme natif de tar pour les backups incrémentaux : backup complet au premier appel, incrémental ensuite.
• À la restauration, --listed-incremental=/dev/null est ce qui rejoue les suppressions. Sans lui, un fichier effacé entre deux sauvegardes réapparaît.
• --exclude et --exclude-from évitent d'archiver les caches, .git et node_modules.
• zstd est le meilleur choix pour les backups modernes : taux comparable à bzip2, vitesse proche de gzip.
• --acls et --xattrs se passent aux deux bouts, à la création et à l'extraction. Une archive créée avec l'option et extraite sans perd quand même ses droits fins.
• --sparse change l'ordre de grandeur sur les images disque : 513 Mo contre 10 Ko sur un fichier creux de 512 Mio.
• Le propriétaire n'est restauré que si l'extraction est faite par root ; sinon tout appartient à l'opérateur.
• L'extraction sélective (tar -xzf archive.tar.gz chemin/dans/archive) évite de tout décompresser.
• Le pipeline tar | ssh transfère une arborescence complète sans fichier temporaire et préserve les permissions.
• Toujours tester une archive avec tar -tvf avant d'en avoir besoin, et tester une restauration avant d'en dépendre.

Pour aller plus loin

• Synchroniser avec rsync : Synchronisation intelligente (delta) vers un serveur distant, l'outil complémentaire de tar pour les backups continus.
• Vérifier l'intégrité d'un fichier : sha256sum, md5sum et signatures GPG pour s'assurer qu'une archive n'a pas été altérée.
• Copier avec SCP : Copie rapide one-shot via SSH, l'alternative simple à tar+ssh pour les fichiers individuels.
• Référence tar : Toutes les options tar classées par usage, cheatsheet complète.

×

📖 Voir la documentation →