Backups Linux : rsync, tar et stratégie 3-2-1

À la fin de ce tutoriel, vous saurez expliquer la stratégie 3-2-1, monter un lab rsync backup (local + --dry-run), produire une archive tar gzip, appliquer une rétention simple sur des dossiers datés, puis réussir un restore test — le tout sous /tmp, sans secrets ni machine de prod.

Niveau : Intermédiaire · Temps estimé : 45–55 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-backups-rsync · Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 6)

Prérequis

• Hub Linux Admin ; chapitres disques / LVM utiles pour savoir où vivent les données
• Planification : Cron et at (à paraître) ou systemd timers pour automatiser plus tard — ici on se concentre sur la copie et la preuve de restore
• Paquets : rsync et tar (sudo apt install -y rsync tar ou sudo dnf install -y rsync tar)
• VM ou WSL jetable ; travail exclusif sous /tmp/lab-backup ; aucun secret, clé SSH de prod, ni --delete vers un chemin système

Coût estimé : 0 €. Lab 100 % local. Un second disque / volume cloud (ex. EBS) peut servir de « 2ᵉ support » conceptuel, sans remplacer un offsite réel.

Ce que nous allons construire

Stratégie 3-2-1 (concepts)
  → Jeu de données lab sous /tmp/lab-backup/src
  → rsync local (-a -v) + --dry-run avant --delete
  → Archive tar.gz + list / extract
  → Rétention : dossiers daily-YYYYMMDD (garder 7)
  → Restore test (fichier effacé → revenu)
  → Nettoyage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Backups Linux : 3-2-1, rsync backup, tar gzip, rétention, restore test ».)

Sixième chapitre de Linux Admin. Après la planification : que faire si le disque meurt ou qu’un répertoire disparaît ? Un rsync backup, une archive tar gzip et une rétention ne valent rien sans restore test. Ce lab boucle la preuve en sécurité.

Étape 1 — Stratégie 3-2-1 : ce que ça veut dire concrètement

Règle	Signification lab / VPS	Anti-exemple
3 copies	Original + backup local + copie ailleurs	Un seul dossier backup/ sur le même disque
2 supports	Disque OS + disque/USB/volume distinct	Deux dossiers sur / uniquement
1 offsite	Autre machine, objet cloud, autre région	Snapshot LVM seul sur la même VM

Un snapshot LVM ou cloud (EBS) aide au rollback — ce n’est pas un backup 3-2-1. Ici : outils de copie (rsync, tar) et discipline du restore test.

Étape 2 — Jeu de données lab

mkdir -p /tmp/lab-backup/{src/docs,src/bin,dst,archives,daily,restore}
printf 'rapport lab %sn' "$(date -Is)" > /tmp/lab-backup/src/docs/rapport.txt
printf 'config=demon' > /tmp/lab-backup/src/docs/app.conf
echo '#!/bin/sh' > /tmp/lab-backup/src/bin/hello.sh
echo 'echo hello-lab' >> /tmp/lab-backup/src/bin/hello.sh
chmod +x /tmp/lab-backup/src/bin/hello.sh
# Fichier à exclure volontairement
printf 'cache junkn' > /tmp/lab-backup/src/docs/cache.tmp
find /tmp/lab-backup/src -type f -ls

Vous aurez une arborescence mini « appli » : docs + script + un .tmp à exclure.

Étape 3 — Premier rsync backup local

rsync ne retransfère que le delta. Flags du quotidien :

Flag	Rôle
-a	Archive : récursif + permissions/temps (équivalent pratique -rlptgoD)
-v	Verbose
-z	Compression réseau (peu utile en local ; OK en SSH)
-n / --dry-run	Simule sans écrire
--delete	Supprime dans la dest ce qui n’existe plus à la source (danger)
--exclude	Ignore des motifs

# Première sync (création)
rsync -av /tmp/lab-backup/src/ /tmp/lab-backup/dst/

# Modifier la source puis re-sync (incrémental)
echo 'ligne 2' >> /tmp/lab-backup/src/docs/rapport.txt
rsync -av /tmp/lab-backup/src/ /tmp/lab-backup/dst/

# Dry-run avec exclusion + delete simulé
rsync -avn --delete --exclude='*.tmp' 
  /tmp/lab-backup/src/ /tmp/lab-backup/dst/

Le slash final compte : src/ copie le contenu ; src peut créer un sous-dossier src dans la destination. Habituez-vous à vérifier avec -n avant un vrai --delete.

