Eine selbstgehostete Keyright-Instanz sichern und wiederherstellen

Ein Lizenzserver verdient sein Geld, indem er genau in dem Moment da ist, in dem ein Kunde aktiviert. Das macht seine Daten kostbar: Verlieren Sie die Aufzeichnung, wer lizenziert ist, welche Sitze beansprucht sind und wie viele Guthaben verbleiben, dann sind Sie nicht nur ausgefallen — Sie haben die Wahrheit verloren, von der die Installationen Ihrer Kunden abhängen. Sicherung und Notfallwiederherstellung für selbstgehostetes Keyright verdienen also denselben bewussten Entwurf, den Sie der Hochverfügbarkeit gegeben haben. Die gute Nachricht ist, dass dieselbe Architektur, die HV einfach macht, auch die DR einfach macht.

Kernaussage: Selbstgehostetes Keyright ist eine zustandslose App, deren gesamter Zustand in Ihrem PostgreSQL liegt — DR ist damit eigentlich Postgres-Sicherung/Wiederherstellung plus das Absichern zweier Geheimnisse, die Sie erzeugen. Sichern Sie die Datenbank für Ihren gesamten Zustand; sichern Sie Ihren KEYRIGHT_KEK und Ihren KEYRIGHT_SIGNING_KEY separat und sicher — denn ohne den KEK können die verschlüsselten Signierschlüssel in der Datenbank nicht wiederhergestellt werden.

Was wirklich gesichert werden muss

Keyright hat genau zwei bewegliche Teile: eine zustandslose App und Ihre Datenbank. Diese Aufteilung ist die ganze Sicherungsgeschichte.

Die App ist das Image ghcr.io/delta1-labs/keyright — ein ASP.NET-Core-Dienst auf Port 8080, ohne Datenbank darin. Es hält zwischen Anfragen keinen Zustand. In dem App-Container gibt es also nichts zu sichern: Er wird aus dem veröffentlichten Image plus Ihrer Konfiguration und Ihren Umgebungsvariablen rekonstruiert. Verschwindet ein Knoten, eine VM oder ein ganzer Cluster, rollen Sie dasselbe Image neu aus, und es kommt identisch zurück. Behandeln Sie die App-Schicht als Vieh, nicht als Haustiere.

Alles, was zählt, liegt in PostgreSQL. Lizenzen, Aktivierungen und Sitze, Guthabenstände und ihr Hauptbuch, das Audit-Log, der Zustand von Webhooks und Benachrichtigungen, Ihre Mandanten- und Produktkonfiguration — und die Signierschlüssel, verschlüsselt im Ruhezustand gespeichert. Sie richten die App mit der Verbindungszeichenfolge KEYRIGHT_DB darauf, und sie erstellt und migriert ihr eigenes Schema. Weil sich aller dauerhafte Zustand in einer Datenbank konzentriert, ist das Sichern von Keyright das Sichern dieser Datenbank. Es gibt keinen verstreuten Dateizustand, keinen knotenlokalen Wahrheits-Cache, nichts auf irgendeiner Platte, das eine Postgres-Sicherung verpassen würde.

Die zwei Geheimnisse, die eine Datenbanksicherung nicht enthält

Hier ist der Teil, der die Leute erwischt, und das Wichtigste in diesem Beitrag. Zwei Geheimnisse sind Ihre — Sie erzeugen sie, Keyright sieht sie nie — und sie sind nicht aus einer Datenbanksicherung rekonstruierbar:

• KEYRIGHT_KEK — ein Schlüssel-Verschlüsselungsschlüssel von 32 Byte in base64. Er verschlüsselt Ihre Signierschlüssel im Ruhezustand, was genau der Grund ist, warum diese Schlüssel sicher in der Datenbank liegen können. Die Kehrseite: Ohne den KEK können die verschlüsselten Signierschlüssel in Ihrer Datenbank nicht wiederhergestellt werden. Ein perfekter Datenbank-Snapshot plus ein verlorener KEK ergibt eine Instanz, die ihre eigenen Signierschlüssel nicht mehr entschlüsseln kann — sie kann jede Zeile wiederherstellen und dennoch kein einziges Lease mit dem ursprünglichen Schlüssel signieren. Jeder Client, der den passenden öffentlichen Schlüssel gepinnt hat, würde dann neue Leases ablehnen.
• KEYRIGHT_SIGNING_KEY — der private RSA-PKCS#8-Schlüssel in base64, der Offline-Leases und air-gapped-Guthabenblöcke signiert und dessen öffentliche Hälfte die Apps Ihrer Kunden einbetten. Wenn Sie ihn ausdrücklich setzen (empfohlen), ist er Teil Ihrer Konfiguration, nicht etwas, das Sie ohne erneutes Pinnen öffentlicher Schlüssel in jedem ausgelieferten Client neu erzeugen können.

