1. Objectifs : RPO, RTO, RTA, MTD et BIA

Une stratégie de sauvegarde ne se conçoit pas à partir d'un outil mais à partir d'objectifs métier chiffrés. Les outils (Veeam, Proxmox Backup Server, restic...) ne sont que des moyens d'atteindre ces objectifs.

1.1 Définitions

Terme	Définition	Ce qui le détermine techniquement
RPO (Recovery Point Objective)	Perte de données maximale admissible, exprimée en temps	Fréquence des sauvegardes, réplication, journaux de transactions
RTO (Recovery Time Objective)	Durée maximale admissible entre l'incident et le retour du service	Débit de restauration, Instant Recovery, site de secours, runbooks
RTA (Recovery Time Actual)	Durée mesurée lors d'un test ou d'un incident réel	Tests de restauration : seul chiffre qui fait foi
MTD (Maximum Tolerable Downtime)	Durée au-delà de laquelle l'activité subit un dommage inacceptable (financier, légal, réputation)	Décision métier ; RTO + temps de vérification/reprise doit rester < MTD
WRT (Work Recovery Time)	Temps de remise en conditions métier après restauration technique (ressaisie, contrôles)	Procédures métier ; MTD = RTO + WRT

1.2 BIA (Business Impact Analysis) : méthode

1. Lister les processus métier (facturation, production, paie, support client...) et non les serveurs.
2. Pour chaque processus, évaluer l'impact dans le temps d'une interruption (1 h, 4 h, 1 j, 3 j, 1 sem) : financier, contractuel (pénalités SLA), réglementaire, image.
3. En déduire MTD, puis RTO et RPO cibles.
4. Cartographier les dépendances techniques : applications, bases, partages, AD/DNS, réseau, SaaS, prestataires.
5. Attribuer une classe de service à chaque actif (tableau ci-dessous).
6. Faire valider et signer par la direction : c'est elle qui accepte le risque résiduel et le budget.

1.3 Classes de service type

Classe	Exemples	RPO	RTO	Moyens typiques
Critique (Tier 0/1)	AD, DNS, ERP, base de production	≤ 15 min	≤ 4 h	Réplication + sauvegarde horaire + PITR + Instant Recovery
Important (Tier 2)	Fichiers, intranet, applications métier secondaires	≤ 24 h	≤ 24 h	Sauvegarde quotidienne, copie externalisée
Standard (Tier 3)	Environnements de test, archives	≤ 7 j	≤ 5 j	Sauvegarde hebdomadaire ou reconstruction par IaC
Reconstructible	Serveurs décrits en Ansible/Terraform, conteneurs	N/A (code et données sauvegardés séparément)	Temps de déploiement	Git + sauvegarde des seules données

2. Règle 3-2-1-1-0 et architecture cible

2.1 La règle

Chiffre	Exigence	Menace couverte
3	3 copies des données (production + 2 sauvegardes)	Défaillance d'une copie
2	Sur 2 supports ou technologies différents	Défaut commun (firmware, bug du stockage, même baie)
1	1 copie hors site	Sinistre physique (incendie, inondation, vol)
1	1 copie immuable ou déconnectée	Rançongiciel, administrateur malveillant, compte compromis
0	0 erreur aux vérifications de restauration	Sauvegarde corrompue découverte le jour du sinistre

2.2 Architecture de référence (PME/ETI)

   Site principal                         Site secondaire / cloud
 +-------------------------+            +------------------------------+
 | Production (VM, BDD)    |            | Dépôt secondaire               |
 |        |                |  copie     | (PBS distant / Linux durci / |
 |        v                |  chiffrée  |  S3 Object Lock COMPLIANCE)  |
 | Dépôt primaire (rapide)  | ---------> | rétention longue, immuable    |
 | rétention courte 14-30 j |   (pull de |                              |
 | Instant Recovery        |   préférence)+------------------------------+
 +-------------------------+
            |
            +--> Bande LTO / disque rotatif déconnecté (air gap), mensuel

