Opslag en back-up¶

Machinevertaling van het Franse origineel.

De Obsidian-vault en zijn vijf kopieën¶

De Obsidian-vault is het geschreven geheugen van het park. Er zijn vijf exemplaren, waarvan slechts één de waarheid vertegenwoordigt.

Locatie	Pad	Status
NAS Synology	`/volume3/obsidian/homelab-vault`	Bron van waarheid (SSD)
vm-claude	`/home/<user>/homelab-vault`	NFS-mount van de bron
vm-docker	`/docker-mounts/homelab-vault`	NFS-mount van de bron
Mac	`~/homelab-vault`	Syncthing-replica
iOS	—	Remote opslaan 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

De twee NFS-mounts zijn geen kopieën: het schrijven vanaf vm-claude of vm-docker, is het schrijven naar de NAS. De Mac heeft daarentegen een echte replica, wat leidt tot het tijdsverschil hieronder.

Een NFS-schrijf is niet zichtbaar voor de inotify van de NAS

Een bestand dat vanaf vm-claude of vm-docker wordt geschreven, verschijnt niet in Obsidian op de Mac, maar pas na ongeveer twee minuten: Syncthing ziet het evenement niet, het wacht op zijn periodieke scan. Om dit te forceren:

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

Data van containers¶

Er zijn twee regimes, afhankelijk van wat de service doet met zijn schijf:

Lokale mount (bind mount)NFS-mount

Voor alles wat willekeurig wordt gelezen en een slot vasthoudt: PostgreSQL, Redis, zoekindex.

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

Een basis op NFS kan uiteindelijk zijn logbestand corrumperen of vastlopen op een slot dat de server nooit vrijgeeft.

Voor grote volumes die sequentieel worden gelezen: media, documenten, foto's.

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

De snelheid blijft behouden, en de data blijft intact na het verlies van de host.

Wat het opslag onbetrouwbaar maakt¶

De virtuele schijf van vm-docker heeft een gemiddelde leesduur van ongeveer 1,4 ms. Met 80 containers die tegelijk starten, stijgt de belasting tot 85 – dit is een kwestie van I/O, niet van de CPU. Dit verklaart de vertraging die beschreven wordt in Levenscyclus van een stack.
Een nachtelijke schijffout lijkt niet op een normale schijffout. Het manifesteert zich in i/o timeout en netwerkproblemen. Op 24 augustus 2026 heeft het een fout veroorzaakt in het ext4-logbestand van /opt/docker.

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