Aller au contenu principal
Sauvegarde

Sauvegarder un serveur Linux avec rsync sans erreur

Par Julien Martel

Pourquoi utiliser rsync pour sauvegarder un serveur Linux

rsync est l’un des outils les plus utilisés sous Linux pour copier et synchroniser des fichiers de manière fiable. Sur un serveur, il permet de construire une sauvegarde simple, lisible et automatisable, sans dépendre d’une interface graphique ni d’un logiciel propriétaire. Son intérêt principal est pratique : après la première copie complète, rsync ne retransfère que les fichiers modifiés, ce qui réduit fortement le volume de données à envoyer et le temps d’exécution.

Sur la plupart des distributions Linux, rsync est disponible directement via le gestionnaire de paquets. On le retrouve couramment sur Debian, Ubuntu, AlmaLinux, Rocky Linux, Fedora ou encore openSUSE. Il fonctionne aussi bien pour une sauvegarde locale vers un disque monté que pour une sauvegarde distante via SSH.

Ce guide montre comment mettre en place une sauvegarde de serveur avec rsync en évitant les erreurs les plus fréquentes : droits mal recopiés, exclusions mal placées, suppression accidentelle de fichiers, oubli des systèmes de fichiers spéciaux comme /proc ou /sys, et mauvaise gestion des journaux ou des bases de données.

Ce que rsync sait faire, et ce qu’il ne faut pas lui demander

rsync est très bon pour sauvegarder :

  • des répertoires applicatifs comme /var/www, /srv ou /opt ;
  • des fichiers de configuration comme /etc ;
  • des répertoires utilisateurs comme /home ;
  • des sauvegardes vers un disque USB, un NAS monté, ou un autre serveur via SSH.

En revanche, il faut être prudent sur certains cas :

  • une base MySQL ou MariaDB en cours d’écriture ne doit pas être sauvegardée “à chaud” par simple copie brute de ses fichiers sans procédure adaptée ;
  • les pseudo-systèmes de fichiers comme /proc, /sys, /dev ou /run ne doivent généralement pas être inclus dans une sauvegarde classique du système ;
  • si vous voulez une image système démarrable, rsync seul ne remplace pas toujours un outil d’image disque ou de snapshot.

La bonne approche consiste donc à utiliser rsync pour les fichiers, et à compléter si nécessaire avec des exports applicatifs, par exemple mysqldump, mariadb-dump ou pg_dump pour les bases de données.

Préparer une stratégie de sauvegarde réaliste

Avant d’écrire la moindre commande, il faut répondre à trois questions :

  • Quoi sauvegarder ? Le système entier, seulement les données, ou un ensemble ciblé de répertoires.
  • Où sauvegarder ? Disque local, disque externe, autre serveur Linux, stockage monté en NFS ou SMB.
  • Avec quelle fréquence ? Quotidienne, horaire, hebdomadaire, selon la criticité des données.

Sur un serveur web Linux classique, une base minimale de sauvegarde comprend souvent :

  • /etc pour la configuration système ;
  • /var/www ou /srv/www pour les sites ;
  • /home si des comptes utilisateurs stockent des données ;
  • les dumps de bases de données générés juste avant la sauvegarde ;
  • éventuellement /opt ou /usr/local si des logiciels y sont installés manuellement.

Évitez de lancer une sauvegarde “tout le système” sans exclusions. C’est possible, mais plus risqué si vous ne maîtrisez pas encore le comportement de rsync.

Installer rsync

Sur Debian ou Ubuntu :

apt update && apt install rsync

Sur Rocky Linux, AlmaLinux ou CentOS Stream :

dnf install rsync

Sur les systèmes plus anciens utilisant yum :

yum install rsync

Vérifiez ensuite la présence de l’outil :

rsync --version

Cette commande affiche la version installée ainsi que les fonctionnalités compilées, comme la prise en charge des ACL, des attributs étendus ou de la compression.

Comprendre les options essentielles de rsync

La commande rsync peut sembler dense, mais quelques options couvrent la majorité des besoins.

  • -a : mode archive. Il préserve récursivement les fichiers, liens symboliques, permissions, dates et propriétaires.
  • -v : mode verbeux.
  • -h : tailles lisibles par un humain dans certaines sorties.
  • --delete : supprime dans la destination ce qui n’existe plus dans la source.
  • --dry-run : simulation sans rien modifier.
  • --exclude : exclut des fichiers ou répertoires.
  • -e ssh : utilise SSH comme transport pour une cible distante.
  • --numeric-ids : conserve les UID et GID numériques, utile entre serveurs.
  • -A : préserve les ACL si le système les utilise.
  • -X : préserve les attributs étendus.

