Aller au contenu

Stockage et vault

Le vault Obsidian et ses cinq copies

Le vault est la mémoire écrite du parc. Il existe en cinq exemplaires, dont un seul fait foi.

Emplacement Chemin Statut
NAS Synology /volume3/obsidian/homelab-vault Source de vérité (SSD)
vm-claude /home/<user>/homelab-vault Montage NFS de la source
vm-docker /docker-mounts/homelab-vault Montage NFS de la source
Mac ~/homelab-vault Réplique Syncthing
iOS — Remotely Save via WebDAV 
flowchart LR
    subgraph source["Source de vérité"]
        nasv["NAS · SSD<br/>/volume3/obsidian/homelab-vault"]
    end

    vmc["vm-claude<br/>/home/<user>/homelab-vault"]
    vmd["vm-docker<br/>/docker-mounts/homelab-vault"]
    mac["Mac · Obsidian<br/>~/homelab-vault"]
    ios["iOS<br/>Remotely Save"]

    vmc ---|"NFS — montage, pas une copie"| nasv
    vmd ---|"NFS — montage, pas une copie"| nasv
    nasv ---|"Syncthing — vraie réplique"| mac
    nasv ---|"WebDAV"| ios

    vmc -.->|"écriture invisible<br/>pour l'inotify"| nasv

    classDef truth stroke-width:3px
    class nasv truth

Les deux montages NFS ne sont pas des copies : écrire depuis vm-claude, c'est écrire sur le NAS. Le Mac, lui, détient une vraie réplique — d'où le décalage ci-dessous.

Une écriture NFS est invisible pour l'inotify du NAS

Un fichier écrit depuis vm-claude ou vm-docker n'apparaît pas dans Obsidian sur le Mac avant environ deux minutes : Syncthing ne voit pas passer l'événement, il attend son balayage périodique. Pour forcer :

curl -s -X POST -H "X-API-Key: $STKEY" \
  "http://nas:8384/rest/db/scan?folder=homelab-vault"

Données des conteneurs

Deux régimes, choisis selon ce que le service fait de son disque :

Pour tout ce qui écrit en accès aléatoire et tient un verrou : PostgreSQL, Redis, index de recherche.

volumes:
  - /opt/docker/<stack>/data:/var/lib/postgresql/data

Une base sur NFS finit par corrompre son journal ou par bloquer sur un verrou que le serveur ne rend jamais.

Pour les gros volumes lus séquentiellement : médias, documents, photos.

volumes:
  - /docker-mounts/medias:/medias

Le débit tient, et les données survivent à la perte de l'hôte.

Ce qui rend le stockage fragile

  • Le disque virtuel de vm-docker plafonne à ~1,4 ms par lecture aléatoire. Avec 80 conteneurs qui démarrent ensemble, la charge monte à 85 — c'est de l'attente d'E/S, pas du CPU. C'est la raison du démarrage étalé décrit dans Cycle de vie d'un stack.
  • Une panne disque nocturne ne ressemble pas à une panne disque. Elle se présente en i/o timeout et en erreurs réseau. Le 2026-08-24, elle a avorté le journal ext4 de /opt/docker.

Dernière vérification de cette page : 2026-09-08