🛡️ Storage Systems — Chapitre 28 : Backup

Première page de la Partie 9 — Sauvegarde, restauration et continuité. Ce chapitre couvre les fondamentaux du backup professionnel : full, incremental, differential, synthetic full, image-level, application-aware, immutable backup, snapshots vs backup, PITR, restauration granulaire, déduplication, GFS, 3-2-1-1-0, repositories, chiffrement, anti-ransomware, virtualisation, Kubernetes, cloud/SaaS, catalogue, tests de restauration, outils, runbooks et checklist production.

Full / Incremental / DifferentialSynthetic fullImage-levelApplication-awareImmutable backup3-2-1-1-0

28.1

Sauvegarde complète

Full backup : copie complète d’un périmètre à un instant donné. Simple à restaurer, coûteuse en capacité, indispensable comme base de stratégie.

Full backupBaselineRestore simple

28.2

Sauvegarde incrémentale

Incremental backup : sauvegarde uniquement ce qui a changé depuis le dernier backup. Très efficace en capacité et fenêtre, plus dépendant de la chaîne.

IncrementalChanged blocksRPO

28.3

Sauvegarde différentielle

Differential backup : sauvegarde les changements depuis le dernier full. Plus lourd qu’incrémental mais chaîne de restauration plus courte.

DifferentialSince fullRestore balanced

28.4

Synthetic full

Synthetic full : reconstruction logique d’un nouveau full à partir d’un ancien full et d’incrémentaux, souvent côté repository, sans relire toute la production.

Synthetic fullMergeRepository-side

28.5

Image-level backup

Image-level backup : sauvegarde d’une VM, d’un serveur ou d’un disque entier. Très utilisé en virtualisation, cloud privé et PRA rapide.

VM imageBare-metalCBT

28.6

Application-aware backup

Application-aware backup : sauvegarde cohérente avec l’application : bases de données, journaux, VSS, Oracle RMAN, SQL Server, Exchange, PostgreSQL, MySQL.

OracleSQL ServerExchangeConsistency

28.7

Backup immuable

Backup immuable : protection contre suppression ou modification pendant une durée donnée. Brique centrale anti-ransomware et cyber recovery.

ImmutableRansomwareWORM

28.8

Snapshots vs backups

Snapshot et backup sont souvent confondus. Le snapshot est un point de changement rapide ; le backup est une copie indépendante gouvernée et restaurable.

SnapshotBackupClone

28.9

PITR : Point-In-Time Recovery

PITR permet de restaurer une base ou application à un instant précis grâce aux backups complets et journaux transactionnels.

PITRLogsDatabases

28.10

Restauration granulaire

Restaurer une partie seulement : fichier, dossier, mailbox, table, objet S3, VM disk, volume Kubernetes ou ligne logique selon outil.

FileMailboxTableObject

28.11

Déduplication et compression backup

La déduplication et compression réduisent capacité et trafic, mais imposent des contraintes CPU/RAM, repository, chaîne de blocs et performance restore.

DedupCompressionRepository

28.12

Rétention, GFS et politique de conservation

La rétention définit combien de temps garder les points. GFS : Grandfather-Father-Son, journaliers, hebdomadaires, mensuels, annuels.

GFSRetentionPolicy

28.13

Règle 3-2-1-1-0

Évolution moderne de la règle 3-2-1 : 3 copies, 2 supports, 1 hors site, 1 immuable/offline, 0 erreur de restauration.

3-2-1Air gapZero error

28.14

Repositories backup : disque, object, tape, cloud

Le repository est le cœur physique/logique du backup : disque local, NAS, appliance, object storage, cloud, tape, hardened Linux repository.

RepositoryObjectTape

28.15

Chiffrement, clés et sécurité des backups

Les backups contiennent tout : données, secrets, fichiers, bases. Chiffrement, KMS, séparation des droits et audit sont obligatoires.

EncryptionKMSSecrets

28.16

Backup anti-ransomware

La stratégie ransomware doit supposer compromission admin, suppression snapshots, chiffrement prod et corruption logique. Le backup devient dernier rempart.

RansomwareCyber vaultClean room

28.17

Backup VMware / Hyper-V / Proxmox

La virtualisation permet des backups image-level, CBT, snapshots, replication et instant recovery, mais exige cohérence app et contrôle snapshots.

