Backup und Restore

Drei Ebenen

Ebene	Umfang	Werkzeug
Infrastruktur	ganzer Cluster	Datenbank-Snapshots des Betreibers
Mandant	eine Organisation	nächtlicher Export (siehe unten)
Zone	eine Domain	Zeitreise-Restore (EE)

Keine Ebene ersetzt eine andere: Ein Cluster-Snapshot hilft nicht, wenn ein einzelner Mandant sich etwas zerschossen hat, und ein Zonen-Restore hilft nicht bei einem Datenbankausfall.

Mandanten-Export

Mit gesetztem DNSE_BACKUP_DIR läuft ein nächtlicher Job, der je Organisation einen vollständigen logischen Export schreibt (JSON Lines, inklusive Historie). Geschrieben wird atomar, damit ein abgebrochener Lauf nicht als Wiederherstellungspunkt auftaucht.

DNSE_BACKUP_DIR=/var/lib/dnseditor/backups

Die Aufbewahrung ist rollierend: Punkte, die älter als 35 Tage sind, werden beim nächsten Lauf entfernt.

Verschlüsselt auf der Platte

Der Export entschlüsselt die Felder der Datenbank — er soll ja wiederherstellbar sein. Damit lägen Provider-Zugangsdaten, private Zertifikatsschlüssel und TOTP-Geheimnisse im Klartext neben der Datenbank, geschützt nur durch Dateirechte. Seit Runde 105 wird der Strom deshalb beim Schreiben versiegelt: AES-256-GCM, derselbe Schlüssel wie für die Felder (inklusive Rotation über die Schlüssel-ID), in Rahmen zu 64 KiB.

Erkennbar ist das am Namen: neue Punkte heißen …jsonl.enc, ältere …jsonl. Beide bleiben gültige Wiederherstellungspunkte — der Wechsel entwertet keinen Bestand. Beim Herunterladen liefert der Server den entschlüsselten Strom (die Verschlüsselung schützt die Datei auf dem Server, nicht vor dem Administrator, dem die Daten gehören).

Jeder Rahmen trägt seine laufende Nummer, der letzte eine Endemarke. Eine abgeschnittene oder veränderte Datei wird deshalb abgelehnt, statt einen halben Mandanten wiederherzustellen.

Sicherungen aus der Zeit davor versiegelt ein einmaliger Lauf nach:

systemd-run --unit=dnse-backup-seal --wait \
  --property=EnvironmentFile=/etc/dnseditor-cloud/env \
  --property=User=dnseditor-cloud \
  /usr/bin/dnseditor-cloud backup-seal

Ob der Bestand lesbar ist, beantwortet der Gegenprobe-Lauf — er öffnet jeden Punkt und liest ihn vollständig:

systemd-run --unit=dnse-backup-verify --wait \
  --property=EnvironmentFile=/etc/dnseditor-cloud/env \
  --property=User=dnseditor-cloud \
  /usr/bin/dnseditor-cloud backup-verify

Der Befehl braucht weder Datenbank noch laufenden Dienst, überspringt bereits versiegelte Punkte und ist wiederholbar. Was er nicht kann: die alten Dateien sicher überschreiben — auf einem journalenden Dateisystem kann der Inhalt in freien Blöcken stehen bleiben. Wer das ausschließen muss, braucht Verschlüsselung auf Datenträgerebene.

In der Produktion zeigt das Verzeichnis auf den Objektspeicher der jeweiligen Heimat-Region — ein EU-Backup bleibt damit in der EU.

Wiederherstellungspunkte

Sichtbar an zwei Stellen:

Mandanten-Admin — Administration → Sicherung. Die Selbstbedienung ist eine Produkt-Funktion des Plan-Features org-backup (Standard: Enterprise). Gesichert wird unabhängig davon jede Organisation — das Feature steuert nur, wer die Punkte selbst sieht und eine Wiederherstellung anfragen kann.
Operator — im Mandanten-Detail, für jede Organisation und jeden Plan, zusätzlich mit Jetzt exportieren und Herunterladen je Punkt.

Restore anfordern

Eine Wiederherstellung durchläuft bewusst mehrere Hürden:

Namen eintippen. Der Name der Organisation muss zur Bestätigung eingegeben werden.
Sicherheits-Export. Unmittelbar vorher wird der Ist-Zustand exportiert — damit ist der Restore selbst umkehrbar.
Protokoll. Jede Anfrage wird mit Zeitpunkt, Auslöser und Zielpunkt festgehalten.
Cooldown. Innerhalb von 15 Minuten wird keine zweite Anfrage angenommen.

Ausführung

Nach den Hürden führt die Wiederherstellung aus (tenants.Import, seit Runde 83): Die Organisation wird archiviert (Schreibzugriffe abgewiesen), der gewählte Punkt ersetzt den Bestand vollständig, danach ist sie wieder aktiv. Dabei gilt:

Geheimnisse und personenbezogene Daten werden mit dem aktuellen Schlüssel neu verschlüsselt — seit v28 zählen dazu auch E-Mail-Adressen, Klarnamen und die Billing-Stammdaten samt Rechnungs-PDFs; die Login-Indizes (Blind-Index über E-Mail bzw. Benutzername) werden beim Import neu berechnet.
Abgeleitete Sichten werden aus den importierten Ereignissen neu projiziert — nur so ist das Ergebnis garantiert konsistent.
Geo: Es gilt die aktuell erklärte Heimatregion der Organisation — nach einem Umzug landet die Wiederherstellung in der neuen Region, nicht dort, wo der Export einst lag.
Abbruch: Die Organisation bleibt erkennbar unvollständig (Schreibzugriffe scheitern mit klarer Meldung) statt still halb gefüllt; eine wiederholte Anfrage räumt auf und setzt neu auf — der Cooldown tritt für diesen Reparaturfall beiseite.
Fremder Schemastand wird mit Begründung abgelehnt, nie still eingespielt.

Schlüssel nicht vergessen

Ein Export ist ohne den zugehörigen DNSE_ENCRYPTION_KEY nicht wiederherstellbar. Bis Runde 105 stand dieser Satz hier zwar schon, stimmte aber nicht: die Exporte trugen die Nutzdaten im Klartext. Jetzt gilt er buchstäblich.

Daraus folgt beides:

Der Schlüssel gehört getrennt gesichert — nicht in dasselbe Verzeichnis, nicht in dieselbe Sicherung.
Er gehört wirklich gesichert. Wer ihn verliert, verliert mit der Datenbank auch jede Sicherung. Das ist kein neues Risiko, sondern ein ehrliches: eine Datenbank ohne ihren Schlüssel war schon vorher unlesbar.