Coordonner les sauvegardes par snapshot SAN : cohérence des volumes entre hôtes et vérifications de RESTauration

La capture de snapshot SAN est considérée en exploitation comme „rapide et élégante“ : un snapshot est créé en quelques secondes, qu’il y ait plusieurs téraoctets derrière ou non. En pratique, le problème ne survient pas lors du snapshot lui‑même, mais lorsqu’il s’agit de savoir si les données sont réellement exploitables au RESTore. C’est précisément là que les équipes doivent coordonner les backups par snapshot SAN : sur plusieurs hôtes, plusieurs volumes, éventuellement des systèmes de fichiers en cluster et des bases de données — et avec des contrôles de RESTauration qui vont au‑delà de « Snapshot existiert ».

Cet article présente une démarche opérationnelle qui fonctionne aussi dans des environnements hétérogènes (Windows/Linux, VMware/physique, iSCSI/Fibre Channel). L’accent est mis sur la cohérence des volumes (état simultané sur plusieurs LUNs/volumes), les mécanismes de quiesce (mise au repos ciblée des E/S) et la validation de RESTauration (redémarrage vérifiable). Vous trouverez des étapes de vérification concrètes, des pièges typiques, une checklist ainsi qu’une stratégie de repli si la coordination des hôtes n’est pas assurée.

Pourquoi un snapshot n’est pas une sauvegarde — et où la cohérence se rompt réellement

Un SAN-Snapshot est une fonction de stockage qui fige l’état à un instant d’un volume (souvent d’une LUN). Selon le système, cela se fait en Copy-on-Write ou Redirect-on-Write : toutes les données ne sont pas copiées immédiatement, seules les modifications à partir du point de snapshot sont conservées séparément. C’est rapide, mais c’est d’abord juste une image temporelle de stockage.

En revanche, une sauvegarde au sens opérationnel couvre davantage : conservation définie, copie immuable (selon le niveau de protection), RESTauration traçable et tests réguliers. Les snapshots font souvent partie de la chaîne de sauvegarde — mais seuls ils ne garantissent pas contre les défaillances de stockage, les erreurs d’opérateur ou les ransomwares (selon le durcissement des snapshots).

Le point critique est la cohérence :

• Crash-consistent : le snapshot correspond à l’état comme si l’hôte s’était « éteint subitement ». Les journaux de système de fichiers aident souvent, mais les bases de données peuvent nécessiter une récupération et les états applicatifs peuvent être incohérents.
• Application-consistent : l’application/DB est placée dans un état défini avant le snapshot (flush, freeze, checkpoint). Sur Windows c’est souvent le VSS (Volume Shadow Copy Service) qui est pertinent ; sous Linux, par ex. fsfreeze (court freeze du système de fichiers) plus flush/lock spécifique à la DB.
• Multi-volume consistent : plusieurs volumes (p. ex. données + logs, ou plusieurs LUNs d’un système de fichiers) sont sauvegardés simultanément. Côté stockage, on parle souvent de Consistency Group (groupe cohérent), côté hôte cela nécessite une orchestration.

Erreur classique au quotidien : « Nous snapshotons les LUNs les unes après les autres, ça suffit. » Dès qu’une application écrit en parallèle (ou que les logs sont séparés), quelques secondes de décalage suffisent pour créer, au RESTore, une lacune logique. Les symptômes n’apparaissent alors que des semaines plus tard — au moment de la RESTauration.

Prérequis en exploitation : ce qu’il faut clarifier avant la première orchestration

Avant d’entrer dans l’aspect technique, clarifiez trois éléments qui sont souvent confondus en exploitation :

• Objectif de protection : RPO (perte de données maximale en temps) et RTO (temps de reprise maximal). Cela détermine si les snapshots sont juste un « coussin temporaire » ou font partie d’une chaîne plus longue.
• Topologie des données : quels volumes/LUNs appartiennent logiquement ensemble ? Où résident les données, les journaux de transactions, les temporaires, les index, les attachments, les disques VM ?

