Sauvegarde automatique rsync sur Linux : protéger un serveur sans intervention manuelle

Une sauvegarde automatique rsync repose sur un script Bash qui lance rsync avec des options contrôlées, puis sur une tâche planifiée telle que cron. Le mécanisme peut copier les fichiers d’un serveur Linux vers un stockage local ou distant via SSH, enregistrer le résultat dans un journal et signaler un échec par son code de retour.

Rsync est un outil de synchronisation de fichiers qui ne transfère, après une première copie, que les différences détectées entre une source et une destination. Une synchronisation miroir n’est toutefois pas une stratégie de sauvegarde suffisante à elle seule : un fichier supprimé ou chiffré sur la source peut aussi disparaître de la copie si l’option --delete est utilisée.

Comment fonctionne une sauvegarde avec rsync ?

Rsync est un programme de synchronisation qui compare une source et une destination pour transférer les éléments nouveaux ou modifiés. Une sauvegarde automatique rsync réduit les copies inutiles après le premier passage, mais ne crée pas spontanément un historique de versions. La syntaxe de base reste rsync [options] source destination, avec une source locale ou un chemin distant accessible par SSH.

Le mode archive -a est adapté à de nombreux répertoires serveur, car il synchronise récursivement et préserve notamment les liens symboliques, les permissions, les dates, les propriétaires et les groupes. La préservation des propriétaires et groupes suppose toutefois des droits suffisants ; un compte de sauvegarde non privilégié ne pourra pas forcément reproduire toutes les métadonnées.

Une copie synchronisée répond à une question simple : « quels fichiers sont présents maintenant ? » Une sauvegarde exploitable doit aussi répondre à une seconde question : « puis-je restaurer un état sain ? »

Pourquoi automatiser la sauvegarde d’un serveur Linux ?

Une sauvegarde quotidienne de serveur ne dépend plus d’un oubli humain lorsque cron ou un minuteur systemd lance le script à une heure définie. L’automatisation apporte de la régularité, mais elle ne prouve pas le succès de chaque exécution : un journal, un code de retour et des contrôles d’espace disponible restent nécessaires.

Le slash final change le résultat

Le slash final d’un chemin source modifie l’arborescence copiée. Avec /srv/app, rsync copie le dossier app lui-même dans la destination ; avec /srv/app/, rsync copie le contenu de app. Cette différence paraît mineure, mais elle détermine le chemin utilisé plus tard pour restaurer les fichiers.

Élément	Effet	Point de contrôle
-a	Copie récursive avec conservation de métadonnées importantes	Vérifier les droits du compte exécutant rsync
--dry-run ou -n	Simule les changements sans écrire sur la destination	Utiliser avant chaque changement de règle
--delete	Supprime en destination les éléments absents de la source	Employer seulement pour un miroir compris et testé
--partial	Conserve les parties de fichiers déjà transférées après interruption	Utile pour des fichiers volumineux ou une liaison instable
--exclude	Écarte certains chemins de la synchronisation	Ne pas exclure de données nécessaires à la restauration

Préparer le serveur source et la destination

La préparation d’une sauvegarde distante Linux consiste à identifier les répertoires utiles, choisir une destination située hors du serveur protégé et créer un accès limité. Une destination sur le même disque que la source ne protège pas contre la panne de ce disque ni contre la perte complète du serveur. Un second serveur, un volume séparé ou un stockage monté sur une autre machine répond mieux à ce risque matériel.

Une sauvegarde de fichiers ne remplace pas toujours une sauvegarde applicative. Les fichiers d’une base de données en cours d’écriture peuvent ne pas former un état cohérent ; pour ce cas, produire d’abord une exportation avec l’outil de la base concernée, puis sauvegarder l’export. La même prudence vaut pour les volumes applicatifs et les services qui maintiennent des fichiers verrouillés.

Étape 1 : délimiter les données à protéger

Commencez par écrire les chemins réellement restaurables, par exemple /srv/app/, /etc/ ou le répertoire qui contient des exports de base de données. Évitez de copier indistinctement tout le système : les pseudo-systèmes de fichiers tels que /proc, /sys, /dev et /run ne correspondent pas à des données ordinaires à restaurer par rsync.

