🔄 PCA/PRA — RTO, RPO & BorgBackup
| Formation | BTS SIO option SISR — IRIS Mediaschool |
|---|---|
| Bloc | B3 — Cybersécurité des services informatiques |
| Module | M3.4 — Disponibilité, intégrité et confidentialité |
| Durée | 3h30 (10 min accroche · 75 min théorie · 85 min TP · 10 min synthèse) |
| Prérequis | C3.4.2 — Veille vulnérabilités et patch management |
| Contexte | InnovatTech 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
| Plan | Objectif | Exemple |
|---|---|---|
| PCA | Maintenir l'activité en mode dégradé pendant la crise | Mise à disposition de postes de remplacement, copie locale des données |
| PRA | Reprendre l'activité normale après une interruption totale | Procé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
| Service | RTO max | RPO max | Impact horaire estimé | Dépendances |
|---|---|---|---|---|
| Messagerie | 2 h | 1 h | 300 €/h | DNS, réseau, AD |
| CRM (ventes) | 4 h | 1 h | 1 200 €/h | DB, AD, NAS |
| Active Directory | 4 h | 1 h | 500 €/h | DNS, AD secondaires |
| Site web | 8 h | 24 h | 150 €/h | DNS, serveur web, DB |
| NAS (fichiers) | 24 h | 1 h | 800 €/h | Réseau, sauvegardes |
| ERP (compta) | 8 h | 1 h | 700 €/h | DB, NAS, AD |
| VPN | 4 h | 24 h | 200 €/h | Firewall, gateway |
| DNS interne | 2 h | 1 h | 150 €/h | AD, 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
| Type | Contenu sauvegardé | Avantage | Inconvénient |
|---|---|---|---|
| Full | Toutes les données | Restauration rapide et simple | Longue, volumineuse |
| Incrémentale | Changements depuis la dernière sauvegarde | Rapide, économe en espace | Restauration longue (full + toutes les incrémentielles) |
| Différentielle | Changements depuis la dernière Full | Restauration simple (full + dernière diff) | Taille croissante entre deux fulls |
| Snapshot | État instantané (LVM, ZFS, hyperviseur) | Très rapide, cohérence garantie | Dé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
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
- Si le CRM d'InnovatTech a un RPO de 1 heure, quelle fréquence de sauvegarde est nécessaire au minimum ?
- Quelle est la règle de sauvegarde "3-2-1-1" et pourquoi la copie "+1" est-elle essentielle contre les ransomwares ?
- Quelle caractéristique de BorgBackup permet de n'enregistrer que les blocs de données modifiés, réduisant l'espace disque ?
- Vrai ou Faux — Le RTO définit la quantité maximale de données qu'on peut perdre, exprimée en durée.
- Comment la BIA (Business Impact Analysis) permet-elle de définir l'ordre de priorité de restauration des services ?
📝 Afficher les corrections
- 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.
- 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.
- 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.
- 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.
- 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.
