Sauvegarde et restauration Linux avec des exemples pratiques

Intro

Une sauvegarde n’est pas qu’une copie de fichiers ; c’est la capacité prouvée à restaurer exactement les données, la configuration et l’état requis dans un délai défini. Des objectifs de reprise différents exigent des méthodes différentes :

• RPO (Recovery Point Objective — point de reprise maximal toléré) : combien de données peut-on se permettre de perdre.
• RTO (Recovery Time Objective — délai de remise en service) : en combien de temps doit-on être opérationnel.

En pratique, vous combinerez souvent :

• Sauvegardes de fichiers : données utilisateurs, scripts, répertoires de projets.
• Sauvegardes système : configuration de l’OS, services, listes de paquets, clés.
• Snapshots : états rapides d’un système de fichiers (Btrfs/LVM/ZFS/Timeshift) servant à créer des sauvegardes cohérentes, pas comme seule copie.
• Image disque : clones au niveau des secteurs pour la reconstruction bare metal.
• Sauvegardes applicatives : répertoires de données d’applis, secrets, manifestes.
• Sauvegardes de bases de données : exports logiques ou snapshots natifs/cohérents du moteur.

Une sauvegarde jamais restaurée est une sauvegarde non vérifiée.

Un cadre rapide pour choisir sa méthode

Répondez à ces questions pour fixer votre approche :

1. Que devez-vous restaurer ? Uniquement des fichiers, un système complet, ou du bare metal.
2. Quelle perte maximale de données est acceptable (RPO) ? Minutes, heures, jours.
3. À quelle vitesse faut-il revenir en service (RTO) ? Minutes, heures.
4. Où stockerez-vous les copies ? Local, distant, hors site, immuable.
5. Comment testerez-vous les restaurations et surveillerez-vous les échecs ?

Mise en correspondance des besoins courants avec des outils :

• Petits serveurs et portables : rsync ou Timeshift pour le système ; Restic pour le hors site chiffré.
• Serveurs à données changeantes : Restic ou Borg pour des sauvegardes dédupliquées et versionnées.
• Bases de données avec RPO strict : exports natifs + archivage des binlogs/WAL ; éventuellement assistés par snapshot.
• Récupération bare metal : Clonezilla/Rear, plus sauvegardes de configs et de données pour l’actualité.

Suivez la règle 3-2-1 : 3 copies, 2 types de supports, 1 hors site. Utilisez un stockage immuable quand c’est possible.

Planifier RPO et RTO

Quoi sauvegarder (et quoi exclure)

À inclure :