VMHypervisorInstant recovery

28.18

Backup Kubernetes

Kubernetes backup ne se limite pas aux YAML : il faut sauvegarder stateful data, PVC, etcd, secrets, CRDs, operators et GitOps state.

VeleroPVCetcdGitOps

28.19

Backup cloud-native et SaaS

Cloud backup : snapshots, managed backups, object versioning, cross-region copies, SaaS backup M365/Google Workspace/Salesforce et responsabilité partagée.

AWSAzureGCPSaaS

28.20

Catalogue, index et metadata backup

Le catalogue est la mémoire du système de backup : où sont les points, quels objets, quelles versions, quelles dépendances, quelles clés.

CatalogIndexMetadata

28.21

Tests de restauration et fire drills

Le backup n’existe réellement qu’après restauration testée. Les fire drills mesurent RTO/RPO, révèlent dépendances et entraînent les équipes.

Restore drillRTORPO

28.22

Outils backup : Veeam, Commvault, Rubrik, Cohesity, Borg, Restic

Panorama des familles d’outils : enterprise backup suites, appliances convergées, open source chiffré, cloud-native, database-native et SaaS backup.

ToolsEnterpriseOpen source

28.23

Runbooks incidents backup

Les runbooks backup doivent couvrir suppression fichier, corruption base, ransomware, perte site, repository full, job failed, clé perdue et restauration urgente.

IncidentRunbookRecovery

28.24

Checklist production Backup

Checklist finale pour une stratégie backup professionnelle : RPO/RTO, 3-2-1-1-0, immutabilité, chiffrement, monitoring, tests restore, documentation.

ChecklistAuditProd-ready

28.1 Sauvegarde complète

Définition opérationnelle

Full backup : copie complète d’un périmètre à un instant donné. Simple à restaurer, coûteuse en capacité, indispensable comme base de stratégie.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Source	VM, serveur, base, filesystem, NAS, bucket, application.
Backup set	Jeu complet de données sauvegardées.
Metadata	Catalog, index, checksums, dépendances.
Repository	Disque, appliance, object storage, tape, cloud.
Retention	Durée de conservation et politique d’expiration.

Cas d’usage principaux

Baseline hebdomadaire/mensuelle
Petits environnements
Archive longue durée
Avant migration majeure
Gold copy de référence
Restore simplifié

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Restauration conceptuellement simple
Peu de dépendances entre jobs
Très lisible pour audit
Bonne base pour tests restore
Moins de chaîne cassable

Risques / limites

Coûteux en capacité et bande passante
Fenêtre de backup longue
Impact production possible
Difficile sur très gros volumes
RPO potentiellement élevé

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.2 Sauvegarde incrémentale

Définition opérationnelle

Incremental backup : sauvegarde uniquement ce qui a changé depuis le dernier backup. Très efficace en capacité et fenêtre, plus dépendant de la chaîne.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Full initial	Point de départ obligatoire.
Incremental chain	Suites de deltas depuis full ou précédent incrémental.
CBT / changed blocks	Suivi blocs modifiés pour VM/disques.
Catalog	Lien entre points de restauration.
Merge / consolidation	Nettoyage et reconstruction de chaînes.

Cas d’usage principaux

Backups quotidiens fréquents
VMs nombreuses
Données changeant peu
WAN limité
Cloud repository coûteux
RPO court

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Fenêtre courte
Faible consommation capacité
Faible transfert réseau
Adapté grands parcs VM
Permet nombreux points de restauration

Risques / limites

Chaîne plus fragile
Restore peut nécessiter plusieurs deltas
Corruption d’un maillon impacte suite
Consolidation à surveiller
Catalog critique

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.3 Sauvegarde différentielle

Définition opérationnelle

Differential backup : sauvegarde les changements depuis le dernier full. Plus lourd qu’incrémental mais chaîne de restauration plus courte.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Full base	Backup complet de référence.
Differential set	Tous les changements depuis le full.
Restore chain	Full + dernier différentiel.
Schedule	Full périodique + différentiels intermédiaires.
Capacity planning	Croissance du différentiel dans le temps.

Cas d’usage principaux