# Appliquer exclude + delete après dry-run OK
rsync -av --delete --exclude='*.tmp' 
  /tmp/lab-backup/src/ /tmp/lab-backup/dst/
ls -la /tmp/lab-backup/dst/docs/
# cache.tmp ne doit PAS être présent si l'exclude a été respecté

AVERTISSEMENT : --delete sur un mauvais chemin (ex. / ou $HOME) est destructeur. En lab, gardez source et dest sous /tmp/lab-backup. En prod : dry-run, logs, puis sync.

Variante « remote » (lab-safe)

Sans second serveur, simulez une cible distante par un second répertoire, ou utilisez SSH vers localhost si sshd est dispo :

# Forme classique (à adapter : user@host:/chemin/)
# rsync -avz -e ssh /tmp/lab-backup/src/ user@backup-host:/backups/lab/
mkdir -p /tmp/lab-backup/offsite
rsync -av --delete --exclude='*.tmp' 
  /tmp/lab-backup/src/ /tmp/lab-backup/offsite/

Le second dossier simule le « 2ᵉ support » ; un vrai offsite = autre machine ou stockage objet.

Étape 4 — Archive tar gzip (snapshot portable)

tar + gzip produit un fichier unique pratique pour archivage, transfert ou rétention datée. Moins « incrémental » que rsync au quotidien, excellent pour un point-in-time.

STAMP=$(date +%Y%m%d-%H%M%S)
ARCHIVE="/tmp/lab-backup/archives/src-${STAMP}.tar.gz"

tar -czvf "$ARCHIVE" -C /tmp/lab-backup src
# -c create · -z gzip · -v verbose · -f fichier · -C change dir

# Lister sans extraire
tar -tzf "$ARCHIVE" | head

# Taille
ls -lh "$ARCHIVE"

Commande	Effet
tar -czf arch.tar.gz -C parent dossier	Crée l’archive
tar -tzf arch.tar.gz	Liste
tar -xzf arch.tar.gz -C /cible	Extrait

Sur Rocky/Alma : mêmes flags ; pigz optionnel pour compresser plus vite sur multi-cœurs (hors scope ici).

Étape 5 — Rétention : dossiers daily + garder 7 jours

Idée simple et lisible : chaque run copie vers daily-YYYYMMDD, puis on ne garde que les 7 plus récents.

cat > /tmp/lab-backup/backup-daily.sh << 'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
ROOT=/tmp/lab-backup
SRC="$ROOT/src"
DAILY="$ROOT/daily"
KEEP=7
DAY=$(date +%Y%m%d)
DEST="$DAILY/daily-$DAY"

mkdir -p "$DEST"
rsync -a --delete --exclude='*.tmp' "$SRC/" "$DEST/"
# Copie archive du jour (optionnel)
tar -czf "$ROOT/archives/daily-$DAY.tar.gz" -C "$ROOT" "daily/daily-$DAY"