• Copie primaire locale : optimisée pour le RTO (disques rapides, restauration instantanée).
• Copie secondaire : optimisée pour la survie (hors site, immuable, autre domaine d'administration).
• Copie tertiaire hors ligne : dernière ligne de défense, acceptée lente.
• Le flux vers la copie secondaire se fait idéalement en pull : le site secondaire vient chercher les données ; un attaquant sur le site principal n'a donc aucun identifiant pour le détruire.

2.3 Choix des supports

Support	Forces	Faiblesses	Rôle
Disque local / SAN	Très rapide, Instant Recovery	Dans le même domaine de défaillance et d'administration	Copie primaire
NAS (SMB/NFS)	Simple, bon marché	Partage monté = chiffrable par le rançongiciel ; identifiants souvent réutilisés	À éviter comme seule cible
Linux durci (XFS reflink, immuabilité)	Immuable, rapide, maîtrisé	Demande une rigueur d'exploitation (pas de SSH, accès console)	Primaire ou secondaire
Objet S3 avec Object Lock	Immutabilité contractuelle, hors site, élastique	Coût de sortie (egress), latence de restauration	Secondaire
Bande LTO	Hors ligne natif, coût/To faible, longévité	Lente, gestion physique, compatibilité des lecteurs (générations)	Tertiaire, archives
Disque USB rotatif	Air gap simple	Erreur humaine, fiabilité, pas d'automatisation	Petites structures

3. Types de sauvegarde et chaînes

Type	Principe	Volume par passe	Restauration	Risque
Complète	Copie intégrale	Maximal	1 seul jeu	Fenêtre longue, stockage
Incrémentale	Changements depuis la dernière sauvegarde (quelle qu'elle soit)	Minimal	Complète + toutes les incrémentales	Un maillon corrompu casse la suite de la chaîne
Différentielle	Changements depuis la dernière complète	Croît jusqu'à la complète suivante	Complète + dernière différentielle	Volume croissant
Incrémentale permanente (forever forward)	Une complète initiale puis uniquement des incrémentales ; la plus ancienne est fusionnée dans la complète à l'expiration	Minimal	Chaîne reconstituée	Fusion coûteuse en E/S ; dépend de la santé de la complète
Synthétique complète	Complète reconstruite sur le dépôt à partir des incrémentales, sans relire la production	Nul côté source	1 seul jeu	Charge E/S du dépôt (neutralisée par le block cloning XFS/ReFS)
Dédupliquée par blocs (restic, Borg, PBS)	Chaque sauvegarde est un instantané complet logique ; seuls les blocs nouveaux sont écrits	Minimal	Un instantané = vue complète	Index/métadonnées critiques : leur corruption touche tout le dépôt

3.1 Suivi des changements

• CBT (VMware Changed Block Tracking), RCT (Hyper-V Resilient Change Tracking), dirty bitmaps QEMU (Proxmox) : l'hyperviseur sait quels blocs ont changé ; pas besoin de relire tout le disque.
• Un bitmap perdu (redémarrage de VM sur Proxmox, réinitialisation CBT) force une relecture complète : sauvegarde nettement plus longue mais pas plus grosse si le dépôt déduplique.
• Fichiers : le scan des métadonnées (taille, mtime, inode) suffit pour restic/Borg ; sur des millions de petits fichiers, c'est le parcours, pas le transfert, qui domine.

4. Cohérence applicative : VSS, quiesce, dumps, PITR

4.1 Niveaux de cohérence

Niveau	Obtenu par	État à la restauration
Crash-consistent	Snapshot brut du disque	Comme après une coupure de courant : le moteur rejoue son journal ; acceptable pour beaucoup de charges, risqué pour certaines
File-system consistent	Gel du FS (fsfreeze via qemu-guest-agent, VMware Tools)	FS propre, mais transactions applicatives en vol possibles
Application-consistent	VSS writers (Windows), scripts pre/post (Linux), dump natif	Base propre, journaux tronqués correctement

4.2 Windows : VSS

REM État des writers (tous doivent être "Stable" / "No error")
vssadmin list writers

REM Espace des clichés et fournisseurs
vssadmin list shadowstorage
vssadmin list providers

REM Redémarrer le service associé à un writer en échec (ex. SQL Server VSS Writer)
net stop SQLWriter && net start SQLWriter

Un writer en Failed / Retryable error donne une sauvegarde au mieux crash-consistent. Exchange, SQL Server et AD (writer NTDS) ont besoin du traitement applicatif côté logiciel de sauvegarde pour tronquer leurs journaux ; sans cela, les journaux de transactions grossissent jusqu'à saturer le disque.

4.3 Linux : quiesce et scripts pre/post

# Proxmox : activer l'agent invité (nécessite qemu-guest-agent dans la VM)
qm set 101 --agent enabled=1,fstrim_cloned_disks=1
qm agent 101 ping

# Dans la VM : hook exécuté par l'agent au gel / dégel (selon distribution)
#   /etc/qemu/fsfreeze-hook  et  /etc/qemu/fsfreeze-hook.d/*.sh
# Exemple : vider les tables MySQL avant gel
#!/bin/sh
case "$1" in
  freeze) mysql -e "FLUSH TABLES WITH READ LOCK; SYSTEM sleep 1;" ;;
  thaw)   : ;;
esac

4.4 Bases de données : dumps et sauvegardes physiques

Moteur	Logique	Physique / à chaud	PITR
MySQL / MariaDB	mysqldump --single-transaction, mydumper	Percona XtraBackup, mariadb-backup	Binlogs (mysqlbinlog)
PostgreSQL	pg_dump -Fc, pg_dumpall --globals-only	pg_basebackup, pgBackRest, Barman	Archivage WAL
SQL Server	BACPAC (structure + données)	BACKUP DATABASE FULL/DIFF	BACKUP LOG (modèle FULL)

Voir aussi MySQL, PostgreSQL et SQL Server.

4.5 PITR MySQL avec binlogs

# my.cnf - prérequis
[mysqld]
server_id        = 1
log_bin          = /var/lib/mysql-binlog/binlog
binlog_format    = ROW
binlog_expire_logs_seconds = 1209600   # 14 jours (MySQL 8+)
sync_binlog      = 1

# Sauvegarde complète quotidienne cohérente avec position binlog
mysqldump --single-transaction --routines --triggers --events \
  --source-data=2 --all-databases | zstd -T0 > /backup/mysql/full-$(date +%F).sql.zst
# (--source-data remplace --master-data à partir de MySQL 8.0.26)

# Copier les binlogs fermés vers le dépôt toutes les 5 min (RPO ~5 min)
mysql -e "FLUSH BINARY LOGS"
rsync -a --exclude "$(tail -n1 /var/lib/mysql-binlog/binlog.index | xargs basename)" \
  /var/lib/mysql-binlog/ backup@backup.example.com:/srv/binlogs/db01/

# Restauration à 14:32:00 (juste avant un DROP malheureux)
zstd -dc full-2026-10-19.sql.zst | mysql
# Lire la position de départ dans l'en-tête du dump (CHANGE REPLICATION SOURCE TO ... / CHANGE MASTER TO ...)
mysqlbinlog --start-position=157 --stop-datetime="2026-10-19 14:32:00" \
  binlog.000412 binlog.000413 | mysql

4.6 PITR PostgreSQL avec archivage WAL

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /srv/wal/%f && cp %p /srv/wal/%f'   # démonstration ; en prod : pgBackRest
archive_timeout = 300                                            # force un segment toutes les 5 min

# Sauvegarde de base
pg_basebackup -D /backup/pg/base-$(date +%F) -Ft -z -Xs -P -U replicator -h db01.example.com

# Restauration (PostgreSQL 12+) : extraire la base, puis dans postgresql.conf
restore_command = 'cp /srv/wal/%f %p'
recovery_target_time = '2026-10-19 14:32:00+02'
recovery_target_action = 'promote'
# et créer le fichier signal
touch $PGDATA/recovery.signal

4.7 SQL Server : chaîne FULL/DIFF/LOG

-- Plan type : FULL dimanche, DIFF chaque nuit, LOG toutes les 15 min (modèle de récupération FULL)
BACKUP DATABASE [Erp] TO DISK = N'\\backup01\sql\Erp_FULL.bak' WITH COMPRESSION, CHECKSUM, INIT;
BACKUP DATABASE [Erp] TO DISK = N'\\backup01\sql\Erp_DIFF.bak' WITH DIFFERENTIAL, COMPRESSION, CHECKSUM, INIT;
BACKUP LOG [Erp] TO DISK = N'\\backup01\sql\Erp_LOG_202610191430.trn' WITH COMPRESSION, CHECKSUM;