Sur le plan technique, vous devriez également vérifier les points suivants :

• Capacités de stockage : existe-t-il des Consistency Groups, SnapMirror/Replication, rétention des snapshots, éventuellement des Immutable Snapshots (selon le fournisseur) ?
• Intégration hôte : Windows VSS Provider (logiciel/matériel), Linux-tools (fsfreeze), VMware Tools / intégration VADP, options agent/script.
• Multipathing/Failover : pour iSCSI/FC, Multipath (plusieurs chemins vers le stockage) est la norme. Les timeouts et les basculements de chemin pendant les phases de gel sont un écueil fréquent.
• Droits/Change-Control : la création de snapshots est un changement impactant la production. La journalisation et une exécution traçable sont obligatoires.

Coordination des sauvegardes par snapshot SAN : principe d’architecture pour le côté hôte et stockage

Une architecture robuste sépare les responsabilités, tout en les reliant via un runbook d’orchestration :

• Côté hôte assure des états I/O définis (quiesce) : vidage des bases de données, gel des systèmes de fichiers, arrêt des services critiques si nécessaire.
• Côté stockage crée des snapshot(s) au sein d’un groupe de cohérence : autant que possible atomique, pas séquentiel.
• Côté validation monte les snapshots isolément et exécute des contrôles vérifiables (système de fichiers, récupération de bases de données, échantillons de fichiers/ACL).

Important : la coordination ne signifie pas « geler tout ». L’objectif est une fenêtre de quiesce courte (secondes), durant laquelle aucune suite d’écritures incohérente n’apparaît. Des gels prolongés augmentent le risque de timeouts (application, Multipath, cluster) et aggravent les effets secondaires.

Termes que vous devez définir clairement dans le runbook

• LUN / Volume : unité de stockage apparaissant au niveau de l’hôte comme un périphérique bloc (p. ex. /dev/sdX, Windows Disk). « Volume » peut signifier, selon le contexte, volume de stockage ou volume de système de fichiers – définissez-le précisément.
• Consistency Group : mécanisme de stockage permettant de snapshotter plusieurs volumes simultanément.
• Quiesce : mettre l’application ou le système de fichiers dans un état calme, afin que les écritures en cours soient terminées (flush) et qu’aucune nouvelle ne commence.
• Mount-Host : serveur/VM isolé sur lequel les copies de snapshot sont montées pour vérification, sans impacter la production.

Méthodes de quiesce par plateforme : ce qui fonctionne réellement (et ce qui engendre des effets secondaires)

Vous n’avez pas besoin de connaître chaque application en détail, mais vous devez disposer d’une couche robuste par plateforme.

Windows: Utiliser VSS de manière pertinente (Writer, Provider, coordination)

VSS (Volume Shadow Copy Service) coordonne les « Writer » (applications comme SQL Server), le « Requestor » (outil de sauvegarde) et les « Provider » (logiciel ou matériel de stockage). Dans les workflows de snapshot, il est crucial de savoir si vous ne créez qu’une shadow copy Windows ou si un Hardware-VSS-Provider déclenche de manière cohérente le snapshot SAN.

Problèmes courants en pratique :

• Les VSS Writers RESTent bloqués dans des états d’erreur (« Failed »), les snapshots s’exécutent mais ne sont pas cohérents au niveau applicatif.
• Trop d’actions VSS parallèles (p. ex. via plusieurs outils) provoquent des conflits.
• Mismatch de provider : le software-provider crée un snapshot local, le snapshot de stockage est néanmoins exécuté séparément — sans coordination.

Vérifiez régulièrement les Writers :

vssadmin list writers

Les runbooks devraient préciser : « Si le Writer X n’est pas Stable, le snapshot n’est que crash-consistent et le contrôle de RESTauration doit impérativement inclure la récupération de la base de données. »

Linux: fsfreeze plus vidage applicatif – bref, contrôlé, réversible