• Fichiers de configuration nécessaires au redémarrage d’un service.
• Données utilisateur, documents, médias et répertoires applicatifs.
• Exports cohérents de bases de données, produits avant rsync.
• Clés et secrets uniquement si leur sauvegarde respecte votre politique de sécurité.

Étape 2 : créer un compte dédié et une clé SSH

Un compte distinct, par exemple backup, limite la portée de la connexion utilisée pour la sauvegarde avec rsync. Créez la paire de clés sur la machine qui exécutera le script, protégez la clé privée avec des permissions restrictives, puis placez uniquement la clé publique dans le fichier ~backup/.ssh/authorized_keys de la machine distante.

La documentation ssh-keygen d’OpenSSH décrit la création et la gestion des paires de clés. Une clé sans phrase de passe peut être nécessaire à une exécution non interactive, mais elle augmente l’importance des permissions, de la limitation du compte distant et de la protection du serveur qui héberge la clé privée.

Étape 3 : vérifier les prérequis avant l’automatisation

Le script doit disposer de rsync, de ssh, d’un shell Bash et d’un répertoire de destination accessible en écriture. La commande flock, fournie sur de nombreux systèmes Linux, aide à empêcher deux exécutions simultanées ; vérifiez sa présence avec command -v flock avant de l’intégrer à un script.

Comment tester une première commande rsync sans risque ?

Une première commande rsync doit être exécutée avec --dry-run, qui affiche les modifications prévues sans copier ni supprimer de fichier. Le test doit porter sur les chemins définitifs, avec les mêmes exclusions et le même slash final que le script futur. Un répertoire de démonstration ne révèle pas toujours une erreur de chemin présente dans l’environnement réel.

Depuis le serveur de sauvegarde, l’exemple suivant récupère le contenu de /srv/app/ depuis un serveur distant vers une destination locale. Remplacez les valeurs d’exemple avant toute exécution et gardez le slash final sur la source si vous souhaitez copier son contenu.

rsync -a --dry-run --itemize-changes \
  -e "ssh -i /home/backup/.ssh/id_ed25519 -o BatchMode=yes" \
  [email protected]:/srv/app/ \
  /srv/sauvegardes/serveur-app/

Le paramètre BatchMode=yes force SSH à échouer plutôt qu’à attendre une saisie de mot de passe, comportement indispensable pour une tâche planifiée. L’option --itemize-changes rend le journal plus lisible en indiquant les éléments modifiés, ajoutés ou supprimés.

Étape 4 : ajouter les exclusions utiles

Les exclusions servent à retirer des fichiers temporaires, des caches régénérables ou des fichiers de travail. Une règle --exclude ne doit pas être choisie parce qu’un dossier paraît volumineux : le critère utile est de savoir si l’application peut fonctionner ou être restaurée sans ce dossier.

rsync -a --dry-run \
  --exclude="cache/" \
  --exclude="tmp/" \
  --exclude="*.log" \
  -e "ssh -i /home/backup/.ssh/id_ed25519 -o BatchMode=yes" \
  [email protected]:/srv/app/ \
  /srv/sauvegardes/serveur-app/

Étape 5 : décider explicitement du miroir avec suppression

L’option --delete supprime, dans la destination, les fichiers qui n’existent plus dans la source. Une commande miroir peut être pertinente pour répliquer un répertoire actif, mais elle ne protège pas contre une suppression accidentelle déjà présente dans la source. Lancez d’abord rsync -a --dry-run --delete ..., lisez chaque suppression annoncée, puis retirez seulement --dry-run lorsque le résultat est attendu.

L’option --delete n’est pas dangereuse par nature ; elle devient dangereuse quand la destination, la source ou les exclusions n’ont pas été vérifiées.

Créer un script de sauvegarde automatique rsync

