Bidirektionale Synchronisation der Darktable-Datenbank und Fotobibliothek zwischen einem lokalen Linux-Rechner und einem Server (Synology NAS) via SSH.

Aktueller Stand

Die Skripte synchronisieren DB und Fotos mit Unison über SSH. Der Wrapper startet einen Pre-Sync vor und einen Post-Sync nach jedem Darktable-Start.

darktable_wrapper.sh   → Pre-Sync → Darktable starten → Post-Sync
darktable_sync.sh      → Unison-Sync (DB + Fotos, bidirektional)
darktable_common.sh    → Gemeinsame Hilfsfunktionen

Voraussetzungen: Unison (gleiche Version auf Client und Server), SSH-Key-Auth.

Architektur-Entscheidungsprotokoll

Dieses Dokument hält fest, welche Sync-Ansätze untersucht wurden und warum bestimmte Entscheidungen getroffen oder offengelassen wurden.

Problem 1: Upload-Delete-Safety (rsync --delete)

Das ursprüngliche System verwendete rsync --delete für den Foto-Upload. Das führt zu einem strukturellen Problem:

rsync kennt keinen Unterschied zwischen:

Datei lokal gelöscht → soll auch auf Server gelöscht werden ✓
Datei lokal nie vorhanden (weil ein anderer Client sie hochgeladen hat) → darf NICHT gelöscht werden ✗

Konkretes Beispiel: 2025-08_Nordkap_Handy/ existiert nur auf dem Server (von Smartphone hochgeladen), nicht auf dem Laptop. Beim nächsten Upload löscht rsync den gesamten Ordner vom Server — dauerhafter Datenverlust.

Erster Lösungsansatz: rsync-Manifest — eine Textdatei mit allen zuletzt synchronisierten Pfaden. Beim Upload: fehlt lokal + im Manifest → gelöscht → OK. Fehlt lokal + nicht im Manifest → nie synchronisiert → nicht löschen.

Verworfen, weil Unison dasselbe Problem architektonisch sauber löst: Unison pflegt intern Archive über den letzten Sync-Zustand und leitet daraus korrekt ab, ob eine fehlende Datei gelöscht oder nie vorhanden war.

Analyse der Sync-Alternativen

Unison (aktuell implementiert)

Vorteile:

Internes Archiv löst Upload-Delete-Safety nativ
Triggered Sync (kein Daemon) — passt zur Pre/Post-Sync-Architektur
Transport via SSH, kein zusätzlicher Dienst auf dem Server nötig
Bidirektionaler Sync in einem Aufruf pro Replica-Paar

Konfliktverhalten:

DB-Konflikte: bestehender Sync-Token-Dialog bleibt erhalten → User entscheidet (-force local / -force remote)
Foto-Konflikte: -prefer newer (neuere Datei gewinnt, kein Dialog)

Kritischer Nachteil: Synology-Installation Unison erfordert exakt die gleiche Version auf Client und Server — und nicht nur die Unison-Version, sondern auch die zugrundeliegende OCaml-Compiler-Version. Auf einer Synology NAS gibt es kein apt. Alle bekannten Anleitungen für Unison auf Synology (Stand 2025) stammen aus 2011–2021 und beschreiben aufwändige Cross-Compilation, die bei jedem DSM-Update erneut erforderlich wird. Entware könnte helfen, aber die Versionskompatibilität ist nicht garantiert. Unison auf Synology ist ein dauerhaftes Wartungsproblem.

Syncthing

Vorteile:

SynoCommunity bietet ein aktiv gepflegtes Paket für DSM 7.x (v2.0.14, Stand 2025) — einfache Installation über Package Center
Kein Versionszwang zwischen Nodes
Upload-Delete-Safety: Syncthing weiß aus seiner eigenen Datenbank, was es synchronisiert hat, und löscht nie Dateien anderer Devices
Transparente Konfliktbehandlung via .sync-conflict-...-Dateien
Eingebaute Versionierung (File Versioning)

Nachteil: Always-On-Daemon Syncthing läuft kontinuierlich. Das kollidiert mit der triggered-sync-Architektur (Pre/Post-Sync um Darktable herum). Das Pausieren via CLI ist technisch möglich (syncthing cli config folders <id> paused set true/false), macht die Wrapper-Logik aber komplexer.

Das SQLite-Problem: Darktable verwendet SQLite im WAL-Modus. Dabei entstehen drei Dateien: library.db, library.db-wal, library.db-shm. Syncthing synct auf Dateiebene ohne SQLite-Semantik zu verstehen. Bei aktivem Sync während Darktable läuft könnte eine inkonsistente DB-Kombination auf der anderen Seite ankommen. Ausserdem erzeugt SQLite-Checkpointing mtime-Updates ohne inhaltliche Änderung — das kann zu Falsch-Konflikten führen.

