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

Restauration rest Décidé

Quatre modes servis par un seul moteur, une reprise qui n'est que le scan à l'envers, des écritures atomiques, un plan de téléchargement groupé par segment — et un principe : le snapshot est une entrée non fiable.

En clair — l'album photo, pas la pile de calques Les backups traditionnels empilent un « full » puis des incréments : pour retrouver le 12 mars, on repart du full et on rejoue 40 diffs — long, fragile, et si un calque de la pile est abîmé, tout ce qui suit est perdu. Cairn range des pages d'album : chaque snapshot est une photo complète de la machine (la racine pointe vers un arbre entier — les pages partagent leurs photos en coulisse via la dédup, donc l'album ne grossit presque pas). Restaurer le 12 mars = ouvrir l'album à la page du 12 mars. Le « point-in-time » n'est pas une fonctionnalité, c'est la construction même.

Ce que l’architecture donne gratuitement

  • Chaque snapshot est un « full » logique — aucune chaîne à rejouer, on choisit une racine et on descend le DAG.
  • Restaurer, c'est vérifier. Chaque adresse est le hash du contenu chiffré, chaque déchiffrement valide le tag AEAD : un chunk corrompu, tronqué ou substitué est détecté mécaniquement, pas par bonne volonté. Un restore --dry-run qui n'écrit rien = le test de vérification de la section M, gratuit.

Décision 1 — Quatre modes, un seul moteur

Restauration complète, partielle (un sous-arbre, une sélection), un fichier, ou une plage d’octets d’un fichier — les quatre sont le même algorithme : descendre le DAG en n’ouvrant que les branches demandées. Pour la plage, la somme préfixe des len du manifeste donne directement quels chunks couvrent les octets voulus (seek) : restaurer 100 Mo au milieu d’une image disque de 2 To ne télécharge que ~50 chunks, pas le fichier.

Décision 2 — La reprise, c’est le scan à l’envers

En clair — le déménageur qui coche sa liste Restauration interrompue au carton 80 000 sur 100 000 : on ne redéménage pas tout. Le déménageur repasse avec sa liste et coche ce qui est déjà en place — bon carton, bonne pièce, bon état — et ne transporte que ce qui manque. Or cette « liste à cocher », on l'a déjà construite : c'est la marche fusionnée du scan, utilisée à l'envers.

Le moteur de comparaison du backup (arbre du snapshot ↔ disque local) sert dans les deux sens : au backup, ce qui diffère monte ; à la restauration, ce qui diffère descend. Conséquences :

  • Reprise après crash = relancer la même commande — le re-run est idempotent, les fichiers déjà restaurés (présents et conformes) sont sautés.
  • Mode « synchroniser » gratuit — ramener un dossier à l'état exact d'un snapshot, en ne touchant que ce qui a dévié.
  • Un seul moteur à écrire, tester et durcir, pour les deux directions.

Décision 3 — Écriture atomique, métadonnées en dernier

Jamais de demi-fichier sous son nom final. Chaque fichier est écrit dans un temporaire puis basculé d’un rename() atomique — un crash en pleine restauration laisse des brouillons identifiables, jamais un fichier final corrompu. Et l’ordre des finitions compte :

  • contenu → xattrs/ACL → permissions → timestamps en dernier (sinon la pose des attributs les modifierait) ;
  • mtimes des répertoires en post-order — écrire les enfants modifie le mtime du parent, donc on date le parent après ses enfants ;
  • liens durs : première occurrence = contenu, suivantes = lien ;
  • propriétaires : au choix par uid/gid numériques ou par noms (on stocke les deux) — indispensable quand on restaure sur une autre machine où « l'utilisateur 1000 » n'est pas le même.

Décision 4 — Le plan de téléchargement

En clair — les courses par rayon, pas dans l'ordre de la recette La recette dit « farine, puis beurre, puis encore de la farine » : personne ne traverse le magasin trois fois. On lit toute la recette, on regroupe la liste par rayon, et on fait un seul passage. Restaurer fichier par fichier, c'est suivre la recette : des allers-retours partout dans l'entrepôt (le point douloureux de restic). Cairn lit d'abord tous les manifestes, regroupe les chunks par segment, et télécharge dans l'ordre des caisses.

Concrètement, une restauration de 1 To ≈ 500 000 chunks éparpillés. La phase de plan collecte toutes les adresses, les trie par (segment, offset) → le serveur lit ses segments quasi séquentiellement (les HDD adorent), le client réassemble. Et la dédup joue à l’envers : un chunk partagé par 50 fichiers est téléchargé une fois, écrit 50 fois — cache éphémère de session, même contrat que celui du scan (optionnel, jetable).

Décision 5 — Le snapshot est une entrée non fiable

L'étiquette piégée — à ne jamais suivre aveuglément Un arbre corrompu — ou forgé — peut contenir un nom de fichier ../../etc/passwd, ou un lien symbolique vers l'extérieur suivi d'écritures « à travers » le lien. Suivre ces étiquettes aveuglément = écrire hors du répertoire cible — la famille de CVE « path traversal » qui a mordu tar et restic. Règles gravées : noms validés (pas de séparateur, pas de .., noms réservés Windows rejetés), symlinks jamais suivis pendant la création (O_NOFOLLOW / RESOLVE_BENEATH), et toute violation arrête la restauration avec un diagnostic — pas un warning qu'on scrolle.

Décision 6 — Politiques de collision

Restaurer vers l’emplacement d’origine ou ailleurs ; si un fichier existe déjà : skip, overwrite ou newer-only — l’overwrite étant sûr par construction (temp + rename). Défaut non destructif : restauration dans un sous-dossier daté (restore-2026-07-02/) ; écraser en place est un choix explicite, jamais une surprise.

Plus tard (noté, pas conçu) : monter un snapshot en lecture seule comme un disque (FUSE / WinFsp), avec téléchargement paresseux — parcourir « le NAS d’il y a trois semaines » dans l’explorateur de fichiers avant de choisir quoi restaurer. Servira l’UI de restauration de la section H.