📸 Storage Systems — Chapitre 29 : Snapshots

Chapitre dense sur les snapshots : définition, copy-on-write, redirect-on-write, snapshots storage array, cloud snapshots, limites, snapshots filesystem, VM, bases de données, consistency groups, lifecycle, performance, réplication, backup source, ransomware, coûts cloud, Kubernetes CSI, object versioning, gouvernance, runbooks et checklist production. L’objectif est de supprimer la confusion dangereuse entre snapshot, backup et PRA.

Point-in-timeCopy-on-writeRedirect-on-writeStorage arrayCloud snapshotsNot a backup

29.1

Définition

Image instantanée d’un volume, d’un filesystem, d’une VM, d’un LUN ou d’un dataset à un instant logique donné.

Point-in-timeVolumeFilesystem

29.2

Copy-on-write

Copy-on-write : avant de modifier un bloc source, l’ancien bloc est copié dans l’espace snapshot afin de préserver l’état original.

COWOld blockMetadata

29.3

Redirect-on-write

Redirect-on-write : les nouvelles écritures sont redirigées vers de nouveaux emplacements ; le snapshot conserve naturellement les anciens blocs.

ROWRedirectNew block

29.4

Snapshots storage array

Snapshots de baies enterprise : LUN, volumes, consistency groups, clones, replication, application integration et protection court terme.

Baie enterpriseLUNConsistency group

29.5

Snapshots cloud

Snapshots cloud : EBS snapshots, Azure managed disk snapshots, GCP Persistent Disk snapshots. Souvent incrémentaux et stockés dans un service régional/global selon provider.

EBSAzure DiskGCP PD

29.6

Limites

Un snapshot n’est pas un vrai backup s’il reste dans le même domaine de panne, le même compte compromis, la même baie, le même cluster ou la même région.

Not backupSame failure domainRisk

29.7

Snapshots filesystem : ZFS, Btrfs, LVM, APFS, ReFS

Snapshots au niveau filesystem ou volume manager : cohérence locale, rollback, clones, replication et protection court terme.

ZFSBtrfsLVMAPFS

29.8

Snapshots VM : VMware, Hyper-V, Proxmox, KVM

Snapshots VM capturent l’état disque et parfois mémoire/configuration d’une VM, utiles pour maintenance courte mais dangereux comme sauvegarde longue.

VMHypervisorDisk state

29.9

Snapshots bases de données

Snapshots de bases : utiles uniquement si cohérence transactionnelle garantie ou si combinés avec logs/PITR.

DBQuiescePITR

29.10

Crash, filesystem et application consistency

Tous les snapshots ne se valent pas : crash-consistent, filesystem-consistent et application-consistent offrent des garanties très différentes.

Crash-consistentFS-consistentApp-consistent

29.11

Consistency groups et snapshots multi-volumes

Les applications enterprise utilisent souvent plusieurs volumes. Les consistency groups garantissent un snapshot coordonné entre volumes.

Consistency groupMulti-volumeAtomicity

29.12

Lifecycle, rétention et explosion de snapshots

Les snapshots doivent avoir une politique de durée de vie. Sans lifecycle, ils deviennent dette de capacité, performance et risque opérationnel.

RetentionSprawlCleanup

29.13

Impact performance et capacité

Les snapshots modifient le chemin d’écriture, la fragmentation, les métadonnées et la capacité. L’impact dépend technologie et durée de vie.

LatencyDeltaIOPS

29.14

Snapshots et réplication

Les snapshots servent souvent de points de réplication : ZFS send, array replication, cloud snapshot copy, object copy, DR site.

ReplicationDRAsync

29.15

Snapshots comme source de backup

Le bon usage enterprise : prendre un snapshot court, sauvegarder depuis ce point vers un repository indépendant, puis supprimer le snapshot source.

Off-host backupProxyRepository

29.16

Snapshots et ransomware

Les snapshots peuvent aider contre ransomware uniquement s’ils sont protégés contre suppression/modification par l’attaquant.

RansomwareImmutable snapshotsCyber recovery

29.17

Coûts snapshots cloud

Les snapshots cloud semblent invisibles mais peuvent coûter cher : stockage incrémental, copies cross-region, rétention excessive, volumes supprimés mais snapshots conservés.

CostIncrementalEgress

29.18

Outils et commandes snapshots