Dans beaucoup de cas serveur, une base sérieuse est :

rsync -aAXH --numeric-ids

Selon le contexte, on y ajoute --delete, --info=progress2 ou -e ssh.

Attention au slash final : une erreur classique

Avec rsync, la présence ou non d’un slash final change le résultat.

Exemple :

rsync -a /etc /backup/

Ici, rsync copie le répertoire /etc dans /backup/, ce qui donne /backup/etc.

En revanche :

rsync -a /etc/ /backup/etc/

Ici, rsync copie le contenu de /etc/ dans /backup/etc/.

Cette différence paraît mineure, mais elle provoque régulièrement des arborescences inattendues. Avant d’automatiser, testez toujours avec --dry-run.

Exemple simple : sauvegarder un répertoire local vers un disque monté

Supposons qu’un disque de sauvegarde soit monté sur /backup et que vous vouliez sauvegarder la configuration système et les sites web.

Commencez par créer l’arborescence cible :

mkdir -p /backup/serveur/{etc,var-www}

Puis lancez une simulation :

rsync -aAXHv --dry-run /etc/ /backup/serveur/etc/

Si le résultat est cohérent :

rsync -aAXHv /etc/ /backup/serveur/etc/

Pour un site web hébergé dans /var/www/ :

rsync -aAXHv /var/www/ /backup/serveur/var-www/

Cette méthode est simple et efficace pour des sauvegardes ciblées. Elle évite déjà beaucoup de problèmes liés à une copie aveugle du système complet.

Exemple concret : sauvegarder un serveur distant via SSH

Un cas courant consiste à envoyer la sauvegarde vers un autre serveur Linux. Supposons :

  • serveur source : machine de production ;
  • serveur de sauvegarde : [email protected] ;
  • répertoire distant : /data/backups/serveur1/.

Commande type :

rsync -aAXH --numeric-ids -e ssh /etc/ [email protected]:/data/backups/serveur1/etc/

Pour les données web :

rsync -aAXH --numeric-ids -e ssh /var/www/ [email protected]:/data/backups/serveur1/var-www/

Si vous utilisez une clé SSH dédiée, vous pouvez préciser :

rsync -aAXH --numeric-ids -e "ssh -i /root/.ssh/id_backup" /etc/ [email protected]:/data/backups/serveur1/etc/

Cette approche est robuste et largement utilisée. SSH chiffre le transport, ce qui évite d’exposer les données en clair sur le réseau.

Préserver correctement permissions, propriétaires et attributs

La fiabilité d’une sauvegarde ne se limite pas à la présence des fichiers. Si les droits sont faux à la restauration, le service peut ne plus démarrer, un site web peut retourner une erreur, ou des utilisateurs peuvent perdre l’accès à leurs données.

Pour un serveur Linux, les points importants sont :

  • permissions : mode de lecture, écriture, exécution ;
  • propriétaire et groupe : souvent root, www-data, nginx, apache, mysql selon la distribution et les services ;
  • ACL : si elles sont utilisées ;
  • attributs étendus : utiles notamment dans certains contextes de sécurité.

La commande -a couvre déjà une grande partie du besoin, mais pour une sauvegarde système sérieuse, ajoutez souvent -A et -X. Si vous sauvegardez entre machines Linux différentes, --numeric-ids évite que rsync tente de faire des correspondances de noms d’utilisateurs ou de groupes qui pourraient diverger.

En pratique :

rsync -aAXH --numeric-ids /source/ /destination/

Le -H sert à préserver les liens physiques. Il peut coûter plus de mémoire sur de très gros jeux de données, mais reste utile sur certaines arborescences système.

Exclure ce qu’il ne faut pas sauvegarder

Les exclusions sont indispensables. Sans elles, vous risquez de copier des fichiers temporaires, des caches, des sockets, des montages réseau ou des pseudo-systèmes de fichiers inutiles en sauvegarde.

Pour une sauvegarde large d’un serveur, on exclut souvent :

  • /proc
  • /sys
  • /dev
  • /run
  • /tmp
  • /mnt
  • /media
  • les répertoires de cache applicatifs selon le besoin

