Sauvegarde et restauration Linux avec des exemples pratiques

Intro

Sauvegarder, ce n’est pas simplement copier des fichiers : c’est pouvoir restaurer exactement les données, configurations et l’état dont vous avez besoin dans un délai défini. Des objectifs de reprise différents exigent des méthodes différentes. En pratique, une stratégie Linux mêle :

• Sauvegardes de fichiers : données utilisateurs, configurations, scripts.
• Sauvegardes système : configuration de l’OS, services, listes de paquets.
• Image disque : clone secteur par secteur pour du bare metal.
• Instantanés (snapshots) : état rapide et ponctuel du système de fichiers (Btrfs/LVM/ZFS/Timeshift).
• Sauvegarde de configuration : /etc, unités systemd, clés SSH.
• Sauvegarde applicative : répertoires propres à l’app, secrets, manifestes.
• Sauvegarde de base de données : logique ou par instantané, cohérente et restaurable.
• Reprise bare-metal : reconstruction de bout en bout, du firmware aux services.

Une sauvegarde qui n’a jamais été restaurée est une sauvegarde non vérifiée.

Stratégie de sauvegarde

Définissez vos objectifs avant de choisir les outils.

• RPO (Recovery Point Objective) : tolérance à la perte de données (ex. 15 minutes).
• RTO (Recovery Time Objective) : délai de remise en service (ex. 1 heure).
• Règle 3-2-1 : 3 copies, 2 supports différents, 1 copie hors site.
• Sauvegardes immuables : copies verrouillées en écriture pour résister aux ransomwares.
• Air-gapped : copies inaccessibles depuis le réseau de production.
• Hors site : cloud, second datacenter, site physiquement distinct.
• Rétention/versioning : conserver un historique suffisant pour annuler une erreur humaine.
• Tests de restauration : restaurations régulières qui prouvent que les sauvegardes fonctionnent.

Exemple de matrice de stratégie :

Quoi sauvegarder

Inclure :