Lösung für das WAL-Problem: .db-wal und .db-shm via .stignore ausschließen. Dann synct Syncthing nur library.db, die nach Darktable-Beendigung immer konsistent ist (SQLite checkpointed beim Schließen).

Das eigentliche Konflikt-Problem: Wenn Darktable auf zwei Rechnern unabhängig voneinander läuft und beide eine divergierte library.db erzeugen, entsteht ein echter inhaltlicher Konflikt — den kein Sync-Tool automatisch auflösen kann (SQLite-Merging wäre dazu nötig). Syncthing macht diesen Konflikt mit einer .sync-conflict-Datei sichtbar, was ehrlicher ist als so zu tun, als könnte man ihn "lösen".

Gegenüberstellung

Kriterium	rsync (original)	Unison (aktuell)	Syncthing
Upload-Delete-Safety	✗ (Problem)	✓ (Archiv)	✓ (Device-DB)
Synology-Installation	einfach	sehr schwierig	einfach (SynoCommunity)
DB-Konflikt-Erkennung	Token + Dialog	Token + Dialog	.sync-conflict-Datei
DB-Konflikt-Auflösung	User entscheidet	User entscheidet	automatisch (neuere Datei)
Kein Daemon nötig	✓	✓	✗
Triggered Sync	✓	✓	nur mit Pause/Resume
Foto-Versioning	✗	Backup-Dir	✓ eingebaut

Offene Architekturentscheidung

Es stehen zwei grundlegend verschiedene Ansätze zur Wahl:

Option A: Script-System beibehalten (Unison)

Das bestehende System mit darktable_sync.sh bleibt, mit Unison als Sync-Engine. Voraussetzung: Unison muss auf der Synology NAS installierbar sein (Entware oder manuelles Binary). Der Workflow (Pre/Post-Sync, Token-Dialog, Active-Marker, Versions-Check) bleibt erhalten.

Offen: Ist Unison auf der DS234+ mit einer zum Client kompatiblen Version installierbar? Das muss praktisch getestet werden.

Option B: Vollständig auf Syncthing umstellen

Das gesamte Script-System entfällt. Syncthing übernimmt die Synchronisation dauerhaft. Der darktable_wrapper.sh entfällt oder wird auf Pause/Resume-Steuerung reduziert. Das Repo würde zu einem Setup-Guide mit .stignore-Template schrumpfen.

Vorteile: Kein eigener Code zu pflegen, bewährte Software, einfache Synology-Installation.

Nachteile: Kein expliziter Versions-Check (Darktable-Versionen müssen manuell übereinstimmen), kein Active-Marker (kein Schutz gegen gleichzeitige Nutzung auf mehreren Rechnern), Konflikte werden automatisch statt durch User-Entscheidung aufgelöst.

Empfohlene nächste Schritte

Testen: Ist Unison via Entware auf der DS234+ mit kompatibler Version installierbar?
- Falls ja → Option A ist machbar
- Falls nein → Option B (Syncthing) ist der pragmatische Weg
Bei Option B:
- Syncthing auf DS234+ via SynoCommunity installieren
- .stignore für *.db-wal, *.db-shm konfigurieren
- File Versioning in Syncthing aktivieren
- Unison-Migration (aktueller Branch) reverten

Installation (aktueller Stand: Unison)

Voraussetzung: Unison muss auf Client und Server installiert sein, exakt gleiche Version.

# Client (Ubuntu/Debian)
sudo apt install unison

# Server (Synology) — noch ungeklärt, siehe Architektur-Entscheidungsprotokoll oben

git clone https://gitea.troeger-net.org/martin/darktable-sync.git
cd darktable-sync
cp .env.example ~/.config/darktable-sync/.env
chmod 600 ~/.config/darktable-sync/.env
nano ~/.config/darktable-sync/.env
./install.sh

Konfiguration

Datei: ~/.config/darktable-sync/.env (Permissions: 600)

Variable	Bedeutung
`SERVER_IP`	IP oder Hostname des Servers
`SERVER_USER`	SSH-Benutzer auf dem Server
`SERVER_SSH_PORT`	SSH-Port (Standard: 22)
`SERVER_DB_DIR`	Pfad zur Darktable-DB auf dem Server
`SERVER_PHOTO_DIR`	Pfad zur Fotobibliothek auf dem Server
`LOCAL_DARKTABLE_DB_DIR`	Lokaler Darktable-DB-Pfad
`LOCAL_PHOTO_DIR`	Lokaler Fotobibliothek-Pfad

Lizenz

MIT

README.md Unescape Escape

darktable-sync