Die Regel also, direkt aus der Konfigurationsreferenz: Sichern Sie den KEK und den Signierschlüssel getrennt von der Datenbank und sicher — in einem Secrets-Manager mit eigener Sicherung, einem Offline-Tresor, wo auch immer Ihre Organisation Geheimnisse auf Root-Ebene aufbewahrt. Nie in der Datenbank, die Sie schützen, nie im Image, nie in der Versionskontrolle. Eine Datenbanksicherung und der KEK sind zwei Hälften einer einzigen wiederherstellbaren Sicherung; bewahren Sie sie an verschiedenen Orten auf, aber bewahren Sie beide auf.

Die Datenbank sichern

Alles liegt in PostgreSQL, nutzen Sie also Standard-Postgres-Werkzeuge. Für die meisten Deployments ist ein geplanter logischer Dump der einfachste korrekte Ansatz:

pg_dump --format=custom --no-owner \
  "host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
  --file "keyright-$(date +%F).dump"

Das Custom-Format stellt sich sauber mit pg_restore wieder her und komprimiert gut. Führen Sie es per Timer aus (cron, ein Sidecar-Job, Ihr verwalteter Scheduler), kopieren Sie jeden Dump außer Haus in Objektspeicher und wenden Sie eine Aufbewahrungsrichtlinie an. Prüfen Sie, dass die Datei nicht leer und wiederherstellbar ist — eine ungetestete Sicherung ist eine Hoffnung, kein Plan.

Für eine größere Instanz oder eine engere RPO ergänzen Sie physische Sicherungen mit Point-in-Time-Recovery (PITR). Nehmen Sie eine Basissicherung und archivieren Sie das WAL, damit Sie bis zu jedem Moment vorrollen können:

pg_basebackup --pgdata=/backup/base --format=tar --gzip \
  --wal-method=stream --checkpoint=fast

Mit konfigurierter WAL-Archivierung lässt PITR Sie bis zu einem gewählten Zeitstempel wiederherstellen — unschätzbar, wenn eine fehlerhafte Migration oder ein Bedienfehler bis zur Sekunde vor seinem Eintreten rückgängig gemacht werden muss.

Wenn Sie verwaltetes Postgres betreiben — was Sie für alles jenseits der Evaluierung tun sollten, mit einer Primär-plus-Standby-Topologie — stützen Sie sich auf dessen automatische Snapshots und Sicherungsaufbewahrung. Ein täglicher (oder häufigerer) Snapshot plus das PITR-Fenster des Anbieters gibt Ihnen meist eine stärkere RPO als selbstgebaute Dumps, und das Wiederherstellen ist eine Konsolen- oder CLI-Operation. In jedem Fall gilt dasselbe Prinzip: Die Datenbank ist der Ort, an dem jedes Byte Zustand liegt, also ist die Datenbank das, in dessen Schutz Sie investieren. Verlassen Sie sich nicht auf das mitgelieferte Evaluierungs-Postgres, das die Kits anbieten — es dient dazu, Keyright auf einem Laptop auszuprobieren, nicht der DR in Produktion.

RPO und RTO für einen Lizenzserver

Denken Sie die beiden Zahlen ausdrücklich durch, denn ein Lizenzserver hat ein ungewöhnlich nachsichtiges Ausfallprofil.

Ihre RPO (wie viele Daten Sie verlieren dürfen) bestimmt Ihre Sicherungskadenz. Ein nächtliches pg_dump riskiert, bis zu einen Tag Aktivierungen, Guthaben-Ausgaben und Audit-Datensätze zu verlieren; kontinuierliche WAL-Archivierung oder häufige verwaltete Snapshots grenzen das auf Minuten ein. Wählen Sie die Kadenz danach, wie viel Aktivierungs- und Hauptbuch-Historie Sie bereit sind, erneut abzuspielen oder zu verlieren.

