Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Fichiers ouverts & verrouillés vss Décidé

Snapshot d'abord, sur chaque plateforme — VSS activé par défaut sous Windows, APFS sous macOS, btrfs/ZFS/LVM sous Linux — avec une échelle de dégradation propre, des hooks pour la cohérence applicative, et le niveau de cohérence réellement obtenu gravé dans chaque snapshot.

En clair — photographier une scène en mouvement Sauvegarder une machine vivante, c'est photographier une scène où tout bouge. Trois qualités de photo :

1. La photo prise pendant que tout bouge (lecture directe) — risque de flou : un fichier en cours d'écriture est capturé moitié ancienne version, moitié nouvelle.
2. Figer toute la scène au même instant (snapshot du système de fichiers) — la photo est nette et cohérente dans son ensemble : c'est exactement l'état qu'aurait laissé une coupure de courant. Les applications à journal (bases de données avec WAL) savent s'en remettre au démarrage. On dit crash-consistent.
3. Demander à tout le monde de prendre la pose (snapshot + quiescing) : les applications vident leurs tampons avant le cliché — la restauration ne nécessite aucune récupération. On dit app-consistent.

Cairn vise le niveau 2 partout par défaut, le niveau 3 là où c'est possible — et surtout, note sur chaque photo la qualité réellement obtenue.

Le problème — deux saveurs très différentes

  • Windows : le verrou. Les fichiers peuvent être verrouillés (sharing violations) — le PST Outlook ouvert, la base SQL : illisibles, point. Sans mécanisme dédié, le backup les saute entièrement.
  • Linux/macOS : la lecture déchirée. Pas de verrous obligatoires — tout se lit, mais un fichier en cours d'écriture donne une lecture déchirée (torn read) : la lecture « réussit », les données sont de la bouillie. Plus sournois que le verrou, car rien ne signale l'erreur.

Décision 1 — Snapshot d’abord, partout, avec échelle de dégradation

PlateformeMécanismeNotes
WindowsVSS, activé par défautL’agent est requester ; snapshot par volume ; restic ne le fait qu’en opt-in, on vise mieux
macOSSnapshot APFS (fs_snapshot_create)root + Full Disk Access requis
Linux — btrfsSnapshot de sous-volumeInstantané — cas Synology, mais root requis : en paquet non-root (nominal), c’est l’échelle de dégradation qui s’applique
Linux — ZFSSnapshot ZFSLe cas QNAP QuTS hero
Linux — LVMSnapshot LVMSi extents libres ; device-mapper gèle le FS automatiquement
Linux — ext4 nuaucun snapshot possible→ échelle de dégradation ci-dessous

Les fichiers sont lus depuis le snapshot (les chemins d’origine sont enregistrés, pas ceux du point de montage du snapshot), puis le snapshot est supprimé.

L'échelle de dégradation — jamais silencieuse Pas de snapshot possible (ext4 nu, VSS en échec) ? Lecture directe + le contrôle stat/re-stat du scan (N tentatives). Toujours instable ? Capturé quand même mais marqué « instable » dans le rapport — ou sauté, selon la config. Verrouillé Windows sans VSS ? Sauté et rapporté. La règle d'or s'applique telle quelle : dégrader oui, mentir jamais.

Décision 2 — La cohérence applicative : hooks autour de l’instant du snapshot

Sous Windows, les VSS writers font le travail : SQL Server, Exchange et tout l’écosystème Microsoft s’abonnent au freeze/thaw du service → app-consistency gratuite au moment du snapshot.

Sous Linux/macOS, pas de writers → hooks configurables pre-snapshot / post-snapshot : FLUSH TABLES WITH READ LOCK, quiesce applicatif, ou dump natif (pg_dump) vers un fichier qui sera sauvegardé.

En clair — on fige la pose, pas la journée Le point que tout le monde rate : les hooks encadrent l'instant du snapshot — quelques secondes — pas la durée du backup (des heures). La base de données prend la pose, clic, elle respire à nouveau ; le backup lit ensuite tranquillement la photo figée. Sans snapshot, il faudrait geler la base pendant tout l'upload — inacceptable, et c'est exactement pourquoi le snapshot est la fondation et pas une option.

Décision 3 — Le niveau de cohérence est une métadonnée du snapshot

Chaque racine de snapshot enregistre ce qui a été réellement obtenu : snapshot FS utilisé ou non (et lequel), hooks exécutés ou non, liste des fichiers instables ou sautés. À la restauration — et dans le dashboard — on sait si c’était app-consistent, crash-consistent ou best-effort. Prolongement direct de « ne jamais mentir » : la qualité de la photo est écrite au dos de la photo.

Décision 4 — Les échecs VSS sont la norme, pas l’exception

Les timeouts de writers VSS (fenêtre de freeze de 60 s, flush-and-hold de 10 s) sont le grand classique des backups Windows sur serveurs chargés (Exchange, SQL). Politique :

  • Dégrader + rapporter plutôt qu'échouer tout le backup — un poste de travail préfère un backup crash-consistent à pas de backup du tout.
  • Mode strict require-snapshot pour les serveurs où crash-consistent ne suffit pas : là, échec franc et alerte.
  • Hygiène des snapshots — suppression après backup, et détection des orphelins d'un run planté au démarrage suivant. Le snapshot LVM oublié qui se remplit jusqu'à figer le volume est un footgun célèbre ; un snapshot APFS/btrfs oublié épingle de l'espace disque en silence.

Deux renvois : tout ceci exige root/SYSTEM → sujet Forme (l’agent-daemon) ; et pour les VM, le proxy image-level de la section P contourne entièrement le problème — le snapshot se fait au niveau de l’hyperviseur, l’invité n’est même pas sollicité.