Les snapshots doivent être automatisés, surveillés et testés. Les commandes varient selon ZFS, LVM, VMware, cloud et Kubernetes.

CLIZFSLVMCloud

29.19

Snapshots Kubernetes CSI

Kubernetes supporte les snapshots de volumes via CSI VolumeSnapshot, mais la cohérence applicative reste à gérer par l’application ou l’opérateur.

CSIPVCVolumeSnapshot

29.20

Versioning objet vs snapshot

Object storage ne fait pas toujours des snapshots classiques ; il utilise versioning, object lock, lifecycle et parfois bucket snapshots selon provider.

Object versioningS3Blob

29.21

Gouvernance et audit snapshots

Les snapshots doivent être gouvernés : qui peut créer, supprimer, restaurer, verrouiller, exporter, copier vers autre région ou cloner des données sensibles.

GovernanceRBACAudit

29.22

Runbooks incidents snapshots

Les runbooks doivent couvrir rollback urgent, snapshot full, datastore plein, consolidation VM, clone dev, suppression accidentelle et restore cloud.

IncidentRollbackConsolidation

29.23

Checklist production snapshots

Checklist pour utiliser les snapshots proprement en production : rétention, cohérence, monitoring, suppression, backup externe, sécurité et tests.

ChecklistProd-readyAudit

29.24

Synthèse : snapshot, backup, DR

Synthèse finale : snapshot = point local rapide ; backup = copie indépendante ; DR = capacité à redémarrer service dans un périmètre de panne différent.

SnapshotBackupDR

29.1 Définition

Définition opérationnelle

Image instantanée d’un volume, d’un filesystem, d’une VM, d’un LUN ou d’un dataset à un instant logique donné.

Point clé : le snapshot est une photographie logique rapide. Il devient une brique de protection seulement s’il est cohérent, gouverné, surveillé, et éventuellement copié hors du domaine de panne.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Source	Volume, LUN, dataset ZFS/Btrfs, VM disk, bucket, DB tablespace selon technologie.
Point-in-time	Instant logique de référence.
Metadata	Carte des blocs/objets existants au moment du snapshot.
Delta area	Zone où sont suivies les modifications après snapshot.
Rollback / clone	Retour arrière ou création d’un environnement dérivé.

Cas d’usage principaux

Rollback avant maintenance
Clone dev/test
Protection court terme
Base de backup agentless
Snapshot VM avant upgrade
Restauration fichier rapide

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très rapide
Consomme peu au départ
Très utile pour opérations courtes
Facilite clone/test
Peut servir de source backup

Risques / limites

Pas un backup indépendant
Dépend du même domaine de panne
Peut grossir vite
Peut dégrader performance
Cohérence applicative non garantie

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.2 Copy-on-write

Définition opérationnelle

Copy-on-write : avant de modifier un bloc source, l’ancien bloc est copié dans l’espace snapshot afin de préserver l’état original.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Original block	Bloc appartenant au volume source au moment du snapshot.
First write	Première modification après snapshot.
Copy old block	Copie de l’ancien contenu vers le snapshot store.
Write new block	Écriture du nouveau contenu sur la source.
Snapshot map	Table permettant de relire l’ancien état.

Cas d’usage principaux

Snapshots classiques storage array
Filesystems COW
Rollback rapide
Protection avant patch
Clones à faible coût
Backups basés snapshot

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Économie capacité initiale
Simple à comprendre
Très efficace si peu de changements
Rollback facile
Mature

Risques / limites

Pénalité à la première écriture
Fragmentation possible
Snapshot store plein dangereux
Multiples snapshots peuvent alourdir I/O
Performance sensible aux writes

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.3 Redirect-on-write

Définition opérationnelle

Redirect-on-write : les nouvelles écritures sont redirigées vers de nouveaux emplacements ; le snapshot conserve naturellement les anciens blocs.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Snapshot pointer	Référence l’ancien mapping.
New write	Écriture vers nouvel emplacement.
Metadata update	Le volume actif pointe vers le nouveau bloc.
Old block retained	L’ancien bloc reste attaché au snapshot.
Garbage collection	Nettoyage après suppression snapshot.

Cas d’usage principaux

