Sauvegarde et restauration avec Rsync et Cron

1. Objectif du cours

Mettre en place une stratégie de sauvegarde adaptée à une PME (périmètre, fréquence, supports), automatiser les sauvegardes avec Cron et Rsync via SSH, et vérifier régulièrement la restaurabilité des données.

2. Notions et définitions essentielles

• RPO (Recovery Point Objective) : point dans le temps jusqu'auquel les données doivent pouvoir être récupérées (perte tolérée).
• RTO (Recovery Time Objective) : durée maximale tolérée pour rétablir le service.
• Règle 3-2-1 : trois copies des données, deux supports différents, une copie hors ligne.
• Sauvegarde totale / incrémentale / différentielle : types de jeux de sauvegarde (référence et conséquence sur taille/restauration).
• Rsync : outil de synchronisation local/distant via SSH, préserve (avec options) permissions et structure.
• Cron / crontab : démon et fichiers listant les tâches planifiées.

3. Fonctionnement et principes

• Commencer par recenser avec le responsable métier ce qui doit absolument survivre : application web, base de données, partages, fichiers de configuration.
• Choix de la fréquence guidé par le RPO ; RTO fixe l'urgence de remise en service. Ex. PME : RPO = 24 h, RTO = 4 h.
• Schéma recommandé pour la PME : rotation hebdomadaire (sauvegarde totale le week-end + incrémentales chaque nuit) : bon compromis espace/restauration. Attention : une chaîne incrémentale dépend de chaque maillon — une sauvegarde manquante ou corrompue peut invalider les points suivants.
• Automatisation : Rsync (via SSH) transfère les jeux ; Cron planifie l'exécution. Cron exécute dans un environnement minimal : utiliser chemins absolus ou définir PATH.
• Traçabilité : formaliser la politique (périmètre, fréquence, support, rétention, responsable, fréquence de test) et tenir un registre d'exploitation consignant chaque sauvegarde, anomalies et tests de restauration.

4. Commandes et manipulations

Regrouper les commandes réellement présentes dans le cours avec leur rôle (présentation compacte) : - Gestion de crontab : crontab -e (éditer la crontab utilisateur), crontab -l (lister), crontab -r (supprimer toutes les tâches — suppression immédiate sans confirmation). - Exemple de ligne planification et journalisation : ajouter en fin de ligne >> /var/log/backup.log 2>&1 pour capturer stdout et stderr dans un journal. - Vérification du démon cron : afficher les entrées du journal dédiées au démon (journalctl -u cron --since "yesterday") pour confirmer le déclenchement. - Simulation de l'environnement réduit de Cron : exécuter le script via env -i PATH=/usr/bin:/bin HOME=/root /usr/local/bin/backup.sh pour diagnostiquer dépendances d'environnement. - Rsync (exemples de transfert et restauration) : push/restore via SSH, par exemple /usr/bin/rsync -avz -e ssh backupuser@serveur-prestataire:/backup/ /mnt/restore/ et rsync -avz -e ssh backupuser@serveur-prestataire:/backup/2025-07-13/app/ /var/www/app/ (sens inverse pour restauration). - Contrôle post-exécution et alertes : tester le code de retour ($?) et écrire une ligne d'alerte dans le journal en cas d'échec (bloc if et echo vers /var/log/backup.log). - Tests de restauration : créer répertoire temp (mkdir -p /tmp/restore_test/app), comparer arborescences restaurées avec diff -rq, et lister fichiers/permissions (ls -la) ; redémarrer services via systemctl et vérifier leur état.

5. Sécurité et bonnes pratiques

• Formaliser la politique de sauvegarde et tenir un registre d'exploitation (date, type, résultat, anomalies, tests).
• Appliquer la règle 3-2-1 (copie hors ligne recommandée par ANSSI).
• Ne pas laisser Cron envoyer des sorties non capturées (rediriger stdout et stderr vers un fichier de log).
• Toujours utiliser chemins absolus dans les scripts exécutés par Cron, ou définir PATH en tête du script, car Cron utilise un environnement minimal.
• Simuler l’environnement Cron pour diagnostiquer les échecs silencieux.
• Préserver et vérifier permissions/propriétés après restauration ; redémarrer les services et tester leur fonctionnement avant remise en production.
• Tester régulièrement (mensuel pour les données les plus critiques) et consigner les résultats.

