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

Scan & détection de changements scan Décidé

Savoir quels fichiers ont changé sans base locale et sans relire des téraoctets chaque nuit : l'arbre du snapshot parent sert d'état de référence, une marche fusionnée compare les métadonnées, et seuls les fichiers modifiés sont relus. Vite, mais jamais faux.

En clair — l'inventaire comparé Chaque nuit, l'inventoriste refait le tour de l'entrepôt. Méthode naïve : rouvrir chaque carton et tout recompter — des heures. Méthode intelligente : prendre l'inventaire de la veille et longer les étagères en le comparant — même étiquette, même poids, même date sur le carton ? On ne l'ouvre pas, on recopie la ligne d'hier. Seuls les cartons dont l'étiquette a bougé sont rouverts. Toute la page décrit cette comparaison — et les pièges qui feraient recopier la ligne d'un carton qui a en réalité changé.

L’état de référence : l’arbre du snapshot parent

Le client est stateless — aucune base locale requise. Son état de référence, c’est l’arbre du snapshot précédent, téléchargé au début du backup : la racine, puis les nœuds répertoire (petits, servis depuis les segments métadonnées SSD — le stockage a été conçu pour exactement ce chemin). L’état vit chez le serveur, chiffré ; le client ne fait que l’emprunter le temps du backup.

La marche fusionnée

On parcourt en parallèle le système de fichiers local et l’arbre parent, répertoire par répertoire, dans l’ordre des noms — et la décision « entrées triées par nom » paie ici : comparer deux listes triées se fait en un seul passage, mémoire bornée à la profondeur du chemin, aucun arbre entier en RAM.

# pour chaque répertoire, deux listes triées côte à côte
présent des deux côtés → comparer les métadonnées # inchangé ? → copier la référence
présent seulement en local → nouveau fichier # chunker, chiffrer, uploader
présent seulement dans l'arbre parent → supprimé # absent du nouveau snapshot

Fichier inchangé → zéro lecture. On copie la référence (addr, clé) de son manifeste depuis l’entrée parente, sans même ouvrir le manifeste. Un backup incrémental d’un NAS calme = une promenade de métadonnées plus quelques fichiers relus.

Décision 1 — L’heuristique « inchangé »

En clair — contrôler la carte d'identité, pas refaire l'interrogatoire Relire un fichier de 10 Go pour vérifier qu'il n'a pas changé, c'est refaire l'interrogatoire complet. Comparer sa taille, sa date de modification et son numéro d'inode, c'est contrôler la carte d'identité : quasi instantané, et fiable — sauf faux papiers. Le reste de la page traite précisément des faux papiers.

Le verdict « inchangé » s’appuie sur taille + mtime + ctime + inode quand ils sont disponibles et fiables — le même trio que restic, borg et kopia, renforcé du ctime. Chaque champ a son rôle et ses pièges :

  • taille + mtime — le socle. Pièges : mtime est falsifiable (touch -t), certains outils le préservent en changeant le contenu, et sa granularité peut être grossière (FAT : 2 s).
  • ctime — le garde-fou : non falsifiable sous Linux (aucune API pour le forcer), il trahit les modifications à mtime préservé et les changements de métadonnées.
  • inode — attrape le fichier remplacé par un autre de même taille et même date. Piège : instable sur certains FS réseau/FUSE → ignoré là où il ment.
  • Dégradation par système de fichiers — le client sait quels champs sont fiables sur quel FS et ajuste : pas d'inode sur tel montage réseau, granularité 2 s sur FAT, etc.

Décision 2 — La fenêtre d’instabilité

Le piège classique — le fichier modifié pendant qu'on le lit Un fichier modifié pendant sa lecture peut être capturé incohérent — moitié ancienne version, moitié nouvelle. Pire : si sa date de modification tombe dans la même seconde que le scan, le backup suivant le jugera « inchangé » et recopiera pour toujours la version incohérente. borg s'y est brûlé. Parade en deux temps : stat avant lecture, re-stat après — s'il a bougé entre les deux, on le relit ou on le marque instable ; et tout fichier dont le mtime est trop proche de l'instant du scan est relu d'office au backup suivant, par principe.

Décision 3 — Les journaux OS : accélérateurs, jamais autoritaires

Certains systèmes tiennent un journal des changements : USN Journal sous Windows (fiable, éprouvé — il permet de sauter des sous-arbres entiers), FSEvents sous macOS (indices par répertoire), et rien de fiable sous Linux qui survive au reboot (inotify ne tient pas l’échelle).

Même principe que le bloom filter du stockage Un journal a le droit de dire « rien n'a bougé ici, saute » pour accélérer — jamais de servir de source de vérité. La marche de métadonnées reste le chemin canonique, et un scan complet périodique sert de filet de sécurité. Optimisation par plateforme, pas fondation : le jour où le journal ment (rotation, reboot, bug), le backup reste correct, juste moins rapide.

Décision 4 — La politique, en trois crans

  • fast (défaut) — l'heuristique métadonnées : confiance au trio taille + mtime + ctime/inode.
  • paranoid — en plus : relire un échantillon aléatoire des fichiers « inchangés » à chaque run (attrape les modifications à mtime préservé), et une relecture complète planifiée (p. ex. mensuelle). Se marie avec la vérification de restauration de la section M.
  • force — tout relire. Pour les audits et les doutes.

Décision 5 — Le cache éphémère local, enfin cadré

Télécharger l’arbre parent à chaque backup coûte un peu (quelques Mo à quelques centaines de Mo pour des millions de fichiers). Un cache local de l’arbre parent l’évite — à trois conditions qui préservent le contrat stateless :

  • Optionnel — tout fonctionne cache vide, rien n'en dépend.
  • Jetable — le supprimer ne casse rien, il se reconstitue au backup suivant.
  • Revalidé par adresse — le serveur annonce l'adresse de la racine du snapshot parent ; si le cache ne correspond pas, il est ignoré et re-téléchargé. Le serveur reste l'unique source de vérité.

Ça referme la note « cache éphémère local à cadrer » du sujet Client stateless.

Ce que ça donne, chiffré

NAS d’un million de fichiers, 0,5 % modifiés par nuit : la marche stat prend quelques minutes, ~5 000 fichiers sont relus et re-chunkés, le reste n’est que copies de références. Sans ce mécanisme : relecture de 4 To chaque nuit. Avec : quelques Go lus. C’est le multiplicateur de vitesse des backups quotidiens — et la raison d’être du choix stateless-mais-pas-lent.