Skip to content

Storage and Vault

Machine translation of the French original.

The Obsidian Vault and its Five Copies

The vault is the written memory of the park. There are five copies, and only one is considered authoritative.

Location Path Status
Synology NAS /volume3/obsidian/homelab-vault Source of truth (SSD)
vm-claude /home/<user>/homelab-vault NFS mount of the source
vm-docker /docker-mounts/homelab-vault NFS mount of the source
Mac ~/homelab-vault Syncthing replica
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

The two NFS mounts are not replicas: writing to vm-claude or vm-docker writes to the NAS. The Mac, on the other hand, holds a true replica – hence the delay below.

An NFS write is invisible to the NAS's inotify

A file written to from vm-claude or vm-docker does not appear in Obsidian on the Mac for about two minutes: Syncthing does not see the event, it waits for its periodic scan. To force:

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

Container Data

Two regimes, chosen depending on what the service does with its disk:

For anything that writes randomly and holds a lock: PostgreSQL, Redis, search indexes.

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

A database on NFS can eventually corrupt its log or get stuck on a lock that the server never releases.

For large volumes read sequentially: media, documents, photos.

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

The throughput is maintained, and the data survives the loss of the host.

What makes the storage fragile

  • The vm-docker virtual disk reaches ~1.4 ms per random read. With 80 containers starting simultaneously, the load increases to 85 – this is due to I/O latency, not CPU usage. This explains the staggered startup described in Lifecycle of a Stack.
  • A nighttime disk failure does not resemble a typical disk failure. It manifests as errors in i/o timeout and network issues. On August 24, 2026, it caused the ext4 journal in /opt/docker to fail.

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