Automatisation d'une solution de sauvegarde sous Linux

Projet en bref

Contexte

Ce projet répond au besoin d’une organisation disposant de données aux profils très différents : fichiers métiers régulièrement modifiés, messagerie, contenus web et images de machines virtuelles plus volumineuses.

L’objectif était de concevoir une solution capable d’adapter la fréquence et la durée de conservation à chaque type de donnée, sans appliquer une stratégie unique trop coûteuse ou insuffisante. Le laboratoire devait également permettre de restaurer rapidement une version récente, un fichier précis ou un ensemble complet de données.

Les données, noms et volumes utilisés sont simulés. L’environnement peut ainsi être déployé et démontré sans exposer d’informations réelles.

Objectifs techniques

• Automatiser le déploiement d’une infrastructure de sauvegarde à deux serveurs ;
• définir des stratégies adaptées aux données courantes et volumineuses ;
• limiter l’espace consommé par les versions successives ;
• sécuriser les transferts et le compte de stockage selon le principe du moindre privilège ;
• fournir des procédures de restauration compréhensibles et reproductibles.

Architecture retenue

Le laboratoire sépare la production des sauvegardes de leur stockage :

flowchart LR
  COURANTES_SRC[/Données courantes<br/>Site · RH · Tickets · Fichiers · Mails/]
  VOLUMINEUSES_SRC[/Données volumineuses<br/>Images de machines virtuelles/]

  SAUVEGARDE[[Sauvegardes automatisées<br/>cron · serveur source]]
  ROTATION[[Rotation des archives<br/>cron · serveur de stockage]]
  RESTAURATION[[Restauration à la demande<br/>serveur source]]

  SNAPSHOTS_ACTIFS[(Snapshots incrémentaux actifs<br/>version actuelle · version précédente)]
  ARCHIVES[(Archives incrémentales<br/>rétention progressive)]
  COMPLETE[(Sauvegarde complète<br/>référence mensuelle)]
  DIFFERENTIELLE[(Sauvegarde différentielle<br/>état quotidien)]

  SORTIE([Données restaurées<br/>espace de validation])

  JOURNAL_SAUVEGARDE([Journal des sauvegardes])
  JOURNAL_RESTAURATION([Journal des restaurations])
  JOURNAL_ROTATION([Journal de rotation])
  TRACE_INC_SAUVEGARDE([Trace des transferts<br/>incrémentaux])
  TRACE_VOL_SAUVEGARDE([Trace des transferts<br/>volumineux])
  TRACE_INC_RESTAURATION([Trace des restaurations<br/>incrémentales])
  TRACE_VOL_RESTAURATION([Trace des restaurations<br/>volumineuses])

  COURANTES_SRC -.- SAUVEGARDE
  VOLUMINEUSES_SRC -.- SAUVEGARDE

  SAUVEGARDE -->|rsync link-dest + SSH durci| SNAPSHOTS_ACTIFS
  SAUVEGARDE -->|archive les versions antérieures| ARCHIVES
  SAUVEGARDE -->|initiale puis mensuelle| COMPLETE
  SAUVEGARDE -->|quotidienne| DIFFERENTIELLE
  COMPLETE -. référence link-dest .-> DIFFERENTIELLE

  SAUVEGARDE --> JOURNAL_SAUVEGARDE
  SAUVEGARDE --> TRACE_INC_SAUVEGARDE
  SAUVEGARDE --> TRACE_VOL_SAUVEGARDE

  ROTATION --> JOURNAL_ROTATION
  ROTATION -->|horaire · quotidienne · hebdomadaire| ARCHIVES

  SNAPSHOTS_ACTIFS -.- RESTAURATION
  DIFFERENTIELLE -.- RESTAURATION
  COMPLETE -.- RESTAURATION
  RESTAURATION --> SORTIE
  RESTAURATION --> JOURNAL_RESTAURATION
  RESTAURATION --> TRACE_INC_RESTAURATION
  RESTAURATION --> TRACE_VOL_RESTAURATION

  classDef source fill:#eaf4ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
  classDef process fill:#fff7ed,stroke:#c2410c,stroke-width:1.5px,color:#1f2937;
  classDef storage fill:#ecfdf5,stroke:#047857,stroke-width:1.5px,color:#0f172a;
  classDef output fill:#f5f3ff,stroke:#6d28d9,stroke-width:1.5px,color:#0f172a;
  classDef log fill:#fef9c3,stroke:#a16207,stroke-width:1.5px,color:#1f2937;

  class COURANTES_SRC,VOLUMINEUSES_SRC source;
  class SAUVEGARDE,ROTATION,RESTAURATION process;
  class SNAPSHOTS_ACTIFS,ARCHIVES,COMPLETE,DIFFERENTIELLE storage;
  class SORTIE output;
  class JOURNAL_SAUVEGARDE,JOURNAL_RESTAURATION,JOURNAL_ROTATION,TRACE_INC_SAUVEGARDE,TRACE_VOL_SAUVEGARDE,TRACE_INC_RESTAURATION,TRACE_VOL_RESTAURATION log;

Le serveur source initie tous les échanges. Le serveur de stockage n’expose qu’un accès SSH par clé à un compte dédié, sans privilèges d’administration. La clé autorisée est limitée à l’adresse IP du serveur source et ne permet ni terminal interactif ni redirection de flux.

Travaux réalisés

Infrastructure

• Description de deux machines Ubuntu Server avec Vagrant ;
• configuration d’un réseau privé avec des adresses fixes ;
• ajout d’un disque virtuel de 100 Go au serveur de stockage ;
• génération automatique de jeux de données et de cinq images de machines virtuelles totalisant 7 Gio.

Sauvegarde des données courantes