# Rétention : lister daily-* triés, supprimer le trop vieux
mapfile -t dirs < <(find "$DAILY" -maxdepth 1 -type d -name 'daily-*' | sort)
count=${#dirs[@]}
if (( count > KEEP )); then
  to_remove=$(( count - KEEP ))
  for ((i=0; i<to_remove; i++)); do
    rm -rf "${dirs[$i]}"
  done
fi
echo "OK backup $DEST (keep=$KEEP, have=$(find "$DAILY" -maxdepth 1 -type d -name 'daily-*' | wc -l))"
SCRIPT
chmod +x /tmp/lab-backup/backup-daily.sh
/tmp/lab-backup/backup-daily.sh
ls /tmp/lab-backup/daily/

Pour simuler plusieurs jours en lab sans attendre :

# Crée des dossiers factices plus anciens (démo rétention)
mkdir -p /tmp/lab-backup/daily/daily-20260101 /tmp/lab-backup/daily/daily-20260102
/tmp/lab-backup/backup-daily.sh
ls /tmp/lab-backup/daily/ | sort

Automatisez ensuite via cron ou un systemd timer qui appelle ce script — sans dupliquer la leçon planification.

Étape 6 — Restore test (obligatoire)

Une sauvegarde non testée est une hypothèse. Scénario : on « perd » un fichier, on restaure depuis dst puis depuis l’archive.

# 1) Perte simulée
rm -f /tmp/lab-backup/src/docs/rapport.txt
test ! -f /tmp/lab-backup/src/docs/rapport.txt && echo 'fichier absent — OK'

# 2) Restore depuis miroir rsync
rsync -av /tmp/lab-backup/dst/docs/rapport.txt /tmp/lab-backup/src/docs/
cat /tmp/lab-backup/src/docs/rapport.txt

# 3) Restore depuis tar.gz vers un sandbox
rm -rf /tmp/lab-backup/restore/*
LATEST=$(ls -1t /tmp/lab-backup/archives/*.tar.gz | head -1)
tar -xzf "$LATEST" -C /tmp/lab-backup/restore
find /tmp/lab-backup/restore -type f
# Vérifier le contenu attendu
grep -n 'rapport|config|hello' /tmp/lab-backup/restore/src/docs/* /tmp/lab-backup/restore/src/bin/* 2>/dev/null || true

Succès : fichier de nouveau lisible ; l’extract tar montre la même arbo sous restore/.

Vérification

• [ ] rsync -av a peuplé /tmp/lab-backup/dst/
• [ ] Un --dry-run --delete a été exécuté avant un vrai --delete
• [ ] *.tmp exclus de la dest
• [ ] Au moins une archive .tar.gz listable avec tar -tzf
• [ ] Script de rétention exécuté sans erreur
• [ ] Restore test : fichier effacé puis restauré (rsync et/ou tar)

# Nettoyage lab
rm -rf /tmp/lab-backup

Dépannage

Symptôme	Cause probable	Piste
Dest contient un dossier src/ en trop	Oubli du slash final src/	Relancer avec src/ → dst/
Permission denied	Droits ou mauvais user	Lab sous /tmp ; éviter chemins système
--delete a trop effacé	Pas de dry-run / mauvaise dest	Restaurer depuis archive ; toujours -n d’abord
Archive vide / chemins bizarres	Mauvais -C	tar -tzf pour inspecter avant extract
Rétention ne coupe pas	Noms hors motif daily-*	Vérifier find … -name 'daily-*' | sort
rsync SSH refuse	Clés / sshd	Tester local d’abord ; puis -e ssh en lab

Quiz (3 questions)

1. À quoi sert surtout rsync -n / --dry-run avant un --delete ?
– A. Compresser plus fort
– B. Simuler les changements (y compris suppressions) sans écrire
– C. Formater la destination

2. Dans la stratégie 3-2-1, que signifie le « 1 » ?
– A. Une seule sauvegarde suffit
– B. Au moins une copie offsite (autre site / autre trust boundary)
– C. Un snapshot LVM local uniquement

3. Pourquoi un restore test est-il indispensable ?
– A. Parce que tar refuse de lister sans restore
– B. Pour prouver que la copie est restorable (pas seulement « job OK »)
– C. Uniquement pour les bases SQL

Réponses : 1‑B · 2‑B · 3‑B

FAQ

rsync ou tar : lequel choisir ?
Les deux. rsync pour miroir incrémental quotidien (rapide, delta). tar gzip pour un point-in-time portable, rétention datée, envoi ponctuel. Beaucoup de VPS combinent : rsync vers un disque backup + archive hebdo.

--delete est-il obligatoire ?
Non. Sans --delete, la dest accumule des fichiers obsolètes (parfois voulu). Avec --delete, la dest reflète la source — puissant et risqué. Dry-run + exclude + chemins bornés.

Un snapshot cloud remplace-t-il ce lab ?
Non. Les snapshots (EBS, etc.) aident au disaster recovery de volume ; ils ne dispensent pas d’une stratégie fichiers (rsync/tar), d’une copie offsite et d’un restore test applicatif.

Pour aller plus loin

• man rsync, man tar, man gzip
• Planifier le script : Cron et at · systemd timers
• Outils avancés (hors scope) : restic, borgbackup — déduplication et chiffrement
• Cloud : AWS EBS volumes & snapshots

Maillage série Linux Admin

← Précédent	Cron et at : planifier des tâches fiables (lot 2) · ou LVM Linux
→ Suivant	Monitoring local : load, iostat, free, df (à paraître) · hub Linux Admin
Hub	Linux Admin
Aussi	AWS EBS : volumes et snapshots · systemd timers

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Backups Linux : rsync, tar gzip et stratégie 3-2-1 (2026)
• Meta description (≤ 155) : Sauvegardez avec rsync et tar gzip, appliquez le 3-2-1 et testez un restore. Guide Linux Admin DevOps 2026.
• Focus keyphrase : rsync backup
• KW secondaires : tar gzip, rétention, restore test
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-backups-rsync-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire
• Slug : linux-backups-rsync
• Statut : HOLD — draft only (ne pas publier)

← Retour parcours Linux — Basics, Admin, Réseau & Sécurité, Shell & Automation.