Baies modernes
Filesystems COW avancés
Snapshots fréquents
Clones rapides
Environnements VM
Dédup/compression intégrée

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Moins de double écriture immédiate
Bon avec clones
Souvent plus performant que COW classique
Gestion élégante des snapshots multiples
Très adapté architectures modernes

Risques / limites

Metadata plus complexe
Garbage collection critique
Fragmentation logique possible
Suppression snapshot peut être coûteuse
Debug plus difficile

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.4 Snapshots storage array

Définition opérationnelle

Snapshots de baies enterprise : LUN, volumes, consistency groups, clones, replication, application integration et protection court terme.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
LUN / volume	Unité logique snapshotée.
Consistency group	Groupe de volumes snapshotés ensemble.
Clone / thin clone	Copie dérivée instantanée.
Replication	Envoi vers baie/site secondaire.
App integration	Plug-ins Oracle, VMware, SQL, SAP selon constructeur.

Cas d’usage principaux

SAN enterprise
VMware datastores
Oracle/SQL Server
SAP
Pré-upgrade baie/app
Clone dev/test

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très rapide
Intégré performance baie
Consistency groups puissants
Clones dev/test efficaces
Peut alimenter backup off-host

Risques / limites

Même baie = même domaine de panne
Licences/options
Snapshots trop longs = dette
Ransomware peut supprimer snapshots
Cohérence app à configurer

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.5 Snapshots cloud

Définition opérationnelle

Snapshots cloud : EBS snapshots, Azure managed disk snapshots, GCP Persistent Disk snapshots. Souvent incrémentaux et stockés dans un service régional/global selon provider.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Cloud disk	EBS, Azure Managed Disk, GCP Persistent Disk.
Snapshot service	Service managé de point-in-time.
Incremental blocks	Blocs modifiés sauvegardés.
Cross-region copy	Copie vers autre région selon provider.
Image / template	Création de nouvelles instances depuis snapshot.

Cas d’usage principaux

Backup VM cloud
Migration région
Golden images
DR simple
Avant patching cloud
Clone environnement

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Automatisation API/IaC
Incrémental et managé
Copie cross-region possible
Intégration IAM/KMS
Restauration disque rapide

Risques / limites

Même compte compromis
Coûts snapshots oubliés
Pas toujours app-consistent
Egress/cross-region
Rétention mal maîtrisée

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.6 Limites

Définition opérationnelle

Un snapshot n’est pas un vrai backup s’il reste dans le même domaine de panne, le même compte compromis, la même baie, le même cluster ou la même région.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Same storage	Snapshot dépend de la source.
Same admin domain	Même compte admin peut tout supprimer.
Same corruption domain	Corruption logique peut être capturée.
Same ransomware path	Attaquant peut supprimer snapshots.
No restore proof	Sans test, aucun niveau de garantie.

Cas d’usage principaux

Audit architecture
Revue ransomware
PRA/PCA
Correction fausse stratégie backup
Formation équipes
Design backup

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très bon complément backup
RTO court local
Protection erreur récente
Support clone/rollback
Base de copie externe

Risques / limites

Ne protège pas contre panne totale source
Ne protège pas toujours contre ransomware
Ne remplace pas rétention offsite
Peut être supprimé avec prod
Peut masquer absence backup

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.7 Snapshots filesystem : ZFS, Btrfs, LVM, APFS, ReFS

Définition opérationnelle

Snapshots au niveau filesystem ou volume manager : cohérence locale, rollback, clones, replication et protection court terme.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
ZFS snapshots	Snapshots COW avec send/receive.
Btrfs snapshots	Subvolumes et snapshots.
LVM snapshots	Snapshot bloc Linux classique.
APFS snapshots	macOS snapshots système/fichiers.
ReFS/VSS	Windows ecosystem selon usage.

Cas d’usage principaux

NAS OpenZFS
Proxmox datasets
Linux servers
Desktops macOS
Rollback package/system
Replication site à site

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très proches des données
Rapides
Souvent scriptables
ZFS send/receive très puissant
Rollback local simple

Risques / limites

Même disque/pool sauf réplication
LVM snapshots anciens peuvent être fragiles
Pas automatiquement app-consistent
Capacité snapshot à surveiller
Permissions/ACL à préserver

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.8 Snapshots VM : VMware, Hyper-V, Proxmox, KVM

Définition opérationnelle