Sous Linux, fsfreeze est un mécanisme courant pour « freezer » brièvement un système de fichiers monté (aucune nouvelle écriture) pendant que le snapshot est créé côté stockage. Ce n’est pas la même chose qu’un snapshot LVM ; il s’agit d’une coordination côté hôte.

Séquence d’exemple (principe, non spécifique au fournisseur) :

#!/usr/bin/env bash
set -euo pipefail

MOUNTPOINT="/data"

# 1) Applikation/DB: Flush/Checkpoint (hier nur Platzhalter)
# systemctl stop app || true

# 2) Filesystem kurz einfrieren
fsfreeze -f "$MOUNTPOINT"

# 3) Storage-Snapshot auslösen (hier als Platzhalter)
# storagecli snapshot create --cg prod-cg --name "prod-$(date +%F-%H%M%S)"

# 4) Unfreeze
fsfreeze -u "$MOUNTPOINT"

# 5) Applikation wieder starten
# systemctl start app || true

Quand cela échoue : pour les systèmes de fichiers distribués/cluster-FS, lors d’opérations de snapshot très longues (freeze trop long), ou si des applications écrivent directement sur des raw devices (p. ex. base de données sur un blockdevice sans FS). Dans ce cas, vous aurez besoin de mécanismes spécifiques à l’application (mode de sauvegarde DB, points de contrôle, réplication cohérente).

VMware/virtualisierung: Snapshot-Kette sauber halten

Dans les environnements virtualisés, il existe plusieurs niveaux de snapshots : VM-snapshots (hyperviseur), storage-snapshots (SAN), éventuellement des métadonnées supplémentaires dans le logiciel de sauvegarde. L’objectif est d’éviter d’empiler aveuglément plusieurs chaînes de snapshots les unes sur les autres. Cela génère des risques de performance et complexifie les chemins de RESTauration et l’analyse des erreurs.

Bonne pratique opérationnelle : décidez, pour chaque workload, quel niveau est le « leader ». Si les storage-snapshots sont le moyen principal, le niveau VM doit servir uniquement à la coordination (Quiesce), pas à la conservation à long terme.

Consistence multi-hôte et multi-volume : le point critique pour les vrais workloads SAN

Dès qu’un service s’exécute sur plusieurs hôtes (cluster, App-Tier + DB-Tier, cluster de serveurs de fichiers), un « freeze sur l’hôte A » n’est pas suffisant. Il vous faut une fenêtre orchestrée : tous les hôtes impliqués doivent dans un ordre défini passer en état de quiescence, effectuer ensuite le snapshot dans une Consistency Group, puis revenir en exploitation normale.

Constellations typiques :

• Serveurs DB + serveurs applicatifs : la base de données doit être cohérente, les caches applicatifs ne doivent pas provoquer d’écritures à un « mauvais moment ». Souvent, il suffit de mettre l’application brièvement en mode maintenance ou d’arrêter les opérations d’écriture.
• Système de fichiers en cluster : plusieurs hôtes écrivent en parallèle sur les mêmes LUNs. Un fsfreeze local sur un nœud n’est pas suffisant et peut même être dangereux. Utilisez des mécanismes de freeze/flush spécifiques au cluster ou sauvegardez via des méthodes au niveau applicatif.
• Données + journaux sur des volumes séparés : sans Consistency Group, un snapshot peut être décalé dans le temps et donc risqué. Dans ce cas, le support du stockage est presque impératif.

Si votre plateforme de stockage ne propose pas de véritable Consistency Group pour les LUNs concernés, c’est un signal clair : soit vous acceptez une cohérence de type crash-consistent avec une validation de RESTauration rigoureuse, soit vous passez à une méthode de sauvegarde qui assure la cohérence à un niveau supérieur (sauvegarde applicative, sauvegardes natives de la base de données, agents).

Pièges typiques et symptômes d’erreur (Troubleshooting aus Betriebssicht)