6. Points essentiels à retenir pour le TSSR

• RPO et RTO sont des indicateurs métier à définir avec le client, pas des choix purement techniques.
• Privilégier une rotation hebdomadaire (full + incrémentales) pour limiter la longueur de la chaîne de restauration.
• La sauvegarde n'est réellement fiable que si la restauration est testée et tracée.
• Cron exécute dans un environnement restreint : scripts non reproductibles en session interactive peuvent échouer en planifié.
• Toujours journaliser les exécutions (horodatage début/fin, code de retour) pour détection et diagnostic rapides.
• Une sauvegarde locale seule n'est pas suffisante : prévoir un support secondaire isolé ou hors site.
• Vérifier l’intégrité des snapshots par date et volumétrie après chaque exécution.
• En cas d’échec enregistré (code non nul), consigner et alerter pour intervention.
• Restaurer d’abord dans un emplacement neutre pour valider avant écrasement de la production.
• Contrôler permissions/ownership avant de remettre un service en production.

7. Tableau récapitulatif

Élément comparé	Totale	Incrémentale	Différentielle
Point de référence	Aucun (jeu complet)	Dernière sauvegarde (totale ou incrémentale)	Dernière sauvegarde totale
Taille du jeu	Max	Minimale	Croissante au fil des jours
Vitesse de restauration	Très rapide (1 jeu)	Plus lente (1 totale + N incrémentales)	Rapide (1 totale + 1 différentielle)
Risque de chaîne	Faible	Dépend fortement de chaque maillon	Limité (dépend uniquement de la totale + dernière)

8. Vérifications pratiques

(énoncées sans recopier intégralement les commandes déjà listées) - Confirmer le déclenchement : consulter le journal du démon cron pour la journée concernée. - Vérifier traces du script : contrôler le journal du backup pour les horodatages début/fin et le code de retour. - Consulter le répertoire de destination : s'assurer de la présence des snapshots récents et vérifier leurs dates de modification. - Comparer la taille du snapshot avec les exécutions précédentes pour détecter une sauvegarde partielle ou un problème de montage. - Simuler l’environnement Cron localement pour reproduire un échec silencieux et détecter dépendances manquantes. - Test de restauration : restaurer dans un emplacement neutre, comparer récursivement l’arborescence restaurée à la référence, puis analyser écarts. - Après restauration, contrôler propriété et permissions des fichiers critiques, redémarrer les services concernés et vérifier leur état et réponse applicative. - Consigner chaque vérification et test dans le registre d'exploitation (date, snapshot, périmètre, résultat, technicien).

9. Flashcards Anki

Que signifie RPO ? :: Recovery Point Objective — durée maximale de données tolérée à perdre
Que signifie RTO ? :: Durée maximale tolérée pour rétablir le service après un incident
Quelles exigences impose la règle 3-2-1 ? :: Trois copies des données, deux supports différents, une copie hors ligne
Quels périmètres sont listés pour la PME ? :: Application web (/var/www/html), BDD (/var/lib/mysql), partages (/home/partages), config (/etc/)
Quelle rotation hebdomadaire est proposée pour la PME ? :: Sauvegarde totale le dimanche et incrémentales chaque nuit du lundi au samedi
Que sauvegarde une stratégie incrémentale ? :: Les données modifiées depuis la dernière sauvegarde (totale ou incrémentale)
Quel rôle remplit Cron ? :: Démon qui lit une liste de tâches planifiées et les exécute au moment voulu
Combien de champs temporels contient une crontab utilisateur ? :: Cinq champs temporels
Pourquoi utiliser des chemins absolus dans les scripts Cron ? :: Parce que l'environnement de Cron est réduit (PATH limité), sinon les binaires peuvent être introuvables
Quelle commande compare récursivement deux répertoires et n'affiche que les différences ? :: diff -rq