• /home : données utilisateurs, configs SSH, GPG, dotfiles.
• /etc : configuration système, réseau, fstab, DNS, sudoers.
• Clés et secrets : /etc/ssh, ~/.ssh utilisateur, secrets applicatifs (source de vérité).
• systemd : /etc/systemd/system et surcharges dans /etc/systemd/system/*.d/.
• Cron : /var/spool/cron, /etc/cron.*, crontabs utilisateur.
• Docker/conteneurs : fichiers compose, .env, liste d’images épinglées, volumes.
• Kubernetes : manifestes/Helm charts ; sauvegarde etcd si autogéré.
• Bases de données : exports logiques cohérents ou snapshots natifs du moteur.
• Gestion de config : dépôts Ansible/Puppet/Chef.
• Listes de paquets : dpkg --get-selections ou rpm -qa.
• Journaux (sélectif) : conformité/forensique.

À exclure en général : /proc, /sys, /dev, /run, /tmp, caches, conteneurs éphémères, artefacts de build. Préférez réinstaller les paquets plutôt que copier les binaires de /usr.

Créer des sauvegardes : commandes sûres et répétables

Les exemples ci-dessous préservent permissions, ACL et xattrs quand pertinent. Faites des essais à blanc et journalisez les sorties.

Fichiers et permissions avec rsync

Options clés : -a (archive), -A (ACL), -X (xattrs), --numeric-ids, --delete (répliquer les suppressions).

• Miroir local avec ACL/xattrs et essai à blanc :

# Aperçu
rsync -aAXn --delete /srv/data/ /backups/data/
# Exécuter quand l’aperçu est validé
rsync -aAX --delete --info=stats2 --human-readable /srv/data/ /backups/data/

AVERTISSEMENT : --delete supprime au destinataire les fichiers absents de la source. Vérifiez avec --dry-run avant d’exécuter.

• Envoi distant via SSH avec IDs stables :

rsync -aAX --numeric-ids --delete -e "ssh -i /root/.ssh/backup" \
  /etc/ /var/www/ /home/ backup@backup-host:/tank/host1/

• Rotation façon snapshot avec liens matériels (hard links) :

# Créer le snapshot le plus récent en se basant sur le précédent
rsync -aAX --delete --link-dest=/backups/daily.1/ /srv/ /backups/daily.0/
# Faire pointer la rotation à moindre coût (liens matériels)
cp -al /backups/daily.{0,1}

Conserver explicitement ACL et attributs étendus

# Enregistrer ACL et xattrs (en plus de rsync/tar qui les transportent aussi)
getfacl -R /etc > /backups/metadata/etc.acl
getfattr -R -d /etc > /backups/metadata/etc.xattr

Instantané de configuration de /etc et liste de paquets

# Archiver /etc avec ACL et xattrs
sudo tar --acls --xattrs -cpf /backups/system/etc-$(date +%F).tar -C / etc
# Liste des paquets Debian/Ubuntu
dpkg --get-selections > /backups/system/dpkg-selections-$(date +%F).txt
# Liste RHEL/Rocky/Alma
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' > /backups/system/rpm-list-$(date +%F).txt
# Unités systemd et timers
sudo systemctl list-unit-files --type=service --all > /backups/system/systemd-services.txt
sudo systemctl list-timers --all > /backups/system/systemd-timers.txt

Sauvegardes chiffrées hors site avec Restic

export RESTIC_REPOSITORY="s3:https://s3.example.com/my-bucket/host1"
export RESTIC_PASSWORD="change-me"
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
restic init
# Créer un snapshot
restic backup /etc /var/www /home --exclude-file=/root/restic-excludes.txt
# Lister et vérifier
restic snapshots
restic check
# Rétention
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
# Restaurer vers un répertoire temporaire sécurisé (recommandé)
restic restore latest --target /restore-test

AVERTISSEMENT : restaurer directement dans / (racine) peut écraser des fichiers en production. Préférez restaurer dans /restore-test puis recopiez sélectivement après validation.

Archives dédupliquées avec Borg

export BORG_REPO=ssh://backup@backup-host:22/./repos/host1
export BORG_PASSPHRASE="change-me"
borg init --encryption=repokey $BORG_REPO
borg create --stats --progress ::{hostname}-{now:%F-%H%M} /etc /var/www /home
borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg check --verify-data
# Parcourir ou extraire
borg mount ::2024-07-01 /mnt/borg

Snapshots pour capturer des états cohérents

Utilisez des snapshots pour figer des données très changeantes, puis sauvegardez la vue figée.

# Exemple LVM (les noms de VG/LV varient)
sudo lvcreate -L 2G -s -n data_snap /dev/vg/data
# Monter le snapshot en lecture seule, le sauvegarder, puis le supprimer
sudo mount -o ro /dev/vg/data_snap /mnt/datasnap
rsync -aAX /mnt/datasnap/ /backups/data/
sudo umount /mnt/datasnap && sudo lvremove -f /dev/vg/data_snap

AVERTISSEMENT : assurez-vous que le snapshot est assez grand pour absorber les changements pendant la sauvegarde, sinon il deviendra invalide.

Image disque (pour bare metal)

• Préférez Clonezilla/Partclone pour une image hors ligne qui ignore l’espace libre.
• Utilisez dd uniquement si vous devez capturer précisément les layouts/bootloaders.

AVERTISSEMENT : dd peut détruire des données si la source/la destination sont erronées. Vérifiez les noms de périphériques et n’imager jamais un système de fichiers actif sans snapshot.

Sauvegardes de bases de données (schémas sûrs)

Copier des fichiers de base de données « vivants » est dangereux sauf via snapshots adaptés au moteur. Préférez des exports logiques ou des outils natifs, et testez la restauration en isolation.

MySQL/MariaDB

# Export cohérent sans verrouiller les tables (InnoDB)
mysqldump --single-transaction --routines --triggers --events \
  -u backup -p mydb | gzip > /backups/mysql/mydb-$(date +%F).sql.gz

# Test de restauration dans une base isolée
zcat /backups/mysql/mydb-2024-07-01.sql.gz | mysql -u restore -p mydb_restore

Prérequis : compte avec droits minimaux d’export ; rétention suffisante des binlogs si vous visez une reprise point-dans-le-temps.

PostgreSQL

# Export logique au format custom
sudo -u postgres pg_dump -Fc mydb > /backups/pg/mydb-$(date +%F).dump
# Test de restauration dans une nouvelle base
dropdb --if-exists mydb_restore && createdb mydb_restore
sudo -u postgres pg_restore -d mydb_restore /backups/pg/mydb-2024-07-01.dump
# Sauvegarde physique de base (assurez-vous que wal_level=replica)
sudo -u postgres pg_basebackup -D /backups/pg/base -Ft -z -P

MongoDB et Redis

mongodump --db mydb --archive=/backups/mongo/mydb-$(date +%F).archive.gz --gzip

redis-cli SAVE
cp /var/lib/redis/dump.rdb /backups/redis/dump-$(date +%F).rdb

AVERTISSEMENT : pour des restaurations qui écrasent des bases existantes, planifiez une maintenance, arrêtez les services et prenez d’abord un snapshot ou une copie de sécurité locale.

Conteneurs et volumes (Docker)

# Épingler les versions d’images pour les reconstructions
docker images --digests > /backups/docker/images-$(date +%F).txt
# Sauvegarder un volume nommé vers une archive tar sur l’hôte
docker run --rm -v myvol:/data -v /backups:/backups alpine \
  sh -c "tar czf /backups/myvol-$(date +%F).tar.gz -C /data ."
# Restaurer dans un volume neuf (sans impacter l’existant)
docker volume create myvol
docker run --rm -v myvol:/data -v /backups:/backups alpine \
  sh -c "tar xzf /backups/myvol-2024-07-01.tar.gz -C /data"

Stockez les secrets dans un système dédié (Docker secrets, Vault) et sauvegardez la source de vérité.

Automatiser et surveiller

Utilisez des timers systemd ou cron. Remontez succès/échec à votre supervision.

# Restic nocturne avec un ping de santé
0 2 * * * RESTIC_REPOSITORY=... RESTIC_PASSWORD=... \
  /usr/local/bin/restic backup /etc /var/www /home \
  && curl -fsS -m 10 https://hc-ping.com/UUID || echo "backup failed" >&2

Faites tourner et purgez (restic forget --prune, borg prune). Surveillez les codes de retour et les logs.

Tester les restaurations et vérifier l’intégrité

Séparez clairement la création de sauvegardes des tests de restauration. Ne testez jamais en écrasant des chemins de production.

Checklist de vérification de restauration :

• Choisir un snapshot récent et un plus ancien aléatoire.
• Restaurer dans un répertoire temporaire ou une instance isolée.
• Valider nombres de fichiers, permissions, ACL, xattrs (diff -r, getfacl/getfattr).
• Pour les configs, lancer des vérifications de syntaxe (ex. : nginx -t, systemd-analyze verify).
• Pour les bases, faire un test de restauration et quelques requêtes de base.
• Exécuter restic check ou borg check et analyser les logs.
• Documenter la durée (RTO) et le point de reprise atteint (RPO réalisé).

Exemple de test de restauration de fichiers :

restic restore latest --target /restore-test
sudo rsync -aAXn /restore-test/etc/ /etc/   # comparaison à blanc

Exemple de promotion de configuration (après validation) :

# Prérequis : fenêtre de maintenance, service arrêté, copie locale de sécurité
sudo systemctl stop nginx
sudo cp -a /etc/nginx /etc/nginx.bak-$(date +%s)
sudo rsync -aAX /restore-test/etc/nginx/ /etc/nginx/
sudo nginx -t && sudo systemctl start nginx

Runbook de triage en cas d’échec (sauvegarde ou restauration)

• Cadrer le problème : quel hôte, quel jeu de données, depuis quand, cas isolé ou récurrent.
• Vérifier identifiants et connectivité : DNS, réseau, pare-feu, clés SSH/HTTPS.
• Inspecter la santé du dépôt : restic check / borg check ; espace disponible et statut d’Object Lock.
• Valider la santé du système de fichiers source : dmesg, SMART, besoin de fsck, épuisement d’inodes.
• Revoir les changements récents : mises à jour paquets, noyau, permissions, SELinux/AppArmor.
• Réessayer prudemment avec plus de verbosité ; capturer les logs.
• Escalader avec artefacts : commande, versions, logs, IDs de snapshot, timing, taille.

Pièges courants

• Ne sauvegarder que /home et ignorer /etc, les bases et les secrets.
• Ne jamais tester les restaurations ou tester sur des chemins de production.
• Sauvegardes sur le même disque/NAS sans immutabilité ni hors site.
• Perdre ACL/xattrs/ownership ; les applications échouent ensuite à l’exécution.
• Utiliser dd pour des sauvegardes versionnées ; lent, non incrémental, difficile à gérer.
• Pas de rétention/rotation ; soit les buckets saturent, soit l’historique utile disparaît.
• Aucune supervision ; des échecs silencieux pendant des mois.

Conclusion

La sauvegarde et la restauration Linux visent la reprise, pas la copie. Démarrez par vos RPO/RTO, sauvegardez les bonnes données (y compris configurations et bases), chiffrez et expédiez des copies hors site, automatisez et surveillez. Utilisez des snapshots pour des points cohérents, mais vérifiez toujours en restaurant dans des emplacements sûrs et en validant permissions et fonctionnalités. La seule sauvegarde fiable est celle que vous avez restaurée et contrôlée.