Snapshots VM capturent l’état disque et parfois mémoire/configuration d’une VM, utiles pour maintenance courte mais dangereux comme sauvegarde longue.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Disk snapshot	Delta disk ou checkpoint.
Memory snapshot	État RAM optionnel.
VM config	Configuration VM/hardware virtuel.
Quiesce tools	VMware Tools, VSS, guest agent.
Consolidation	Fusion des deltas après suppression snapshot.

Cas d’usage principaux

Avant patch OS
Avant upgrade applicatif
Lab/dev test
Backup agentless source
Rollback rapide
Formation/démonstration

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très pratique
Rollback rapide
Clone lab facile
Intégration backup VM
Pas d’agent app requis pour crash-consistent

Risques / limites

Snapshots longs dégradent performance
Datastore full
Consolidation failure
DB incohérente si non quiescée
Pas un backup

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.9 Snapshots bases de données

Définition opérationnelle

Snapshots de bases : utiles uniquement si cohérence transactionnelle garantie ou si combinés avec logs/PITR.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Quiesce / freeze	Mise en pause ou flush contrôlé.
Transaction logs	WAL, redo, binlog, archivelog.
Checkpoint	État cohérent écrit.
Snapshot storage	Point-in-time disque.
Recovery process	Rejouer logs ou recovery DB.

Cas d’usage principaux

Oracle storage snapshots
SQL Server VSS
PostgreSQL filesystem snapshot + WAL
MySQL freeze/flush + binlogs
SAP HANA storage snapshot
Clone DB dev/test

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très rapide pour grosses DB
Bon pour clones
RTO court si maîtrisé
Réduit fenêtre backup
PITR possible avec logs

Risques / limites

Snapshot crash-consistent peut être insuffisant
Logs manquants = perte PITR
Freeze trop long impacte prod
Plugin DB nécessaire
Tests recovery obligatoires

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.10 Crash, filesystem et application consistency

Définition opérationnelle

Tous les snapshots ne se valent pas : crash-consistent, filesystem-consistent et application-consistent offrent des garanties très différentes.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Crash-consistent	Équivalent coupure brutale.
Filesystem-consistent	Buffers FS vidés, structure disque propre.
Application-consistent	Application prépare transactions et logs.
VSS / guest agent	Mécanismes Windows/Linux.
Validation restore	Preuve de cohérence réelle.

Cas d’usage principaux

Choix politique snapshot
VM backups
DB backups
Apps multi-volumes
Audit PRA
Architecture enterprise

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Clarifie les garanties
Évite fausse sécurité
Guide plugins nécessaires
Améliore restore
Aide RPO/RTO

Risques / limites

Confusion fréquente
Marketing outil ambigu
Application non supportée
Multi-volume non atomique
Pas de test = incertitude

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.11 Consistency groups et snapshots multi-volumes

Définition opérationnelle

Les applications enterprise utilisent souvent plusieurs volumes. Les consistency groups garantissent un snapshot coordonné entre volumes.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Volumes group	Data, logs, temp, binaries.
Atomic snapshot	Capture coordonnée.
Write-order fidelity	Respect ordre écritures.
Application hooks	Freeze/thaw app.
Restore group	Restauration cohérente de tout le groupe.

Cas d’usage principaux

Oracle ASM
SQL Server data/logs
SAP
VM datastores multiples
Microservices stateful
Applications clusterisées

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Cohérence multi-disques
Indispensable DB complexes
Réduit corruption logique
Simplifie restore app
Bon pour DR

Risques / limites

Mal groupé = restore cassé
Pas app-consistent sans hooks
Restauration partielle dangereuse
Gestion plus complexe
Coordination baie/hyperviseur/app

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.12 Lifecycle, rétention et explosion de snapshots

Définition opérationnelle

Les snapshots doivent avoir une politique de durée de vie. Sans lifecycle, ils deviennent dette de capacité, performance et risque opérationnel.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Schedule	Fréquence snapshot.
Retention	Combien garder.
Expiration	Suppression automatique.
Monitoring	Capacité delta, âge, nombre.
Owner	Responsable et justification.

Cas d’usage principaux

Snapshots horaires/journaliers
Pré-maintenance
Dev/test clones
GFS local court terme
Politique NAS
VM snapshots contrôlés

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Contrôle capacité
Réduit risques performance
Audit clair
Évite snapshots oubliés
Préserve RTO court

Risques / limites

