🔄 PCA/PRA — RTO, RPO & BorgBackup

Bloc 3 Module 3.4 Séance 1/2 BTS SIO SISR
FormationBTS SIO option SISR — IRIS Mediaschool
BlocB3 — Cybersécurité des services informatiques
ModuleM3.4 — Disponibilité, intégrité et confidentialité
Durée3h30 (10 min accroche · 75 min théorie · 85 min TP · 10 min synthèse)
PrérequisC3.4.2 — Veille vulnérabilités et patch management
ContexteInnovatTech SARL — Debian 12, NAS Synology, données clients critiques

🎯 Objectifs

  • Distinguer PCA (maintenir l'activité) et PRA (reprendre l'activité)
  • Définir des RTO et RPO réalistes via une Business Impact Analysis (BIA)
  • Maîtriser la règle de sauvegarde 3-2-1 et son extension 3-2-1-1 (immuable)
  • Installer et utiliser BorgBackup (déduplication, chiffrement, rétention)
  • Automatiser les sauvegardes via cron

🔥 Accroche — Hôpital André-Mignot (décembre 2022)

Le 3 décembre 2022, l'hôpital André-Mignot (Versailles) est victime d'un ransomware du groupe VICE SOCIETY. Systèmes chiffrés, déprogrammation d'opérations, transferts de patients. La reprise complète a duré 3 mois. L'enquête a montré qu'un PRA non testé et des sauvegardes insuffisantes ont largement contribué à l'ampleur du sinistre. Pour une PME comme InnovatTech, un incident similaire peut conduire à la cessation d'activité.

📖 Section 1 — PCA, PRA et analyse d'impact

PCA vs PRA

PlanObjectifExemple
PCAMaintenir l'activité en mode dégradé pendant la criseMise à disposition de postes de remplacement, copie locale des données
PRAReprendre l'activité normale après une interruption totaleProcédures de restauration des serveurs, scripts d'automatisation, priorités

RTO et RPO

  • RTO (Recovery Time Objective) — temps maximal d'interruption tolérable. Question : combien de temps puis-je me passer de ce service ?
  • RPO (Recovery Point Objective) — perte de données maximale tolérable, exprimée en durée. Question : combien de données puis-je me permettre de perdre ?

BIA — Business Impact Analysis InnovatTech

ServiceRTO maxRPO maxImpact horaire estiméDépendances
Messagerie2 h1 h300 €/hDNS, réseau, AD
CRM (ventes)4 h1 h1 200 €/hDB, AD, NAS
Active Directory4 h1 h500 €/hDNS, AD secondaires
Site web8 h24 h150 €/hDNS, serveur web, DB
NAS (fichiers)24 h1 h800 €/hRéseau, sauvegardes
ERP (compta)8 h1 h700 €/hDB, NAS, AD
VPN4 h24 h200 €/hFirewall, gateway
DNS interne2 h1 h150 €/hAD, DHCP

Règle de sauvegarde 3-2-1 et 3-2-1-1

  • 3 copies des données (originale + 2 sauvegardes)
  • 2 supports différents (ex. NAS local + cloud)
  • 1 copie hors-site (protection contre incendie, vol, catastrophe locale)
  • +1 copie immuable/offline (protection ransomware — Object Lock S3 ou Borg append-only)

Types de sauvegardes

TypeContenu sauvegardéAvantageInconvénient
FullToutes les donnéesRestauration rapide et simpleLongue, volumineuse
IncrémentaleChangements depuis la dernière sauvegardeRapide, économe en espaceRestauration longue (full + toutes les incrémentielles)
DifférentielleChangements depuis la dernière FullRestauration simple (full + dernière diff)Taille croissante entre deux fulls
SnapshotÉtat instantané (LVM, ZFS, hyperviseur)Très rapide, cohérence garantieDépend du système de stockage

📖 Section 2 — BorgBackup : déduplication et chiffrement

BorgBackup propose : déduplication au niveau des blocs, compression (lz4, zstd), chiffrement AES-256 et authentification HMAC. Léger, scriptable et idéal pour les PME.

# Initialiser un dépôt chiffré local
borg init --encryption=repokey /mnt/backup/innovattech-backup

# Ou vers un serveur distant via SSH
borg init --encryption=repokey ssh://backup-server/backup/innovattech

# Créer une sauvegarde (archive)
borg create \
  --verbose --stats \
  --compression lz4 \
  /mnt/backup/innovattech-backup::{hostname}-{now:%Y-%m-%dT%H:%M:%S} \
  /var/www /home /etc /srv

# Lister les archives
borg list /mnt/backup/innovattech-backup

# Vérifier l'intégrité du dépôt
borg check /mnt/backup/innovattech-backup

# Restaurer une archive complète
borg extract /mnt/backup/innovattech-backup::innovattech-2024-02-20T08:00:00

# Restaurer un fichier spécifique
borg extract /mnt/backup/innovattech-backup::innovattech-2024-02-20T08:00:00 \
  var/www/html/config.php

# Politique de rétention (7 quotidiennes, 4 hebdomadaires, 12 mensuelles)
borg prune \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=12 \
  /mnt/backup/innovattech-backup