Vous pouvez utiliser un fichier d’exclusion, plus propre qu’une longue ligne de commande. Exemple : /root/rsync-excludes.txt

/proc
/sys
/dev
/run
/tmp
/mnt
/media
/lost+found

Puis :

rsync -aAXH --numeric-ids --exclude-from=/root/rsync-excludes.txt / /backup/rootfs/

Important : cette commande doit être pensée avec soin. Sauvegarder / est possible, mais seulement si vous comprenez bien les exclusions et les conséquences.

Utiliser --delete sans se piéger

--delete est très utile pour garder la destination fidèle à la source. Si un fichier a été supprimé côté source, il sera aussi supprimé dans la sauvegarde. Cela évite l’accumulation de fichiers obsolètes.

Mais c’est aussi une option dangereuse. Si la source est vide à cause d’un montage absent, d’une erreur de chemin ou d’un script défaillant, rsync peut supprimer massivement des données côté destination.

Bonnes pratiques :

  • toujours tester avec --dry-run avant la première exécution ;
  • vérifier que le point de montage source ou destination est bien présent ;
  • journaliser les exécutions ;
  • éviter --delete tant que vous n’avez pas validé le périmètre exact de la sauvegarde.

Exemple prudent :

rsync -aAXHv --delete --dry-run /var/www/ /backup/serveur/var-www/

Une fois le résultat validé :

rsync -aAXHv --delete /var/www/ /backup/serveur/var-www/

Sauvegarder aussi les bases de données, mais correctement

rsync ne remplace pas un export logique de base de données. Pour MariaDB ou MySQL, utilisez de préférence mysqldump ou mariadb-dump. Pour PostgreSQL, utilisez pg_dump ou pg_dumpall selon le besoin.

Exemple simple pour MariaDB/MySQL :

mysqldump --all-databases --single-transaction --routines --events > /root/db-all.sql

Puis sauvegardez ce fichier avec rsync :

rsync -a /root/db-all.sql [email protected]:/data/backups/serveur1/db/

Pour PostgreSQL, on peut par exemple générer un dump avec l’utilisateur postgres, puis le transférer de la même manière. L’important est de ne pas se contenter d’une copie brute des fichiers de données sans méthode adaptée au moteur utilisé.

Créer un script de sauvegarde fiable

Automatiser est essentiel. Voici une structure simple et réaliste pour un script shell de sauvegarde. L’idée n’est pas d’empiler des options, mais de sécuriser l’exécution.

Exemple de logique :

  • vérifier que le point de montage de destination existe ;
  • créer un répertoire daté pour les dumps de bases ;
  • générer les exports applicatifs ;
  • lancer rsync sur les répertoires ciblés ;
  • écrire un journal ;
  • retourner un code d’erreur exploitable par cron ou systemd.

Exemple de commandes à intégrer :

mkdir -p /backup/logs

mkdir -p /backup/dumps

mysqldump --all-databases --single-transaction --routines --events > /backup/dumps/db-all.sql

rsync -aAXH --numeric-ids /etc/ /backup/serveur/etc/ >> /backup/logs/rsync.log 2>&1

rsync -aAXH --numeric-ids /var/www/ /backup/serveur/var-www/ >> /backup/logs/rsync.log 2>&1

rsync -a /backup/dumps/ /backup/serveur/dumps/ >> /backup/logs/rsync.log 2>&1

Si vous sauvegardez vers un autre serveur, remplacez simplement la destination locale par une cible SSH.

Planifier la sauvegarde avec cron

Sur de nombreux serveurs Linux, cron reste une solution simple et éprouvée. Pour éditer la crontab root :

crontab -e

Exemple pour exécuter la sauvegarde tous les jours à 2h30 :

30 2 * * * /root/scripts/backup-rsync.sh

Avant cela, assurez-vous que le script est exécutable :

chmod 700 /root/scripts/backup-rsync.sh

Si votre distribution utilise systemd de manière centralisée pour les tâches planifiées, un couple .service et .timer peut aussi être pertinent. Mais pour un besoin simple, cron suffit souvent.

Vérifier qu’une sauvegarde est vraiment exploitable

Une sauvegarde n’a de valeur que si la restauration fonctionne. C’est le point le plus négligé sur beaucoup de serveurs.

Vérifiez régulièrement :

  • que les fichiers attendus existent bien ;
  • que les tailles sont cohérentes ;
  • que les permissions et propriétaires sont corrects ;
  • que les dumps SQL sont lisibles ;
  • qu’une restauration partielle sur un environnement de test est possible.