De nombreux problèmes ne se manifestent pas lors du snapshot, mais par des effets secondaires « étranges » : baisse de performance, timeouts, volumes incohérents après RESTauration. Voici des causes fréquentes avec des symptômes clairs.

La fenêtre de quiescence est trop longue : timeouts, blocages, réinitialisations Multipath

Une fenêtre de quiescence trop longue peut suffire à provoquer des arrêts d’applications ou une réévaluation des chemins. Particulièrement avec iSCSI/Multipath, on observe alors des bascules de chemin, de la mise en file d’attente et des pics d’I/O ultérieurs.

Contre-mesures :

• Maintenir la fenêtre de quiescence aussi courte que possible : la création du snapshot doit être « instantanée » (ou le stockage doit confirmer rapidement le commit).
• Préparer les opérations de snapshot : schéma de nommage, CG, rétention, aucune interaction pendant la fenêtre de quiescence.
• Ne pas augmenter les timeouts de manière systématique sans corriger la cause – sinon vous ne ferez que déplacer le problème.

« Snapshot réussi », mais la RESTauration ne boot pas / la DB ne démarre pas

C’est classique pour des snapshots crash-consistents sur des workloads à fort taux d’écritures ou répartis sur plusieurs volumes. Sans points de flush définis, des blocs appartenant ensemble peuvent manquer ou des transactions peuvent être « à moitié » appliquées.

Vérifiez notamment lors de la RESTauration :

• Récupération du système de fichiers (relecture du journal) et, si nécessaire, fsck dans un environnement isolé.
• Journaux de recovery propres à la base de données : les logs ont-ils été sauvegardés de manière cohérente ? Y a-t-il des erreurs « missing log » ?
• Ordre : monter d’abord les logs, puis les données ? Ou inversement ? Cela dépend de l’application – consignez-le dans le runbook.

Les snapshots « explosent » en taille : rétention, taux de changement, effet ransomware

Les snapshots ne sont pas « gratuits ». À fort taux de changements, la zone delta augmente. Si la rétention est trop longue ou si un rançongiciel génère massivement des modifications, le stockage dédié aux snapshots peut rapidement se remplir. Cela peut alors impacter la production (selon l’implémentation du stockage).

Opérationnalisez donc :

• Quotas/monitoring pour le delta des snapshots et l’occupation globale.
• Rétention selon RPO/RTO et selon « Zeit bis zur Entdeckung » (Detection Window) – sans affirmer que les snapshots constituent la seule protection contre les ransomwares.
• Règles déterminant qui peut supprimer les snapshots (et comment cela est consigné dans les logs).

Implémentation en tant que Runbook : séquence d’étapes, verrouillage, journalisation, repli

Un bon Runbook n’est pas seulement une « chaîne de commandes », il inclut des mécanismes de verrouillage (pour éviter l’exécution parallèle de deux jobs), des codes de sortie clairs et un comportement de repli défini. Les pRESTataires techniques en particulier ont besoin de cela pour des interventions reproductibles.

1) Preflight-Checks (avant Quiesce)

• Le Consistency Group est-il correctement composé (tous les LUNs/Volumes inclus) ?
• La capacité de snapshots est-elle suffisante (delta/réserve) ?
• Les VSS-Writers sont-ils « Stable » (Windows) et l’Applikations-Health ok (Linux/DB) ?
• Y a-t-il déjà des jobs Snapshot-/Backup en cours (Lock) ?
• Le Mount-Host est-il disponible pour des contrôles ultérieurs (accès stockage, VLAN, iSCSI/FC-Zoning) ?

2) Quiesce-Fenster : aussi court que possible

Seuls les éléments strictement nécessaires doivent être exécutés ici. Tout le RESTe (nommage, dossiers de logs, notifications) doit être fait en amont.

• Déclencher le flush/checkpoint de l’application.
• Geler éventuellement le système de fichiers (freeze).
• Déclencher le storage-snapshot dans la Consistency Group.
• Unfreeze / normaliser l’application.