Snapshots orphelins
Delta énorme
Datastore/pool plein
Suppression longue
Coût cloud caché

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.13 Impact performance et capacité

Définition opérationnelle

Les snapshots modifient le chemin d’écriture, la fragmentation, les métadonnées et la capacité. L’impact dépend technologie et durée de vie.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Write amplification	Écritures supplémentaires COW/metadata.
Metadata overhead	Mappings de blocs/objets.
Fragmentation	Blocs actifs et snapshots dispersés.
Delta growth	Croissance des changements.
Consolidation	Fusion/suppression coûteuse.

Cas d’usage principaux

Sizing storage array
VMware snapshot policies
ZFS/Btrfs NAS
Cloud snapshot costs
DB under load
Backup window tuning

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Snapshots courts souvent peu coûteux
Technos modernes optimisées
Très utile pour protection rapide
Peut réduire backup window

Risques / limites

Performance collapse possible
Capacité pleine = incident critique
Consolidation très longue
Latence DB impactée
Suppression snapshot coûteuse

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.14 Snapshots et réplication

Définition opérationnelle

Les snapshots servent souvent de points de réplication : ZFS send, array replication, cloud snapshot copy, object copy, DR site.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Snapshot source	Point de départ.
Delta transfer	Changements depuis snapshot précédent.
Target repository/site	Destination de réplication.
Retention target	Historique côté cible.
Failover/failback	Procédure PRA.

Cas d’usage principaux

ZFS send/receive
SAN replication
NAS replication
Cloud cross-region snapshots
DR site
Offline copy

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Transfert delta efficace
Très utile DR
Rétention côté cible
Peut sortir du domaine de panne
Base de PRA

Risques / limites

Réplication corruption/ransomware possible
RPO dépend fréquence
Failback complexe
Bande passante
Cible doit être protégée

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.15 Snapshots comme source de backup

Définition opérationnelle

Le bon usage enterprise : prendre un snapshot court, sauvegarder depuis ce point vers un repository indépendant, puis supprimer le snapshot source.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Production snapshot	Point court et cohérent.
Backup proxy	Lit snapshot sans bloquer prod.
Repository independent	Stockage de backup séparé.
Catalog	Index restore.
Snapshot cleanup	Suppression rapide après job.

Cas d’usage principaux

Veeam VMware
NetApp SnapCenter
Dell/IBM/HPE plugins
Cloud snapshot export
DB off-host backup
NAS backup

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Réduit impact production
Fenêtre snapshot courte
Repository indépendant
Bonne architecture backup
Compatible app plugins

Risques / limites

Snapshot oublié après backup failed
Repository non immuable
Cohérence app oubliée
Dépend API storage
Nettoyage à surveiller

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.16 Snapshots et ransomware

Définition opérationnelle

Les snapshots peuvent aider contre ransomware uniquement s’ils sont protégés contre suppression/modification par l’attaquant.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Protected snapshots	Snapshots verrouillés/immutables selon plateforme.
Admin separation	Comptes prod et backup séparés.
MFA	Protection console/API.
Cyber vault	Copie isolée.
Clean restore	Restauration dans environnement sain.

Cas d’usage principaux

NAS ransomware
VM encryption
File server rollback
Object lock snapshots
Cyber recovery vault
Forensic timeline

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Rollback rapide si snapshots intacts
Très utile file server/NAS
Réduit downtime
Complète backup immuable
Aide forensic

Risques / limites

Attaquant supprime snapshots
Snapshots contiennent déjà fichiers chiffrés
Même credentials
Rétention trop courte
Pas de clean room

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.17 Coûts snapshots cloud

Définition opérationnelle

Les snapshots cloud semblent invisibles mais peuvent coûter cher : stockage incrémental, copies cross-region, rétention excessive, volumes supprimés mais snapshots conservés.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Incremental storage	Blocs conservés même si source supprimée.
Cross-region copy	Stockage + transfert.
KMS keys	Chiffrement et permissions.
AMI/images	Snapshots cachés derrière images.
Lifecycle manager	Expiration automatique.

Cas d’usage principaux

AWS EBS snapshots
Azure Disk snapshots
GCP PD snapshots
Golden images
DR cloud
FinOps cleanup

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Automatisable
Pas de full manuel
Cross-region DR
Très pratique IaC
Granular retention

Risques / limites

