⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Introduction

J’ai dû concevoir et implémenter une solution de sauvegarde pour une migration Proxmox. Le scénario était une mission R&D classique : trouver une alternative à la solution historique, la tester en profondeur, documenter comment la restaurer, et présenter le tout à un jury technique. J’ai choisi rsync avec SSH, un duo transparent, auditable et maîtrisable. Te voici ce que j’ai découvert en mettant les mains dans le cambouis.

Le problème à résoudre

Dans ma formation d’administrateur systèmes et réseaux, l’un des projets les plus concrets a porté sur la résilience des données. Une organisation dont la solution de sauvegarde historique était devenue incompatible avec son infrastructure migrant vers Proxmox avait besoin d’une alternative. Il fallait non seulement la trouver, mais la tester, la documenter techniquement, et la justifier.

Les objectifs du projet étaient précis : comprendre et mettre en œuvre les deux paradigmes de sauvegarde (incrémentale et différentielle), implémenter une solution robuste avec rsync et SSH, écrire des scripts Bash maintenables avec gestion d’erreurs, automatiser l’ensemble via crontab, documenter les procédures de restauration, et le présenter en 15 minutes avec démo.

C’est un exercice complet, pas juste « faire marcher un truc » mais vraiment maîtriser les concepts et être capable de les expliquer.

Architecture et choix techniques

L’architecture que j’ai choisie est volontairement simple. Une VM client simule l’environnement de production avec des données métier et des images de machines virtuelles. Une VM serveur de stockage reçoit toutes les sauvegardes. Les deux communiquent via SSH avec authentification par clé asymétrique, pas de mot de passe, pas d’interaction humaine pour les tâches automatisées.

VM Client (simulation)  ──SSH+rsync──►  VM Serveur de stockage
   10.0.50.20                                 10.0.50.10

   Données métier :                      Sauvegardes organisées :
   SITE / RH / TICKETS                   ├── SITE/complete/
   FICHIERS / MAILS                      ├── SITE/incremental/
                                         ├── RH/ ...
   Fichiers lourds :                     └── MACHINES/
   VM_IMAGES/ (simule des VMs)               differential/

J’ai retenu rsync comme outil principal, c’est la référence pour la synchronisation de fichiers sous Linux. Il dispose d’un algorithme delta efficace, supporte SSH nativement, et offre des options avancées comme les hard links. Il n’y a pas vraiment d’alternative sérieuse pour ce cas d’usage en termes de rapport fonctionnalités-simplicité.

Pour l’authentification, j’ai utilisé OpenSSH avec des clés ed25519 dédiées aux opérations non interactives, bien plus sûr qu’un accès par mot de passe pour un processus automatisé. Les scripts d’orchestration sont en Bash, qui est natif, portable, et parfait pour l’automatisation système. Pour la planification, crontab suffisait largement, pas besoin de surcharger avec Ansible ou Jenkins pour cette mission.

J’aurais pu partir sur Bacula ou Amanda, qui sont des solutions complètes avec interface de gestion et catalogue. Mais ces outils ajoutent une couche de complexité (serveur de catalogue, agents spécialisés, protocoles propriétaires) qui n’était pas justifiée ici. L’objectif pédagogique était de comprendre les mécanismes fondamentaux, pas de cliquer dans une interface. rsync + SSH, c’est transparent, auditable et maîtrisable ligne par ligne.

Incrémentale vs différentielle : la fondation

C’est probablement la notion la plus importante de ce projet. Elle détermine directement ton RTO (Recovery Time Objective) et ton RPO (Recovery Point Objective).

La sauvegarde incrémentale contient uniquement les changements depuis la dernière sauvegarde, qu’elle soit complète ou incrémentale. Elle économise massif en espace et en temps de transfert. Mais pour restaurer, tu dois rejouer toute la chaîne : sauvegarde complète, puis chaque incrément dans l’ordre chronologique. Si tu as 15 incrémentaux, tu dois les appliquer 15 fois.

La sauvegarde différentielle contient les changements depuis la dernière sauvegarde complète. Elle est plus volumineuse que l’incrémentale, surtout vers la fin de la semaine, mais la restauration est plus simple : sauvegarde complète + le dernier différentiel, c’est tout. Deux étapes.

Dans mon implémentation, j’ai utilisé chaque stratégie selon son contexte. Pour les données métier (peu volatiles, nombreux fichiers), j’ai choisi l’incrémentale avec --link-dest pour les hard links. Les fichiers inchangés ne sont pas re-copiés, ils sont référencés via un lien physique. Espace disque minimal. Pour les images de VMs (fichiers volumineux, moins nombreux), j’ai choisi la différentielle, les fichiers sont gros, donc la restauration doit être rapide et simple.