3) Postflight : inventaire des snapshots et journal d’événements

Au minimum, les données suivantes doivent figurer dans votre log central (ticket/CMDB/système de logs) : nom du snapshot, timestamp, volumes affectés, hôtes impliqués, résultat du contrôle de quiesce, ainsi que référence au rapport de vérification de RESTauration.

Locking-Beispiel (Linux) pour des jobs coordonnés

#!/usr/bin/env bash
set -euo pipefail

LOCKFILE="/var/lock/san-snapshot.lock"
exec 9>"$LOCKFILE"

if ! flock -n 9; then
  echo "ERROR: Snapshot-Job läuft bereits." >&2
  exit 20
fi

echo "OK: Lock gehalten, Job startet."

Cela empêche les opérateurs ou les ordonnanceurs de lancer des snapshots en parallèle par erreur, ce qui provoque des erreurs difficiles à expliquer, notamment pour les Consistency Groups et VSS.

RESTore-Checks : ce qu’il faut contrôler pour que « Snapshot vorhanden » signifie réellement « RESTore möglich »

Le levier principal pour des sauvegardes fiables n’est pas le bouton snapshot, mais la validation régulière des RESTaurations. L’objectif est une preuve répétable que vos snapshots fonctionnent dans le mode de RESTauration prévu.

Sur le plan pragmatique, un modèle à plusieurs niveaux s’est avéré efficace :

• Niveau 1 : Mount-Check – le snapshot peut être monté sur le Mount-Host, les volumes sont visibles, pas d’erreurs d’E/S évidentes.
• Niveau 2 : Filesystem-Check – montage en lecture seule, journal-replay/check (selon le FS), échantillonnage des répertoires, ACLs/permissions.
• Niveau 3 : vérification applicative – démarrer une instance de base de données dans un environnement isolé ou au minimum vérifier la cohérence de la structure (p. ex. métadonnées, journaux de récupération). Chaque contrôle n’a pas besoin d’être un démarrage complet, mais il doit être significatif.

Linux: Montage en lecture seule et tests de base (exemple)

L’isolation est primordiale : ne jamais « insérer » de manière non contrôlée un volume productif ayant la même signature sur le même hôte s’il existe un risque qu’il soit monté automatiquement ou importé dans LVM. Utilisez des filtres de périphérique clairs et montez en lecture seule.

#!/usr/bin/env bash
set -euo pipefail

DEVICE="/dev/mapper/snap_lun1p1"
MNT="/mnt/RESTorecheck"

mkdir -p "$MNT"
mount -o ro,noload "$DEVICE" "$MNT"

# Stichprobe: Verzeichnisbaum und Dateizählung
find "$MNT" -maxdepth 2 -type d | head -n 50

# Prüfen, ob kritische Pfade vorhanden sind
test -d "$MNT/app/data"
test -f "$MNT/app/config/production.conf"

umount "$MNT"

Remarque : des options comme noload dépendent du système de fichiers (p. ex. ext4). Le principe prime : lecture seule et sans actions de récupération en écriture si vous ne souhaitez que valider.

Windows: Montage/attachement dans un environnement isolé et indices VSS

Sur Windows le défi fréquent est de présenter des LUNs de snapshot de façon contrôlée (SAN-Zoning/iSCSI Targeting) et de ne pas entrer accidentellement en collision avec des volumes existants. Exécutez de préférence les contrôles de RESTauration sur un hôte de RESTauration dédié qui n’amène pas de disques productifs en ligne.

Pour les workloads basés sur VSS : au-delà du simple « snapshot présent », il importe de vérifier si les Writers ont été réellement propres pendant la fenêtre de sauvegarde et si, lors de la RESTauration, l’application peut effectuer correctement sa récupération. Prévoyez au moins un test périodique de RESTauration « profond » (Niveau 3), pas seulement des contrôles de montage.