Bases de données PME
Fichiers utilisateurs
Systèmes avec restore rapide
Environnements où l’incrémental est trop fragile
Audit simplifié
Fenêtre moyenne

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Restore plus simple qu’incrémental
Moins de dépendances
Bon compromis capacité/temps
Restauration prévisible
Facile à expliquer

Risques / limites

Différentiel grossit chaque jour
Fenêtre augmente avec temps depuis full
Capacité supérieure à incremental
Full base critique
Planification à optimiser

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.4 Synthetic full

Définition opérationnelle

Synthetic full : reconstruction logique d’un nouveau full à partir d’un ancien full et d’incrémentaux, souvent côté repository, sans relire toute la production.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Full précédent	Base de reconstruction.
Incrementals	Deltas accumulés.
Repository engine	Moteur de synthèse/merge.
New synthetic full	Image complète reconstruite.
Health check	Validation de cohérence du nouveau point.

Cas d’usage principaux

Réduire fenêtre de backup production
Sites distants
Veeam-like workflows
Repositories dédupliquants
Backups VM massifs
Optimisation réseau

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Moins d’impact production
Full logique récent
Réduit trafic source
Bon avec déduplication
Améliore stratégie long terme

Risques / limites

Repository très sollicité
Corruption repository dangereuse
Merge long si sous-dimensionné
Besoin de health checks
Peut masquer problèmes de chaîne

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.5 Image-level backup

Définition opérationnelle

Image-level backup : sauvegarde d’une VM, d’un serveur ou d’un disque entier. Très utilisé en virtualisation, cloud privé et PRA rapide.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Snapshot VM/disk	Point-in-time source.
CBT	Changed Block Tracking.
Guest processing	Quiesce, VSS, scripts pre/post.
Image repository	Stockage des blocs/image.
Instant recovery	Démarrage rapide depuis backup selon produit.

Cas d’usage principaux

VMware/Hyper-V/Proxmox
Serveurs Windows/Linux
Bare-metal recovery
PRA rapide
Migration V2V/P2V
Test lab clone

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Restauration serveur complet
Très pratique pour VM
Granular restore possible selon produit
RTO court avec instant recovery
Compatible DR

Risques / limites

Cohérence applicative non automatique
Snapshots longs dangereux
Restauration fichier/base à tester
Drivers/boot/network après restore
Gros volumes inutiles si mal filtrés

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.6 Application-aware backup

Définition opérationnelle

Application-aware backup : sauvegarde cohérente avec l’application : bases de données, journaux, VSS, Oracle RMAN, SQL Server, Exchange, PostgreSQL, MySQL.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Quiesce	Mise en cohérence applicative.
Transaction logs	WAL, redo logs, binlogs, SQL logs.
App plugin	Agent ou intégration application.
Catalog app	Métadonnées de restauration granulaire.
PITR	Point-in-time recovery.

Cas d’usage principaux

Oracle Database
SQL Server
Exchange
PostgreSQL/MySQL/MariaDB
SAP/HANA
Applications métiers transactionnelles

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Cohérence transactionnelle
PITR possible
Truncation logs contrôlée
Restore granulaire
Réduit risque corruption logique

Risques / limites

Agents/plugins à maintenir
Permissions sensibles
Backup doit suivre version app
Snapshots seuls insuffisants
Tests restore obligatoires

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.7 Backup immuable

Définition opérationnelle

Backup immuable : protection contre suppression ou modification pendant une durée donnée. Brique centrale anti-ransomware et cyber recovery.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Object Lock / WORM	Verrouillage temporel ou réglementaire.
Hardened repository	Serveur Linux durci, immutabilité locale.
Air gap logical/physical	Séparation logique ou offline.
MFA / dual control	Réduction risque admin compromis.
Retention lock	Rétention non raccourcissable selon mode.

Cas d’usage principaux

Protection ransomware
Backups critiques
Conformité légale
Cyber vault
Assurance cyber
Administrations/banques/santé

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Résiste suppression malveillante
Critère moderne majeur
Complète EDR/SIEM
Permet reprise après chiffrement
Améliore auditabilité

Risques / limites

Mauvaise config peut bloquer purge légitime
Coût capacité si rétention excessive
Clés admin à protéger
Immutabilité non testée = illusion
Ransomware peut viser prod avant backup

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.8 Snapshots vs backups

Définition opérationnelle