Mise en place : sans prise de tête

Préparation SSH

Avant d’écrire la moindre ligne de rsync, j’ai configuré l’authentification SSH correctement. Si SSH n’est pas fiable, rien ne fonctionne en automatisé.

J’ai généré une paire de clés ed25519 dédiée aux sauvegardes, pas ma clé principale d’admin. J’ai déployé la clé publique sur le compte rsync_user du serveur de stockage, testé la connexion sans mot de passe. Ensuite j’ai arrêté de me poser des questions.

La DNS interne de Proxmox m’a joué un tour. La VM client ne résolvait pas le hostname du serveur. J’ai dû ajouter une entrée dans /etc/hosts et comprendre pourquoi la résolution DNS interne n’était pas configurée. Petit problème, énorme leçon, toujours vérifier les bases avant de compliqué.

Deuxième découverte : rsync n’était pas installé par défaut sur l’installation minimale Debian. which rsync retournait rien. Quelques minutes de débogage avant de saisir l’évidence.

Les scripts de sauvegarde

J’ai écrit 7 scripts au total. Sauvegarde complète stratégie 1, sauvegarde incrémentale 1, restauration incrémentale 1. Pareil pour la stratégie 2. Plus un script de vérification d’espace disque.

Chaque script suit une structure identique. Variables de configuration en tête (faciles à adapter). Vérifications préalables : les répertoires sources existent ? Le serveur SSH est accessible ? Exécution des opérations rsync. Résumé final avec codes de retour. Log horodaté pour chaque exécution.

La partie la plus intéressante techniquement est l’utilisation de --link-dest. rsync compare les fichiers avec la sauvegarde précédente. Pour les fichiers non modifiés, au lieu de les recopier, il crée un hard link. Résultat : chaque répertoire de sauvegarde semble contenir tous les fichiers, mais ils partagent le même inode sur le disque. L’économie d’espace est significative quand tes données bougent peu.

Résultats et cas d’usage

La solution déployée couvre les besoins initiaux. Deux stratégies opérationnelles, 7 scripts fonctionnels, planification automatique, logs structurés, procédures de restauration documentées et testées.

Concrètement : 5 contextes métier sauvegardés en incrémental (SITE, RH, TICKETS, FICHIERS, MAILS). Sauvegarde différentielle des images de VMs en place. Économie d’espace estimée à 60-70% sur les données peu volatiles grâce aux hard links. Temps moyen de restauration d’un contexte métier sous 2 minutes. Logs horodatés pour chaque opération, traçabilité complète.

Les cas d’usage réels vont comme suit. Un fichier est supprimé accidentellement en production. Tu sélectionnes la bonne version dans les incrémentaux et utilises rsync en sens inverse pour la récupérer. Une reprise après sinistre VM : restaure la sauvegarde complète, applique le dernier différentiel.

Leçons : technique et méthodologie

Sur le plan technique, la différence entre incrémentale et différentielle n’est pas juste théorique. Elle détermine directement ton RTO et ton RPO, des métriques critiques en production. Les hard links rsync (--link-dest) sont une optimisation d’espace remarquable, mais il faut vraiment comprendre ce qu’est un inode sous Linux pour ne pas se faire surprendre. Et la gestion des codes de retour rsync importe. Le code 23 correspond à un transfert partiel, tu dois le gérer correctement pour ne pas traiter des erreurs partielles comme des succès.

Sur le plan méthodologique, j’ai eu tendance à vouloir écrire les scripts d’un coup sans tester chaque brique. La bonne approche : teste rsync manuellement d’abord, valide la connexion SSH, puis construis le script autour. Documentation des procédures de restauration, c’est aussi important que celle des sauvegardes, mais on la rédige en dernier, ce qui n’a aucun sens. Préparer une démo technique force à comprendre vraiment ce qu’on a fait. Le fait de devoir expliquer --link-dest en 30 secondes m’a obligé à le vraiment saisir.

Les erreurs courantes : ne pas tester la restauration avant la présentation ou avant d’en avoir besoin en production. Laisser la rétention désactivée, les incrémentaux s’accumulent indéfiniment. Utiliser root pour les opérations rsync, crée un compte dédié avec les permissions minimales.

Ressources

Les scripts et la documentation sont sur GitHub. Si tu entreprends un projet similaire, creuse la documentation rsync, essaie --link-dest sur des données réelles, et teste systématiquement ta restauration avant de l’oublier pendant 6 mois.