Liste de contrôle : comment assurer la cohérence des volumes entre hôtes

Si vous ne voulez imprimer qu’une seule page, c’est celle-ci. Elle est délibérément orientée exploitation et formulée de manière neutre vis-à-vis des fournisseurs.

Planification

• Classification des workloads : tolérance crash-consistent acceptable ou cohérence applicative requise ?
• Quels volumes appartiennent ensemble (données/journaux/métadonnées/quorum) ?
• Existe-t-il des Consistency Groups sur le stockage — et tous les volumes y sont-ils inclus ?
• Définir RPO/RTO et rétention de façon à ce que l’espace de stockage des snapshots ne croisse pas de manière incontrôlée.

Avant le Snapshot (Preflight)

• Health : stockage, chemins (Multipath), état de l’hôte, état de l’application.
• Windows : VSS-Writers stables, pas de jobs VSS concurrents.
• Linux : points de montage univoques, Freeze/Unfreeze testés, limites de timeout claires.
• Locking : pas de job de snapshot parallèle, fenêtre de changements respectée.

Fenêtre de snapshot

• Quiesce/Freeze seulement quelques secondes, snapshot atomique (Consistency Group), puis retour immédiat.
• Gestion propre des erreurs : si le snapshot échoue, exécuter impérativement l’unfreeze et normaliser l’application.

Après le Snapshot

• Consigner l’inventaire des snapshots (nom, heure, CG, volumes).
• Contrôles automatisés de RESTauration sur l’hôte de montage (au minimum niveaux 1–2).
• Planifier régulièrement des tests de niveau 3 (validation applicative plus approfondie).

Stratégie de repli : que faire si les snapshots coordonnés ne sont pas fiables ?

Toutes les environnements ne peuvent pas être proprement « quiescés ». Certains systèmes de fichiers de cluster, applications héritées ou systèmes très sensibles à la latence réagissent mal. Dans ce cas, la bonne décision n’est pas de « prendre un snapshot quand même », mais un repli contrôlé :

• Sauvegardes applicatives: sauvegarder les bases de données avec leurs propres mécanismes (p. ex. Hot-Backup/Online-Backup), car elles connaissent le mieux la cohérence.
• Procédés basés sur les logs: si l’exigence RPO est faible, les journaux de transactions et les flux répliqués sont souvent plus robustes que les seuls snapshots de stockage.
• Crash-consistent + validation stricte des RESTaurations: si vous acceptez la consistance crash, le niveau 3 des vérifications de RESTauration doit être exécuté plus fréquemment et plus strictement, y compris les procédures de récupération.
• Segmentation: séparez les charges de travail. Tout ne doit pas être soumis à la même politique de snapshots.

Il est important que le plan de repli soit documenté : quels risques acceptez-vous, quelles vérifications compensent cela, et à quoi ressemble la procédure d’urgence (étapes de RESTauration, responsabilités, voie de communication) ?

Conclusion : coordination et vérifications de RESTauration rendent les snapshots sûrs en exploitation

Les snapshots sur le SAN sont un outil puissant si vous les exploitez comme partie d’un processus contrôlé. La différence entre « nous réalisons des snapshots » et « nous savons RESTaurer » tient à deux disciplines : d’une part, vous devez coordonner les sauvegardes par snapshot SAN afin que les charges multi‑volumes et multi‑hôtes atteignent un état cohérent. D’autre part, il vous faut des vérifications de RESTauration qui démontrent régulièrement que le montage, le système de fichiers et — le cas échéant — la récupération applicative fonctionnent.

Si vous opérationnalisez cela sous forme de runbook (Preflight, courte fenêtre de quiescence, groupes de snapshots atomiques, journalisation, validation de RESTauration par paliers), vous réduirez drastiquement les surprises habituelles : volumes incohérents, VSS-Writers en erreur, Freeze-Timeouts et chemins de RESTauration qui n’existent que sur le papier.

Pour ce sujet, Linux Fsfreeze sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.