Un script rsync rassemble les chemins, les exclusions, la clé SSH, le journal et le contrôle d’erreur dans un fichier relisible. Le script ci-dessous réalise une synchronisation miroir contrôlée, mais il ne crée pas de versions historiques. Conservez donc une politique distincte de snapshots ou de rotation si la restauration d’un fichier ancien est nécessaire.

Étape 6 : écrire le script Bash

Créez le fichier /usr/local/sbin/sauvegarde-rsync-app.sh avec un compte administrateur, puis adaptez chaque variable. Le chemin /var/log nécessite souvent des droits élevés ; si le script s’exécute sous un compte non privilégié, utilisez plutôt un journal dans son répertoire personnel.

#!/usr/bin/env bash
set -u

SOURCE="[email protected]:/srv/app/"
DESTINATION="/srv/sauvegardes/serveur-app/"
CLE_SSH="/home/backup/.ssh/id_ed25519"
JOURNAL="/var/log/sauvegarde-rsync-app.log"
VERROU="/tmp/sauvegarde-rsync-app.lock"

mkdir -p "$DESTINATION"

exec 9>"$VERROU"
flock -n 9 || exit 0

{
  echo "===== Début : $(date -Is) ====="

  if rsync -a --delete --partial --itemize-changes \
    --exclude="cache/" \
    --exclude="tmp/" \
    -e "ssh -i $CLE_SSH -o BatchMode=yes" \
    "$SOURCE" "$DESTINATION"
  then
    echo "Résultat : succès"
    exit 0
  else
    CODE_RETOUR=$?
    echo "Résultat : échec, code rsync $CODE_RETOUR"
    exit "$CODE_RETOUR"
  fi
} >> "$JOURNAL" 2>&1

Rendez ensuite le fichier exécutable avec chmod 700 /usr/local/sbin/sauvegarde-rsync-app.sh, puis lancez-le manuellement une première fois. Le verrou flock -n quitte sans démarrer une seconde copie si une exécution précédente détient déjà le verrou ; cette mesure évite des transferts concurrents vers la même destination.

Étape 7 : tester le script avant la copie réelle

Ajoutez temporairement --dry-run dans la ligne rsync du script, lancez le fichier et consultez le journal. Une fois la sortie validée, retirez l’option de simulation, relancez le script, puis vérifiez que les fichiers attendus existent dans la destination.

Comment automatiser rsync avec cron ?

Cron est un planificateur Unix qui exécute une commande selon cinq champs : minute, heure, jour du mois, mois et jour de semaine. Pour programmer une sauvegarde quotidienne à 02 h 15, cron utilise l’expression 15 2 * * *. L’éditeur de crontab s’ouvre avec crontab -e pour le compte qui doit lancer le script.

Le comportement exact de cron dépend de la distribution et de la configuration du service. Vérifiez que le démon cron ou crond est actif sur votre système, et utilisez des chemins absolus dans la crontab : l’environnement d’une tâche planifiée est plus limité que celui d’un terminal interactif.

Étape 8 : ajouter la tâche planifiée

La ligne suivante lance le script chaque jour à 02 h 15. Le script gère déjà son propre journal ; la redirection finale permet néanmoins de conserver les erreurs qu’un problème survenant avant l’initialisation du journal pourrait produire.

15 2 * * * /usr/local/sbin/sauvegarde-rsync-app.sh >> /var/log/sauvegarde-rsync-cron.log 2>&1

La page de manuel crontab(5) détaille la syntaxe des champs de planification. Pour une exécution chaque dimanche à 03 h 30, utilisez 30 3 * * 0 ; pour une exécution toutes les six heures à la minute 10, utilisez 10 */6 * * *.

1. Ouvrez la crontab du compte concerné avec crontab -e.
2. Ajoutez la ligne qui appelle le script par son chemin absolu.
3. Enregistrez le fichier et vérifiez la présence de la règle avec crontab -l.
4. Contrôlez le journal après le premier créneau programmé.
5. Conservez le verrou dans le script pour éviter les chevauchements.

Limiter le débit si la liaison est partagée