-- Restauration point dans le temps
RESTORE DATABASE [Erp] FROM DISK = N'...Erp_FULL.bak' WITH NORECOVERY, REPLACE;
RESTORE DATABASE [Erp] FROM DISK = N'...Erp_DIFF.bak' WITH NORECOVERY;
RESTORE LOG [Erp] FROM DISK = N'...Erp_LOG_202610191430.trn' WITH STOPAT = '2026-10-19T14:32:00', RECOVERY;

4.8 Conteneurs et Kubernetes

Dans un cluster, on ne sauvegarde pas les nœuds mais trois choses distinctes :

Élément	Moyen	Remarque
Définitions (manifests, Helm, Kustomize)	Git (GitOps)	Le dépôt Git est la source de vérité ; le sauvegarder lui aussi
État du cluster (etcd)	etcdctl snapshot save ou sauvegarde gérée (clusters managés)	Contient les Secrets : chiffrer la sauvegarde
Volumes persistants	Velero (snapshots CSI + copie vers un stockage objet), sauvegarde applicative (dump BDD)	Un snapshot CSI reste souvent sur le même stockage : exiger la copie vers l'objet

# Instantané etcd (nœud control-plane kubeadm)
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/backups/etcd-$(date +%F).db

# Velero : sauvegarde planifiée d'un namespace avec copie des volumes vers l'objet
velero schedule create app-quotidien --schedule="0 2 * * *" \
  --include-namespaces production --ttl 720h --snapshot-move-data
velero backup get
velero restore create --from-backup app-quotidien-20261019020000

Voir Kubernetes. Les options de Velero (déplacement des données de snapshot, plugins par fournisseur) évoluent selon les versions : vérifier la documentation de la version déployée.

Si un logiciel de sauvegarde image tronque aussi les journaux SQL en parallèle de ces sauvegardes natives, la chaîne LOG est cassée. Un seul maître de la chaîne de journaux par base.

5. Immutabilité et isolement (air gap)

5.1 Panorama