Script d'automatisation Borg

#!/bin/bash
# /usr/local/bin/innovattech-borg-backup.sh
set -o errexit ; set -o nounset ; set -o pipefail

REPO="/mnt/backup/innovattech-backup"
ARCHIVE_NAME="$(hostname -s)-$(date +%Y-%m-%dT%H:%M:%S)"
LOGFILE="/var/log/innovattech-borg-backup.log"

log() { echo "$(date -Is) - $*" | tee -a "$LOGFILE"; }
log "=== Début sauvegarde: $ARCHIVE_NAME ==="

borg create --verbose --stats --compression lz4 \
  "$REPO::$ARCHIVE_NAME" /etc /var/www /home >> "$LOGFILE" 2>&1 \
  && log "Sauvegarde OK" \
  || { log "ERREUR sauvegarde"; exit 2; }

borg prune "$REPO" --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \
  >> "$LOGFILE" 2>&1 && log "Prune OK"

borg check "$REPO" >> "$LOGFILE" 2>&1 && log "Vérification OK"
log "=== Fin sauvegarde ==="
# Planifier via cron (tous les jours à 02:00)
# 0 2 * * * root /usr/local/bin/innovattech-borg-backup.sh

🛠️ TP — BIA, stratégie de sauvegarde et BorgBackup (85 min)

Partie 1 — BIA et stratégie (45 min)

Compléter le tableau BIA pour chaque service d'InnovatTech. Identifier les 3 services les plus critiques et justifier la stratégie de sauvegarde 3-2-1 appliquée à chacun.

Partie 2 — BorgBackup en pratique (35 min)

# Installer BorgBackup
sudo apt update && sudo apt install -y borgbackup

# Initialiser un dépôt de test local
sudo borg init --encryption=repokey /tmp/test-backup-innov

# Créer une sauvegarde de test
borg create /tmp/test-backup-innov::test-$(date +%Y%m%d) /etc /var/log

# Lister et vérifier
borg list /tmp/test-backup-innov
borg check /tmp/test-backup-innov

# Test de restauration — supprimer un fichier et le restaurer
sudo rm /etc/hostname
cd /tmp && borg extract /tmp/test-backup-innov::test-$(date +%Y%m%d) etc/hostname
sudo cp /tmp/etc/hostname /etc/hostname
hostname  # Vérifier

💬 Synthèse — Question finale

Quelle est la différence opérationnelle entre RTO et RPO ? Exemple avec le CRM d'InnovatTech.

RTO = durée maximale d'indisponibilité tolérable. RPO = âge maximal des données tolérable (fenêtre de perte). Pour le CRM : RTO = 4h (les commerciaux peuvent travailler sans CRM pendant 4h), RPO = 1h (on ne peut pas perdre plus d'1h de transactions). Stratégie associée : sauvegardes horaires + réplication des journaux de transaction.

📝 QCM — Testez vos connaissances

  1. Si le CRM d'InnovatTech a un RPO de 1 heure, quelle fréquence de sauvegarde est nécessaire au minimum ?
  2. Quelle est la règle de sauvegarde "3-2-1-1" et pourquoi la copie "+1" est-elle essentielle contre les ransomwares ?
  3. Quelle caractéristique de BorgBackup permet de n'enregistrer que les blocs de données modifiés, réduisant l'espace disque ?
  4. Vrai ou Faux — Le RTO définit la quantité maximale de données qu'on peut perdre, exprimée en durée.
  5. Comment la BIA (Business Impact Analysis) permet-elle de définir l'ordre de priorité de restauration des services ?
📝 Afficher les corrections
  1. Sauvegardes toutes les heures (sauvegardes horaires) — le RPO de 1h signifie qu'on peut perdre au maximum 1h de données. Si la sauvegarde est quotidienne et qu'un incident survient en fin de journée, on perd jusqu'à 23h de transactions — inacceptable pour un CRM.
  2. 3 copies, 2 supports différents, 1 hors-site, 1 immuable/offline — la copie "+1" immuable (WORM, Object Lock S3 ou Borg append-only) ne peut pas être modifiée ou supprimée par un ransomware depuis le réseau. Elle garantit une restauration même si l'attaquant a compromis les accès aux autres sauvegardes.
  3. La déduplication au niveau des blocs — BorgBackup compare les blocs de données et ne stocke que les blocs nouveaux ou modifiés. Les blocs identiques entre archives sont référencés une seule fois, réduisant drastiquement l'espace disque et la bande passante pour les transferts hors-site.
  4. Faux — le RPO (Recovery Point Objective) définit la perte de données maximale tolérable. Le RTO (Recovery Time Objective) définit le temps maximal d'indisponibilité tolérable. Ces deux concepts sont souvent confondus mais répondent à des questions différentes.
  5. La BIA identifie les services les plus critiques et leur coût horaire d'indisponibilité — les services avec le coût d'arrêt le plus élevé et le plus de dépendances (ex. AD → tous les services en dépendent) sont restaurés en priorité. Cela permet de définir l'ordre de restauration dans le PRA.
← C3.4.2 Séance 2 C3.4.3 Séance 2 →