• /home : données utilisateurs, configs SSH, GPG, dotfiles.
• /etc : configuration système, réseau, fstab, DNS, sudoers.
• Clés SSH : /etc/ssh/ et ~/.ssh ; protéger avec des permissions strictes.
• systemd : /etc/systemd/system/, overrides dans /etc/systemd/system/*.d/.
• Cron : /var/spool/cron/, /etc/cron.*, crontabs utilisateurs.
• Docker : fichiers compose, .env, liste des images et surtout les volumes.
• Kubernetes : manifestes/Helm charts, sauvegarde d’état du cluster (ex. etcd en autogéré).
• Bases de données : dumps logiques cohérents ou instantanés natifs du moteur.
• Données applicatives : répertoires stateful, uploads, caches utiles.
• Gestion de configuration : dépôts Ansible/Puppet/Chef ; traiter comme du code.
• Listes de paquets : dpkg --get-selections ou rpm -qa pour reconstruire.
• Journaux (sélectif) : pour conformité/forensique, rarement pour restauration rapide.

À exclure en général : /proc, /sys, /dev, /run, /tmp, caches, conteneurs éphémères, artéfacts de build. Privilégier la réinstallation des paquets plutôt que la sauvegarde des binaires de /usr.

Choisir le bon outil

Choisissez selon RPO/RTO, volumétrie et opérations :

*Avec des compléments ou des wrappers. N’utilisez dd que lorsque vous devez capturer les layouts/bootloaders exacts.

Sauvegardes de fichiers avec rsync

Options clés :

• -a (archive) : préserve permissions, dates, liens symboliques ; implique -rlptgoD.
• -A : préserve les ACL ; -X : préserve les xattrs ; utilisez les deux sur les systèmes modernes.
• --hard-links : préserve les liens durs.
• --delete : reflète les suppressions ; combinez avec --dry-run au préalable.
• Barre oblique finale : rsync src/ dest copie le contenu ; rsync src dest crée dest/src.
• --numeric-ids entre systèmes dissemblables pour éviter la remap UID/GID.

Exemples :

• Miroir local avec ACL/xattrs et suppression :

rsync -aAX --delete --info=stats2 --human-readable /srv/data/ /backups/data/

• Envoi distant via SSH (Ubuntu/Debian/RHEL/Rocky/Alma) :

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

• Simulation (dry-run) pour auditer les changements :

rsync -aAXn --delete /srv/app/ /backups/app/

• Rotation incrémentale avec liens durs (instantanés basés rsync) :

rsync -aAX --delete --link-dest=/backups/daily.1/ /srv/ /backups/daily.0/
cp -al /backups/daily.0/ /backups/daily.1/

Sauvegardes chiffrées avec Restic

Restic est un outil de sauvegarde dédupliqué et chiffré, idéal pour S3, Backblaze B2, Wasabi, MinIO ou SSH. Concepts :

• Dépôt (repository) : chemin local, SFTP ou s3:s3.amazonaws.com/bucket.
• Instantanés : vues ponctuelles des fichiers.
• Dédup + chiffrement : AES-256, clés par bloc ; mot de passe ou fichier de clé.

Mise en place (Linux générique, paquets apt/dnf disponibles) :

export RESTIC_REPOSITORY="s3:https://s3.wasabisys.com/my-bucket/host1"
export RESTIC_PASSWORD="change-me"
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
restic init

Sauvegarder les chemins importants :

restic backup /etc /var/www /home --exclude-file=/root/restic-excludes.txt

Lister, vérifier et appliquer la rétention :

restic snapshots
restic check
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Restaurer d’abord dans un répertoire temporaire sûr :

restic restore latest --target /restore-test

Monter pour parcourir un instantané :

restic mount /mnt/restic

Sauvegardes dédupliquées avec BorgBackup

Borg crée des archives compressées, dédupliquées et optionnellement chiffrées, vers des disques locaux, SSH ou des services type BorgBase.

Initialiser et sauvegarder :

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:%Y-%m-%d_%H-%M} /etc /var/www /home

Purge et vérification :

borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg check --verify-data

Montage via FUSE :

borg mount ::2024-07-01 /mnt/borg

Borg vs Restic (aperçu rapide) :

• Restic : binaire simple et multiplateforme, excellent avec des backends S3 ; CPU légèrement plus élevé dans certains cas.
• Borg : dédup/compression très rapides, excellent en SSH/local ; S3 nécessite rclone/passerelle.

Instantanés système : Timeshift, Btrfs, LVM, ZFS

Les instantanés sont instantanés, économes en espace et excellents pour revenir en arrière, mais ils vivent sur la même machine. Si le disque meurt, les instantanés aussi.

• Timeshift (desktop) : instantanés du système (rsync ou Btrfs). Pas une sauvegarde de données utilisateur.
• Instantanés Btrfs : basés sur des sous-volumes, quasi instantanés ; à coupler avec send/receive pour des copies hors hôte.
• Instantanés LVM : niveau bloc ; pratiques pour figer un FS et dumper une base de données.
• Instantanés ZFS : rapides, cohérents et réplicables avec zfs send | receive.

Utilisez les instantanés pour créer des points cohérents, puis répliquez hors de la machine.

Image disque

À utiliser quand il faut préserver partitions, bootloaders ou appliances.

• Clonezilla/Partclone : image « intelligente », ignore l’espace libre ; idéal en capture hors-ligne.
• dd : brut et risqué en usage live ; à réserver à la forensique ou aux secteurs d’amorçage.

Ne clonez jamais un système de fichiers vivant et changeant sans instantané. Privilégiez des instantanés FS ou LVM/Btrfs/ZFS, puis imagez le device d’instantané.

Sauvegardes de bases de données

Copier des fichiers de bases en cours d’usage est dangereux, sauf avec des instantanés pilotés par le moteur. Préférez les sauvegardes logiques ou natives au moteur.

• MySQL/MariaDB (famille Debian/Ubuntu/RHEL) :

mysqldump --single-transaction --routines --triggers --events \
  -u root -p mydb | gzip > /backups/mysql/mydb-$(date +%F).sql.gz

Pour les grosses bases, envisagez Percona XtraBackup ou un instantané LVM/ZFS + flush tables.

• PostgreSQL :

sudo -u postgres pg_dump -Fc mydb > /backups/pg/mydb-$(date +%F).dump
# Sauvegarde physique complète du cluster (assurez wal_level=replica) :
sudo -u postgres pg_basebackup -D /backups/pg/base -Ft -z -P

• MongoDB :

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

• Redis : privilégier les instantanés RDB ; s’assurer que la persistance est activée :

redis-cli SAVE
cp /var/lib/redis/dump.rdb /backups/redis/

Testez toujours la restauration dans une instance isolée avant de faire confiance au dump.

Sauvegardes Docker

Sauvegardez ce qui ne se reconstruit pas automatiquement :

• Fichiers Compose, .env, secrets.
• Liste des images (docker images --digests) pour pinner les versions.
• Volumes (données persistantes) via un conteneur helper ou rsync.

Sauvegarde et restauration de volume :

# 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 vierge
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 hors de l’image (Docker secrets, Vault) ; sauvegardez la source de vérité, pas seulement les conteneurs.

Automatisation et supervision

Utilisez des timers systemd ou cron, plus des sondes de santé et des journaux.

• Exemple cron :

0 2 * * * RESTIC_REPOSITORY=... RESTIC_PASSWORD=... /usr/local/bin/restic backup /etc /var/www /home && curl -fsS -m 10 https://hc-ping.com/UUID

• Timer systemd (haute fiabilité, logs dans journald).
• Rotation et purge : restic forget --prune, borg prune.
• Supervisez les échecs : codes de sortie, journald, alertes email/Slack.

Procédures de restauration

Règle d’or : restaurez d’abord vers un chemin temporaire quand c’est possible.

• Fichier unique : restic restore latest --include "/etc/nginx/nginx.conf" --target /restore.
• Répertoire : borg extract ::2024-07-01 var/www/site.
• Configuration : rsync -aAX /restore/etc/ /etc/ puis valider la syntaxe et recharger.
• Application : restaurer le volume, réinstaller les paquets, redéployer les conteneurs.
• Rebuild serveur : réinstaller l’OS, restaurer /etc, clés, utilisateurs, services ; rattacher les données ; valider.
• Bare-metal : utiliser une image Clonezilla/Rear, puis mettre à jour UUID/fstab/bootloader si nécessaire.

Reprise après sinistre : déroulé rapide

Scénario : panne SSD sur un hôte web + BD.

1. Remplacer le disque, installer un OS minimal avec le même hostname.
2. Rétablir l’accès SSH et installer les outils de sauvegarde (apt/dnf).
3. Restaurer /etc, utilisateurs, clés SSH : restic restore latest --target / ; valider propriétaires/droits.
4. Restaurer les données applicatives (Borg/Restic) vers /srv.
5. Restaurer la base depuis le dernier dump cohérent ; appliquer binlogs/WAL jusqu’au RPO visé.
6. Recréer les volumes Docker et redéployer les conteneurs ou services systemd.
7. Valider : health checks, logs, tests fonctionnels.
8. Rouvrir le trafic ; surveiller de près.

Vérification et sécurité

• Vérifiez régulièrement : restic check, borg check --verify-data, checksum de fichiers tests.
• Testez des restaurations mensuelles et après tout changement majeur ; documentez les résultats.
• Chiffrez les données hors site ; protégez clés/mots de passe dans un gestionnaire ou KMS.
• Utilisez des buckets immuables (S3 Object Lock) contre les ransomwares.
• Restreignez les identifiants de sauvegarde (moindre privilège). Séparez les comptes du serveur de backup.

Erreurs fréquentes

• Ne sauvegarder que /home ; ignorer /etc, les bases et les secrets.
• Ne jamais tester les restaurations.
• Conserver les sauvegardes sur le même disque/NAS sans immutabilité.
• Ignorer permissions, ACL, xattrs ; perte d’accès applicatif.
• Utiliser dd pour tout ; lent, fragile, sans versioning.
• Oublier les clés SSH et unités systemd.
• Pas de rétention/rotation ; buckets pleins ou versions perdues.
• Aucune supervision ; échecs silencieux pendant des mois.

Optimisation des performances

• Compression : lz4/zstd pour la vitesse, zlib/zstd-high pour l’espace ; ajuster Borg/Restic.
• Parallélisme : planifier en heures creuses ; utiliser ionice/nice.
• Réseau : SSH ControlMaster, accélération WAN seulement si sûre.
• Cadence incrémentale : des sauvegardes fréquentes et petites réduisent les deltas.
• Mise en page favorable à la dédup : chemins stables et tailles « chunk-friendly » améliorent la réutilisation.

Architecture minimale (exemple)

Un schéma simple et résilient :

Application -> Base de données -> Agent de sauvegarde -> Dépôt chiffré -> Stockage hors site
                                               -> Hôte de restauration -> Validation

• Agent : Restic/Borg sur chaque hôte.
• Dépôt : serveur SSH ou bucket compatible S3 avec verrouillage d’objets.
• Hôte de restauration : machine dédiée aux tests de restauration et à la DR.

Conclusion

La sauvegarde et la restauration sous Linux parlent de reprise, pas de copie. Alignez vos outils sur RPO/RTO, sauvegardez les bonnes données (y compris bases et configurations), chiffretez et expédiez des copies hors site, automatisez et supervisez, puis effectuez des restaurations régulières. Les instantanés sont excellents pour des retours rapides, mais ne remplacent pas des sauvegardes immuables hors machine. La seule sauvegarde digne de confiance est celle que vous avez restaurée et validée.