Mécanisme	Garantie	Qui peut lever la protection ?
S3 Object Lock COMPLIANCE	Aucune suppression/réécriture d'une version avant la date de rétention	Personne, y compris le compte racine (seule la fermeture du compte chez le fournisseur)
S3 Object Lock GOVERNANCE	Protection contre les suppressions ordinaires	Tout principal disposant de s3:BypassGovernanceRetention
Legal Hold S3	Blocage sans date de fin	Principal disposant de s3:PutObjectLegalHold
Linux durci (Veeam Hardened Repository)	Attribut immuable posé par le service local sur les fichiers de sauvegarde pendant N jours	Root local de la machine (d'où : pas de SSH, accès console seulement, identifiants à usage unique)
Proxmox Backup Server	Sync en pull vers un PBS distant, permissions fines, datastore amovible, protection d'instantanés	Administrateur du PBS distant (pas celui du site principal)
restic/Borg append-only	Le client ne peut qu'ajouter	L'administrateur du serveur de dépôt
Bande éjectée / WORM	Déconnexion physique ; cartouches WORM non réinscriptibles	Accès physique

5.2 S3 Object Lock : mise en place

# Object Lock doit être activé à la création du bucket (active aussi le versioning)
aws s3api create-bucket --bucket backup-immuable-example \
  --region eu-west-3 --create-bucket-configuration LocationConstraint=eu-west-3 \
  --object-lock-enabled-for-bucket

# Rétention par défaut : 30 jours en mode COMPLIANCE
aws s3api put-object-lock-configuration --bucket backup-immuable-example \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

# Vérifier
aws s3api get-object-lock-configuration --bucket backup-immuable-example
aws s3api get-object-retention --bucket backup-immuable-example --key chemin/objet

5.3 Ce que l'immutabilité ne protège pas

• Les données déjà chiffrées par un attaquant avant la sauvegarde : l'immutabilité conserve fidèlement des fichiers inutilisables. D'où une rétention suffisante pour remonter avant la date d'intrusion (souvent des semaines).
• Le catalogue / la configuration du logiciel de sauvegarde : sauvegarder la configuration (export Veeam, /etc/proxmox-backup, clés restic) à part.
• La fermeture du compte cloud ou le non-paiement.
• Les clés de chiffrement perdues ou détruites (section 7).

5.4 Linux durci pour dépôt de sauvegarde

• OS minimal, XFS avec reflink=1 (fast clone), disques locaux ou DAS ; pas de SAN partagé avec la production.
• SSH désactivé après installation ; administration par console physique / IPMI isolé.
• Compte de service sans sudo permanent ; identifiants à usage unique pour l'enrôlement initial.
• NTP fiable et protégé : l'immutabilité repose sur l'horloge ; un attaquant qui avance l'horloge fait expirer les verrous.
• Pare-feu local : seuls les ports du logiciel de sauvegarde depuis les proxys/serveurs autorisés.
• Pas de jonction au domaine AD.

# Préparer un volume XFS adapté au block cloning
mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
mkdir -p /backups && mount /dev/sdb /backups

# Durcissement de base
systemctl disable --now ssh
ufw default deny incoming && ufw allow from 192.0.2.10 to any port 6162 proto tcp && ufw enable
# (port et plage à adapter au logiciel de sauvegarde)

6. Modèle de menace ransomware

6.1 Déroulé typique d'une attaque

1. Accès initial (VPN sans MFA, phishing, vulnérabilité exposée).
2. Élévation de privilèges jusqu'à administrateur du domaine.
3. Reconnaissance de l'infrastructure de sauvegarde : console Veeam, vCenter, NAS, PBS.
4. Destruction des sauvegardes : suppression des jobs et points de restauration, formatage des dépôts, suppression des instantanés, changement de rétention à 1 jour.
5. Exfiltration des données (double extorsion).
6. Chiffrement de la production, souvent la nuit ou le week-end.

L'objectif d'architecture est que l'étape 4 échoue même si l'attaquant est administrateur du domaine.

6.2 Mesures

Mesure	Détail
Domaine d'administration séparé	Serveur de sauvegarde hors domaine AD de production (workgroup ou domaine de gestion dédié) ; comptes locaux spécifiques
MFA	MFA sur la console de sauvegarde, les consoles cloud (S3), les hyperviseurs ; comptes de bris de glace hors ligne
Aucune réutilisation d'identifiants	Mots de passe des dépôts, NAS, iDRAC/iLO uniques et dans un coffre hors domaine
Réseau isolé	VLAN de sauvegarde, flux uniquement depuis/vers les proxys ; pas d'accès RDP/SSH depuis le réseau bureautique ; voir Pare-feu
Pas de partage monté	Aucune cible de sauvegarde montée en lettre de lecteur ou en SMB permanent sur un serveur Windows du domaine
Principe des quatre yeux	Suppression de points de restauration ou réduction de rétention soumise à approbation (fonction disponible dans certains logiciels, ex. Veeam)
Copie immuable + pull	Section 5
Détection	Alertes sur suppression de jobs, changement de rétention, connexion à la console hors horaires, hausse anormale du taux de changement (signe de chiffrement massif)
Analyse avant restauration	Scanner les points de restauration (antivirus, YARA, indicateurs de compromission) avant de les remettre en production

7. Chiffrement et gestion des clés

7.1 Où chiffrer

Niveau	Protège contre	Ne protège pas contre
En transit (TLS, SSH)	Interception réseau	Vol du dépôt
Au repos côté stockage (SSE, LUKS)	Vol de disque, déclassement de matériel	Administrateur du stockage, compte cloud compromis
Côté client (restic, Borg, Veeam, PBS)	Fournisseur de stockage, vol du dépôt	Vol de la clé sur le serveur client

Pour toute copie hors site ou cloud, le chiffrement côté client est la norme : le prestataire ne doit jamais détenir la clé.

7.2 Gestion des clés : règles

• Une clé perdue = des sauvegardes perdues. Aucun éditeur ne peut déchiffrer sans elle (c'est le but).
• Conserver les clés / phrases de passe dans au moins deux emplacements indépendants de l'infrastructure sauvegardée : coffre de mots de passe hors domaine + copie papier sous enveloppe scellée dans un coffre physique.
• Ne pas stocker la clé uniquement dans le coffre de mots de passe hébergé sur un serveur que l'on sauvegarde (dépendance circulaire).
• Pour PBS : exporter la clé client (proxmox-backup-client key paperkey) ; pour Borg en mode repokey : borg key export ; pour restic : la clé maître est dans le dépôt, c'est le mot de passe qu'il faut conserver (plusieurs mots de passe possibles via restic key add).
• Tester la restauration depuis la copie de secours de la clé, sur une machine neuve, une fois par an.
• Rotation : changer la phrase de passe d'accès ne rechiffre pas les données (la clé maître reste) ; une vraie rotation impose un nouveau dépôt.

8. Rétention et GFS

8.1 Schéma GFS (Grand-père / Père / Fils)

Niveau	Exemple	Objectif
Fils (quotidien)	14 à 30 points	Erreurs utilisateur, restaurations courantes
Père (hebdomadaire)	8 à 12 points	Corruption ou intrusion détectée tardivement
Grand-père (mensuel)	12 à 24 points	Exigences comptables, enquêtes
Annuel	Selon obligations légales	Archivage (attention : une sauvegarde n'est pas un archivage à valeur probante)

8.2 Contraintes à arbitrer

• Durée de dormance des intrusions : prévoir au moins 30 à 90 jours de points accessibles et immuables pour revenir avant la compromission.
• RGPD / minimisation : une sauvegarde conservée 10 ans conserve aussi les données personnelles qui auraient dû être effacées. Documenter la rétention dans le registre des traitements et la justifier ; prévoir la procédure en cas de restauration (réappliquer les effacements).
• Coût : avec la déduplication, le coût marginal d'un point est le taux de changement ; sur S3 immuable, la rétention minimale est facturée même si le point est inutile.
• Obligations sectorielles : santé (HDS), finance, contrats clients : vérifier avec le juridique.

# Traduction GFS dans les outils open source
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --keep-yearly 3 --prune
borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --keep-yearly 3 ::
# PBS : options keep-daily / keep-weekly / keep-monthly / keep-yearly des prune jobs du datastore

9. restic : mise en œuvre complète

restic : binaire Go unique, déduplication par blocs de taille variable, chiffrement AES-256 + authentification systématique, nombreux backends (local, SFTP, S3, REST server, B2, Azure, GCS, rclone). Format de dépôt v2 avec compression (zstd) depuis la version 0.14.

9.1 Choix du backend

Backend	Usage	Protection contre la suppression
rest-server --append-only	Serveur de sauvegarde interne	Le client ne peut pas supprimer ; la purge se fait côté serveur
S3 + Object Lock	Copie hors site	Voir section 5 ; attention, forget/prune échoue sur les objets verrouillés : planifier la rétention en conséquence
SFTP	Simple	Aucune (le client peut tout effacer)

9.2 Initialisation

# Fichier d'environnement (droits 600, propriétaire root)
cat > /etc/restic/env <<'EOF'
RESTIC_REPOSITORY=rest:https://backup01.example.com:8000/srv01/
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_CACHE_DIR=/var/cache/restic
RESTIC_COMPRESSION=auto
EOF
chmod 600 /etc/restic/env

# Phrase de passe générée, à recopier IMMÉDIATEMENT dans le coffre hors site
openssl rand -base64 48 > /etc/restic/password && chmod 600 /etc/restic/password

set -a; . /etc/restic/env; set +a
restic init
restic cat config      # vérifie l'accès et affiche la version du dépôt

9.3 Serveur REST en mode append-only

# Sur backup01 (utilisateur dédié, stockage dédié)
rest-server --path /srv/restic --listen :8000 --append-only --private-repos \
  --tls --tls-cert /etc/rest-server/cert.pem --tls-key /etc/rest-server/key.pem

# Comptes : un par client (htpasswd bcrypt)
htpasswd -B -c /srv/restic/.htpasswd srv01

# Purge côté serveur uniquement, avec accès direct au répertoire (pas via le client)
restic -r /srv/restic/srv01 forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Avec --private-repos, chaque utilisateur n'accède qu'au sous-répertoire portant son nom : un serveur compromis ne voit pas les sauvegardes des autres.

9.4 Script de sauvegarde complet

#!/usr/bin/env bash
# /usr/local/sbin/restic-backup.sh
set -euo pipefail
set -a; . /etc/restic/env; set +a

HC_URL="https://hc.example.com/ping/00000000-0000-0000-0000-000000000000"   # sonde dead man's switch
LOCK=/run/restic-backup.lock
exec 9>"$LOCK"; flock -n 9 || { echo "Déjà en cours"; exit 1; }

curl -fsS -m 10 --retry 3 "$HC_URL/start" >/dev/null || true

# 1. Dump cohérent des bases avant la sauvegarde des fichiers
install -d -m 700 /var/backups/db
mysqldump --single-transaction --routines --triggers --events --all-databases \
  | zstd -T0 -q > /var/backups/db/mysql.sql.zst

# 2. Sauvegarde
restic backup \
  --one-file-system \
  --exclude-file /etc/restic/excludes \
  --exclude-caches \
  --tag quotidien --host "$(hostname -s)" \
  /etc /home /srv /var/backups /root

# 3. Vérification partielle (5 % des données relues chaque jour = tout en ~20 jours)
restic check --read-data-subset=5%

# 4. Métrique pour la supervision (Prometheus node_exporter textfile)
SNAP_TIME=$(restic snapshots --latest 1 --json | jq -r '.[0].time')
printf 'restic_last_success_timestamp_seconds{host="%s"} %s\n' \
  "$(hostname -s)" "$(date -d "$SNAP_TIME" +%s)" \
  > /var/lib/node_exporter/textfile/restic.prom.$$
mv /var/lib/node_exporter/textfile/restic.prom.$$ /var/lib/node_exporter/textfile/restic.prom

curl -fsS -m 10 --retry 3 "$HC_URL" >/dev/null || true

# /etc/restic/excludes
/var/cache
/var/tmp
/tmp
/home/*/.cache
*.iso
/srv/*/node_modules

9.5 Planification avec systemd timer

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Sauvegarde restic
Wants=network-online.target
After=network-online.target
OnFailure=notify-failure@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7
# Durcissement : lecture seule partout sauf les chemins nécessaires
ProtectSystem=strict
ReadWritePaths=/var/cache/restic /var/backups /var/lib/node_exporter/textfile /run
PrivateTmp=true
NoNewPrivileges=true

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Sauvegarde restic quotidienne

[Timer]
OnCalendar=*-*-* 01:30:00
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/notify-failure@.service
[Unit]
Description=Notification d'échec pour %i

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -fsS -m 10 --data-raw "Échec %i sur %H" https://hc.example.com/ping/00000000-0000-0000-0000-000000000000/fail

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer
systemctl start restic-backup.service && journalctl -u restic-backup.service -n 50

9.6 Restauration

restic snapshots --host srv01 --tag quotidien
restic ls latest /etc/nginx
restic diff 1a2b3c4d 5e6f7a8b                       # ce qui a changé entre deux instantanés

# Restaurer un dossier dans un répertoire de travail (jamais directement sur l'original)
restic restore latest --target /restore --include /srv/www/site1

# Monter le dépôt (FUSE) pour parcourir
mkdir -p /mnt/restic && restic mount /mnt/restic

# Récupérer un seul fichier vers la sortie standard
restic dump latest /etc/fstab > /tmp/fstab.restored

10. BorgBackup, rclone, Bacula/Bareos

10.1 Comparatif

Outil	Modèle	Points forts	Limites
restic	Client → dépôt (multi-backends)	Backends objet natifs, simple, multi-plateforme	Pas de gestion centrale native
BorgBackup	Client → dépôt via SSH	Très efficace, append-only par clé SSH, mature	Backend SSH/local seulement (1.x) ; Borg 2 change le format (vérifier son statut avant adoption)
rclone	Synchronisation de fichiers	70+ backends, chiffrement crypt, copie de dépôts vers le cloud	Ce n'est pas un logiciel de sauvegarde versionné par lui-même
Bacula / Bareos	Client-serveur (Director, Storage, File daemons, catalogue SQL)	Bandes, bibliothèques, gros parcs hétérogènes, planification centrale	Courbe d'apprentissage, catalogue à sauvegarder

10.2 BorgBackup avec dépôt append-only

# Sur le serveur de dépôt : ~borg/.ssh/authorized_keys (une ligne par client)
command="borg serve --append-only --restrict-to-path /srv/borg/srv01",restrict ssh-ed25519 AAAA...cle-publique... root@srv01

# Sur le client
export BORG_REPO=ssh://borg@backup01.example.com/srv/borg/srv01
export BORG_PASSCOMMAND="cat /etc/borg/passphrase"
borg init --encryption=repokey-blake2
borg key export "$BORG_REPO" /root/borg-key-srv01.txt     # à mettre au coffre hors site

borg create --stats --compression zstd,6 --exclude-caches \
  --exclude '/home/*/.cache' \
  ::'{hostname}-{now:%Y-%m-%dT%H:%M}' /etc /home /srv /var/backups

borg list
borg check --verify-data --last 1

# prune/compact : à lancer depuis un accès NON append-only (côté serveur ou clé d'administration)
borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --glob-archives 'srv01-*'
borg compact

10.3 rclone : externaliser un dépôt vers le cloud

# ~/.config/rclone/rclone.conf (généré par "rclone config")
[s3off]
type = s3
provider = Other
endpoint = https://s3.example.net
access_key_id = PLACEHOLDER
secret_access_key = PLACEHOLDER

[s3crypt]
type = crypt
remote = s3off:backup-offsite/borg
password = (généré et obscurci par rclone config)

# Copie (pas sync : on ne propage pas les suppressions) d'un dépôt local vers le cloud
rclone copy /srv/restic s3off:backup-offsite/restic --transfers 8 --checksum \
  --log-file /var/log/rclone-offsite.log --log-level INFO

# Sync avec conservation des fichiers supprimés/remplacés dans un dossier daté
rclone sync /srv/data s3crypt:data --backup-dir s3crypt:archive/$(date +%F)

Un dépôt restic/Borg copié par rclone n'est cohérent que si aucune sauvegarde ne tourne pendant la copie. Pour restic, préférer restic copy vers un second dépôt (qui gère la cohérence et peut utiliser une autre clé).

10.4 Bacula / Bareos : architecture et commandes

Composant	Rôle
Director (dir)	Planifie, orchestre, connaît les jobs, pools, calendriers
Storage Daemon (sd)	Écrit sur disque, bande, bibliothèque, objet
File Daemon (fd)	Agent sur chaque client
Catalogue	Base PostgreSQL : index des fichiers et volumes — à sauvegarder (job BackupCatalog)

# Extrait de configuration Bareos (Director) - job et calendrier GFS
Schedule {
  Name = "GFS"
  Run = Level=Full     Pool=Mensuel   1st sun at 21:00
  Run = Level=Differential Pool=Hebdo 2nd-5th sun at 21:00
  Run = Level=Incremental  Pool=Quotidien mon-sat at 21:00
}

Job {
  Name = "srv01-fichiers"
  JobDefs = "DefaultJob"
  Client = "srv01-fd"
  FileSet = "LinuxStandard"
  Schedule = "GFS"
}

# Console
bconsole
*status dir
*run job=srv01-fichiers level=Full yes
*list jobs client=srv01-fd
*restore client=srv01-fd select current all done yes where=/tmp/restore

11. Sauvegarde SaaS (M365, Google Workspace)

11.1 Responsabilité partagée

Le fournisseur SaaS assure	Le client reste responsable de
Disponibilité de la plateforme, réplication entre centres de données	Suppressions par utilisateur, admin, script ou connecteur de synchronisation
Sécurité physique et de l'infrastructure	Compte compromis qui supprime ou chiffre (OneDrive/Drive synchronisés)
Corbeilles et fenêtres de récupération limitées	Rétention au-delà de ces fenêtres, données des comptes supprimés
Outils de conformité (rétention, eDiscovery)	Restauration granulaire et rapide à un instant T

Les outils de rétention (Microsoft Purview, Google Vault) sont des outils de conformité, pas de restauration : voir Google Workspace avancé et M365 / Exchange Online.

11.2 Options

• Microsoft 365 Backup (service natif payant) : restauration rapide de SharePoint, OneDrive, Exchange ; les sauvegardes restent dans la frontière Microsoft (ne répond pas seul à l'exigence « 1 copie hors du fournisseur »).
• Solutions tierces SaaS ou auto-hébergées (ex. Veeam Backup for Microsoft 365, Synology Active Backup, solutions SaaS spécialisées) : copie hors du tenant, rétention libre.
• Critères : périmètre (Teams, canaux privés, Planner, groupes), fréquence, throttling des API, restauration en masse (scénario rançongiciel sur OneDrive), immutabilité, localisation des données.

12. Tests de restauration

12.1 Plan de tests

Type de test	Fréquence	Périmètre	Preuve attendue
Intégrité automatique (check, verify)	Quotidienne / hebdomadaire	Tous les dépôts	Journal sans erreur, métrique
Restauration de fichier aléatoire	Hebdomadaire (automatisée)	Échantillon de serveurs	Hachage comparé à la source
Démarrage de VM en bac à sable	Mensuelle (SureBackup, PBS + VM isolée)	Serveurs critiques	VM démarrée, services répondent, capture
Restauration de base + requête de contrôle	Mensuelle	Bases critiques	Nombre de lignes, dernière transaction
Restauration complète d'une application	Semestrielle	Chaque application critique	RTA mesuré, validation par le métier
Exercice PRA	Annuelle	Site / SI entier	Rapport, écarts, plan d'action
Restauration sans infrastructure	Annuelle	Clés, documentation, accès cloud	Restauration réussie depuis un poste neuf avec les seuls éléments du coffre

12.2 Test automatisé de restauration de fichier

#!/usr/bin/env bash
# restore-test.sh - restaure 20 fichiers aléatoires du dernier instantané et compare
set -euo pipefail
set -a; . /etc/restic/env; set +a
WORK=$(mktemp -d); trap 'rm -rf "$WORK"' EXIT
SNAP=$(restic snapshots --latest 1 --json | jq -r '.[0].short_id')

restic ls "$SNAP" --json | jq -r 'select(.type=="file" and .size > 0) | .path' \
  | grep -E '^/(etc|srv)/' | shuf -n 20 > "$WORK/liste"

KO=0
while read -r f; do
  restic dump "$SNAP" "$f" > "$WORK/f" 2>/dev/null || { echo "ECHEC dump $f"; KO=$((KO+1)); continue; }
  # Un fichier modifié depuis la sauvegarde est normal : on compare seulement s'il n'a pas bougé
  if [ -f "$f" ] && [ "$(stat -c %Y "$f")" -lt "$(date -d "$(restic snapshots "$SNAP" --json | jq -r '.[0].time')" +%s)" ]; then
    cmp -s "$WORK/f" "$f" || { echo "DIFF $f"; KO=$((KO+1)); }
  fi
done < "$WORK/liste"

echo "$(date -Is) snapshot=$SNAP fichiers=20 erreurs=$KO" >> /var/log/restore-test.log
[ "$KO" -eq 0 ]

12.3 Fiche de preuve (à archiver)

• Date, opérateur, actif testé, point de restauration utilisé (date/heure).
• Heure de début, heure de service rendu, heure de validation métier : RTA mesuré et perte de données constatée (RPO réel).
• Écarts par rapport au runbook, incidents rencontrés.
• Captures / journaux, signature du responsable métier.
• Actions correctives avec responsable et échéance.

Ces fiches sont la matière première des audits (ISO 27001, NIS2, assureur cyber) : un test non documenté n'existe pas.

13. PRA/PCA : runbooks, ordre de redémarrage, DRaaS

13.1 PRA vs PCA

	PCA (continuité)	PRA (reprise)
Objectif	Maintenir l'activité pendant l'incident, éventuellement en mode dégradé	Restaurer le SI après l'arrêt
Moyens	Haute disponibilité, réplication synchrone, actif/actif, procédures manuelles de contournement	Sauvegardes, réplication asynchrone, site de secours
RTO typique	Proche de zéro	Heures à jours
Périmètre	Métier + IT (personnes, locaux, fournisseurs)	Principalement IT

13.2 Scénarios à couvrir

• Perte d'un serveur / d'une baie (matériel).
• Perte du site (incendie, inondation, coupure électrique prolongée).
• Rançongiciel : scénario dimensionnant aujourd'hui, car il touche aussi l'AD, les sauvegardes en ligne et parfois le site de secours répliqué (la réplication propage le chiffrement).
• Perte d'un fournisseur (hébergeur, SaaS, opérateur réseau).
• Perte des comptes d'administration (IdP indisponible, MFA inaccessible).

13.3 Ordre de redémarrage (dépendances)

Vague	Composants	Critère de passage à la vague suivante
0	Réseau (pare-feu, commutateurs, VPN d'administration), stockage, hyperviseurs, serveur de sauvegarde, coffre de secrets	Console de sauvegarde accessible, dépôts lisibles
1	Contrôleurs de domaine / DNS / NTP, PKI si nécessaire	dcdiag OK, résolution DNS interne, Kerberos fonctionnel
2	Bases de données, serveurs de fichiers, DHCP	Services démarrés, requête de contrôle OK
3	Serveurs d'applications, middleware, files de messages	Santé applicative OK
4	Frontaux web, RDS/VDI, accès utilisateurs	Recette métier
5	Systèmes secondaires, batchs, reporting	-

13.4 Structure d'un runbook

RUNBOOK - Application ERP - v3 - validé le 2026-09-15
1. Déclenchement      : qui décide (cellule de crise), critères, numéros d'astreinte
2. Prérequis          : vagues 0-1 OK, accès coffre de secrets, clé de chiffrement du dépôt
3. Point de restauration : comment choisir (dernier point sain, avant date d'intrusion)
4. Étapes numérotées  : commande exacte, résultat attendu, durée mesurée au dernier test
   4.1 Restaurer VM db-erp-01 sur hyperviseur de secours (réseau isolé)
   4.2 Restaurer la base au point T (chaîne FULL + DIFF + LOG)
   4.3 Restaurer app-erp-01, modifier la chaîne de connexion si l'IP change
   4.4 Bascule DNS : erp.example.com -> 198.51.100.20 (TTL abaissé en temps normal à 300 s)
5. Contrôles          : requêtes de contrôle, connexion d'un utilisateur test, facture test
6. Retour arrière    : comment revenir sur le site principal (resynchronisation inverse)
7. Communication    : messages types (direction, utilisateurs, clients, CNIL si violation)
8. Annexes          : schéma de flux, comptes nécessaires (référence coffre, jamais le secret), contacts éditeur

Le runbook doit être disponible hors du SI (impression à jour, coffre cloud indépendant) : il est inutile s'il est sur le partage de fichiers chiffré.

13.5 Site de secours et DRaaS

Option	RTO	Coût	Remarques
Site froid (matériel à commander)	Jours à semaines	Faible	Contrats de fourniture express à négocier
Site tiède (matériel présent, restauration depuis sauvegardes)	Heures à 1-2 jours	Moyen	Cas le plus courant en PME/ETI
Site chaud (réplication continue)	Minutes à heures	Élevé	Réplication = propage aussi le chiffrement : garder des points de réplication multiples
DRaaS (reprise chez un prestataire / cloud)	Minutes à heures	Abonnement + consommation lors de l'activation	Vérifier : capacité réservée, réseau (IP, VPN), tests inclus dans le contrat, réversibilité
Reconstruction cloud par IaC	Heures	Faible au repos	Exige IaC complète et testée, données déjà dans le cloud

13.6 Cellule de crise et décisions

• Qui déclare le sinistre et active le PRA : nom, suppléant, critères objectifs (durée d'indisponibilité prévisible > seuil).
• Moyens de communication hors SI : la messagerie et la téléphonie IP peuvent être touchées ; prévoir une liste téléphonique imprimée et un canal de secours (messagerie instantanée externe, adresse e-mail hors domaine).
• Obligations : dépôt de plainte, déclaration à l'assureur cyber (souvent avec délai contractuel et prestataire imposé), notification CNIL sous 72 h en cas de violation de données personnelles, notification des incidents significatifs aux autorités pour les entités soumises à NIS2.
• Préservation des preuves : avant de réinstaller, conserver images disque et journaux des systèmes compromis (exigé par l'assureur et les enquêteurs).
• Journal de crise horodaté : décisions, actions, responsables. Il sert au retour d'expérience et aux déclarations.

13.7 Exercice PRA : déroulé type

1. J-30 : périmètre, scénario (ex. perte du site principal un lundi 8 h), critères de succès, information du métier.
2. J-7 : vérifier les accès (comptes de secours, clés, VPN vers le site de secours), réserver le réseau isolé.
3. Jour J : dérouler les runbooks tels qu'ils sont écrits, chronométrer chaque étape, noter chaque improvisation.
4. Validation métier : un utilisateur réel exécute un scénario de test (saisie de commande, facture).
5. J+7 : rapport (RTA par application, écarts, causes), mise à jour des runbooks, plan d'action daté.

14. Supervision des sauvegardes

14.1 Alerter sur l'absence de succès

L'erreur classique : alerter uniquement sur les « échecs ». Un job supprimé, désactivé, bloqué indéfiniment, un timer systemd jamais activé, un serveur sorti du périmètre ou un logiciel de sauvegarde lui-même arrêté ne génère aucun échec. Il faut alerter sur l'ancienneté du dernier succès (principe du dead man's switch).

14.2 Indicateurs

Indicateur	Seuil type
Âge du dernier point réussi, par actif	> RPO + marge (ex. > 26 h pour un quotidien)
Couverture : actifs inventoriés sans sauvegarde	> 0
Durée du job	> 150 % de la médiane (fenêtre dépassée, dégradation)
Volume transféré / taux de changement	Hausse brutale (chiffrement massif ?) ou chute à zéro (exclusion accidentelle ?)
Espace libre du dépôt	< 20 %
Résultat des vérifications d'intégrité	Toute erreur
Copie hors site : retard	> 1 cycle
Dernier test de restauration réussi	> périodicité du plan
Expiration des certificats / licences / abonnements cloud	< 30 jours

14.3 Mise en œuvre

# Règle d'alerte Prometheus sur la métrique publiée par le script restic (section 9.4)
groups:
- name: sauvegardes
  rules:
  - alert: SauvegardeTropAncienne
    expr: time() - restic_last_success_timestamp_seconds > 26 * 3600
    for: 15m
    labels: { severity: critical }
    annotations:
      summary: "Aucune sauvegarde réussie depuis plus de 26 h sur {{ $labels.host }}"
  - alert: MetriqueSauvegardeAbsente
    expr: absent(restic_last_success_timestamp_seconds{host="srv01"})
    for: 1h
    labels: { severity: critical }

• Sondes passives (Healthchecks auto-hébergé, Uptime Kuma en mode push, Zabbix trapper) : le job « pingue » en fin de succès ; l'absence de ping dans la période déclenche l'alerte.
• Logiciels commerciaux : rapports et alarmes natifs (Veeam ONE, notifications PBS), à doubler d'une vérification externe pour couvrir l'arrêt du serveur de sauvegarde lui-même.
• Rapprochement d'inventaire : comparer chaque semaine la liste des VM/serveurs (hyperviseur, CMDB) à la liste des actifs sauvegardés. Les nouvelles VM oubliées sont la première cause de « pas de sauvegarde ».
• Les alertes de sauvegarde doivent arriver sur un canal indépendant de l'infrastructure surveillée (SMS, service externe). Voir Monitoring.

# Proxmox : comparer VM existantes et VM couvertes par un job de sauvegarde (vzdump)
pvesh get /cluster/backup-info/not-backed-up --output-format json | jq -r '.[] | "\(.vmid) \(.name)"'

15. Dépannage et pièges classiques

15.1 Symptôme -> cause -> correction

Symptôme	Cause probable	Correction
Sauvegardes « vertes » mais restauration impossible	Aucun test ; données exclues ; base sauvegardée ouverte sans cohérence	Tests de restauration planifiés, dumps natifs
Journaux SQL/Exchange qui saturent le disque	Traitement applicatif inactif : journaux jamais tronqués	Activer le traitement applicatif ou des sauvegardes de journaux natives (un seul maître)
Erreur VSS 0x800423f4 ou writer en échec	Writer en erreur, espace de clichés insuffisant, conflit avec un autre fournisseur VSS	vssadmin list writers, redémarrer le service du writer, étendre le shadowstorage
Sauvegarde incrémentale aussi longue qu'une complète	CBT/RCT/bitmap réinitialisé (redémarrage, migration, snapshot orphelin)	Normal une fois ; si récurrent : snapshots orphelins à nettoyer, CBT à réinitialiser
restic : repository is already locked	Sauvegarde concurrente ou processus tué	Vérifier qu'aucun restic ne tourne, puis restic unlock
Borg : Failed to create/acquire the lock	Même cause	borg break-lock après vérification
Dépôt plein malgré la rétention	Prune sans compact/GC ; instantanés protégés ; Object Lock plus long que la rétention	restic prune, borg compact, GC PBS ; aligner rétention logicielle et verrou S3
Restauration lente depuis S3	Classe d'archivage (Glacier) ou débit limité, nombreux petits objets	Classe de stockage adaptée au RTO ; restauration parallèle ; copie primaire locale
Pas d'alerte alors que la sauvegarde ne tourne plus	Supervision basée sur les échecs	Alertes sur l'ancienneté du dernier succès
Fichiers déjà chiffrés dans tous les points	Rétention trop courte au regard du temps de détection	Allonger la rétention, détecter les taux de changement anormaux
Restauration bloquée : clé introuvable	Clé seulement sur le serveur détruit	Aucune correction a posteriori : coffre hors site obligatoire

15.2 Pièges de conception

• La réplication n'est pas une sauvegarde : RAID, réplication de VM, synchronisation de fichiers ou DFS-R répliquent aussi les suppressions et le chiffrement.
• Les instantanés (snapshots) ne sont pas une sauvegarde : même stockage, même administrateur ; et sur VMware, un snapshot conservé longtemps dégrade les performances.
• Serveur de sauvegarde dans le domaine AD avec un compte Domain Admins : premier serveur que l'attaquant visite.
• Dépendance circulaire : console de sauvegarde virtualisée sur le cluster qu'elle protège, documentation sur le partage sauvegardé, coffre de mots de passe dans la VM restaurée, DNS nécessaire pour joindre le dépôt.
• Exclusions oubliées : un nouveau volume /data2 hors des chemins sauvegardés ; --one-file-system qui ignore un montage.
• Fuseau / horloge : PITR à une heure locale interprétée en UTC (ou l'inverse), une heure de données perdue ou rejouée.
• Licences et abonnements : licence expirée = jobs arrêtés ; carte bancaire expirée = compte cloud suspendu.

16. Checklist et matrice d'audit

16.1 Checklist de mise en production

#	Contrôle	Statut
1	BIA réalisée, RPO/RTO par classe validés et signés par la direction	☐
2	Inventaire des actifs rapproché automatiquement de la liste des actifs sauvegardés	☐
3	3 copies, 2 supports, 1 hors site, 1 immuable ou hors ligne	☐
4	Cohérence applicative vérifiée pour chaque base / application (VSS, dumps, PITR)	☐
5	Infrastructure de sauvegarde hors domaine AD de production, MFA sur les consoles	☐
6	Identifiants uniques, stockés hors du SI protégé	☐
7	Réseau de sauvegarde isolé, flux minimaux, copie hors site en pull	☐
8	Chiffrement côté client des copies externes ; clés en 2 emplacements, restauration testée depuis la copie de la clé	☐
9	Rétention GFS documentée, compatible RGPD et temps de détection d'intrusion	☐
10	SaaS (M365, Google Workspace) couvert par une sauvegarde hors du fournisseur	☐
11	Supervision sur l'ancienneté du dernier succès, canal d'alerte indépendant	☐
12	Vérifications d'intégrité automatiques planifiées	☐
13	Plan de tests de restauration, fiches de preuve archivées	☐
14	Runbooks par application, ordre de redémarrage, disponibles hors SI	☐
15	Procédure de restauration AD (forêt) écrite et exercée	☐
16	Exercice PRA annuel avec mesure du RTA et plan d'action	☐

16.2 Matrice d'audit (maturité)

Domaine	Niveau 1 - Initial	Niveau 2 - Maîtrisé	Niveau 3 - Optimisé
Objectifs	Aucun RPO/RTO formalisé	RPO/RTO par application	BIA revue annuellement, RTA mesuré ≤ RTO
Couverture	Liste manuelle	Rapprochement périodique	Rapprochement automatique, alerte sur nouvel actif non couvert
Copies	Une seule copie locale	3-2-1	3-2-1-1-0, copie immuable en pull
Isolation	Serveur de sauvegarde dans le domaine	Comptes dédiés, MFA	Domaine d'administration séparé, quatre yeux sur suppressions
Cohérence	Crash-consistent partout	Application-consistent sur les bases	PITR sur les bases critiques, testé
Supervision	E-mail d'échec lu (parfois)	Tableau de bord, alertes d'échec	Alertes sur ancienneté, taux de changement, intégrité
Tests	Restauration à la demande	Tests planifiés manuels	Tests automatisés + exercices PRA documentés
PRA	Inexistant	Document écrit	Runbooks exercés, DRaaS ou site de secours testé
Clés	Sur le serveur uniquement	Coffre numérique	Coffre numérique + copie physique, test annuel