Datenbank und Schlüssel

Welche Datenbank wofür

Ablage	Konfiguration	Geeignet für
SQLite	DNSE_DB=./dnseditor.db (Vorgabe)	Einzelinstanz, Desktop, Test
PostgreSQL	DNSE_DB_DSN=postgres://…	Produktivbetrieb, Backups per pg_dump
YugabyteDB	DNSE_DB_DSN=… und DNSE_DB_YB=on	Mehrere Knoten, verteilter Betrieb

YugabyteDB spricht das PostgreSQL-Protokoll, braucht aber einen eigenen Treiber. Deshalb genügt der DSN allein nicht — ohne DNSE_DB_YB=on wird die Verbindung als gewöhnliches PostgreSQL behandelt.

Das Schema wird beim Start automatisch migriert. Laufen mehrere Knoten, führt der zuerst gestartete die Migration aus; die übrigen warten, bis das Schema passt.

Der Verschlüsselungsschlüssel

DNSE_ENCRYPTION_KEY schützt alles, was nicht im Klartext liegen darf: Provider-Zugangsdaten, private Zertifikatsschlüssel, SMTP-Passwort und 2FA-Geheimnisse. Die Datenbank enthält davon nur verschlüsselte Formen.

Daraus folgen drei Regeln:

1. Der Schlüssel gehört nicht in dieselbe Sicherung wie die Datenbank. Wer beides zusammen erbeutet, hat alles.
2. Ein Backup ohne Schlüssel ist wertlos. Vor dem ersten produktiven Start sichern und den Ablageort dokumentieren.
3. Alle Knoten brauchen denselben Schlüssel. Sonst kann Knoten 2 nicht entschlüsseln, was Knoten 1 geschrieben hat.

Sicherung

Bei PostgreSQL genügt der übliche Weg:

pg_dump -Fc dnseditor > dnseditor-$(date +%F).dump

Bei SQLite die Datei sichern, während der Dienst steht oder über sqlite3 dnseditor.db ".backup dnseditor-backup.db".

Für Wiederherstellungsproben gilt dasselbe wie überall: Eine Sicherung, die nie zurückgespielt wurde, ist keine.

Hinweis

Verlorene Provider-Zugangsdaten sind ärgerlich, aber nicht katastrophal — die Zonen liegen weiterhin beim Anbieter. Nach dem Wiederherstellen meldet der Abgleich alles, was seit dem Sicherungsstand beim Provider passiert ist, als Drift; über Übernehmen holt man den neueren Stand zurück.