Snapshot et backup sont souvent confondus. Le snapshot est un point de changement rapide ; le backup est une copie indépendante gouvernée et restaurable.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Array/VM snapshot	Point-in-time local.
Copy-on-write / redirect-on-write	Technique de snapshot.
Backup copy	Copie externalisée ou indépendante.
Catalog	Index de restauration.
Retention	Politique indépendante de la source.

Cas d’usage principaux

Pré-maintenance rapide
Clone dev/test
Restauration fichier courte durée
Protection VM rapide
Base pour backup agentless
Rollback immédiat

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Très rapide
Faible overhead initial
Granulaire selon plateforme
Excellent pour opérations courtes
Base de clone

Risques / limites

Pas un backup indépendant
Dépend de la source
Snapshots longs dégradent performance
Ransomware peut supprimer snapshots
Pas toujours app-consistent

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.9 PITR : Point-In-Time Recovery

Définition opérationnelle

PITR permet de restaurer une base ou application à un instant précis grâce aux backups complets et journaux transactionnels.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Base backup	Backup complet ou snapshot cohérent.
Transaction logs	WAL/binlog/redo/archivelogs.
Timestamp/LSN/SCN	Point de restauration exact.
Restore target	Instance de restauration isolée.
Validation	Tests applicatifs après recovery.

Cas d’usage principaux

Erreur humaine SQL
Suppression table
Ransomware applicatif
Corruption logique
Audit forensic
Restauration avant incident

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

RPO très fin
Très adapté bases critiques
Permet revenir juste avant erreur
Complète backup VM
Indispensable DBA

Risques / limites

Logs manquants = PITR impossible
Horodatage mal maîtrisé
Restauration longue sur gros volumes
Tests fréquents nécessaires
Stockage logs à protéger

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.10 Restauration granulaire

Définition opérationnelle

Restaurer une partie seulement : fichier, dossier, mailbox, table, objet S3, VM disk, volume Kubernetes ou ligne logique selon outil.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Index	Métadonnées et catalogue de contenu.
Search	Recherche par nom/date/type.
Mount backup	Montage temporaire d’un point.
Extract	Extraction ciblée.
ACL restore	Restauration permissions/ownership.

Cas d’usage principaux

Fichier supprimé
Mailbox Exchange/M365
Table SQL
Objet bucket
PVC Kubernetes
Dossier utilisateur

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

RTO court pour petites pertes
Moins intrusif qu’un restore complet
Très utile support utilisateurs
Réduit downtime
Bon pour audit

Risques / limites

Index volumineux
Permissions mal restaurées
Pas disponible pour tous formats
Risque incohérence applicative
Catalogue sensible

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.11 Déduplication et compression backup

Définition opérationnelle

La déduplication et compression réduisent capacité et trafic, mais imposent des contraintes CPU/RAM, repository, chaîne de blocs et performance restore.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Inline dedup	Dédup pendant écriture.
Post-process dedup	Dédup après écriture.
Global dedup	Dédup entre jobs/sources.
Compression	Réduction bloc/objet.
Rehydration	Reconstruction données au restore.

Cas d’usage principaux

Backups VM similaires
VDI
File servers
Long retention
WAN backups
Appliances backup

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Réduction capacité massive
Réduit coûts stockage
Optimise WAN
Compatible synthetic full
Très utile long terme

Risques / limites

Restore plus CPU/IO intensive
Repository corrompu très impactant
Ratios marketing variables
Chiffrement avant dedup casse ratio
RAM/index critiques

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.12 Rétention, GFS et politique de conservation

Définition opérationnelle

La rétention définit combien de temps garder les points. GFS : Grandfather-Father-Son, journaliers, hebdomadaires, mensuels, annuels.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Daily	Restauration court terme.
Weekly	Référence hebdomadaire.
Monthly	Conservation administrative.
Yearly	Conformité long terme.
Legal hold	Blocage suppression selon besoin.

Cas d’usage principaux

Conformité
Audit financier
Restauration utilisateur
Archive annuelle
Plan ransomware
Politique RGPD

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Lisible pour audit
Contrôle coûts
Structure long terme
Facilite purge
Répond obligations

Risques / limites

Trop court = impossible restore
Trop long = coût/risque données
RGPD droit suppression
Immutabilité mal configurée
Pas aligné RPO/RTO

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.13 Règle 3-2-1-1-0

Définition opérationnelle