Rsync propose --bwlimit pour limiter la bande passante utilisée, avec une valeur exprimée en kilobits par seconde. Cette option peut réduire l’impact d’une sauvegarde distante sur un service en production, mais la valeur pertinente dépend du débit disponible, des autres usages réseau et de la fenêtre de sauvegarde.

Vérifier la sauvegarde et restaurer un fichier de test

Une sauvegarde automatique rsync est vérifiable par trois indices : le code de retour de rsync, le contenu du journal et une restauration réelle vers un emplacement séparé. La présence d’un répertoire de destination ne prouve pas que les données copiées sont complètes, cohérentes ou restaurables. La commande rsync renvoie un code nul en cas de réussite ; le script précédent inscrit ce résultat dans le journal.

Examinez les dernières lignes après chaque premier lancement et après toute modification des exclusions ou des chemins. Un journal utile comporte une date de début, la liste des changements et un statut explicite ; évitez de n’enregistrer que la sortie standard, car les erreurs SSH sont généralement écrites sur la sortie d’erreur.

Étape 9 : effectuer une restauration non destructive

Restaurer un fichier de test vers /srv/restore-test/ valide le chemin de copie sans écraser la production. L’exemple restaure le contenu du dossier de configuration déjà sauvegardé ; adaptez le chemin à l’arborescence réellement produite par votre choix de slash final.

mkdir -p /srv/restore-test/config/

rsync -a --dry-run \
  /srv/sauvegardes/serveur-app/config/ \
  /srv/restore-test/config/

Après lecture de la simulation, retirez --dry-run et comparez les fichiers restaurés avec les fichiers attendus. Une restauration complète d’application exige souvent des étapes supplémentaires, comme l’arrêt du service, la restauration d’un export de base de données ou l’ajustement des permissions : documentez-les séparément plutôt que de supposer qu’une copie de fichiers suffit.

Conserver des versions plutôt qu’un seul miroir

Un miroir rsync unique contient le dernier état connu de la source. Une stratégie de conservation des versions peut reposer sur des snapshots du système de fichiers de destination, sur des répertoires datés ou sur un outil conçu pour la déduplication et l’historique. Le choix dépend de l’espace disponible, de la durée de rétention et du délai acceptable pour restaurer un état ancien.

Erreurs fréquentes avec une sauvegarde automatique rsync

Les erreurs les plus coûteuses ne viennent pas toujours de rsync, mais d’un chemin mal interprété, d’un accès SSH interactif ou d’une destination insuffisamment séparée. Chaque modification de script doit être simulée et suivie d’une vérification du journal, surtout lorsqu’elle touche aux suppressions ou aux exclusions.

• Utiliser --delete sans simulation : la destination peut perdre des fichiers attendus. Lancez toujours la commande avec --dry-run et contrôlez la liste avant l’exécution réelle.
• Oublier le slash final : la sauvegarde crée une arborescence différente de celle attendue. Écrivez le chemin de restauration prévu avant de valider la commande.
• Attendre un mot de passe SSH : cron ne peut pas répondre à une invite interactive. Utilisez une clé SSH et BatchMode=yes pour obtenir un échec explicite.
• Exclure un répertoire sans analyser son rôle : un cache est parfois régénérable, mais un dossier de données ou une pièce jointe ne l’est pas. Testez la restauration fonctionnelle.
• Conserver la copie sur le même serveur : une panne du serveur peut affecter la source et la destination. Placez au moins une copie sur un support ou une machine distincte.

Rsync, rsnapshot, BorgBackup ou restic : quel outil choisir ?

Rsync convient lorsqu’un répertoire synchronisé, lisible directement sur la destination et contrôlé par script répond au besoin. Rsync est pertinent pour une copie simple et transparente ; un outil avec déduplication et historique devient plus adapté lorsque la conservation de plusieurs versions est une exigence centrale. Rsnapshot, BorgBackup et restic sont des alternatives connues, mais leur mise en œuvre doit être vérifiée dans leur documentation officielle avant un déploiement en production.