Sprawl coûteux
Images anciennes oubliées
Cross-region surprise
KMS key disabled = restore impossible
Même compte compromis

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.18 Outils et commandes snapshots

Définition opérationnelle

Les snapshots doivent être automatisés, surveillés et testés. Les commandes varient selon ZFS, LVM, VMware, cloud et Kubernetes.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
CLI/API	Créer, lister, supprimer, restaurer.
Scheduler	Planification et rétention.
Monitoring	Âge, taille, erreurs.
Audit	Qui a créé/supprimé.
Automation	Terraform, Ansible, scripts.

Cas d’usage principaux

Ops Linux
Cloud IaC
NAS ZFS
Proxmox
Kubernetes CSI
Runbook support

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Reproductibilité
Audit
Moins d’oubli
Intégration monitoring
Réduction erreur humaine

Risques / limites

Script sans garde-fou
Suppression massive accidentelle
Credentials trop larges
Pas de dry-run
Logs insuffisants

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.19 Snapshots Kubernetes CSI

Définition opérationnelle

Kubernetes supporte les snapshots de volumes via CSI VolumeSnapshot, mais la cohérence applicative reste à gérer par l’application ou l’opérateur.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
VolumeSnapshotClass	Classe de snapshot CSI.
VolumeSnapshot	Objet Kubernetes du snapshot.
VolumeSnapshotContent	Ressource liée au backend.
CSI driver	Driver storage.
App hooks	Freeze/quiesce applicatif.

Cas d’usage principaux

StatefulSets
DB operators
Velero/Kasten
Migration namespace
Rollback PVC
Dev/test clone

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Native Kubernetes
Automatisable par GitOps
Compatible sauvegarde cluster
Clone PVC possible
Intégration operators

Risques / limites

CSI feature support variable
Snapshots non app-consistent par défaut
CRD/version mismatch
Restore namespace complexe
Backup etcd séparé

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.20 Versioning objet vs snapshot

Définition opérationnelle

Object storage ne fait pas toujours des snapshots classiques ; il utilise versioning, object lock, lifecycle et parfois bucket snapshots selon provider.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Object versioning	Chaque modification crée version.
Delete marker	Suppression logique.
Object Lock	WORM/immutabilité.
Lifecycle	Expiration versions.
Replication	Copie bucket/site.
Inventory	Liste objets/versions.

Cas d’usage principaux

S3 ransomware protection
Erreur suppression objet
Archive légale
Backup repository immuable
Data lake versioned
Object rollback

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Très bon contre suppression logique
Compatible immutabilité
Granularité objet
S3 ecosystem
Réplication possible

Risques / limites

Versioning coûteux si non nettoyé
Pas snapshot atomic multi-objets
Delete markers confus
Object lock irréversible selon mode
Lifecycle mal réglé

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.21 Gouvernance et audit snapshots

Définition opérationnelle

Les snapshots doivent être gouvernés : qui peut créer, supprimer, restaurer, verrouiller, exporter, copier vers autre région ou cloner des données sensibles.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
RBAC	Droits création/suppression/restore.
MFA	Protection comptes admin.
Audit logs	Traçabilité opérations.
Labels/tags	Owner, app, env, retention.
Approval workflow	Contrôle restauration données sensibles.

Cas d’usage principaux

Cloud enterprise
Baies SAN
NAS multi-tenant
Santé/finance
Dev/test clones
Audit interne

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Réduit suppression accidentelle
Améliore conformité
Contrôle données sensibles
Facilite FinOps
Prépare investigations

Risques / limites

Admins trop puissants
Logs non activés
Tags absents
Clone prod vers dev non contrôlé
Données personnelles conservées

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.22 Runbooks incidents snapshots

Définition opérationnelle

Les runbooks doivent couvrir rollback urgent, snapshot full, datastore plein, consolidation VM, clone dev, suppression accidentelle et restore cloud.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Triage	Type snapshot, âge, cohérence.
Capacity check	Espace source/delta/target.
Quiesce status	Cohérence app.
Rollback plan	Retour arrière et validation.
Fallback backup	Plan B si snapshot échoue.

Cas d’usage principaux

Rollback patch raté
VM snapshot consolidation
ZFS pool plein
Cloud snapshot restore
DB clone
Ransomware file server

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