Ihre RTO (wie lange die Wiederherstellung dauert) ist der Punkt, an dem sich die Architektur auszahlt. Weil Clients ein signiertes Lease zwischenspeichern und offline zwischen Aktivierungen validieren, sperrt ein Ausfall niemanden in dem Augenblick aus, in dem er beginnt — ihre Kulanzfenster fangen ihn auf. Sie laufen gegen das längste Client-Kulanzfenster, nicht gegen eine Stoppuhr bei jedem App-Start. Das verwandelt „eine Datenbank wiederherstellen und einen zustandslosen Container neu ausrollen” von einem hektischen Sekundengerangel in eine wohlbemessene Operation, die Sie richtig machen können. (Und wenn Sie zusätzlich Mehrknoten-HV betreiben, werden Routineausfälle überhaupt nie zu einem Wiederherstellungsereignis.)

Die Wiederherstellungsübung

Üben Sie das, bevor Sie es brauchen. Eine Wiederherstellung hat vier Schritte:

1. Stellen Sie die Datenbank wieder her. Aus einem logischen Dump in eine frische, leere Datenbank:

   pg_restore --no-owner --clean --if-exists \
     --dbname="host=db.internal.example.com port=5432 dbname=keyright user=keyright_app sslmode=require" \
     keyright-2026-11-04.dump

   Aus einem verwalteten Snapshot oder PITR stellen Sie über Ihren Anbieter bis zum gewünschten Punkt wieder her und notieren die neue Verbindungszeichenfolge.

2. Rollen Sie die zustandslose App neu aus, über KEYRIGHT_DB auf die wiederhergestellte Datenbank gerichtet. Geben Sie denselben KEYRIGHT_KEK und KEYRIGHT_SIGNING_KEY aus Ihrer separaten Geheimnis-Sicherung — das ist der Moment, in dem der KEK sein Geld verdient, indem er die Signierschlüssel entschlüsselt, die die Wiederherstellung zurückgebracht hat. Migrationen werden beim Start automatisch angewendet, es gibt also kein manuelles SQL.

3. Installieren Sie den Selbstlizenz-Schlüssel. Keyright ist fail-closed: Es braucht einen gültigen Selbstlizenz- (oder Test-)Schlüssel, um überhaupt Verkehr zu bedienen. Setzen Sie KEYRIGHT_SELF_LICENSE (derselbe Schlüssel läuft auf jedem Knoten) und starten Sie die App. Ohne ihn gibt jede Anfrage 402 zurück, so sauber die Datenbank-Wiederherstellung auch war.

4. Prüfen Sie. Zwei Kontrollen bestätigen eine gute Wiederherstellung:

   • GET /health/ready gibt 200 zurück — die App ist in Betrieb und hat die wiederhergestellte Datenbank erreicht (sie gibt 503 zurück, solange Postgres nicht erreichbar ist).
   • GET /admin/self-license meldet Ihre Edition und eine aktive Phase — die Selbstlizenz hat gegriffen und die Instanz bedient, ist nicht gesperrt.

   Machen Sie dann einen Rauchtest eines echten /v1/validate gegen eine bekannte Lizenz, um zu bestätigen, dass der wiederhergestellte Signierschlüssel weiterhin Leases erzeugt, die Ihre Clients akzeptieren.

Bestehen alle vier, sind Sie mit intaktem Zustand zurück auf dem Aktivierungspfad.

Betten Sie es in den Betrieb ein

Sichern Sie die Datenbank in einer Kadenz, die zu Ihrer RPO passt, bewahren Sie KEK und Signierschlüssel dort auf, wo Sie sie nicht verlieren, und proben Sie die Wiederherstellung, damit das erste Mal, dass Sie sie ausführen, nicht während eines Vorfalls ist. Der Betriebsleitfaden enthält die Details zu Sicherung und Update, und weil Keyright in beiden Deployment-Modi ein einziges Produkt ist, hält dieselbe Form aus zustandsloser App plus Ihrer Datenbank, ob Sie einen Knoten oder drei betreiben. Selbstgehostetes Keyright wird pro Deployment über Standard, Pro und Enterprise lizenziert — siehe die Preise — aber die DR-Disziplin ist auf jeder Stufe dieselbe: Schützen Sie die Datenbank, schützen Sie die zwei Geheimnisse, und üben Sie, beide zurückzuholen.