Évolution moderne de la règle 3-2-1 : 3 copies, 2 supports, 1 hors site, 1 immuable/offline, 0 erreur de restauration.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
3 copies	Production + au moins deux copies.
2 supports	Stockages/logiques différents.
1 offsite	Copie hors site/région.
1 immutable/offline	Protection ransomware.
0 error	Restauration testée sans erreur.

Cas d’usage principaux

PME/ETI
Banque/santé
Cloud hybride
Datacenter on-prem
Kubernetes
SaaS critique

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Simple à communiquer
Couvre incidents physiques et logiques
Base anti-ransomware
Audit friendly
Applicable partout

Risques / limites

Souvent déclarée mais non testée
Offsite sans restore = inutile
Immutable mal configuré
Copie cloud exposée aux mêmes credentials
RTO parfois oublié

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.14 Repositories backup : disque, object, tape, cloud

Définition opérationnelle

Le repository est le cœur physique/logique du backup : disque local, NAS, appliance, object storage, cloud, tape, hardened Linux repository.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Disk repository	Rapide, économique, exposé ransomware si mal isolé.
Object repository	S3, object lock, scalabilité.
Tape	Air gap physique, archive longue.
Cloud repository	Offsite, elasticité, coûts egress.
Hardened repository	Linux durci, immutabilité locale.

Cas d’usage principaux

Backup primaire rapide
Copy offsite cloud
Archive tape
Cyber vault
Object lock
Long-term retention

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Permet séparer classes de stockage
Optimise coût/RTO
Object lock moderne
Tape air-gap fort
Tiering possible

Risques / limites

Repository unique = SPOF
NAS accessible par ransomware
Egress cloud oublié
Tape restore lent
Capacité mal dimensionnée

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.15 Chiffrement, clés et sécurité des backups

Définition opérationnelle

Les backups contiennent tout : données, secrets, fichiers, bases. Chiffrement, KMS, séparation des droits et audit sont obligatoires.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Encryption at rest	Chiffrement repository.
Encryption in transit	TLS, VPN, réseau privé.
KMS/HSM	Gestion centralisée clés.
Key escrow	Récupération contrôlée.
RBAC/MFA	Accès restreint et traçable.

Cas d’usage principaux

Données sensibles
Cloud repository
Tape externalisée
Prestataire backup
Secteur santé/finance
Cyber insurance

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Réduit impact fuite backup
Indispensable conformité
Protège supports transportés
Séparation des rôles
Auditabilité

Risques / limites

Clé perdue = backup perdu
Clé stockée avec backup = inutile
Rotation mal testée
Performance impact
Accès admin trop large

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.16 Backup anti-ransomware

Définition opérationnelle

La stratégie ransomware doit supposer compromission admin, suppression snapshots, chiffrement prod et corruption logique. Le backup devient dernier rempart.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Immutable backup	Retention lock/WORM.
Offline/air gap	Support déconnecté ou isolé.
Cyber vault	Environnement isolé de récupération.
Clean room	Restauration et analyse sans contaminer prod.
Malware scan	Détection avant réintégration.

Cas d’usage principaux

Ransomware entreprise
Assurance cyber
Hôpitaux/collectivités
Active Directory compromis
Serveurs fichiers chiffrés
SaaS/M365 compromis

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Permet reprise après attaque
Réduit paiement rançon
Améliore posture cyber
Critère audit/assurance
Force tests de restore

Risques / limites

Backups déjà infectés
Credentials backup compromis
Immutable trop courte
AD/PKI non restaurables
Pas de clean room

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.17 Backup VMware / Hyper-V / Proxmox

Définition opérationnelle

La virtualisation permet des backups image-level, CBT, snapshots, replication et instant recovery, mais exige cohérence app et contrôle snapshots.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
vSphere/Hyper-V API	Intégration hyperviseur.
CBT/RCT	Suivi blocs modifiés.
Proxy backup	Transport data.
Repository	Stockage backups.
Instant VM recovery	Démarrage depuis backup.

Cas d’usage principaux

VMware estate
Hyper-V clusters
Proxmox VE
Migration V2V
Lab restore
PRA court terme

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Restauration VM complète
Très automatisable
Granular restore possible
Bon RTO
Intégration DR

Risques / limites