• Création de snapshots incrémentaux avec rsync --link-dest ;
• utilisation de liens physiques pour réutiliser les fichiers inchangés ;
• maintien des deux versions les plus récentes dans un espace actif ;
• archivage automatique des versions antérieures ;
• définition de cinq politiques de rétention adaptées aux données.

Sauvegarde des données volumineuses

• Création d’une référence complète mensuelle ;
• génération d’un état différentiel quotidien fondé sur cette référence ;
• remplacement atomique de l’état courant pour éviter d’exposer une sauvegarde partielle ;
• sélection automatique de la meilleure source lors d’une restauration.

Sécurité

• Authentification SSH par clé Ed25519 ;
• compte de sauvegarde dédié, sans accès sudo ;
• restriction de la clé à l’adresse IP du serveur source ;
• désactivation du TTY, des tunnels et des redirections SSH ;
• validation des chemins relatifs fournis au script de restauration.

Exploitation et documentation

• Planification distincte de chaque cible avec cron ;
• rotation quotidienne des archives sur le serveur de stockage ;
• séparation des journaux d’orchestration et des traces rsync ;
• documentation des scripts, des modes de restauration et d’une procédure de récupération de fichier.

Difficultés et choix techniques

Adapter la rétention à la valeur des données

Les données ne présentent ni la même fréquence de modification ni la même durée d’utilité. Les courriels conservent toutes leurs versions pendant 48 heures, puis une version par jour jusqu’à 60 jours et une par semaine jusqu’à 180 jours. Les données RH disposent d’une conservation hebdomadaire étendue à un an.

Cette rétention progressive offre des points de restauration rapprochés pour les incidents récents tout en maîtrisant l’occupation disque sur le long terme.

Publier uniquement des sauvegardes terminées

Chaque transfert s’effectue d’abord dans un répertoire .inflight-*. Ce répertoire n’est renommé et défini comme version courante qu’après la réussite de rsync.

Ce mécanisme évite qu’une interruption réseau ou système fasse apparaître une copie incomplète comme dernière sauvegarde valide.

Restaurer d’abord dans un espace de validation

La procédure de restauration d’un fichier utilise un répertoire intermédiaire. L’administrateur contrôle la version récupérée, conserve si nécessaire une copie de l’état actuel, puis remet le fichier validé à son emplacement final.

Cette approche réduit le risque qu’une opération de récupération aggrave un incident.

Conserver plusieurs versions sans dupliquer toutes les données

Problème — Coût des snapshots successifs

Une copie complète à chaque fréquence aurait multiplié les besoins de stockage, en particulier pour les cibles sauvegardées plusieurs fois par jour.

Solution et résultat : l’option --link-dest de rsync crée une vue complète à chaque sauvegarde tout en reliant physiquement les fichiers inchangés au snapshot précédent. Chaque version reste lisible de façon autonome, tandis que seuls les changements consomment un nouvel espace.

Supprimer les anciennes versions sans fragiliser les sauvegardes actives

Problème — Rotation et intégrité

La rétention devait réduire progressivement le nombre de snapshots sans toucher aux deux versions destinées à une restauration rapide.

Solution et résultat : les snapshots n et n-1 restent dans un espace actif. Les versions antérieures sont déplacées dans une archive dédiée, sur laquelle l’algorithme conserve toutes les versions récentes, puis une version par jour et enfin une par semaine. La suppression d’un lien physique n’affecte pas les fichiers encore référencés.

Éviter qu’un transfert interrompu devienne la référence

Problème — Visibilité d’une sauvegarde partielle

Un échec pendant le transfert ne devait pas modifier le pointeur vers la dernière version exploitable.

Solution et résultat : les nouvelles sauvegardes sont construites dans un emplacement temporaire, puis publiées par renommage. Le lien current n’est mis à jour qu’après la réussite de l’opération.

Sécuriser l’automatisation sans bloquer les traitements

Problème — Accès non interactif au stockage

Les tâches planifiées avaient besoin d’un accès autonome au serveur de stockage, sans mot de passe en clair ni droits excessifs.

Solution et résultat : une paire de clés dédiée et un compte sans sudo permettent l’exécution non interactive. Des options appliquées à la clé et au service SSH limitent sa provenance et interdisent les usages qui ne sont pas nécessaires aux sauvegardes.

Résultats

Le projet fournit un environnement démontrable de bout en bout : provisionnement, génération des données, exécution planifiée, conservation à plusieurs niveaux, restauration et traçabilité.

Compétences démontrées

• Administration de serveurs Ubuntu ;
• automatisation d’une infrastructure avec Vagrant ;
• scripting Bash robuste avec validation des entrées et gestion des erreurs ;
• conception de sauvegardes incrémentales et différentielles ;
• utilisation avancée de rsync et des liens physiques ;
• planification de traitements avec cron ;
• sécurisation d’échanges par SSH ;
• application du principe du moindre privilège ;
• définition de politiques de rétention ;
• rédaction de procédures d’exploitation et de restauration.

Retour d’expérience

Ce projet m’a permis de comprendre qu’une stratégie de sauvegarde ne se limite pas à copier des fichiers. Elle doit mettre en relation la criticité des données, leur fréquence de modification, l’espace disponible et le temps nécessaire pour les restaurer.

La séparation entre snapshots actifs et archives m’a également montré l’intérêt de distinguer la restauration opérationnelle immédiate de la conservation à plus long terme. Enfin, la création d’une procédure ciblée confirme qu’une sauvegarde n’a de valeur que si sa restauration est simple, traçable et suffisamment sûre pour être exécutée pendant un incident. Pour aller plus loin, j’ajouterais une copie hors site chiffrée, une supervision centralisée avec alertes, des contrôles d’intégrité et des tests de restauration automatisés exécutés à intervalles réguliers.