Outil	Usage adapté	Limite à examiner
rsync	Miroir de fichiers local ou distant, script simple, restauration lisible	Pas d’historique automatique dans une destination unique
rsnapshot	Rétention par instantanés à partir d’un mécanisme rsync	Politique de rotation et espace disque à définir
BorgBackup	Sauvegardes avec déduplication et archives	Processus de restauration et gestion du dépôt à maîtriser
restic	Sauvegardes vers différents stockages avec historique	Gestion des identifiants et des clés de dépôt à sécuriser

Bonnes pratiques pour une sauvegarde serveur Linux fiable

Une sauvegarde distante Linux gagne en fiabilité lorsque les droits, les journaux et les tests de restauration sont traités comme des éléments du même système. La page de manuel rsync(1) reste la référence pour vérifier le comportement précis d’une option, notamment avant d’ajouter des filtres ou une règle de suppression.

La sécurité du transfert via SSH protège les données pendant leur transport, mais elle ne chiffre pas nécessairement les données une fois stockées sur la destination. Si le stockage de destination est exposé, définissez une politique de chiffrement au repos, de contrôle d’accès et de gestion des clés adaptée à votre environnement.

1. Testez toute nouvelle règle rsync avec --dry-run.
2. Conservez la destination sur une machine ou un support distinct.
3. Utilisez une clé SSH réservée à la sauvegarde, sans mot de passe dans le script.
4. Contrôlez régulièrement le journal et le code de retour.
5. Restaurez périodiquement un fichier puis un jeu de données représentatif.
6. Prévoyez une conservation de versions si une suppression ancienne doit pouvoir être annulée.

Les systèmes Linux, comme les systèmes de géolocalisation, dépendent d’une chaîne de composants plutôt que d’un seul réglage. Comprendre le mécanisme de calcul d’une position GPS aide à voir pourquoi un résultat doit être recoupé ; pour la sauvegarde, le même réflexe consiste à contrôler la chaîne complète, du script au fichier restauré.

Sources utiles à consulter

La documentation primaire évite de bâtir un script de production sur une option mal comprise ou sur un exemple adapté à un autre environnement. Les pages suivantes permettent de vérifier les commandes employées dans ce tutoriel.

• Manuel rsync(1) : options d’archive, suppression, filtres, reprise de transfert et connexions distantes.
• Manuel crontab(5) : syntaxe des expressions de planification et environnement des tâches cron.
• Documentation ssh-keygen : création, gestion et protection des clés SSH.

Questions fréquentes sur rsync et les sauvegardes Linux

Rsync suffit-il pour sauvegarder un serveur Linux ?

Rsync peut suffire pour synchroniser des fichiers vers une destination distincte et restaurer des données récentes. Rsync seul ne fournit pas automatiquement un historique de versions, des instantanés ni une cohérence applicative pour les bases de données actives.

Comment exclure un dossier avec rsync ?

Ajoutez une règle telle que --exclude="cache/" à la commande rsync ou au script. Testez d’abord la règle avec --dry-run, car un chemin d’exclusion incorrect peut laisser passer des fichiers inutiles ou retirer des données nécessaires.

Pourquoi cron ne lance-t-il pas mon script rsync ?

Cron utilise un environnement réduit et peut ne pas retrouver une commande appelée sans chemin complet. Utilisez des chemins absolus pour le script, rsync et les fichiers de clé, puis consultez le journal de la tâche et l’état du service cron ou crond.

Comment restaurer un fichier supprimé avec une sauvegarde rsync ?

Copiez le fichier depuis la destination vers un répertoire de restauration séparé avec rsync, puis vérifiez son contenu avant de le replacer dans l’application. Si le script utilise --delete et qu’aucune version antérieure n’est conservée, un fichier supprimé peut ne plus exister dans le miroir.

À quelle fréquence planifier une sauvegarde quotidienne serveur ?

La fréquence dépend de la quantité de données acceptable à perdre entre deux sauvegardes et de la durée de transfert disponible. Une exécution quotidienne convient à certains serveurs, tandis que des données modifiées fréquemment peuvent nécessiter plusieurs passages ; le verrou du script évite alors les exécutions simultanées.