Snapshot stun/long snapshot
App consistency oubliée
Datastore full
CBT corrompu
Licensing hyperviseur/backup

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.18 Backup Kubernetes

Définition opérationnelle

Kubernetes backup ne se limite pas aux YAML : il faut sauvegarder stateful data, PVC, etcd, secrets, CRDs, operators et GitOps state.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Cluster resources	Deployments, Services, CRDs, RBAC.
PVC snapshots	Volumes persistants.
etcd	État cluster control plane.
Object repository	S3-compatible pour Velero.
GitOps repo	Source déclarative.

Cas d’usage principaux

AKS/EKS/GKE/on-prem
StatefulSets
Namespaces critiques
Migration cluster
DR multi-cluster
Restauration après erreur Helm

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Restauration namespace/app
Migration cluster
Complète GitOps
Backups PVC automatisés
Bon pour platform engineering

Risques / limites

CRDs/operators version mismatch
Secrets mal restaurés
PVC snapshots non app-consistent
etcd restore dangereux
Cluster identity/network oubliés

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.19 Backup cloud-native et SaaS

Définition opérationnelle

Cloud backup : snapshots, managed backups, object versioning, cross-region copies, SaaS backup M365/Google Workspace/Salesforce et responsabilité partagée.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Cloud snapshots	EBS/Azure Disk/PD snapshots.
Managed DB backup	RDS/Azure SQL/Cloud SQL PITR.
Object versioning	S3/Blob/GCS protection.
SaaS backup	M365, Google Workspace, Salesforce.
Cross-account copy	Isolation contre compromission.

Cas d’usage principaux

AWS/Azure/GCP
Cloud databases
SaaS métiers
Object storage
Multi-account enterprise
FinOps backup

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Automatisation native
Cross-region possible
PITR managé
Object immutability
APIs/IaC

Risques / limites

Responsabilité partagée mal comprise
Même compte compromis
Egress restore
Snapshots sans app consistency
SaaS non sauvegardé

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.20 Catalogue, index et metadata backup

Définition opérationnelle

Le catalogue est la mémoire du système de backup : où sont les points, quels objets, quelles versions, quelles dépendances, quelles clés.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Backup catalog	Base centrale des jobs.
Indexes	Fichiers, mailboxes, tables, objets.
Credentials map	Identités, secrets, clés.
Retention DB	Politiques et expirations.
Audit trail	Qui restaure quoi et quand.

Cas d’usage principaux

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Accélère restauration
Prouve conformité
Permet granularité
Facilite reporting
Aide forensic

Risques / limites

Catalog corrompu
Catalogue non sauvegardé
Données sensibles dans index
Version incompatible
Single point of failure

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.21 Tests de restauration et fire drills

Définition opérationnelle

Le backup n’existe réellement qu’après restauration testée. Les fire drills mesurent RTO/RPO, révèlent dépendances et entraînent les équipes.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Restore plan	Procédure documentée.
Isolated environment	Réseau de test/clean room.
Validation scripts	Tests applicatifs.
Timing	Chronométrage RTO.
Evidence	Rapport d’audit.

Cas d’usage principaux

Audit annuel
Cyber insurance
Ransomware readiness
Migration backup
Conformité santé/finance
Reprise post-erreur humaine

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Transforme théorie en preuve
Réduit stress incident
Révèle secrets manquants
Mesure RTO réel
Améliore runbooks

Risques / limites

Tests trop superficiels
Pas de données applicatives
Environnement isolé absent
DNS/AD/PKI oubliés
Résultats non documentés

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.22 Outils backup : Veeam, Commvault, Rubrik, Cohesity, Borg, Restic

Définition opérationnelle

Panorama des familles d’outils : enterprise backup suites, appliances convergées, open source chiffré, cloud-native, database-native et SaaS backup.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Enterprise suites	Veeam, Commvault, Veritas, IBM, Dell PowerProtect.
Cyber resilience platforms	Rubrik, Cohesity, Druva selon besoins.
Open source	Borg, Restic, Kopia, Duplicati.
Database-native	RMAN, pgBackRest, Percona XtraBackup, SQL backups.
Kubernetes	Velero, Kasten, Portworx Backup.

Cas d’usage principaux