RTO court
Réduit panique
Évite rollback destructeur
Clarifie validation
Documente risques

Risques / limites

Rollback écrase données récentes
Snapshot non cohérent
Capacité insuffisante
Pas de plan B backup
Décision métier absente

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.23 Checklist production snapshots

Définition opérationnelle

Checklist pour utiliser les snapshots proprement en production : rétention, cohérence, monitoring, suppression, backup externe, sécurité et tests.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Policy	Quand, quoi, durée.
Consistency	Crash/FS/app.
Capacity	Delta, quotas, alertes.
Security	RBAC, immutability, MFA.
External copy	Backup ou réplication hors domaine.

Cas d’usage principaux

Mise en production
Audit stockage
Runbook VMware
NAS ZFS
Cloud FinOps
Ransomware readiness

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Évite snapshots sauvages
Clarifie responsabilité
Réduit coût
Améliore restore
Base audit

Risques / limites

Checklist sans automatisation
Rétention non appliquée
Monitoring absent
Snapshots trop longs
Backup externe oublié

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.

29.24 Synthèse : snapshot, backup, DR

Définition opérationnelle

Synthèse finale : snapshot = point local rapide ; backup = copie indépendante ; DR = capacité à redémarrer service dans un périmètre de panne différent.

Chaîne snapshot

Source active→Point-in-time→Delta / metadata→Rollback / clone→Backup / replication

RTOCourt

Rollback local rapide.

ScopeLocal

Domaine source à analyser.

RiskDelta

Capacité et performance.

BackupNon

Sauf copie indépendante.

Composant	Rôle / explication
Snapshot	Rollback/clone local rapide.
Backup	Copie restaurable indépendante avec catalogue.
Replication	Copie automatique vers autre cible/site.
Immutable copy	Protection ransomware.
DR plan	Procédure de reprise testée.

Cas d’usage principaux

Formation équipes
Architecture cible
Audit PRA/PCA
Choix outil
Correction fausse sécurité
Design anti-ransomware

Diagramme d’utilisation saine

Pré-check capacité→Quiesce si nécessaire→Snapshot court→Opération→Validation→Suppression / backup

Avantages

Clarifie les rôles
Évite confusion fréquente
Guide architecture robuste
Relie RTO/RPO
Prépare chapitres DR

Risques / limites

Surutiliser snapshots
Sous-investir backup
Ignorer DR
Confondre réplication et sauvegarde
Ne jamais tester restore

Matrice de décision snapshot

Question	Décision à prendre
Quel niveau de cohérence ?	Crash-consistent, filesystem-consistent ou application-consistent. Les bases critiques exigent des logs et un recovery testé.
Quel domaine de panne ?	Même baie, même cluster, même compte cloud, même région : snapshot seul insuffisant.
Quelle durée ?	Snapshots courts pour rollback. Rétention longue uniquement si capacité, performance et gouvernance sont maîtrisées.
Quel owner ?	Chaque snapshot doit avoir application, propriétaire, raison, date d’expiration et criticité.
Quel plan ransomware ?	RBAC, immutabilité éventuelle, MFA, copies séparées, audit des suppressions.
Quel backup indépendant ?	Copie vers repository séparé, object lock, tape, cloud cross-account ou site secondaire.

Règle pratique : snapshot pour revenir vite ; backup pour survivre à la perte ou compromission de la source ; DR pour survivre à la perte d’un site.

Runbook de validation snapshot

Identifier source, application, volumes concernés, dépendances et niveau de cohérence requis.
Vérifier capacité disponible pour les deltas et seuils d’alerte.
Si base/app critique : activer quiesce, VSS, freeze/thaw, checkpoint ou plugin applicatif.
Créer le snapshot et enregistrer owner, ticket, expiration et contexte.
Tester lecture, clone ou restauration sur un environnement isolé si le snapshot est utilisé comme protection.
Supprimer ou expirer automatiquement selon politique.
Vérifier qu’un backup indépendant existe pour la même application.

# Exemples opérationnels
zfs snapshot tank/app@before-upgrade
zfs list -t snapshot
lvcreate -s -n data_snap -L 20G /dev/vg/data
aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "before-upgrade"
kubectl get volumesnapshot
df -h
iostat -x 1

NO-GO : snapshot long sans expiration, application critique sans cohérence, datastore/pool presque plein, ou absence de backup indépendant.