Quelques commandes utiles :

ls -l /backup/serveur/etc

du -sh /backup/serveur/var-www

find /backup/serveur/etc | head

Pour comparer sans modifier :

rsync -aAXHvn /etc/ /backup/serveur/etc/

Le mode simulation permet de voir ce qui diffère encore entre source et destination.

Erreurs fréquentes à éviter

Oublier les droits root

Une sauvegarde lancée avec un utilisateur sans privilèges suffisants ne verra pas tous les fichiers système. Résultat : copie incomplète. Pour sauvegarder des répertoires comme /etc, /var/spool ou certains contenus de /var/lib, il faut souvent exécuter rsync en root.

Confondre sauvegarde et synchronisation destructive

Si vous utilisez --delete sur une destination unique, vous maintenez un miroir, pas un historique. En cas de suppression accidentelle côté source, la suppression sera répercutée. Si vous avez besoin de versions, il faut compléter avec une rotation de snapshots, des répertoires datés, ou un système de fichiers adapté.

Sauvegarder un point de montage vide

Si un disque ou un partage réseau n’est pas monté, rsync peut écrire dans le répertoire local sous-jacent sans que vous vous en rendiez compte. Il faut donc vérifier le montage avant l’exécution, par exemple avec mountpoint.

Inclure des fichiers temporaires inutiles

Les caches, sockets et répertoires temporaires augmentent le bruit, la taille et les risques d’erreur. Les exclusions ne sont pas un détail : elles font partie de la fiabilité.

Ne jamais tester la restauration

C’est l’erreur la plus coûteuse. Une sauvegarde “présente” n’est pas forcément une sauvegarde “restaurable”.

Exemple de procédure simple et solide pour un petit serveur

Pour un serveur web Linux classique avec Nginx ou Apache, PHP, et une base MariaDB, une procédure réaliste peut ressembler à ceci :

  • export quotidien des bases avec mysqldump ou mariadb-dump ;
  • sauvegarde rsync de /etc ;
  • sauvegarde rsync de /var/www ;
  • sauvegarde éventuelle de /home si nécessaire ;
  • envoi vers un second serveur via SSH ;
  • journalisation locale ;
  • test mensuel de restauration sur une machine de test.

Exemple de commandes :

mysqldump --all-databases --single-transaction --routines --events > /root/db-all.sql

rsync -aAXH --numeric-ids -e ssh /etc/ [email protected]:/data/backups/serveur1/etc/

rsync -aAXH --numeric-ids -e ssh /var/www/ [email protected]:/data/backups/serveur1/var-www/

rsync -a -e ssh /root/db-all.sql [email protected]:/data/backups/serveur1/db/

Cette base couvre déjà correctement de nombreux besoins de petites et moyennes infrastructures Linux.

Faut-il compresser avec rsync ?

rsync propose l’option -z pour compresser les données pendant le transfert réseau. Cela peut être utile sur une liaison lente, mais moins intéressant sur un réseau local rapide ou avec des fichiers déjà compressés, comme des archives, des images ou certains dumps compressés.

Sur un serveur moderne relié en réseau local gigabit, l’intérêt de -z dépend surtout du type de données et de la charge CPU acceptable. Le bon réflexe est de tester sur votre jeu de données réel, plutôt que d’activer la compression par habitude.

Conclusion : une sauvegarde rsync fiable repose surtout sur la méthode

rsync est un excellent outil de sauvegarde pour Linux, à condition de l’utiliser avec méthode. La fiabilité ne vient pas d’une commande magique, mais d’un ensemble de bonnes pratiques : cibler les bons répertoires, préserver les droits, exclure les pseudo-systèmes de fichiers, traiter les bases de données séparément, tester avec --dry-run, et vérifier régulièrement la restauration.

Pour un serveur de production, commencez simple : sauvegardez /etc, les données applicatives, et les exports de bases. Ajoutez ensuite l’automatisation, les journaux et les contrôles. C’est cette approche progressive qui transforme rsync en procédure fiable, rapide à appliquer et compréhensible, même sans être administrateur système expert.

Pour aller plus loin sur la ligne de commande Linux, vous pouvez aussi consulter la documentation officielle du projet rsync via le site du projet rsync et la page de manuel disponible sur votre serveur avec man rsync.