VMware/Hyper-V enterprise
Cloud workloads
PME Linux
Kubernetes
Database PITR
SaaS protection

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Choix adapté par contexte
Open source efficace pour Linux
Enterprise = support/reporting
DB-native meilleur pour PITR
K8s spécifique nécessaire

Risques / limites

Un seul outil ne couvre pas tout
Licensing complexe
Agents obsolètes
Plugins applicatifs oubliés
Restore non testé

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.23 Runbooks incidents backup

Définition opérationnelle

Les runbooks backup doivent couvrir suppression fichier, corruption base, ransomware, perte site, repository full, job failed, clé perdue et restauration urgente.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Triage	Type incident, périmètre, urgence.
Containment	Stopper propagation/ransomware.
Recovery point selection	Choisir point propre.
Restore execution	Procédure étape par étape.
Validation	Tests métier et sécurité.

Cas d’usage principaux

Fichier supprimé
Base corrompue
VM perdue
Ransomware
Repository plein
Backup jobs en échec

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Réduit chaos incident
Capitalise expérience
Aide astreinte
Accélère RTO
Facilite post-mortem

Risques / limites

Runbook non testé
Contacts obsolètes
Credentials manquants
Dépendance expert unique
Pas de décision go/no-go

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.

28.24 Checklist production Backup

Définition opérationnelle

Checklist finale pour une stratégie backup professionnelle : RPO/RTO, 3-2-1-1-0, immutabilité, chiffrement, monitoring, tests restore, documentation.

À retenir : un backup n’est valide que si son périmètre est connu, son point de restauration est lisible, son repository est protégé, et sa restauration a été testée.

Chaîne de sauvegarde

Source→Snapshot / Agent / API→Transport→Repository→Catalog→Restore

RPOPerte

Combien de données peut-on perdre ?

RTODélai

Combien de temps pour revenir ?

RetentionDurée

Combien de temps garder ?

ImmutabilityWORM

Résister ransomware/admin compromis.

Composant	Rôle / explication
Scope	Applications, données, dépendances.
Policy	RPO/RTO, rétention, GFS.
Protection	Immutability, offsite, encryption.
Operations	Monitoring, alertes, runbooks.
Evidence	Restore reports, audit, dashboards.

Cas d’usage principaux

Mise en production
Audit interne
Cyber insurance
Conformité
Migration outil backup
Revue annuelle

Diagramme de décision

Criticité métier→RPO/RTO→Méthode backup→Repository→Test restore

Avantages

Vision complète
Réduit trous de couverture
Base audit
Alignement métier/IT
Amélioration continue

Risques / limites

Checklist remplie sans test
RPO/RTO non validés métier
Pas de propriétaire app
Coûts non budgétés
Documentation non tenue

Matrice de décision backup

Question	Décision à prendre
RPO métier	Minutes, heures, jour ? Le rythme de sauvegarde doit venir du métier, pas de l’outil.
RTO métier	Restauration fichier, VM, base, site complet ? Chaque granularité a un délai différent.
Cohérence	Crash-consistent, filesystem-consistent ou application-consistent ? Les bases exigent souvent PITR.
Menace ransomware	Backup immuable, repository isolé, MFA, séparation des comptes, clean room.
Coût complet	Repository, cloud egress, licences, déduplication, rétention, tests, support, temps humain.
Preuve	Rapport de restore, captures, logs, durée réelle, validation applicative.

Règle pratique : RPO/RTO + cohérence applicative + immutabilité + restore testé = stratégie backup crédible.

Runbook de validation

Identifier application, owner, données, dépendances, secrets, DNS, certificats, comptes de service.
Choisir un point de restauration et vérifier son intégrité dans le catalogue.
Restaurer dans un environnement isolé pour éviter d’écraser la production.
Valider techniquement : boot, filesystem, DB consistency, logs, services, permissions.
Valider métier : écrans, transactions, rapports, exports, données attendues.
Mesurer RTO/RPO réel, écarts et blocages.
Mettre à jour runbook, monitoring, politique de rétention et budget.

# Exemples de contrôles post-restore
df -h
systemctl --failed
journalctl -p err -n 100
pg_isready
mysqladmin ping
sqlcmd -Q "SELECT @@SERVERNAME"
rclone check backup:bucket/path restore:/path
sha256sum -c checksums.txt

NO-GO : aucun backup ne doit être déclaré conforme sans test de restauration documenté et validé par l’application.